Subject: [bess] Alvaro Retana's No Objection on draft-ietf-bess-rfc5549revision-04: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Mon, 24 Aug 2020 12:55:00 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-bess-rfc5549revision-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-rfc5549revision/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Security Considerations

The use of an IPv6 Next Hop opens up the possibility of diverting the traffic:
there is no provision in this draft, or rfc2545, to validate or somehow verify
that the address is "correct".  IOW, a rogue BGP speaker may use a Next Hop
address to redirect the traffic elsewhere.  Traffic diversion is a known
vulnerability, but I would still like to see something in this document about
it.

Suggestion (borrowing from draft-ietf-idr-tunnel-encaps)>

   As [RFC4272] discusses, BGP is vulnerable to traffic diversion attacks.
   The ability to advertise an IPv6 Next Hop adds a new means by which an
   attacker could cause traffic to be diverted from its normal path.  Such an
   attack differs from pre-existing vulnerabilities in that traffic could be
   forwarded to a distant target across an intervening network infrastructure
   (e.g. an IPv6 core), allowing an attack to potentially succeed more
   easily, since less infrastructure would have to be subverted.  Potential
   consequences include "hijacking" of traffic or denial of service.

(2) §4:

   The Extended Next Hop Encoding capability MAY be dynamically updated
   through the use of the Dynamic Capability capability and associated
   mechanisms defined in [I-D.ietf-idr-dynamic-cap].

This text creates a Normative dependence on I-D.ietf-idr-dynamic-cap.  However,
that document expired more than 8 years ago.  Please remove this paragraph.

(3) It would be very nice if a section summarizing the changes between this
document and rfc5549 was included.

(4) rfc5549 was written more than 10 years ago...what qualified then as
"current" and "new" doesn't anymore.  It would be nice to update some of that
language.

(5) [nits]

s/IPV4/IPv4/g

s/allows advertising with [RFC4760] of an MP_REACH_NLRI with/allows advertising
the MP_REACH_NLRI attribute [RFC4760] with this content