On Mon, Nov 21, 2011 at 11:15 PM, Terry Manderson <[email protected]> wrote:
>
> Speaking for myself on this one.
>
> On 22/11/2011, at 12:47 PM, Christopher Morrow wrote:
>>
>> ok, so if we step forward and ask for 'give me an attribute to
>> indicate customer/peer/other', would we then trust that? it'd be
>> (presumably) set per as-hop, is that anymore trustworthy than the
>> communities supposed above?
>>
>> (I'd also ask what the rules are for setting this sort of thing, but I
>> don't think that matters since we can't really trust the value in it)
>>
>
> So lets say (hypothetically) we adopt a requirement of this system to allow a
> relying party to parse a route and know if it is intended or not by some
> construction of verifiable information.
>
'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...
> I can't, for the life of me, see a transitive attribute _in_ BGP (signed or
> otherwise) making a positive step in trying to secure intent of the local AS
> as effected by a routing domain 2+ hops away.
>
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?
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"
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" :(
>>>
>>>
>>
>> yup, I don't think we're going to get to the fully publicly exposed
>> policy world though... are we? (we can't, I think, expect everyone to
>> expose that sort of thing, never mind keep it updated)
>
> 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?
> 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 :(
>>
>> yup... no-export/advertise were taken as 'advisory' communities that
>> networks MAY heed, but certainly weren't bound to do so.
>>
>> So, back to the question:
>> "Given BGP as it is today, how do you know if a route is a leak or not?"
>>
>> I suppose documenting: "One leak scenario is <see id name>" is a fine
>> thing, does it help to actually fix the problem though? I think what I
>> heard in the meeting and on the thread(s) here was: "Sure leaks are
>> important, there's not a way devised so far that distinguishes a
>> 'leak' route from a 'normal' route, more than 1 as-hop from the
>> 'source' of the leak.
>>
>> In the id/draft:
>>
>> isp1 isp2 - me
>> \ /
>> AS1
>>
>> I can't tell at 'me' that the route I see is a 'leak', just that I see
>> an as-path that is isp1-as1-isp2.
>
>
> The bit I think that is missing is some knowledge that isp1 asserts it has
> valid routing through isp2, and any other potential 'true' paths. (noting AS1
> is considered the 'Serleena' here)
>
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?
> From what I recall draft-huston-sidr-aao-profile takes a step in that
> direction. (insert my reluctance about tightly binding routing operations to
> allocation practice) in such that it only publicises the valid paths, through
> subsequent AAO's by by other ASNs. Thus if an AAO (in my reading) is created
> by isp1 with only an adjacency to isp2. It provides "me" with an ability to
> say that the received route with AS1 on path is invalid.
>
> The AAO doesn't dive into local policy, and if isp1 has a private peering
> with AS3, then it need not put that in an AAO and thus the business dealings
> remain private - everything else ends up being seen in routeviews over time.
> So this is one way... but not the only way.
>
> 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?)
-chris
> Cheers,
> T.
>
>
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
