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

Paul, thanks for your review. Randy, thanks for the new text. I entered a No Objection ballot.

Alissa

> On Jul 4, 2019, at 5:12 PM, Randy Bush <randy@psg.com> wrote:
> 
>>>> 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.
> 
> i will work on something.
> 
> but there is a hidden problem.  bgpsec drafts used to say extended
> message capability was mandatory.  but lack of progress of this draft
> was seen as delaying bgpsec (which,in my mind, is kinda like delaying
> ipv6:).  so the requirement was removeed.  the result is that we have
> to be careful suggesting issues with bgpsec lest we have to read 312
> emails from <characterisation deleted>.
> 
> and bgp-ls has its own yaks to shave.
> 
> but we can easily give guidance such as not packing a jillion nlri in
> an extended message when they can be spread over 4k traditional
> updates.
> 
> lemme work on this.  e.g. maybe the Operations section could have
> something such as
> 
>   During the years of incremental deployment, speakers that are capable
>   of Extended Messages should not simply pack as many NLRI in a message
>   as they can, or otherwise unnecessarily generate UPDATES above the
>   4,096 octet pre- Extended Message limit, so as not to require
>   downstream routers to decompose for peers that do not support
>   Extended Messages.  See Section 8.
> 
> then, in Sec Cons, the first threat you mention, a bit of mild snark
> may help
> 
>   If a remote attacker is able to craft a large BGP Extended Message to
>   send on a path where one or more peers do not support BGP Extended
>   Messages, peers which support BGP Extended Messages may act to reduce
>   the outgoing message, see Section 4, and in doing so allow a
>   downgrade attack.  This would only affect the attacker's message,
>   where 'downgrade' has questionable meaning.
> 
> i am not sure we can mitigate the second threat (fifth in the
> section).  if anyone has clue, do tell.
> 
> randy
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art