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

[Jon Mitchell <[e-mail]>]

David -

Just to close this out, I don't plan to make these additional changes to
the draft.  I don't plan on saying operators MUST filter private use
ASN's outbound specfically with an AS_PATH filter list or dictate to
operators anything they must do except not to send private use ASN's to
the Internet, which is the same guidance given in RFC 1930 and already
in the draft.  Operators are inventive and can use whatever tool to do
this they please (community/prefix based could be used if they know
which communities or prefixes come from private ASNs for instance).

On the inbound filtering, operators may filter /25 or longer, their own
address space, private or public ASN's or anything else they please in
my opinion, and none of this needs to be codified in this draft, however
is certainly welcomed in BCP documents.  We've already established in
many threads that the worse case is a prefix from a mis-configured
(leaked to Internet Private Use ASN) is dropped.

Jon

On Thu, Dec 20, 2012 at 10:14:42AM -0600, David Farmer wrote:
> On 12/20/12 09:27 , Jon Mitchell wrote:
> >
> >David -
> >
> >I just posted a new rev of the doc which I hope is final incorporating
> >the changes discussed on the list previously (must have just crossed in
> >the wires with this email).
> 
> Yep, I saw it right after clicking send.
> 
> >I made slight changes to the section you
> >describe, although I put the focus on filtering on the user of private
> >ASNs (outbound).
> >
> >I think whether or not filtering inbound or not is a good idea is
> >largely operator preference (I'm personally in favor as it pushes the
> >drop closest to the source of the error which I'm generally in favor of)
> >and the draft is not meant to dictate specific behavior (this is not a
> >BCP doc) in this regard however it seems like if you are using private
> >ASN's, it will simplify things a bit from a troubleshooting standpoint
> >to not mis-identify a leaked private ASN as one of your own by inbound
> >filtering at your border, but the impact in either case is the same and
> >minimal (routes that are leaked are the ones impacted only - encouraging
> >those who leak to fix their issues).
> 
> I'm OK with the focus being on outbound filtering and outbound
> filtering and being required with a "MUST" clause.  However, I
> believe that inbound filtering should be explicitly allowed, but not
> required, with a "MAY" clause being included as well.
> 
> However, there is the old mantra of "trust but verify".  So I think
> we need to be explicit that any other operator "MAY" filter inbound.
> If you get the balance right this can be use to reenforce your focus
> that operators "MUST" filter outbound.
> 
> I'll agree my suggested text below did not get the balance right and
> focuses to much on the inbound filtering.  However, both your
> original and new text don't make it explicit that an operator "MAY"
> filter inbound if they wish.  That is what I would like to see added
> somehow.
> 
> >Also, it should be noted none of these issues are new (related to the
> >new range), although some of them may have to be revisited as Pradosh
> >pointed out if remove private implementations are not updated, and that
> >is the focus of the text change I did make.
> 
> Completely agree, not a new issue.  However, we are touching the
> text, and vendors are going to need to touch code, so now is the
> time to fix issues, especially if they lead to divergent
> interpretations.
> 
> >Jon
> >
> >
> >On Thu, Dec 20, 2012 at 09:03:56AM -0600, David Farmer wrote:
> ...
> >>So here is some suggested text.
> >>
> >>    Operators may drop or disregard any prefix received from the global
> >>    Internet that is originated from or that contains a private use ASN
> >>    in the AS_PATH.  This may result in unpredictable connectivity for
> >>    any prefix originated from or containing a private use ASN in the
> >>    AS_PATH.  Therefore, all operators using private use ASNs to
> >>    originate prefixes or passing an AS_PATH that contains private use
> >>    ASNs to the global Internet, must remove all private use ASNs from
> >>    the AS_PATH before being advertised to the global Internet.
> >>    Furthermore, operators are cautioned to ensure any filters or
> >>    implementation specific features that recognize private use ASNs
> >>    have been updated to recognize both ranges prior to making use of
> >>    the newer, numerically higher range of private use ASNs.
> 
> -- 
> ================================================
> David Farmer               Email: [e-mail]
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: [phone]
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================