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

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

----- Original Message -----
From: "Jon Mitchell" <[e-mail]>
To: "Nick Hilliard" <[e-mail]>
Cc: <[e-mail]>; "Susan Hares" <[e-mail]>
Sent: Friday, December 21, 2012 2:34 PM
> 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.

Since we are putting this under IANA, then I think that the relevant
definition should not be RFC1930 but RFC5226 from which
"     Private Use - For private or local use only, with the type and
            purpose defined by the local site.
<snip>
            It is the responsibility of the sites
            making use of the Private Use range to ensure that no
            conflicts occur (within the intended scope of use)."

from which I would expect removal to be implicit for most readers. I see
no harm in including a MUST just to emphasize the point; and a
reference to site would probably be better than to Internet.

Tom Petch

> > - 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
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>