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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

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) <[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]> 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.)
>>>   
>>>   
>>