Hi Mirja,
>I actually might be mixing this up with some discussion about DNSsec a while
>ago, where the problem was that once enable others will remember that it was
>supported and will not accept non secured requests anymore.
>But as we are talking about this, could there be a similar case here, where a
>router is known to support BGPsec and others would ignore/drop non-signed
>announcements? (Sorry if that’s all discussed in the protocol doc; in this
>case just ignore my questions ;-); didn’t review the protocol spec yet but
>it’s the next doc on my list; probably should have read that one first…)
In BGPsec peering session, it is allowed to send signed updates for some
prefixes and
unsigned updates for other prefixes. This is necessary for backward
compatibility
and incremental deployment.
In this scenario,
AS1-----BGP(unsigned)-----------------AS3---------------BGPsec(signed)--------AS4
|
AS2----BGPsec(signed)--------------------
AS3 forwards to AS4 unsigned updates originated from AS1
and also forwards signed updates originated from AS2.
Just because an AS is known to support BGPsec, it is not required that it must
send only signed updates.
On the receive side, it would be purely a matter of local policy to prefer a
signed update
over an unsigned update for the same prefix or how to treat an unsigned update
in path selection process, etc.
Excerpt from Section 4.1 in the BGPsec protocol draft:
If a BGPsec router has received only a non-BGPsec update message
containing the AS_PATH attribute (instead of the BGPsec_Path
attribute) from a peer for a given prefix, then it MUST NOT attach a
BGPsec_Path attribute when it propagates the update message.
........
Conversely, if a BGPsec router has received a BGPsec update message
(with the BGPsec_Path attribute) from a peer for a given prefix and
it chooses to propagate that peer's route for the prefix, then it
SHOULD propagate the route as a BGPsec update message containing the
BGPsec_Path attribute.
Does this answer your question?
Thanks.
Sriram
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
