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

[Jon Mitchell <[e-mail]>]

On Fri, Dec 21, 2012 at 11:43:22AM +0000, Nick Hilliard wrote:
> 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"?

Terminology seems clear as outside of the "single organization" context
to which Private Use is defined?  This term is the same as in RFC 1930,
and I don't believe the leaks we see are due to semantic issues in that
document, nor future leaks will be based on mis-reading of this text.

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

This is always true even for protocol specifications, implementers can
choose to forgo being RFC compliant for their own reasons.  At MUST it
will be obvious they are not in the right, if we soften it to should,
maybe the operators who ignore the SHOULD will say "the RFC didn't say I
MUST remove them" if asked to fix it?

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

Private Use by definition should be not be seen on the Internet, we are
still awaiting the case where it should be seen outside a single
organization.

> 
> - 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.

The draft doesn't say not to send to eBGP peers, just peers outside of
your organization.

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

Nothing produced by IETF will help in this situation, however I think
IETF should specify what is the correct behavior.

> - 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


Since this is not a protocol specification, I think this is personally
unlikely.  Given there is argueably (but not verifiably) many more
Private ASNs in use than Public ASNs, changing this default seems
unlikely.  Given the impact of leaked private ASNs versus leaked RFC
1918 space, and vendors not defaulting to not sending that, it would
seem unlikely this becomes a default.  But whether or not it does or not
is not likely going to be due to the operational considerations section
of this RFC in my opinion.

> 
> 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.

I agree that nothing in this IETF draft will likely solve the leak
problem, however at least someone might point to it as an indication of
what is correct or not.

> 
> 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.

I don't think this draft nor this section is a good place to specify
vendor implementation behavior.  This was meant to be guidance for
operators in use of 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?

Yes, if we take it out of operator control and into vendor
implementation guidance, these would become risks.

> 
> 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.

I think you are focusing on some possible vendor implementation that
doesn't exist that prevents Private Use ASN exchange over every eBGP
peering and is not configurable rather than the guidance to operators.
If ANY of these cases require routes to go to the global Internet,
Private Use ASNs MUST not be in the AS_PATH as the draft says.   If
these use cases are not for routes that go to the global Internet, the
statment didn't apply in the first place.

Jon