Subject: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-bgp-vpls-control-flags-07: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 09 Apr 2019 08:35:16 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-bgp-vpls-control-flags-07: 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-bgp-vpls-control-flags/

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

Thanks for this document; it's good to get this behavior clarified and made
more usable.

Unfortunately, I cannot agree with the "no new security considerations"
statement in Section 7.  I wavered for a while on whether to make this a
DISCUSS-level point, but decided not to since I don't think the material
consequences are especially severe.  Please take it under consideration,
though.

It seems to me that we are changing the expected tradeoff
between availability and functionality, and that change should be
documented as a new consideration.  Specifically, the state prior to
this document (in practice) seems to be that when a PE advertises the
C-bit in its NLRI, all PWs in both directions that use that NLRI will
use the CW, or will fail.  Any transient error, random bit flip,
attacker-induced bit flip, etc., would cause a PW failure which is
presumably highly visible.  Using the recommendations in this document,
we prioritize availability over using the CW feature, so those
errors/bit-flips now cause the PW to be established but not use the CW,
which may be a less visible event and have second-order effects for the
traffic therein.  The operator deploying this technology should make an
informed decision about its usage.

(We are also changing the behavior of the S bit so there would be
some considerations there, too, though failure to agree on the S bit
still results in a highly visible outage, so the considerations are a
little different.)

Some other, more minor, section-by-section comments follow.

Section 1

["PE" is not listed as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt and thus would
normally be a candidate for expansion on first use]

   The use of the Control Word (CW) helps prevent mis-ordering of IPv4
   or IPv6 Psuedo-Wire (PW) traffic over Equal Cost Multi-Path (ECMP)
   paths or Link Aggregation Group (LAG) bundles. [RFC4385] describes
   the format for CW that may be used over Point-to-Point PWs and over a
   VPLS. Along with [RFC3985], the document also describes sequence
   number usage for VPLS frames.

RFC 4385 seems to be carrying fairly generic disucssion, to me, without
a clear statement that that CW format should be used for p2p PWs and
VPLS usage.  (Though, I cannot dispute the "that may be used" statement,
since the intent of 4385 seems to be quite generic.)  Perhaps it is more
accurate to say "a format" than "the format", though, absent some other
specification that mandates this particular one?

Section 3.1

This new behavior means that any fault (or attacker influence) causes
the PW to degrade to not using the CW, and possibly to do so "silently".
In other contexts this sort of fallback would get harsh review from the
security community, though it's unclear that the risk/reward here merits
a harsh response.

Section 3.2

   send outgoing frames with sequence numbers as well.  This memo
   further specifies the expected behavior. [...]

I would prefer to see an explicit statement of the semantics of (not)
setting the S-bit, as given by this specification.  (That is, the
previous section says "If a PE sets the C-bit in its NLRI, [...]" but we
don't have a similarly declarative statement for the S bit.)
Note, however, that this is the non-blocking COMMENT portion of the
ballot and I am not trying to impose my preference on you.

Do we need to say that if both PEs send a S-bit of 0, sequence numbers
MUST NOT be used?

I a little bit expected to see some text about why CW usage and
sequencing are sufficiently different so as to get differential
treatment for mismatched advertisement, but perhaps it is not really
necessary for a document of this nature.

Section 5

[VPLS-MULTIHOMING] is not yet in IESG processing; would it make sense to
move this content into that document?

Section 5.2

     The PW behavior is similar to the CW scenario so that the insertion
     of S-bit evaluation SHOULD be independent per PW.  However, because

nit: I think this would be a lot clearer if it was "The PW behavior with
respect to sequencing is similar to the CW scenario".  (But maybe that's
just because my brain is still parsing PW and CW as visually similar and
trying to make them be semantically similar, even though they are not.)

     one PW would be established, between PE1 and PE2.  Thus, even
     though CE5 is physically multi-homed, due to PE4's lack of support
     for S-bit, and no PW between PE1 and PE4, CE5 would not be multi-
     homed.

nit: I think the relevant attribute is the lack of support for
*sequencing* (which is indicated via the S-bit), rather than "lack of
support for S-bit" itself.

Section 6

   Let PE2 and PE3 also be CW enabled. Let PE4 not be CW enabled. PE1
   will advertise a VPLS BGP NLRI, containing the C/S bits marked as 1.
   PE2 and PE3 on learning of NLRI from PE1, will include the CW in VPLS
   frames being forwarded to PE1. However, PE4 which does not have the
   ability to include CW, will not.

This text seems to be written to the letter of RFC 4761 excluding the
modifications made by this document (i.e., advertising NLRI leads to
peers setting those bits for traffic to the indicated PE, without any
negotiation).

