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

[t.petch <[e-mail]>]

--- Original Message -----
From: "Brian Dickson" <[e-mail]>
To: "Nick Hilliard" <[e-mail]>
Cc: <[e-mail]>
Sent: Saturday, October 08, 2016 9:14 PM
>
> > On Oct 8, 2016, at 9:35 AM, Nick Hilliard <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr