Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

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

On 3/5/17, 2:46 AM, "Randy Bush" <[e-mail]> wrote:

Randy:

Hi!

I have some in-line comments.  Thanks for the updated document.

Alvaro.


…
> > M2.1.  Even with John’s explanation, I find myself thinking that this
> > specification could result in some sloppy implementations: if I need
> > to account for receiving unexpected Extended Messages in my code, then
> > maybe I won’t worry too much about controlling what to send to my
> > peers – specially in cases where it would be easy to just replicate an
> > UPDATE (like in a peer-group) and not worry about possible exceptions.
> > I know that we can’t avoid bad implementations, no matter what text is
> > added – but I think that recognizing the threat (maybe in the Security
> > Considerations section) of someone receiving an Extended Message when
> > they don’t support it would be good.  I know that there’s text in the
> > document already which talks about what to do if the receiver doesn’t
> > support Extended Messages – I’m just worried about potential issues
> > with memory allocation if the receiver was not ready…
>
> in the absense of an AD with the guts to let me tear that out, i'll put
> a note in sec cons. :)

☺

Personally, I don’t like this path of accepting anything that you didn’t negotiate.  However, I have to assume that, by the time the Chairs request the publication of a document, there is already consensus in the WG – in this case, the Shepherd’s write-up says that there is “strong consensus” [1].  From your answers and the text below, I think you and I would both have been in the rough on this consensus call.

[1] https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/shepherdwriteup/ 


>    Section 5 allowed a receiver to accept an extended message even
>    though they had not advertised the capability.  This slippery slope
>    will surely lead to sloppy implementations sending extended messages
>    when the receiver is not prepared to deal with them, e.g. to peer
>    groups.  At best, this will result in erroes; at worst, buffer
>    overflows.

This text raises the obvious question of: why even do this if it may be so bad?

The text should reflect the WG consensus – not your personal opinion (or mine, for that matter).  Please reword to be more objective.

…
> 6.  Changes to RFC4271
>
>    [RFC4271] states "The value of the Length field MUST always be at
>    least > 19 and no greater than 4096."  This document changes the
>    latter number to 65535 for UPDATE messages.
>
>    [RFC4271] Sec 6.1, specifies raising an error if the length of a
>    message is over 4096 octets.  For UPDATE messages, iff the receiver
>    has advertised the capability to receive extended messages, this
>    document raises that limit to 65535.

This last paragraph is not completely true because of Section 4.



> > M7. What about transition/migration/partial deployment?  What should
> > the behavior be if, for example, an Extended Message UPDATE is
> > received from a peer, but can’t be propagated to others because they
> > don’t support Extended Messages
>
> if they do not support extended messages, then they can not be bgpsec
> speakers.  so the whole bgpsec path stripping applies and the message
> becomes short.
>
> > There should be some guidance for the general case (i.e. when the
> > total size is >4k due simply to the total amount of information, and
> > not because a single attribute, for example, is really big)
>
> how about "do not do this?"
>
> i believe you have entered a twisty maze in which all rooms do not have
> path(s) to the exit.
>
> 4.  Operation
>...
>    A BGP announcement will, in the normal case, propagate throughout the
>    BGP speaking Internet; and there will undoubtedly be BGP speakers
>    which do not have the Extended Message capability.  Therefore putting
>    an attribute which can not be decomposed to 4096 octets or less in an
>    Extended Message is a sure path to routing failure.

If this text is in the document, then you’re basically saying that you shouldn’t deploy anything that could need more than 4k because it is a “sure path to routing failure”.  Again, please reflect WG consensus…

What I was really hoping for was something like what you wrote above about BGPSec: if a 4k-neighbor is encountered, then just revert to “normal operation”.  I’m not asking you to put that text in this document, mostly because there might not be “normal operation” for something new in the future (like there is for BGPSec).  So, what am I asking for?  Two things:

- guidance of what to do if the “normal operation” of adding attributes results in >4k.  Maybe “treat as withdraw” would be appropriate…

- some text saying that if a future extension knows it needs more than 4k (like BGPSec does), then it MUST include some text about what to do.  IOW, you can’t solve the future case now, let them solve it later.


BTW, it looks like you may have overlooked these other questions: “What should the default be for this extension?  Should it be enabled by default or not?”