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

["Susan Hares" <[e-mail]>]

Nick:

Before I start, these are great questions.  Before, I start, I must repeat
John limited the discussion to the range comments.  Please get your comments
in often and early today on the range.

----------

Now, as to your questions... 
RFC 1930 says: 

10. Reserved AS Numbers

   The Internet Assigned Numbers Authority (IANA) has reserved the
   following block of AS numbers for private use (not to be advertised
   on the global Internet):

I will address "global Internet" rather than the phrase "Internet".

Many "fun" adventures in the past with BGP infrastructure have generally
been found to be someone's leak or accident.  Leaks/accidents if painful
enough, will inspire code and operational changes. There tales of equally
fun adventures within the private VPN or private DC space, but it is not the
concern of RFC1930. 

I believe that operations people are smart.  If they ignore "MUST" for
private VPN or private DC, they must deal with the problems.  If they wish
to standardize it, they'll speak up.  If operators want better knobs to
handle private AS, operators will define it. If operators define knobs for
private AS, it's a great topic to talk about in Grow or IDR. 

If they break the global Internet using private AS space, that's what
RFC1930 is for and this draft modifies.  Your stated cases match my
understanding of our original discussions on RFC1930. 

 Your reasons for deciding against rfc 6666 are interesting, I will re-read
RFC 6666.  As you've stated your reasons, I do not think the circumstances
match either the original intent of RFC1930 or the intent of the "MUST" or
"must" in the operational paragraph. 

Sue  


-----Original Message-----
From: Nick Hilliard [mailto:[e-mail]] 
Sent: Friday, December 21, 2012 6:43 AM
To: Susan Hares
Cc: 'Jon Mitchell'; [e-mail]; [e-mail]
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

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