Re: [GROW] ISC Response to draft-ietf-grow-unique-origin-as

[Leo Bicknell <[e-mail]>]

In a message written on Wed, Sep 28, 2011 at 09:35:55PM -0400, Danny McPherson wrote:
> Simply put, if detection or policies can't be defined (discriminated) 
> based on authorized origin and a single upstream adjacent AS alone then 
> adjacent ASes and upstreams need to be codified.  If the origins are 
> consistent in all locations and adjacent ASes are unique per location 
> via the same operator, the origin, adjacent ASes, and upstream adjacent 
> sets all need to be enumerated in detection or routing policies for the 
> prefix, that's the only way you can find a unique discriminator in the 
> set to key off of.

I think I see where your world view and mine do not match.

In a world where an Anycast service contracts with 4-8 upstream
networks for transit they can easily enumerate all of the paths
that might appear, and send it to someone.

In a world where an Anycast service peers with a large number of
networks, this is totally impractical.

If I wanted to list the full set of possible paths by which you
might see F-Root that list would be about 3,000 ASN's long right
now.  I suspect you don't notice that because we also make generous
use of no-export both directly and indirectly, meaning a lot of
these paths may not be visible to you, from your vantage point.

I find, and track down (mostly innocent) route leaks of F on a
weekly basis due to our rich peering.  I can honestly say, for us,
the approch you describe would not make things one bit easier for
me.  

> But it can't today!  Again, the very application of a common origin 
> in all locations for a given prefix, and the thought that that prefix 
> might well appear in some new place with the same origin and a new 
> upstream AS, or escape outside of it's intended catchment illustrates 
> just the problem.  I.e., if it's leaked or hijacked how the heck would 
> anyone know?

I have no idea how anyone, other than the operator of the service
would know.  In all proposed configurations the operator of the
service knows how they configured it, and is the only one qualified
to diagnose.

Simply: A third party cannot know if the route is legitimate unless the
        Anycast operator tells them.

If the operator must enumerate all paths anyway, the difference
between your proposal and say the way F does it is the +1 ASN (N
for your proposal, N+1 for F), but the list of paths is exactly the
same length, N.  That one extra ASN means inconsistent origin isn't
required.

So the operator can provide a list of N things in your proposal, or the
same N things the way F does it, except our way doesn't go against the
tradition of inconsistent origin being a "bad" thing.  Indeed, I can
write the vi transform easily:

   s/$/ 3557/

It's my hope that in the future DNSSEC, SecureBGP, RPKI, or some other
out of band (to the routing system) method will be able to verify, but
until then this proposal doesn't advance things.

> > I see many of the arguments for this proposal were that it helped
> > in diagnostic capabilities.  Yet in all of the GROW archives I have
> > read so far, and in the RFC itself I do not see a single example
> > of how this configuration leads to faster/more accurate troubleshooting
> > than say the F-Root model.  
> 
> OK, re-read the draft, and read the responses above, perhaps they help
> clarify.

Not really.  An example would be:

router> show ......

---->>> This line has foo and bar in it, which mean a leak.

Seriously, show me an algorythm to find a leak for a Anycast service
that does not require any pre-knowledge about how the Anycast service is
configured.  I submit such a thing does not exist.

If it doesn't, this draft does not advance anything, it recommends
one method out of many with no particular advantage, and at least one
easy to document disadvantage (inconsistent origin).

-- 
Leo Bicknell; E-mail: [e-mail], Phone: [phone]
INOC*DBA *3357*592; Internet Systems Consortium, Inc.  www.isc.org