On 22/11/2011, at 3:13 PM, Christopher Morrow wrote:
>
> 'if it is intended' ... means:
> a) "is intended to be seen at the vantage point it was observed at"
> (3 as-hops away)
> b) "with the as-path it shows up with" (isp1 - as1 - isp2 - me)
> c) something else?
>
> it's not clear what you meant, I'll assume b though...
>
to be specific, "it was intended to be seen at the vantage point it was
observed at, and in the form presented".
So something showing up 3 hops away might be fine provided the 3 hops are
intended to be isp1 - as1 - isp2.
>
> err, this didn't parse for me :(
> You mean you don't see the possibility of adding a transitive
> attribute to BGP, which some AS adds to a path (and signs into the
> announcement, so it has to be kept along the path) and is replicated
> with each as-hop?
>
yes. (and sorry for being terse)
> Something like:
> isp1 - as1 - isp2 - me
> out:is-cust in:is-transit out:is-transit in:is-cust out:is-cust
> in:is-transit
>
> So, isp1 signs toward as1 "is-customer"
> as1 signs from isp1 "is-transit"
>
> as1 signs to isp2 "is-transit"
> isp2 signs from as1 "is-customer"
>
the problem is that as1 can validly say "i don't do BGPSEC, but i'm still a
valid on path actor" and you have to trust that at face value even though as1
is maleficent. You need isp1 to say that isp1 & as1 have a valid transit
arrangement.
> isp2 signs to me "is-customer"
> me signs from isp2 "is-transit"
>
> Given that you'd have to configure (I suspect) each peering as
> 'peering' or 'transit' or 'customer' ...I don't see this flying
> either. :( I also don't see how to compute this on the local-router
> level either, given the information in the session, without an
> operator having to designate "this is a X" :(
>
right.
>>
>> History tells us we are (for the most part) inept at doing so, even with
>> tools available.
>
> I had thought that RIPE had this licked in their region, no? they have
> policy-foo encoded in RPSL-stuff in the DB no? Is that NOT working for
> the cases in region?
>
Probably they are the closest it gets, but a line from the ENISA paper sticks
with me:
"Unfortunately, the quality of the IRRs varies, which makes it difficult to
rely on them"
>> But what we do know is that when policy is implemented, the results are
>> transparent and can be seen
>> (ris, routeviews, et al) by anyone who cares to look.
>>
>
> sure... but the data isn't exactly always 'accurate' there, and it's
> not accessible to the 'user' (router in the field) really, and I think
> the data includes lots of helter-skelter cruft that's not very helpful
> for this case :(
I was simply using it to demonstrate that since transit routing relationships
end up in the RIS and routeviews as observable artefacts (cruft included),
advertising who you have a transit relationship in something like the AAO isn't
making any huge declarations of "I peer with company X" that can't be found by
other investigations.
Although in hindsight the AAO might not be fine grained enough. In some cases
an autonomous system may want to optionally list a set of prefixes that are
subject to a transit/peer relationship with an adjacent AS.. (and of course, in
some cases not)
>
> oh, I think danny's draft has a link between isp1/isp2 :(
> you probably meant here: "ISP1 and ISP2 directly connect, the path via
> AS1 is invalid/improper/a-leak" right?
That was my understanding.
>>
>>
>> The killer problem here is that partial deployments will create path
>> islands, where only a number of the ASN hops have created AAO objects and
>> thus a path validity exercise will still fall into a potential leak trap
>> until all ASNs get there. The question then could then be, "is it o.k. for
>> the answer to route leaks to be near unusable until we have a significant
>> deployment"
>>
>
> note sure, is that time also when we'd have full
> resource-certification and the tools mostly available to just filter
> people reliably/properly/everywhere? ('everywhere' for some value of
> all-customers-of-all-isps, and maybe including
> settlement-free-interconnects as well?)
>
That I don't know - crystal ball cracked when I tried to beat this year's NHL
results out of it.
T.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
