Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

["Alvaro Retana (aretana)" <[e-mail]>]

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)" <[e-mail]<mailto:[e-mail]>> 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.)