Subject: [Gen-art] Genart last call review of draft-ietf-grow-large-communities-usage-06

From: Stewart Bryant <[email-masked]>
Date: Tue, 18 Apr 2017 06:41:15 -0700

Reviewer: Stewart Bryant
Review result: Almost Ready

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-grow-large-communities-usage-??
Reviewer: Stewart Bryant
Review Date: 2017-04-18
IETF LC End Date: 2017-04-21
IESG Telechat date: Not scheduled for a telechat

Summary:

This is mostly a well written document, although unfortunately there
are a number of matters that really need to be looked at.

Major issues:

Abstract

   Examples and inspiration for operators to use BGP Large
Communities.

SB> Even if you just copy the Introduction, the Abstract should really
be expanded
SB> to help the reader understand whether or not they want read the
RFC
SB> or if they had read it what it was about.

============

5.  Security Considerations

   Operators should note the recommendations in Section 11 of BGP
   Operations and Security [RFC7454].

SB> You do not address the question of whether there are new
considerations, or considerations
SB> that are of increased importance? Is there is text somewhere
SB> that discusses the integrity and synchronization of the
parameters
SB> and any consequences that arise?

===========

Minor issues:

2.2.  Action Communities

   Action Communities are added as a label to request that a route be
   treated in a particular way within an AS.  The operator of the AS
   defines a routing policy that adjusts path attributes based on the
   community.  For example, the route's propagation characteristics,
the
   LOCAL_PREF (local preference), the next-hop, or the number of
AS_PATH
   prepends to be added when it is received or propagated can be
   changed.

SB> Although these are well known to the target audience, I think you
SB> need some references in the above para.

Nits/editorial comments: 

6.  IANA Considerations

   None.

SB> A little briefer than normal.

---

From: heasley <[email-masked]>
Date: Tue, 18 Apr 2017 15:09:29 +0000

> SB> and any consequences that arise?

I agree that this draft lacks one detail of how RFC7454 applies to it, but
I also note that RFC7454 also does not explain the dangers of ignoring
the recommendations in S11.  I suggest that the subject of removing one's
own communities is subjective and a local issue for which we can only
hypothesize.  I'll try to address the latter, but I do not personally feel
this is necessary.

How so?  Do you mean actual community values similar to the example in 3.1.1?
Because these are int 4.x, as 3.x are examples related to 2.1.

> SB> A little briefer than normal. 

Isn't it elegant. :)

thanks for the review.

---

From: Job Snijders <[email-masked]>
Date: Wed, 19 Apr 2017 01:58:58 +0200

Hi Bryant,

Thank you for taking the time to go through the document.

On Tue, Apr 18, 2017 at 06:41:15AM -0700, Stewart Bryant wrote:
> Please treat these comments just like any other last call comments.
> 
> SB> Even if you just copy the Introduction, the Abstract should
> SB> really be expanded to help the reader understand whether or not
> SB> they want read the RFC or if they had read it what it was about.

OK, we'll copy some text from the introduction section to the abstract
section to provide a better pitch why one would want to read this
document.

> SB> considerations, or considerations that are of increased importance?

It is my understanding that RFC 8092 "BGP Large Communities" are just
like RFC 1997 "BGP Communities", but ...  larger (for lack of better
words). Referencing RFC 7454 seems plenteous.

So, what if there are not any additional considerations, If there were,
they would've been (or are) covered in RFC 8092's security section,
right?

This is an Internet-Draft targetted for Informational status, I'm not
sure what you expect here.

> SB> Is there is text somewhere that discusses the integrity and
> SB> synchronization of the parameters and any consequences that arise?

the what now? Can you elaborate on the above?

>    the LOCAL_PREF (local preference), the next-hop, or the number of
>    AS_PATH prepends to be added when it is received or propagated can
>    be changed.
> 

What reference would you suggest? You feel the section 2.2 text cannot
stand on its own?

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 Apr 2017 10:06:05 +0900

