On Apr 29, 2010, at 12:16 PM, Sriram, Kotikalapudi wrote:
May be we could include a BCP statement or warning within the
algorithm document for the (very few) users of AS sets.
If they use, for example, [AS42] or [AS42, AS42] type of AS set
for whatever reason (i.e., with singleton AS in the AS set
or the same ASN repeated multiple times) and also register a ROA for
their
prefix with that ASN (AS42 in the example) --
the BCP statement would warn them that
their ROA would thwart a potential hijacker of their prefix but
they should not expect to receive a positive ("Valid") assertion for
their
own update which contains that AS set as origin.
I am not following you here -- can you please explain what you mean by
"should not expect to receive a positive ("Valid") assertion for their
own update which contains that AS set as origin."?
Also, the same applies for cases when they actually do a genuine proxy
aggregation such as using an AS set [AS42, AS43, AS44] for example
and register three ROAs for their aggregate prefix for each
of the three ASNs. Again, they should not expect a positive ("Valid")
assertion for their own update which contains that AS set as origin.
Sriram
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
Behalf Of Geoff Huston
> Sent: Thursday, April 29, 2010 2:06 AM
> To: Chris Morrow
> Cc: Sandra Murphy; sidr wg
> Subject: Re: [sidr] SIDR Charter Question
>
>
> On 29/04/2010, at 5:24 AM, Chris Morrow wrote:
>
> >
> >
> > Sandra Murphy wrote:
> >> The relative frequency of use of AS_SETs is interesting, but
not really
> >> germane to the point here.
Well, I sort of think it is -- if 95% of routes contained AS_SETs in
the origin then saying that you just cannot validate routes with
AS_SETs in the origin is a non-starter.
> >>
> >> If we were trying to develop a protection for AS_SETs then we
might want
> >> to ask the engineering question of where and how often they
were used.
> >>
> >> But for the purpose of validating received updates, we need a
rule for
> >> what is done with AS_SETs that appear in the AS_PATH origin.
Lack of
> >> rules leaves opportunities for deliberate or accidental mischief.
Yes -- because their occurrence is not huge, we can make the call that
these routs just do not get the win...
W
> >>
> >> AS_SETs might not be used very often, but that doesn't stop
someone from
> >> using AS_SETs deliberately with malicious intent.
> >
> > right so as a starting point:
> > "AS_SET in an origin is unvalidatable."
> >
> > how about that? (I think this is fine since:
> > 1) they aren't used in production very much anymore
> > 2) where used, they seem to be mis-used
> > 3) the rules for how you do verification/validation of an AS_SET
are at
> > best murky.
> >
> > -chris
> > (regular user)
> >
>
>
> You ask: "how about that?"
>
> That still works for me. Ironically (or any other adjective that
matches - I can think of quite
> a few more extreme ones that I could substitute) this is
_precisely_ where all this started
> when I proposed using the following definition of an "origin
AS" (in my note from 4 April):
>
> "A route's "origin AS" is the final element of the route object's
> AS_PATH attribute. If the final AS_PATH element is an AS Set,
> indicating that the route is an aggregate, then the origin AS
> cannot be determined."
>
>
>
> Geoff
>
>
> _______________________________________________
> sidr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
--
"Build a man a fire, and he'll be warm for a day. Set a man on fire,
and he'll be warm for the rest of his life." -- Terry Pratchett
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
