Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

[Nick Hilliard <[e-mail]>]

On 20/12/2012 23:24, Susan Hares wrote:
> I'd be interested in you suggesting the situations would be valid to leak
> the AS private path AS to a peer, before we downgrade to a "SHOULD". 

the proposed text states: "If Private Use ASNs are used and prefixes are
originated from these ASNs which are destined to the Internet, Private Use
ASNs must be removed from the AS_PATH before being advertised to the global
Internet."

To start off, there's the usual problem: what do we mean when we talk about
"the Internet"?

In fact there's more to the situation.  We're dealing with operational
stuff here rather than protocol specification, i.e. human behaviour rather
than computer specifications.  I'd have no problem with throwing "MUST"
around when dealing with protocol handling, but when it gets to operational
stuff, I would be a lot more circumspect for several reasons:

- operational people will happily ignore a MUST if they feel it suits their
purpose at a specific time.

- the Internet is a bunch of interconnected networks and what works for
policy for one network peer might not work for another.

- I don't not have the wisdom or the foresight to predict every eventuality
where there might be legitimate reasons to forward a prefix with a private
ASN over an ebgp peer.

- I suspect most private asn leaks we see in the DFZ are accidental, and
MUST won't help in this situation.

- if this is specified as 2119-compatible MUST, vendors may be tempted to
hardwire an AS path prefix filter for ebgp sessions into their code in a
way which cannot be circumvented (in the same way that e.g. 169.254/16 is
hardwired and cannot be used in a bgp NLRI).  I'd see lots of value in
having a vendor default of not forwarding private ASNs, but I think this
could be quite harmful to have an absolute prohibition

Private ASN leaks are going to happen in two main circumstances: accidental
and deliberate.  I don't think that putting in "MUST" will actually deal
with either. What's important from an operational point of view is getting
vendors to implement a default but overrideable filter so that the bar for
accidental leaks is raised to a sufficiently high point that accidental
leaks are only going to happen when the safety nets are removed.

If we're going to make a statement on this one way or another, I think it
should be along the lines of SHOULD rather than MUST, and that we should
consider including a vendor hint to suggest that the default implementation
behaviour would be to filter private asns.

This complicates issues slightly because we get into an issue of semantics:
 does the prefix get dropped?  Or does the private ASN component get
stripped from the AS path?

In term of specific situations where this might be useful, yeah, mergers
and acquisitions would be one.  Others might include private peering
between ASN confederations.  Or interconnections between the large number
of private networks around the world, many of which use a mixture of
private and public ASNs.  Or test peerings.

Anyway, these were some of the issues that cropped up during the WG
discussion phase for rfc 6666.  We eventually decided to go with the idea
of making a recommendation that the prefix shouldn't be transferred over
ebgp sessions, and specifically made the point in the security section to
highlight it.  This avoided the issue of defining "the Internet", while
encapsulating what we wanted to say in the way that we wanted to say it.

Nick