Subject: Re: [secdir] SECDIR review of draft-ietf-bess-pta-flags-02.txt

From: "Christian Huitema" <[email-masked]>
Date: Sun, 24 Apr 2016 16:29:00 -0700

Resending with the proper IESG address. Sorry.
=================================================
I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

The document is ready with issues.

The document defines an extension mechanism for the "flags" field in the
"P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" used to carry
information in BGP about multicast routing inside VPN. RFC 6514 describes an
8-bit flag, with 7 bits reserved and 1 bit defined. The draft reserves one
of the 7 bits as an extension mark, and proposes to create an IANA registry
for the remaining 6 values, and for the values of the newly defined
extension field.

The draft is pretty simple, but it poses the generic issue of extensions.
What happens if some routers in a domain are aware of the newly assigned
extension and some are not? The authors argue that this behavior is properly
defined in the documents describing the future extensions. This is
plausible, but the draft does define a generic mechanism, and does switch
the meaning of one of bits marked as "reserved" in RFC 6514. We have thus
two possible issues:

1) A router supports RFC 6514 but does not implement the extension
mechanism.
2) A router supports the extension mechanism, but does not support the
specific extension.

I am able to guess a plausible behavior based on the text in the draft and
the reference to " Treat-as-withdraw" option of RFC 7606, but I would much
prefer if there was a recommended behavior in the draft. 

-- Christian Huitema

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 25 Apr 2016 13:40:26 -0400

On 4/24/2016 7:29 PM, Christian Huitema wrote:
> We have thus two possible issues:
>

With regards to case 1, I don't think there's much to say.  A router 
that supports RFC 6514 but not the pta-flags draft will ignore all the 
flags except the one that is defined in RFC 6514.

Similarly, in case 2, a router that doesn't recognize a particular flag 
will ignore it.  However, I can add some text to the draft saying to 
ignore any bits you don't recognize.

If there are mechanisms that require the use of a particular extension, 
those mechanisms won't work properly with routers that don't support the 
necessary extension.  Applications that require such mechanisms either 
need to provide signaling to determine whether all involved routers 
support the necessary extension, or else they need to define procedures 
for interworking with routers that don't support the extension.  I could 
add some text stating this, but I don't think there's much more that can 
be said.

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 25 Apr 2016 12:20:18 -0700

On Monday, April 25, 2016 10:40 AM, Eric C Rosen wrote:
> With regards to case 1, I don't think there's much to say.  A router that
> supports RFC 6514 but not the pta-flags draft will ignore all the flags
except
> the one that is defined in RFC 6514.
> 
will ignore
> it.  However, I can add some text to the draft saying to ignore any bits
you
> don't recognize.

Yes, please. 

> If there are mechanisms that require the use of a particular extension,
those
> mechanisms won't work properly with routers that don't support the
necessary
> extension.  Applications that require such mechanisms either need to
provide
> signaling to determine whether all involved routers support the necessary
> extension, or else they need to define procedures for interworking with
routers
> that don't support the extension.  I could add some text stating this, but
I don't
> think there's much more that can be said.

Don't routers have to relay these extensions to BGP-adjacent routers? In
that case, are they supposed to blindly relay the extensions that they don't
understand? Are they supposed to reset the corresponding flags to zero, or
just leave them as is? It is probably obvious for you, but these things are
often better said than just implied.

-- Christian Huitema

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 25 Apr 2016 16:25:10 -0400

> often better said than just implied.

Both the "PMSI Tunnel" attribute and the "Additional PMSI Tunnel 
Attribute Flags" Extended Community are defined to be BGP transitive 
attributes.  This means that any BGP speaker that doesn't understand one 
of these attributes would just pass it along unchanged.

If a BGP speaker understands the attributes, but does not understand 
some of the flags, it would not be correct for it to reset the flags.  
The flags might have edge-to-edge (ingress-to-egress or 
egress-to-ingress) significance, and it might not be necessary for 
intermediate routers to understand them.  I will add a statement saying 
that, by default, flags that are not understand SHOULD be left 
unchanged.  (Saying "by default" leaves open the possibility that 
someone might configure a policy to clear certain bits.)

There are cases (discussed in RFCs 6514 and 7524) where the PMSI Tunnel 
attribute is modified as an UPDATE is propagated.  I'll add some text 
pointing out that if the original PMSI Tunnel attribute had the 
extension flag set, but the modified one does not, then the "Additional 
PMSI Tunnel Attribute Flags" Extended Community MUST be removed.

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 26 Apr 2016 10:10:03 -0700

On Monday, April 25, 2016 1:25 PM, Eric C Rosen wrote:
> > Don't routers have to relay these extensions to BGP-adjacent routers?
> > In that case, are they supposed to blindly relay the extensions that
> > they don't understand? Are they supposed to reset the corresponding
> > flags to zero, or just leave them as is? It is probably obvious for
> > you, but these things are often better said than just implied.
> 
> Both the "PMSI Tunnel" attribute and the "Additional PMSI Tunnel Attribute
> Flags" Extended Community are defined to be BGP transitive attributes.
This
> means that any BGP speaker that doesn't understand one of these attributes
> would just pass it along unchanged.
> 
> If a BGP speaker understands the attributes, but does not understand some
of
> the flags, it would not be correct for it to reset the flags.
intermediate
> routers to understand them.  I will add a statement saying that, by
default,
> flags that are not understand SHOULD be left unchanged.  (Saying "by
default"
> leaves open the possibility that someone might configure a policy to clear
> certain bits.)
> 
pointing
> out that if the original PMSI Tunnel attribute had the extension flag set,
but the
> modified one does not, then the "Additional PMSI Tunnel Attribute Flags"
> Extended Community MUST be removed.

Works for me, thanks.

-- Christian Huitema