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

From: Paul Kyzivat <[email-masked]>
Date: Thu, 4 Jul 2019 10:42:28 -0400

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-idr-bgp-extended-messages-33
Reviewer: Paul Kyzivat
Review Date: 2019-07-09
IETF LC End Date: 2019-07-18
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.

Disclaimer:

I have very little understanding of the subject matter of this document, 
so this review is limited to the form and structure of the document.

General:

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.

Issues:

Major: 0
Minor: 0
Nits:  2

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?

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.

Otherwise this short document seems to be in good shape.

---

From: Randy Bush <[email-masked]>
Date: Thu, 04 Jul 2019 11:28:46 -0700

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.

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

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

> Otherwise this short document seems to be in good shape.

thanks

randy

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 4 Jul 2019 16:35:26 -0400

Randy,

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

> ok if we let the routing ad, alvaro, call it.  i have no dog in this

Fair enough.

> 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

---

From: Randy Bush <[email-masked]>
Date: Thu, 04 Jul 2019 14:12:12 -0700

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

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