Re: [Gen-art] Gen-ART Last Call review of draft-ietf-idr-bgp-extended-messages-33

[Paul Kyzivat <[e-mail]>]

Randy,

On 7/4/19 2:28 PM, Randy Bush wrote:
> paul,
> 
> thanks for the review.  appreciated.
> 
>> The Abstract and Introduction are written in the abstract, implying
>> (to me) that the requirements here are intended to be broadly
>> applicable for the stated purposes, over an extended period of
>> time. On the other hand, I get the impression that requirements in
>> this document are actually more focused, intended for use in a
>> one-time selection of an Internet video codec to be a successor to
>> HEVC and VP9.
>>
>> If this document is intended only for one-time use then it isn't
>> evident to me why it ever needs to become an RFC.
> 
> it is intended to change bgp forever.

Oops!!! I'm sorry. This was a cut/paste error from another review. 
Please ignore the entire Summary section. I will resend this review.

>> 1) NIT:
>>
>> Section 4 says:
>>
>>     If a BGP message with a Length greater than 4,096 octets is received
>>     by a BGP listener who has not advertised the Extended Message
>>     Capability, the listener MUST treat this as a malformed message, and
>>     MUST generate a NOTIFICATION with the Error Subcode set to Bad
>>     Message Length (see [RFC4271] Sec 6.1).
>>
>> The "MUST" seems inappropriate because this is not new normative
>> behavior. Rather it is the existing behavior, at it states. This is
>> already covered by the 2nd paragraph of Section 5, so why does it need
>> to be covered here as well?
> 
> the authors have received instruction both ways on this one.  so is it
> ok if we let the routing ad, alvaro, call it.  i have no dog in this
> fight.

Fair enough.

>> 2) NIT:
>>
>> Reading the last two security considerations in section 8 leaves me
>> concerned. I was expecting to see some further discussion of how these
>> issues can be mitigated, or why it is OK that they are not.
> 
> i am not sure if there are mitigations.
> 
> i believe that the hope is that actual message lengths are well below 4k
> today, and this will deploy before they really grow.  e.g. we do not
> expect bgpsec in more then five years, more likely ten.

I didn't have a good idea what to expect in the way of mitigations, but 
the consequences seemed relatively dire.

Perhaps you could put in some of this explanation and stress the need 
for support to be deployed widely before it is needed.

	Thanks,
	Paul