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

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Mirja,

>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.

The draft says the following which covey it (IMO):

Section 2.2, p.5

BGP update messages without the BGPsec_Path attribute MAY be
   sent within a session regardless of whether or not the use of BGPsec
   is successfully negotiated. 

#Sriram: BGP update messages without the BGPsec_Path attribute 
== Traditional BGP update message with AS_PATH
(I should make that substitution in the document for clarity.) 

Top of Section 4.4:

   BGPsec update messages do not contain the AS_PATH attribute.
   However, the AS_PATH attribute can be reconstructed from the
   BGPsec_Path attribute.  This is necessary in the case where a route
   advertisement is received via a BGPsec update message and then
   propagated to a peer via a non-BGPsec update message (e.g., because
   the latter peer does not support BGPsec).

Section 7, p 32. 

   How will migration from BGP to BGPsec look like?  What are the
   benefits for the first adopters?  Initially small groups of
   contiguous ASes would be doing BGPsec.  There would be possibly one
   or more such groups in different geographic regions of the global
   Internet.  Only the routes originated within each group and
   propagated within its borders would get the benefits of cryptographic
   AS path protection.  As BGPsec adoption grows, each group grows in
   size and eventually they join together to form even larger BGPsec
   capable groups of contiguous ASes.  The benefit for early adopters
   starts with AS path security within the contiguous-AS regions spanned
   by their respective groups.  Over time they would see those
   contiguous-AS regions grow much larger.

But I'll see if Alvaro's wording can be additionally 
folded into the document in an appropriate place.

Thank you.

Sriram

________________________________________
From: Mirja Kuehlewind (IETF) <[e-mail]>
Sent: Tuesday, January 17, 2017 10:52 AM
To: Alvaro Retana (aretana)
Cc: Sriram, Kotikalapudi (Fed); [e-mail]; Alexey Melnikov; [e-mail]; The IESG; [e-mail]; Matthias Waehlisch
Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

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