Do we want any discussion of the sequencing behaviors and S-bit settings
for this example?

---

From: Ravi Singh <[email-masked]>
Date: Sat, 20 Apr 2019 02:08:59 +0000

Hi Benjamin
Thanks for your detailed feedback.

Please see inline for <RS>.
Regards
Ravi

> -----Original Message-----
> From: Benjamin Kaduk via Datatracker [mailto:[email-masked]]
> Sent: Tuesday, April 9, 2019 8:35 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Mach Chen
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Subject: Benjamin Kaduk's No Objection on draft-ietf-bess-bgp-vpls-control-
> flags-07: (with COMMENT)
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-
> 2Dcriteria.html&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=bYCIT8qprRL9tp64crav4NXQbv-
> 9JtK1NodEE30aj4Y&s=gKACcDwG815F9IokZIdC2_-SkojE9jRvN6G5s46EJp0&e=
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dbgp-2Dvpls-2Dcontrol-
> 2Dflags_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=bYCIT8qprRL9tp64crav4NXQbv-
> 9JtK1NodEE30aj4Y&s=YK6yKMztrNqCa2EKzwI9j4Rp7lgy5gK6xuHRqJJSbdI&e=
> 
> 
> 

<RS> I've updated the security considerations section.

> It seems to me that we are changing the expected tradeoff between
> availability and functionality, and that change should be documented as a
> new consideration.  Specifically, the state prior to this document (in practice)
> seems to be that when a PE advertises the C-bit in its NLRI, all PWs in both
> directions that use that NLRI will use the CW, or will fail.  Any transient error,
> random bit flip, attacker-induced bit flip, etc., would cause a PW failure
> which is presumably highly visible.  Using the recommendations in this
> document, we prioritize availability over using the CW feature, so those
> (We are also changing the behavior of the S bit so there would be some
> considerations there, too, though failure to agree on the S bit still results in a
> highly visible outage, so the considerations are a little different.)
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
> 2Deditor.org_materials_abbrev.expansion.txt&d=DwICaQ&c=HAkYuh63rsuh
> r6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3-
> fXPV4&m=bYCIT8qprRL9tp64crav4NXQbv-9JtK1NodEE30aj4Y&s=SPOx6ODer-
> K0xPN-CpKPGJii3Lb9cSv41y9d4ChYZb4&e= and thus would normally be a
> candidate for expansion on first use]

<RS>: Addressed

> RFC 4385 seems to be carrying fairly generic disucssion, to me, without a
> clear statement that that CW format should be used for p2p PWs and VPLS
> usage.  (Though, I cannot dispute the "that may be used" statement, since
> the intent of 4385 seems to be quite generic.)  Perhaps it is more accurate to
> say "a format" than "the format", though, absent some other specification
> that mandates this particular one?

[<RS>] 
[<RS>] There is no other specification, AFAIK, for a control-word format other than what is in RFC4835.
So, "the format" seems appropriate.

> 
> Section 3.1
> 
> This new behavior means that any fault (or attacker influence) causes the PW
> to degrade to not using the CW, and possibly to do so "silently".
> security community, though it's unclear that the risk/reward here merits a
> harsh response.
> 
> Section 3.2
> 
> I would prefer to see an explicit statement of the semantics of (not) setting
> the S-bit, as given by this specification.  (That is, the previous section says "If
> a PE sets the C-bit in its NLRI, [...]" but we don't have a similarly declarative
> statement for the S bit.) Note, however, that this is the non-blocking
> COMMENT portion of the ballot and I am not trying to impose my preference
> on you.
> 

<RS> I've address this in -08.

> I a little bit expected to see some text about why CW usage and sequencing
> are sufficiently different so as to get differential treatment for mismatched
> advertisement, but perhaps it is not really necessary for a document of this
> nature.
> 

<RS> I've addressed this in -08.

> move this content into that document?

<RS> I believe keeping C-bit/S-bit mismatch handling in a single document makes it easier to understand the behavior.

> nit: I think this would be a lot clearer if it was "The PW behavior with respect
> to sequencing is similar to the CW scenario".  (But maybe that's just because
> my brain is still parsing PW and CW as visually similar and trying to make
> them be semantically similar, even though they are not.)
> 
> *sequencing* (which is indicated via the S-bit), rather than "lack of support
> for S-bit" itself.

<RS> Addressed

> modifications made by this document (i.e., advertising NLRI leads to peers
> setting those bits for traffic to the indicated PE, without any negotiation).
> 
> Do we want any discussion of the sequencing behaviors and S-bit settings for
> this example?
> 

<RS>: Addressed.