Re: [Idr] FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt

[Jeffrey Haas <[e-mail]>]

Sriram,

In a side conversation, Bruno points out RFC 7606 sense of malformed with
targeted actions is appropriate.  So, I withdraw my comment about not
calling these malformed.

Updated proposal follows:


On Mon, Feb 14, 2022 at 09:02:42PM +0000, Sriram, Kotikalapudi (Fed) wrote:
> > OLD:    If an eBGP speaker receives an UPDATE with an OTC Attribute with a
> >
> >    length different from 4 octets, then the UPDATE SHALL be considered
> >
> >    malformed.  If malformed, the UPDATE message SHALL be handled using
> >
> >    the approach of treat-as-withdraw [RFC7606<https://datatracker.ietf.org/doc/html/rfc7606><http://rfc7606%3Chttps//datatracker.ietf.org/doc/html/rfc7606%3E>]6>].
> >
> >
> >
> >    If an UPDATE with an OTC Attribute is received in iBGP, then the
> >
> >    Attribute or UPDATE SHALL NOT be considered malformed based on the
> >
> >    specified length.  This avoids treat-as-withdraw error handling and
> >
> >    prevents the possibility of long-lived forwarding loops in iBGP
> >
> >    (Section 6 in [RFC7606]<https://datatracker.ietf.org/doc/html/rfc7606#section-6><http://rfc7606]%3Chttps//datatracker.ietf.org/doc/html/rfc7606>)6>).  It also avoids Attribute-discard error
> >
> >    handling [RFC7606<https://datatracker.ietf.org/doc/html/rfc7606><http://rfc7606%3Chttps//datatracker.ietf.org/doc/html/rfc7606%3E>] and hence route leak detection capability is not
> >
> >    compromised in case the route is propagated to eBGP neighbors.
> >
> > NEW: <null>

NEW:

An OTC Attribute with a length that is not 4 octets SHALL be considered
malformed.  

An UPDATE message with a malformed OTC Attribute received from an eBGP peer
MUST be handled using the approach of "treat-as-withdraw".

When an UPDATE message with a malformed OTC Attribute is received from an
iBGP peer, the OTC message's value field SHOULD be ignored and considered
invalid.

Applying "treat-as-withdraw" behaviors to routes received via iBGP may lead
to forwarding loops. ([RFC 7606], Section 6.)  Retaining the malformed OTC
Attribute with an invalid value permits an adjacent AS to prevent route
leaks. 

> >
> > OLD:
> >
> >    2.  If a route with the OTC Attribute is received from a Peer (i.e.,
> >
> >        remote AS with a Peer Role) and the Attribute has a value that is
> >
> >        not equal to the remote (i.e., Peer's) AS number, then it is a
> >
> >        route leak and MUST be considered ineligible.
> >
> >
> > NEW:
> >
> >    2.  If a route with the OTC Attribute is received from a Peer (i.e.,
> >
> >        remote AS with a Peer Role) and the Attribute has a value that is
> >
> >        not equal to the remote (i.e., Peer's) AS number (including when the attribute value is not 4 octets), then it is a
> >
> >        route leak and MUST be considered ineligible.
> 
> 2.  If a route with the OTC Attribute is received from a Peer (i.e.,
> remote AS with a Peer Role) and the Attribute has a value that is
> not equal to the remote (i.e., Peer's) AS number, or the value is invalid,
> then it is a route leak and MUST be considered ineligible.