Hi Alvaro, thanks for the very clear clarification. Not sure if it’s just me or if that’s not clearly stated in the draft, but maybe it would be worth it double-checking.
Mirja > Am 17.01.2017 um 16:47 schrieb Alvaro Retana (aretana) <aret...@cisco.com>: > > Mirja: > > Hi! > > If an AS in the path doesn’t support BGPsec, then BGP goes back to “normal” > mode (as in before BGPsec), and the assurance that the “update propagated via > the sequence of ASes listed” is lost. In other words, from the origin AS to > the AS before the one not supporting BGPsec, we can still provide the > assurance, but not beyond that – so any AS including and beyond the one not > supporting BGPsec won’t be able to verify anything. > > Alvaro. > > > > >> On 1/17/17, 6:05 AM, "Mirja Kuehlewind (IETF)" <i...@kuehlewind.net> wrote: >> >> Hi Sriram, >> >> thanks for your reply. That’s all fine. I really didn’t expect any protocol >> changes at this late stage of the draft but wanted at least to know if these >> points were previously discussed. Also happy to see that some parts where >> discussed with Ross. >> >> One final question (related to point 4): What happens if one router on the >> path does not support/understand BGPsec? Sorry, if that is a stupid question >> but it’s still not fully clear to me from the draft… >> >> Mirja >>> … >>> > 4) section 8.1 says "the recipient of a valid BGPsec update message is >>> > assured that the update propagated via the sequence of ASes listed in the >>> > Secure_Path portion of the BGPsec_Path attribute." >>> > Is that true? It is assured that at least these ASes have been crossed >>> > but there might have been others on the path that did not sign the >>> > BGPsec_Path attribute, no? >>> >>> >>> [Sriram] Yes, it is true. Each AS in the path MUST sign to the next AS >>> (Target AS). Section 3.1 says: >>> >>> >>> The Secure_Path contains one Secure_Path Segment (see Figure 5) for >>> each Autonomous System in the path to the originating AS of the >>> prefix specified in the update message. >>> >>> >>> [Sriram] Also, Section 3.2 says: >>> >>> >>> A Signature_Block in Figure 6 has exactly one Signature Segment (see >>> Figure 7) for each Secure_Path Segment in the Secure_Path portion of >>> the BGPsec_Path Attribute. >>> >>> >>> >>> [Sriram] The following check listed in Section 5.2 make it clear as well: >>> >>> >>> 3. Check that each Signature_Block contains one Signature segment >>> for each Secure_Path Segment in the Secure_Path portion of the >>> BGPsec_Path attribute. (Note that the entirety of each >>> Signature_Block must be checked to ensure that it is well formed, >>> even though the validation process may terminate before all >>> signatures are cryptographically verified.) >>> >>> >> _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