> the what now? Can you elaborate on the above?

you're supposed to guess

the normal hack here is

  this document introduces no new security issues beyond those discussed
  in 1997

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 19 Apr 2017 09:46:53 +0100

> sure what you expect here.
I was wondering if there was more scope to make mischief at a distance 
in a less
less obvious way than before.

If everyone is happy that there is no additional risk then I am fine, 
but seems to
me the more knobs you give the mischeif maker to turn the more security 
risks
you have.

> the what now? Can you elaborate on the above?
So you rely on the nodes that receive these community strings to 
interpret them in
a common way. Maybe this is an already solved problem, or an known risk, 
but what
if the dictionaries get out of sync?

> What reference would you suggest? You feel the section 2.2 text cannot
As I said I imagine that all readers will know the definition of 
LOCAL_PREF and
AS_PATH, but normally we give a reference in a documnet like this.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 19 Apr 2017 09:52:10 +0100

>    this document introduces no new security issues beyond those discussed

Guessing is horrible, but if that is what you do, that is what you do, 
and if the risks are the accepted norm in the BGP
community I am fine.

Is corruption (deliberate or otherwise) of the community strings 
something that BGPsec will address?

- Stewart

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 Apr 2017 17:55:07 +0900

> and if the risks are the accepted norm in the BGP community I am fine.

i meant that, instead of being specific, you left it to the authors to
guess what you wanted.

> something that BGPsec will address?

no.  bgpsec does not sign over communities.  this is because hops may
validly remove them, thus invalidating signatures.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 19 Apr 2017 12:27:43 +0300

> and if the risks are the accepted norm in the BGP

there's a general understanding out there that if you're directly
connect to $asn, you can somewhat believe $asn:* or $asn:*:*
communities, assuming you trust the remote ASN. Otherwise all bets are off.

Nick

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 Apr 2017 22:37:45 +0900

> in a less less obvious way than before.

there isn't

but where were you when the blackhole community was passed?

> interpret them in a common way.

no.  as with bgp communities since they were handed down to us by our
mothers, unless specified in some other document, there is no assumption
that all apply the same semantic to the same syntax.

randy

---

From: Job Snijders <[email-masked]>
Date: Wed, 19 Apr 2017 16:18:41 +0200

On Wed, Apr 19, 2017 at 09:46:53AM +0100, Stewart Bryant wrote:
> > It is my understanding that RFC 8092 "BGP Large Communities" are
> > just like RFC 1997 "BGP Communities", but ...  larger (for lack of
> > better words). Referencing RFC 7454 seems plenteous.
> > 
> > So, what if there are not any additional considerations, If there
> > were, they would've been (or are) covered in RFC 8092's security
> > section, right?
> > 
> > This is an Internet-Draft targetted for Informational status, I'm
> > not sure what you expect here.
>
> but seems to me the more knobs you give the mischeif maker to turn the
> more security risks you have.

Ah, I see now. This document does not create new knobs. RFC 8092
definded the BGP Large Community attribute, and this internet-draft
reflects on possible use cases, much like RFC 1998 was a companion for
RFC 1997.

> interpret them in a common way. Maybe this is an already solved
> problem, or an known risk, but what if the dictionaries get out of
> sync?

Yes, there is not anything novel here. How to keep a list of integers
like UN M.49 up to date (or how to write bug-free software) is out of
scope for this internet draft. ;-)

Deploy coherent routing policy configurations on an autonomous
system-wide level is not for this document to cover.

Kind regards,

Job

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 19 Apr 2017 15:54:06 +0100

Thanks

I think I have done the required Genart level of due diligence on Security.

Stewart

---

From: Job Snijders <[email-masked]>
Date: Wed, 19 Apr 2017 16:58:00 +0200

> I think I have done the required Genart level of due diligence on

Much appreciated, stay tuned for an updated version which incorporates
your feedback.

Kind regards,

Job