Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

Router software will not treat an UPDATE message as malformed
if the Global Administrator field of a Large Community does not contain an ASN.
It doesn't even know that it's an ASN. It's just 32 bits.

I don't think we can or should specify anything stronger than:

A receiving BGP speaker is permitted to remove unexpected
Large Communities from received routes. A Large Community that
is intended to be sent to multiple ASes SHOULD contain an ASN
in the Global Administrator field. The ASN SHOULD be one that
is assigned to the entity
that defines the meaning of the rest of the Large Community.
This allows a route to carry multiple Large Commuinties, the meaning
of each being defined by different independent entities.

Thanks,
Jakob.

> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch
> Sent: Sunday, October 09, 2016 2:55 AM
> To: Brian Dickson <brian.peter.dickson@gmail.com>; Nick Hilliard <nick@foobar.org>
> Cc: idr@ietf.org
> Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt
> 
> --- Original Message -----
> From: "Brian Dickson" <brian.peter.dickson@gmail.com>
> To: "Nick Hilliard" <nick@foobar.org>
> Cc: <idr@ietf.org>
> Sent: Saturday, October 08, 2016 9:14 PM
> >
> > > On Oct 8, 2016, at 9:35 AM, Nick Hilliard <nick@foobar.org> wrote:
> > >
> > > Brian Dickson wrote:
> > >> Is there anything you envision in use of large communities that
> > >> cannot be supported by use of ASNs and private ASNs? I can't see
> > >> anything that would not fit into those two use cases.
> > >
> > > There are plenty of situations where the semantics of what you're
> > > suggesting would be troublesome to define, for example,
> confederations,
> > > asn translation or asn migration, leading to cases where there would
> be
> > > multiple asns being legitimate on a single router.
> > >
> >
> > The operator setting the community would need to know the intended
> semantics. The other operator would need to establish what acceptable
> communities could be used and the corresponding semantics.
> >
> > The operator doing anything complicated will already need to
> understand the ASN gymnastics; the corresponding communities follow
> those same gymnastics.
> >
> > > And even if these cases could be cleared up easily, what happens
> when
> > > someone injects a prefix tagged with a community which isn't the
> same as
> > > their ASN?
> >
> > I said ASN. I didn't say THEIR ASN.
> 
> That is what I intended, although it has not been construed as such.
> 
> There is nothing IMHO in
> '   Global Administrator:  A four-octet namespace identifier.  This
>       MUST be an Autonomous System Number assigned by IANA.'
> which says whose ASN it is, just that it must be an ASN; if you allow
> IPv4 addresses, Router ID, IGP Area numbers and so on, anything else
> that fits into 32 bit, then it all breaks down so it MUST be an ASN.  At
> a stretch, that wording includes private ASN since those values are
> assigned by IANA although we might want to point that out explicitly.
> 
> And as Brian says, security is something else.  Anyone can forge anyone
> else's ASN in there, but that is possible with other BGP data (in the
> absence of SIDR or some such) so the security needs careful
> consideration.
> 
> Tom Petch
> 
> > That is the apparent disconnect.
> >
> > Nothing should enforce what ASN value is used.
> >
> > > You're then stuck with the situation where you're defining
> > > one thing as a MUST in the semantic specification section of the
> rfc,
> > > while down in the Security Considerations section, it's going to
> need to
> > > be admitted that there's no guarantee whatsoever that the global
> > > administrator field in the large community was actually set by the
> ASN
> > > which announced the prefix.
> >
> > Correct. That is the intended behavior.
> >
> > The ASN value will rarely be the ASN setting the community. The cases
> where the sender uses its own ASN can already be handled with extended
> communities.
> >
> > >  Worse still, once it's been changed, there
> > > is no practical way for a neighbor to detect this change, as s-bgp
> isn't
> > > a thing.
> > >
> > > Realistically, vendors are going to implement ways of modifying the
> > > field in exactly the same way as rfc1997 communities can be set to
> > > anything at all at any policy specification point in a bgp-enabled
> network.
> >
> > Yes, and this is the desired state of affairs. Complete parity with
> 1997.
> >
> > Brian
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr