Hi Ben,
Sorry for the delay in responding.
Thank you for the review and very helpful comments.
Please see my responses inline below.
The changes mentioned below that reflect your comments/suggestions
are already incorporated in the forthcoming version-22.
>-2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized
> versions of 2119 words. This draft does not. It seems different 2119
> approaches among the various bgpsec draft could be confusing to the
> reader.
> [Update: Oops, sorry, I meant to say draft-ietf-sidr-bgpsec-ops excludes
> non-capitalized versions of 2119 words. (That is to say, it treats them
> as their normal English equivalents.)]
Thank you for pointing this out. I have gone over the whole document
and wherever the standards language [RFC 2119] is applicable,
I have made sure that upper case “MUST”, “SHOULD” etc. are used
rather than lower case “must”, “should” etc.
> - 5.2, step 2: I'm almost sure I've missed something here, but if I
> understand correctly, previous sections talked about how a peer can
> propagate a BGPsec_Path attribute without modification. Will that cause a
> problem in this step if the immediate peer propagated an unmodified
> BGPsec_Path that came from a different AS?
You are right in pointing this out. The key is that 5.2, step 2
check is meant to be done with eBGP peer (not iBGP).
Unmodified BGPsec update is sent only to
BGPsec-capable iBGP peers (internal peers).
In the case of an eBGP (BGPsec capable) peer, the BGPsec update is always
modified and propagated with a new Secure_Path Segment and Signature added.
So I have modified the wording in 5.2, step 2 to read as follows:
2. Check that AS number in the most recently added Secure_Path
Segment (i.e. the one corresponding to the eBGP peer from which
the update message was received) matches the AS number of that
peer as specified in the BGP OPEN message. (Note: This check is
performed only at an ingress BGPsec router where the update is
first received from a peer AS.)
>
> - 8.4, last paragraph: The text describes a replay attack, and delegates
> the mitigation solution to. This is an
> informational reference; it draft-ietf-sidr-bgpsec-rollover
>seems like it should be normative.
The solution for mitigation of replay attacks is out of band
(in relation to the BGPsec protocol).
As I see it, draft-ietf-sidr-bgpsec-rollover proposes 'a way'
of replay attack mitigation. Techniques for key rollover /
replay attack mitigation are expected to continue to evolve.
There are various variants of the basic key rollover technique that
are discussed in this informational draft:
https://tools.ietf.org/html/draft-sriram-replay-protection-design-discussion-07
What needs to be pointed out in the BGPsec specification is that
there are solutions available for replay attack mitigation.
The above are the reasons why
draft-ietf-sidr-bgpsec-rollover is included in informational references.
Sriram
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
