Subject: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement

From: Dan York <[email-masked]>
Date: Tue, 6 Nov 2012 13:45:18 -0500

Here, in one easy-to-read article, is a great example of why we need RPKI and/or other "secure routing" technologies that verify the origins of route announcements:

http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about

Note: SIDR got a nice callout in the commentary on Hacker News: http://news.ycombinator.com/item?id=4747910  (the exact SIDR reference is here: http://news.ycombinator.com/item?id=4748108 )

-- 
Dan York  [email-masked]
http://www.danyork.me/   skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/danyork

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 6 Nov 2012 20:01:45 -0500

note I do want to see rpki/sidr deployment move forward, but...

On Tue, Nov 6, 2012 at 1:45 PM, Dan York <[email-masked]> wrote:
>
> Here, in one easy-to-read article, is a great example of why we need RPKI
> and/or other "secure routing" technologies that verify the origins of route
> announcements:
>

origin here doesn't seem to actually be bad.
path here seems to be unchanged from a possible path.
probably moratel shouldn't have tried to send all of their routes to
the rest of the world?
maybe the provider to moratel could have filter 'not moratel' routes?
(or filtered any of their routes... just like they didn't for
pktelecom in 07).

> Note: SIDR got a nice callout in the commentary on Hacker News:
> http://news.ycombinator.com/item?id=4747910  (the exact SIDR reference is
> here: http://news.ycombinator.com/item?id=4748108 )

yes, nice... sadly I'm not sure that sidr's work would have helped
here (aside from the possible early deployment steps of 'make
prefix-lists from rpki informed data from IRRs' ... of course, if you
can't be bothered to make prefix-filters to day :(

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Dan York <[email-masked]>
Date: Wed, 7 Nov 2012 09:11:10 -0500

Christopher,

> (or filtered any of their routes... just like they didn't for

Yes, someone else pointed out to me that this looks to be more of a standard "route leakage" that RPI / BGPSEC / etc. would have really done nothing to prevent.
> can't be bothered to make prefix-filters to day :(

Agreed, sadly... but the good news is that this whole thing did get more people thinking about the underlying router infrastructure.  So if it gets some people to wake up and pay more attention, I think that's a good thing.

Thanks,
Dan

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 10:13:49 -0500

On Wed, Nov 7, 2012 at 9:11 AM, Dan York <[email-masked]> wrote:
> Agreed, sadly... but the good news is that this whole thing did get more
> people thinking about the underlying router infrastructure.  So if it gets
> some people to wake up and pay more attention, I think that's a good thing.

yep.

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Nov 2012 10:25:23 -0500

>> some people to wake up and pay more attention, I think that's a good thing.

Chris, 
Given that all the RPKI/BGPSEC machinery fully deployed would NOT have helped here, what is your key desire for this RPKI/SIDR/BGPSEC work?  Is it simply for resource certification?

What do you believe we should do about THIS problem?  

This is precisely why we wrote the "leak" draft (and the IRR draft) - work areas which are somehow out of scope of the _secure _inter-domain _routing WG.  Heck, the Friday conflict with the GROW WG illustrates the disconnect here as well.

And if at the end of the day the answer is that we need IRR-esque capabilities anyway, and if we'd did just that we could remove most of the threats in the routing system, then we sure appear to be doing a helluva lot of work here while totally ignoring these problems?  

-danny

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 11:11:58 -0500

On Wed, Nov 7, 2012 at 10:25 AM, Danny McPherson <[email-masked]> wrote:
> Given that all the RPKI/BGPSEC machinery fully deployed would NOT have
> helped here, what is your key desire for this RPKI/SIDR/BGPSEC work?  Is

resource certification, in the form of RPKI, would at least remove a
barrier people put up about using IRR data to make prefix-filters...
so ideally we get some win with just RPKI.

Origin validation is also handy for the cases where people
mis-originate (happens some).
Path validation is handy for cases where people attempt to insert
false information into the path (for whatever reason they seem to
think is important).

there isn't data in bgp today data which tells you 'this path is a
leak'. Even at the immediately-leaked-to peer there isn't data in the
message that's helpful for this problem.

> it simply for resource certification?
>

go poke bdickson about his draft? (done several times, fyi)
figure out how to tell if the 'leak' is a 'leak' based only on bgp
data on the wire, from more than 2 as-hops away? (several proposals)

> This is precisely why we wrote the "leak" draft (and the IRR draft) - work

the leak draft submitted (the id I mean) doesn't say what a leak is in
any way that's helpful given the bgp data today from more than outside
the immediate leaked-to asn.

> areas which are somehow out of scope of the _secure _inter-domain _routing

I thought the determination was that there wasn't anything today in
BGP that would be available to tell you that the data you see is
actually a 'leak' and not a 'backup path' (or something similar,
hidden path not previously seen || new transit path coming online ||
....) and that SIDR asked IDR to make something be exposed, to which
IDR said: "Is this a problem? ask GROW folks pls to determine if there
is a problem to be worked on."  GROW hasn't seen input on this...

> WG.  Heck, the Friday conflict with the GROW WG illustrates the disconnect
> here as well.

take that up with the secretariat? I'm not sure how 'sidr chairs have
a conflict with grow chairs, since they are the same person' isn't a
clear signal to: "do not schedule these at the sametime".

>
> And if at the end of the day the answer is that we need IRR-esque capabilities

sure... and people willing to actually make filtering happen on their
bgp peerings (pccw seems to just not do that, at least not in any sort
of a reliable manner)

> anyway, and if we'd did just that we could remove most of the threats in the
> routing system, then we sure appear to be doing a helluva lot of work here
> while totally ignoring these problems?

the threats doc I think does try to outline other problems, and I
don't think anyone working on SIDR things is ignoring this problem.

-chris

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Nov 2012 11:33:47 -0500

> so ideally we get some win with just RPKI.

I agree we need resource certification, but if I now have to replicate policy data (e.g., ROAs) contained in that new system in IRRs and then fix the problems in the IRRs anyway, well...

> mis-originate (happens some).

And you can get that from IRR data today, without ANY of the machinery from rtr-rpki or BGPSEC.

> message that's helpful for this problem.

And I'm not convinced it needs to be in BGP.  NOT being in BGP could be considered a feature.

> data on the wire, from more than 2 as-hops away? (several proposals)

I'm not convinced that is the right approach, I don't think it needs to be IN BGP.  Hence the original route leak draft, which we just updated, mind you:

<http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02>

> the immediate leaked-to asn.

I don't believe this needs to be fixed IN BGP.

> is a problem to be worked on."  GROW hasn't seen input on this...

I don't think this needs to be done IN BGP.

> clear signal to: "do not schedule these at the sametime".

Telling, indeed..

> bgp peerings (pccw seems to just not do that, at least not in any sort

Agreed..

> don't think anyone working on SIDR things is ignoring this problem.

Not on my last read, e.g.:

" (These behaviors are not precluded by the specification for BGP, 
   and might be the result of a local policy that is not publicly disclosed.  
   As a result, they are not considered attacks.  See Section 5 for additional 
   discussion.)"

and

    "Moreover, route leaks are outside the scope of PATHSEC, at this time, 
    based on the SIDR charter."

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 11:35:41 -0500

>> clear signal to: "do not schedule these at the sametime".

apparently there's some action coming that may change this timing
problem ... or so I hear.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 13:37:45 -0500

> <http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02>

where to send comments/questions?

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Nov 2012 13:39:39 -0500

> where to send comments/questions?

Fine question, apparently out of the scope of _S_I_D_R.  Perhaps GROW, we should ask the chairs  :-)

-danny

---

From: Shane Amante <[email-masked]>
Date: Wed, 7 Nov 2012 13:39:42 -0500

Chris,

> message that's helpful for this problem.

Why isn't the above considered putting the cart in front of the horse?  Namely, there is this (seemingly) hard requirement that all information must be self-contained within BGP -- even though the above acknowledges that we CANNOT get this information out from BGP.  Shouldn't that suggest there is a pretty fundamental problem here wrt the current definition of the problem?

What's even more perplexing is the WG seems to accept that it's OK to accept substantial complexity in creating, exchanging, validating information using an "out-of-band" certificate repository system (RPKI) ... which is OK to be used for Origin Validation by BGP, but for some reason ... BGPSEC is saying that it cannot depend on external information sources for Path Validation (other than per-router/per-AS certs).  Something really does not add up on where lines appear to be arbitrarily drawn here.

-shane

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 13:42:55 -0500

>    As a result, they are not considered attacks.  See Section 5 for additional

yes, not ignored.

>     based on the SIDR charter."

right, change the charter?
find a way to describe the problem (which is what's been asked for for
~1+yrs now?).

The draft you reference up-thread isn't actually helpful, it doesn't
show how to know that the leak is a leak and not another backup path
coming to light for other reasons in the system.

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 13:48:46 -0500

On Wed, Nov 7, 2012 at 1:39 PM, Shane Amante <[email-masked]> wrote:
> Why isn't the above considered putting the cart in front of the horse?  Namely,
> there is this (seemingly) hard requirement that all information must be
> self-contained within BGP -- even though the above acknowledges that
> we CANNOT get this information out from BGP.  Shouldn't that suggest there
> is a pretty fundamental problem here wrt the current definition of the problem?

I think if you have only a bgp message to deal with that's all you
have to base your judgement upon. The SIDR work so far has added a
signature for origination and in BGPSEC proposes adding signatures as
part of bgpsec-path.

If you know of, or can create, or can find inexistence already, data
that helps solve the 'route leaks problem' please bring it forward. I
think the wgs involved here (at least: sidr, idr, grow) all have
agreed that the first step is:
  1) show/agree that this is a problem (route leaks)
  2) see if bgp data already has the right bits to fix this (idr)
  3) slap some verification on those bits

arguing about carts and horses isn't moving the above 3 steps forward.

> What's even more perplexing is the WG seems to accept that it's OK to
> accept substantial complexity in creating, exchanging, validating information
> using an "out-of-band" certificate repository system (RPKI) ... which is OK to
> be used for Origin Validation by BGP, but for some reason ... BGPSEC is
> saying that it cannot depend on external information sources for Path
> Validation (other than per-router/per-AS certs).  Something really does not

what external source?

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 13:49:34 -0500

> Fine question, apparently out of the scope of _S_I_D_R.  Perhaps GROW, we should ask the chairs  :-)

frankly I'm happy to add comments on the sidr list, or grow list or
you directly... my question perhaps was mis-phrased, I'll try again:

"Where would you like me (or others) to send comments on this draft?"

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Nov 2012 14:02:46 -0500

> coming to light for other reasons in the system.

The fact that even folks here were confused where RPKI/BGPSEC would be helpful and would NOT highlights the disconnect about what problems they're trying to solve for us in SIDR.  The draft was written as an attempt to help minimize confusion and it may have missed the mark but I'm told some have found it helpful.

How about this:  "We need a way to show how to know that the leak is a leak and not another backup path coming to light for other reasons in the system" (that might sound familiar :-).  The solution doesn't presuppose it's codified in BGP on the wire, and shouldn't preclude simply improving existing tooling and systems, of which many operators already employ (e.g., IRRs and static [persistent] AS path and prefix lists).

With the hyper-focus on publication of standard-based RPKI/BGPSEC in this WG I do concur that it's likely not the right place.  However, I would note that if I can solve most of the real problems above without BGP changes or any new systems then I may not need RPKI/BGPSEC work at all.  That said, I would hate to see SIDR be Standards-Track and "legislated" and not solve problems as fundamental as this, while the lower hanging fruit is steam-rolled by efforts here.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Nov 2012 14:04:40 -0500

> "Where would you like me (or others) to send comments on this draft?"

The authors welcome direct comments, their email addresses are in the draft :-)

-danny

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Nov 2012 14:06:43 -0500

>  1) show/agree that this is a problem (route leaks)

Do you believe this is a problem?  When describing events such as this as of late, what did you call it?

>  3) slap some verification on those bits

Are you presupposing this needs to be done *in* BGP?

-danny

---

From: Shane Amante <[email-masked]>
Date: Wed, 7 Nov 2012 14:15:30 -0500

On Nov 7, 2012, at 1:48 PM, Christopher Morrow <[email-masked]> wrote:
> have to base your judgement upon.

Uhhh ... please tell me how a BGPSEC router, receiving a BGP PDU from another AS, is supposed to validate a BGPSEC path signature without relying on *any* offboard systems whatsoever?

> The SIDR work so far has added a

Right, and for all that *additional* complexity & fragility it brings in to the global Internet Routing System it still doesn't solve for route leaks ... one of the more frequent & pernicious threats to Internet routing security.  Weak sauce.

> that helps solve the 'route leaks problem' please bring it forward.

The problem with the above is your mandating I present a solution for which, you yourself, acknowledge no such solution exists.  If we cannot accept and move past that, then how can we have a reasonable discussion on _alternative_ solutions that /are not/ solely in the control plane?

> I

The problem is in step #2, above.  Specifically, there's an unwillingness, which I don't understand, to accept that "bgp data may not contain the right bits to fix this".  If we're not willing to admit we have a problem (at step #2), then step #3 "slap some verification on those bits" ... is not doing anything to solve that problem, IMO.

>> Validation (other than per-router/per-AS certs).  Something really does not

Doesn't BGPSEC depend on the RPKI for publishing & retrieving of per-router/per-AS certs?

-shane

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 7 Nov 2012 20:04:20 +0000

Wasn't there a proposal along the lines of:

Create an attribute that says:
"I authorize you to announce this route to your provider"
The originator and all transited ASes must sign it.
Any AS can remove it.
If you receive an update without it (but with a bgpsec)
from a customer or peer, then human intervention
is required before accepting it.
This way, human intervention occurs before the problem, not after.

What happened to that proposal?
Was it Brian Dickson?

--
Jakob Heitz.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 15:52:55 -0500

(aside: ugh, your mail client doesn't wrap lines properly... or gmail
isn't re-wrapping properly)

On Wed, Nov 7, 2012 at 2:02 PM, Danny McPherson <[email-masked]> wrote:
> The fact that even folks here were confused where RPKI/BGPSEC would be
> helpful and would NOT highlights the disconnect about what problems they're
> trying to solve for us in SIDR.  The draft was written as an attempt to help
> minimize confusion and it may have missed the mark but I'm told some have
> found it helpful.
>
> How about this:  "We need a way to show how to know that the leak is a
> leak and not another backup path coming to light for other reasons in the
> system" (that might sound familiar :-).  The solution doesn't presuppose
> it's codified in BGP on the wire, and shouldn't preclude simply improving
> existing tooling and systems, of which many operators already employ
> (e.g., IRRs and static [persistent] AS path and prefix lists).

sure, with resource certification in place (rpki?) you can go fix up
irr data and go to town. that'd solve the problem, provided people
actually filter. evidence suggests they don't... and won't no matter
how 'simple' it seems.

could we have something in the protocol to do this for us as well? for
the cases of the operators who don't filter or won't filter or can't
filter or ?

could we have something in the protocol to tell a remote asn if this
is a leak or not?

not putting it in bgp is ok, but it seems like that limits things a bit, no?

> With the hyper-focus on publication of standard-based RPKI/BGPSEC in
> this WG I do concur that it's likely not the right place.  However, I would note
> that if I can solve most of the real problems above without BGP changes or
> any new systems then I may not need RPKI/BGPSEC work at all.  That

you'd need rpki, or resource-certification, which is all rpki is...
right? I don't think any 'make better filters' solution works without
resource certification.

> said, I would hate to see SIDR be Standards-Track and "legislated" and not
> solve problems as fundamental as this, while the lower hanging fruit is
> steam-rolled by efforts here.

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 15:53:26 -0500

> The authors welcome direct comments, their email addresses are in the draft :-)

great, also there's:
<mailto:[email-masked]>
I think...

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 15:56:33 -0500

> of late, what did you call it?

sure, but I'm not the grow-wg ... right? aim that question over ->
<mailto: [email-masked]> there.

> Are you presupposing this needs to be done *in* BGP?

I'm not presupposing, I'm saying that today you CAN do what you want
with IRR data, some folks do this with varying degrees of
success/failure. you could improve this with RPKI (or resource
certification)... you'd still be limited to those folks who do
filtering to begin with. You might pickup more filterers with 'more
simpler filteringz', but that's a gamble.

If you want to be closer to a solution, do it in the protocol that
sends the data around, tag the route with a bit(s) that say:
"customer" or "provider" or "transit" or "jimmyhat" ... sign that
bit(s) and let's march on.

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 16:11:41 -0500

(also, your mail client is not wrapping properly)

On Wed, Nov 7, 2012 at 2:15 PM, Shane Amante <[email-masked]> wrote:
> Uhhh ... please tell me how a BGPSEC router, receiving a BGP PDU from another
> AS, is supposed to validate a BGPSEC path signature without relying on *any*
> offboard systems whatsoever?
>

how does your browser verify the ssl certificate on your webserver?

> Right, and for all that *additional* complexity & fragility it brings in to the
> global Internet Routing System it still doesn't solve for route leaks ... one

if you don't want to do the bgpsec on your network, as an operator you
certainly have that choice. If you already filter customer routes (or
solve the route-leaks problem in another way) cool, you're probably
done?

> of the more frequent & pernicious threats to Internet routing security.  Weak
> sauce.

again, propose a solution. I don't think anyone has said 'we do not
want to listen to your problem', in fact many people have said: "yes,
its a problem, provide a solution".

also, resource-certification helps get to a filtering solution of more
worth/merit... so that's nice, and isn't more goop on routers or in
bgp... so, win?

> The problem with the above is your mandating I present a solution for which,
> you yourself, acknowledge no such solution exists.  If we cannot accept and

have you read brian's 3 drafts, do they help? are they a start to
helping? is it off-base?

also, I'm not really mandating anything... I'm just chatting.

> move past that, then how can we have a reasonable discussion on
> _alternative_ solutions that /are not/ solely in the control plane?

said several times, added here again: "if you want only to filter
routes with the equivalent of prefix-list + irr data, great!"

resource certification (rpki) seems like it will help to clean up the
filter data better/faster/cleaner than what's in the IRR today. it's
not in bgp, it's not in the control-plane... hurray.

if you don't think everyone will do filtering tomorrow (we already
know they don't today) then we probably should think outside the
static filtering realm.

> The problem is in step #2, above.  Specifically, there's an unwillingness, which
> I don't understand, to accept that "bgp data may not contain the right bits to fix
> this".  If we're not willing to admit we have a problem (at step #2), then step

what? isn't that what #2 says? I only outlined the steps forward as
agreed upon by the wg and chairs in the affected wgs... maybe I
misunderstood your question/point or ?

> #3 "slap some verification on those bits" ... is not doing anything to solve
> that problem, IMO.

> Doesn't BGPSEC depend on the RPKI for publishing & retrieving of

I think techically rpki is just the jumble of certificate data and
roas that talk about:
  o prefixes and ownership (right to use)
  o as ownerships/right-to-use
  o origination-information for prefixes/subprefixes (roas)

if you just want to 'solve' route-leaks, and you want to do that with
filters, you don't need to do anything to bgp.

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 16:13:45 -0500

> "I authorize you to announce this route to your provider"

I think it was some form of 'bit for transit' and 'bit for customer'
... but sure.

> This way, human intervention occurs before the problem, not after.

I think the proposal was to mark the route as 'bad' and then decide to
do somethign with it (or not... say lower-local-pref/med/etc or
discard/reject/drop - let the local operator decide what to do with
that class of problem)

> What happened to that proposal?

awaiting updates/edits/etc.. and I think moved from sidr to idr,
notionally at least.

> Was it Brian Dickson?

think so, yes.

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Nov 2012 16:22:50 -0500

> you'd need rpki, or resource-certification, which is all rpki is...  right?

No, there's lots of other stuff in there..

> I don't think any 'make better filters' solution works without resource certification.

I agree..

-danny

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 7 Nov 2012 21:28:18 +0000

Doesn't look like we missed that much. A few of the talks may have been interesting but most were buy our product based on whom was presenting and what their subject matter was:)

"Pampers use multiple layers of protection to prevent leakage. Rommel used defense in depth to defend European fortresses." (A.White) [email-masked]

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Christopher Morrow
>Sent: Wednesday, November 07, 2012 1:53 PM
>To: Danny McPherson
>Cc: [email-masked] list
>Subject: Re: [sidr] The need for SIDR - Google limited outage today due
>to bogus route announcement
>

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 7 Nov 2012 21:29:14 +0000

Sorry wrong list:(

>From: Smith, Donald
>Sent: Wednesday, November 07, 2012 2:28 PM
>To: 'Christopher Morrow'; 'Danny McPherson'
>Cc: [email-masked] list'
>Subject: RE: [sidr] The need for SIDR - Google limited outage today due
>Doesn't look like we missed that much. A few of the talks may have been
>interesting but most were buy our product based on whom was presenting
>and what their subject matter was:)
>
>
>"Pampers use multiple layers of protection to prevent leakage. Rommel
>used defense in depth to defend European fortresses." (A.White)
>[email-masked]
>
>

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Nov 2012 16:37:55 -0500

> simpler filteringz', but that's a gamble.

But forcing BGPSEC/RPKI on everyone is better?

Ohh, and you still have to solve the IRR-esque problem.  

And the RPKI/BGPSEC steamroller is squashing low-hanging fruit.

> bit(s) and let's march on.

Right, that's the disconnect.

IF you start with solving this IN BGP, you end up here [sidr].

-danny

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 17:00:31 -0500

> But forcing BGPSEC/RPKI on everyone is better?

no one is forcing bgpsec on people... this is a market economy, people
have to see the benefit and agree to use it.

> Ohh, and you still have to solve the IRR-esque problem.

ideally, in my world view, I can wrap my IRR lookup:
$ whois -h whois.radb.net -K -i mnt-by 'MAINT-AS15169' | head
Warning: RIPE flags used with a traditional server.
aut-num:    AS15169

route:      208.68.108.0/22
origin:     AS11344

and wrap that in some resource certification verification... then
output prefix-lists.

> And the RPKI/BGPSEC steamroller is squashing low-hanging fruit.

which low-hanging fruit? the 'you can make prefix-lists' one? or ?

> IF you start with solving this IN BGP, you end up here [sidr].

the work here didn't pre-suppose a solution in bgp itself... but
there's not much space outside of bgp if you need to solve the leaking
problem. it's fairly apparent that folk just don't deploy prefix
filters at-all/reliably/updated/etc.

if there's a way not in bgp and without resource-certification (rpki
data) to stop leaks it'd be great to talk about that. So far I've not
heard an answer, I've heard a lot of mish/mash but no 'how about X?'

SIDR has worked on a few things, one of which is RPKI, which is really
just 'resource certification'. It's added to that the idea that you
could verify the origin of a route you hear, and later that the
originator could sign the outgoing route such that folk down the line
could say: "Yes, that really did originate from FOO-AS". Later/now
it's trying to say that the other portion of the path (other than
origin) could be verified so you believe the path as you see it is the
path the route followed to get to you.

-chris

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Nov 2012 07:43:53 +0900

> leak and not another backup path coming to light for other reasons in
> the system" (that might sound familiar :-).

yes it does.  what is not familiar is any actual proposed engineering
approach to solve it beyond brian dickson's drafts.  and i was hoping
those would be updated and discussed.

what i see instead is a bunch of noise about process and "it need not be
in X."  i simply do not have the spare time for that.  i would deeply
love to hear actual proposed solution(s).

randy

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 7 Nov 2012 17:47:11 -0500

> (also, your mail client is not wrapping properly)

How's my client treatin' ya? :-P

> how does your browser verify the ssl certificate on your webserver?

I can take a whack at that: not well?  I think DigiNotar helped to illustrate some of the dangers here... Just sayin... ;)

> its a problem, provide a solution".

<broken record>
The offer to provide input to the threats and requirements docs is a genuine attempt to help.  For real! :)  I have the sneaking suspicion that this week's... err, event... cost some people some sleep.  I feel like we _should_ be addressing it, no?
</broken record>

> worth/merit... so that's nice, and isn't more goop on routers or in

I agree that resource certification is a critical component.

> know they don't today) then we probably should think outside the

But couldn't we also claim that they won't do any next-gen anything tomorrow (rpki/bgpsec)?  In that sense, wouldn't the above comment be a bit pedantic statement?

> misunderstood your question/point or ?

I think I read in Shane's response that the idea that bits should be added to BGP is false logic.  The fact that these bits are not in BGP today, does not mean they should be put there tomorrow.  My 0.02 is that there seem to be enough complexities in the policy semantics that the amount of effort needed to get the minimum level of expressiveness into BGP could be a non-starter...  Just my 0.02...

>  o origination-information for prefixes/subprefixes (roas)

I think there's a very complicated replication and fetching hierarchy too.  afaict, there is a huge amount of evaluation left to do just to illustrate the scaling properties and systemic dependencies of the substrate that serves these objects of the rpki...  Well, we've seen some surprising complexity and worrisome performance curves in our preliminary evaluations and simulations.  In short, I think the above misses some of the issues.

> filters, you don't need to do anything to bgp.

What are we (as a wg) trying to solve? I.e. shouldn't we be talking about threats and requirements?

Eric

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Nov 2012 17:54:45 -0500

On Nov 7, 2012, at 5:43 PM, Randy Bush wrote:

> yes it does.  

Eh?

> in X."

Do you understand what happened to Google here Randy?

Do you believe it's a problem?

Do you believe we "ought" to try to solve it somewhere?

Do you believe it's fine to deploy RPKI and BGPSEC and ignore this?

People believe RPKI / BGPSEC solves this problem in the form of path validation.  It does NOT.  

>  i simply do not have the spare time for that.  i would deeply

I'd like to agree on problems first. 

-danny

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Nov 2012 07:57:04 +0900

> I'd like to agree on problems first. 

[ i note lack of engineering suggestions ]

as has been said many times, we agree route leaks are a problem.  they
are not the only problem.

please do not send me any more email without a proposed solution.

randy

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 7 Nov 2012 18:08:49 -0500

> path the route followed to get to you.

Right, but did anyone who was involved in remediating that Moratel leak say, ``we're all set, I can see the path of the leak, it's miller time!''?  I'm pretty sure verifying the leak is not the same as remediating it.

Eric

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 18:10:14 -0500

> How's my client treatin' ya? :-P

just as broke, bug lodged (I hope) for a fix.

> of the dangers here... Just sayin... ;)

point wasn't that multiple-uncontrolled/decentralized certificate
authorities were a failure. it's a fair point though, which was why
'single root pls' was/is asked for here.

> The offer to provide input to the threats and requirements docs is a genuine
> attempt to help.  For real! :)  I have the sneaking suspicion that this week's...
> err, event... cost some people some sleep.  I feel like we _should_ be
> addressing it, no?
> </broken record>

don't disagree, haven't disagreed. (I think)
I'm not sure how much sleep got lost, or anything else really about
it... except that if the route was originated by the origin-asn in the
reported CLI output and the path seen wasn't forged,
bgpsec/origin-validation wouldn't have helped.

nor did filtering on the upstream/customer peerings (clearly)... so
folk that want to fall back on 'but de filterz!!' .. are also in
failville.

> But couldn't we also claim that they won't do any next-gen anything
> tomorrow (rpki/bgpsec)?  In that sense, wouldn't the above comment
> be a bit pedantic statement?

maybe? folk have to see a benefit to any of this in order for it to
move into production use. if as a first step resource certification
work gets me better filtering and/or more people filtering because
more reliable filtering is possible, good.

eventually though, people will realize that:
  1) not everyone is filtering
  2) not everyone will filter
  3) the only solution left is something in the bgp update :(

if there is another '3', let's talk about that.

> I think I read in Shane's response that the idea that bits should be added to
> BGP is false logic.  The fact that these bits are not in BGP today, does
> not mean they should be put there tomorrow.  My 0.02 is that there

that's not what I read, but ok.

where else does the data from which you make a decision about 'leak or
not' come from?

> seem to be enough complexities in the policy semantics that the amount
> of effort needed to get the minimum level of expressiveness into BGP
> could be a non-starter...  Just my 0.02...

perhaps you could explain more/better this problem.

> I think there's a very complicated replication and fetching hierarchy too.  afaict,
> there is a huge amount of evaluation left to do just to illustrate the scaling
> properties and systemic dependencies of the substrate that serves these

this is less concerning... and it's beside the discussion of leak-or-not.
as noted on-list more than one time I'd love to see some scaling and
such work done on the certificate repository... that's not today's
problem though.

> objects of the rpki...  Well, we've seen some surprising complexity and
> worrisome performance curves in our preliminary evaluations and simulations.
>  In short, I think the above misses some of the issues.

sure, but not the issue about leaks, so another thread and another day.

> What are we (as a wg) trying to solve? I.e. shouldn't we be talking about threats

i think we are/were.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 18:14:27 -0500

On Wed, Nov 7, 2012 at 6:08 PM, Eric Osterweil <[email-masked]> wrote:

> Right, but did anyone who was involved in remediating that Moratel leak say,
> ``we're all set, I can see the path of the leak, it's miller time!''?  I'm pretty
> sure verifying the leak is not the same as remediating it.

but today we're stuck 'verifying' by the fact of: "joe user says the
internet gone bye-bye"

again: What methodology or tool or data or ... would you use (and how)
to determine if the route you see is a 'leak' or not?

-chris

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Nov 2012 18:17:05 -0500

On Nov 7, 2012, at 5:57 PM, Randy Bush wrote:

> we agree route leaks are a problem.  

Excellent, progress....  

> please do not send me any more email without a proposed solution.

I'll note that this email was NOT to you, Randy, it was to the [email-masked] mailing list.  You are NOT the WG, as hard as that may be to hear. 

Quite frankly, my problem is that you in your tours to the FCC and DHS and NOGs the world around have done such a bang up job making folks believe RPKI-enabled BGPSEC path validation is lightweight and solves all the problems that I as an operator should care about with regards to routing security -- when I consider this a gapping hole.

I have not pre-envisaged a solution.  As an operator I want the people designing the solution to recognize this is a problem that needs to be solved.

If I hadn't seen folks suggest they would expedite this work through the Internet standards and convince the USG to put these Standards Track documents in procurement materials to "foster" adoption, I'd go away and not care.

-danny

---

From: Shane Amante <[email-masked]>
Date: Wed, 7 Nov 2012 18:17:32 -0500

Chris,

> how does your browser verify the ssl certificate on your webserver?

OK, so you appear to admit that offboard systems are needed (in fact, critical?) for validation.  Yet, the design space for BGPSEC has been specifically restricted to that which can *only* be solved with data carried in BGP itself.  (See below for why I make this statement).

[--snip--]

> its a problem, provide a solution".

I can't, nor do I believe can anyone else.  I refer you to the following:
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-03#section-5
---snip---
   o  "Route leaks" are viewed as a routing security problem by many
      operators, even though there is no IETF-codified definition of a
      route leak.  BGP itself does not include semantics that preclude
      what many perceive as route leaks.  Moreover, route leaks are
      outside the scope of PATHSEC, at this time, based on the SIDR
      charter.  Thus route leaks are not addressed in this threat model.
---snip---

First, the threats document says "there is no IETF-codified definition of a route leak", even though there exists the following: <http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02> and, apparently, based on other messages /no where in the IETF to even discuss it/!  Second, there is this sentence: "BGP itself ***does not include semantics*** that preclude what many perceive as route leaks." ... That statement reads to me as stating that _because_ BGP does include semantics to solve for route-leaks, it's out-of-scope for PATHSEC.

Trimming the rest as irrelevant to the core of the argument here.

-shane

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Nov 2012 08:33:22 +0900

> I'll note that this email was NOT to you, Randy

the header says otherwise.

> I have not pre-envisaged a solution.

http://en.wikipedia.org/wiki/Serenity_Prayer

randy

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 7 Nov 2012 18:38:15 -0500

> just as broke, bug lodged (I hope) for a fix.

But, but, it works for me... jk ;)

> don't disagree, haven't disagreed. (I think)

I hear ya, but I feel like this obviates our need to begin discussions with new design proposals.  How can I offer you a design if we don't agree on what it should do, right?

> folk that want to fall back on 'but de filterz!!' .. are also in

Which of the parties was filtering?

> move into production use.

Right on...  I think that kind of thinking is really what's motivating a lot of leak-based-discussion.  Quick wins might come in plugging leaks, so... on to the threats doc? :-P

> if as a first step resource certification

Yeah, we're on the same page w/ resource certification being a prerequisite.

> if there is another '3', let's talk about that.

Just to follow the same logic, could I not say,
1) not everyone is running bgpsec [clearly, it's not here yet]
2) not everyone will run bgpsec [therefore there will be isolated islands]
3) the only solution left can't be something in the bgp update?

> where else does the data from which you make a decision about 'leak or

My understanding is that we need to fallback to intent.  With some way to expose and verify intent, we get there.  Discussing how to do that seems like the right first step, imho.

> perhaps you could explain more/better this problem.

Maybe I could just say, today we have a very complex policy specification language, and it's not clear how much of it is used, by whom, and to what extent... If we were to say, ``throw it all in an update,'' I think we'd see BGP updates bigger than the bgpsec updates.  As of now, if we can't agree that leaks are a problem worth addressing and/or we can't agree on what leaks actually are, how could we _not_ use a very verbose language to expose relevant policy?

>>> I think techically rpki is just the jumble of certificate data and roas that talk about:
<snip>
> this is less concerning... and it's beside the discussion of leak-or-not.

Yeah, but I didn't bring it...  I just wanted to clarify the above comment.  I didn't mean to distract, but felt the clarification was important.

> such work done on the certificate repository... that's not today's

Yeah, working on that for sure...

>> What are we (as a wg) trying to solve? I.e. shouldn't we be talking about threats

Then I would propose that the insistence on only submitting solutions before allowing requirements discussions is not appropriate.

Eric

---

From: Danny McPherson <[email-masked]>
Date: Wed, 7 Nov 2012 18:38:42 -0500

[I trust you're not reading this RB]

> http://en.wikipedia.org/wiki/Serenity_Prayer

Beautiful...

1) "God, grant me the serenity to accept the things I cannot change,"

Fitting..

2) "The courage to change the things I can,"

I'm trying..

3) "And the wisdom to know the difference."

'nuff said...

-danny

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 7 Nov 2012 18:46:46 -0500

> but today we're stuck 'verifying' by the fact of: "joe user says the

Uhh, point of order, I believe there would be a belch in there somewhere? ;)

> to determine if the route you see is a 'leak' or not?

This is where my record get's stuck, can we put this in the threats and requirements doc?  I suspect there are a lot of ways people could suggest we address these problems, but as of now, (as a valid security threat) it's essentially outlawed by the threats document.  If people spend a lot of time addressing this security problem, the result could be dismissed as not being in-scope.  Why begin pushing on ideas if that is their fate?

Eric

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Nov 2012 08:56:21 +0900

> I hear ya, but I feel like this obviates our need to begin discussions
> with new design proposals.  How can I offer you a design if we don't
> agree on what it should do, right?

eric, folk agreed loooong ago that there is a class of problems we call
leaks, and that they adversely affect operations.  shane/danny did a
draft starting to try to define the class.  brian wrote a bit on his
approach but did not follow through.  i am in correspondence with some
chinese folk who are thinking about the problem.

but there is no actual proposal, other than brian's dropped one, for a
solution.  and, in the ietf, we tend not to put things in charters we
are not confident of achieving.

to me, the core of the problem is what semantics need to be communicated
and the set of actions a distant player is expected to perform and what
effect those actions should have.  once we understand that, we can worry
about the syntax and how it's transported.  i.e. any bgp, dns, rpsl, foo
transport discussion is just noise at the moment.

randy

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 7 Nov 2012 19:13:44 -0500

On Nov 7, 2012, at 6:56 PM, Randy Bush wrote:

<snip>
> in the ietf, we tend not to put things in charters we

My point has been that I believe we _can_ address this problem, but comments in the mail archives and the threats draft itself outlaw this work.  I really feel that we need to at least acknowledge them in the threats doc.

> transport discussion is just noise at the moment.

Let's say there _is_ a solution, but there's another solution for _other_ threats.  How do we (as a wg) judge the relative merits of the two approaches if we don't recognize all of the threats?

To illustrate: Let's say that I'm afraid of bears and rats, but rats are easier to catch, so I ignore bears.  I would not want to try and use a rat trap to catch a bear, but that doesn't mean that bears aren't able to break into the pantry in my mountain cabin while I'm there...  Now, couple that with how much one has to invest in various solutions and you may choose not to want to invest in very expensive rat traps during spring (when bears wake up and go lookin fer fud). :)

I think we can get there, but either way, there is a ``there...''  Just my 0.02,

Eric

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 21:04:28 -0500

> But, but, it works for me... jk ;)

it's (apparently, or hopefully) a display only problem... which causes
pita behavior for the responder (me in this case) if i want things to
sort of look legible.

> I hear ya, but I feel like this obviates our need to begin discussions with new
> design proposals.  How can I offer you a design if we don't agree on what it should do, right?

'it should stop leaks' or as someone else said:  "Show how to know
that the leak is a leak and not another backup path coming to light
for other reasons in the system"

> Which of the parties was filtering?

neither it would seem.

> Right on...  I think that kind of thinking is really what's motivating a lot of
> leak-based-discussion.  Quick wins might come in plugging leaks, so...
> on to the threats doc? :-P
>

not sure it quite goes that way, but i (and I think everyone else) do
see that not everyone
in the bright/new/shiney/future future will be happily configured and
using bgpsec. Even if everyone does, it's fairly clear that there will
be a range of answers to "the route signatures dont match".

There's a clear entrance/exit protocol for the 'islands'... this isn't
getting us to a 'what is a leak, in a way I can tell from even a
directly connected peer' though.

> My understanding is that we need to fallback to intent.  With some way to expose
> and verify intent, we get there.  Discussing how to do that seems like the right first
> step, imho.

ok, see brian's docs... i think.

> Maybe I could just say, today we have a very complex policy specification language, and
> it's not clear how much of it is used, by whom, and to what extent... If we were to say,
> ``throw it all in an update,'' I think we'd see BGP updates bigger than the bgpsec updates.

why?

>  As of now, if we can't agree that leaks are a problem worth addressing and/or we can't

everyone stop... 'if we can't agree that leaks are a problem worth addressing'

everyone (well, almost everyone I've read) has agreed they are a
problem. Even one worth addressing. There's a path that, follow the
path.

now, re-read the above. please.

> agree on what leaks actually are, how could we _not_ use a very verbose language to
> expose relevant policy?
>
> Yeah, but I didn't bring it...  I just wanted to clarify the above comment.  I didn't mean
> to distract, but felt the clarification was important.

ok, it didn't seem to clarify... just distract. on we go though!

> Yeah, working on that for sure...

excellent.

> Then I would propose that the insistence on only submitting solutions before
> allowing requirements discussions is not appropriate.

i had thought the requirement was 'stop leaks'.
if so, again: great.
also, again: how.

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 21:34:42 -0500

> I can't, nor do I believe can anyone else.  I refer you to the following:

i don't know what your first sentence means.

>       charter.  Thus route leaks are not addressed in this threat model.

admittedly I'd have probably said in parts:
"'Route leaks" are viewed as a routing security problem..."
   with a reference to the draft in the GROW-WG that talks about how
route leaks are a problem to be resolved.

> First, the threats document says "there is no IETF-codified definition of a route leak",
> even though there exists the following:
> <http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02> and,
> apparently, based on other messages /no where in the IETF to even discuss it/!

I think the 'codified definition' Stephen's looking for is an rfc... I
could be wrong though.
I also think there are several messages that tell you where you could
talk about route leaks. (in the ietf I mean).

>  Second, there is this sentence: "BGP itself ***does not include semantics*** that
> preclude what many perceive as route leaks." ... That statement reads to me as
> stating that _because_ BGP does include semantics to solve for route-leaks, it's
> out-of-scope for PATHSEC.

read the sentence again, I think you misread it.

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Nov 2012 12:22:16 +0900

<pedantry>

> "'Route leaks" are viewed as a routing security problem..."

route leaks, as we anecdotally know them, are an operational problem.
imiho, they are not particularly a security problem.  but that does not
mean i think the ietf routing community should not be working on a
solution, quite the opposite.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Nov 2012 22:30:01 -0500

> route leaks, as we anecdotally know them, are an operational problem.

sure, I was actually mostly quoting the draft, probably that comment
belongs to the editor/authors. (my comment)

---

From: Shane Amante <[email-masked]>
Date: Thu, 8 Nov 2012 00:00:45 -0500

> route leaks are a problem to be resolved.

Nice try; however, you didn't address the crux of the matter, which are these statements in the threats document:
---snip----
                  BGP itself does not include semantics that preclude
     what many perceive as route leaks.  Moreover, route leaks are
     outside the scope of PATHSEC, at this time, based on the SIDR
     charter.  Thus route leaks are not addressed in this threat model.
---snip----

IMO, until those latter three statements are stricken from the threats draft, it IS NOT worth anyone's time or effort in bringing forth any proposed solutions, because it's very easy to dismiss them as "out-of-scope".

> I think the 'codified definition' Stephen's looking for is an rfc... I

If that's all it took, could the authors of draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02 ask for it to be published as an RFC via the Independent Submissions process?  I imagine -- but I could be [very] wrong -- that the Independent Submissions process does not meet the rigor of an "IETF-codified definition of a route leak" that is stated in the route-leaks document.  Thus, that Independent Submissions process would be pointless.  So, the question is: what WG and/or IETF process does it need to go through?

> talk about route leaks. (in the ietf I mean).

Let me go pour over the recent barrage of list messages to see if I can find that ...

> read the sentence again, I think you misread it.

I don't think so.

-shane

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 8 Nov 2012 00:13:33 -0500

> Nice try; however, you didn't address the crux of the matter, which are these statements in the threats document:

ugh, i keep trying to be polite and point out that:
  1) no one said you can't discuss this
  2) no one said that leaks aren't a problem
  3) the process to get this problem addressed was discussed and
agreed upon in prague (I believe) - about 1yr ago in any effect.
  4) continuously going around the mulberry bush isn't getting to a solution.

please:
1) go get grow to agree that this is a problem (this should not be
hard, apparently)
2) go get IDR to either provide the semantics in BGP OR aim you in
another direction that does not include BGP as a transport/signaling
protocol
3) if 2 == idr-work, happily bring that here so we can deal with it properly.

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 8 Nov 2012 00:14:29 -0500

>> read the sentence again, I think you misread it.

you did:

"does not include"

"does include"

missing word important.

---

From: Russ White <[email-masked]>
Date: Fri, 09 Nov 2012 21:16:48 -0500

> if there is another '3', let's talk about that.

I don't think the conclusion follows from the premises, because it assumes:

1. Specifying new information in the BGP update will have the magical
powers of forcing the deployment of said system.
2. The information required to resolve this problem cannot be carried in
some other way, nor expressed with something other than a filter --or
even that filters cannot express the solution to the leak issue.

I find both of these presuppositions to be problematic, at best.

> where else does the data from which you make a decision about 'leak or

Lots and lots of places. Proposals have been made in the past, only to
be shot down because they don't resolve the "man in the middle attack"
(which is also a policy failure rather than "attack," and it has nothing
to do with "a man in the middle").

Reality check:

1. Leaks are caused, essentially, by someone who isn't following policy.
2. Providers have said (on this list and otherwise) that they are not
willing to release _any_ policy in _any_ way, _ever_ into the hands of
_anyone_ (even, "this peer is not a transit AS").
3. Any solution actually adopted _must_ be able to prevent leaks of this
type, or it's essentially adding a lot of complexity and overhead for
very minimal (or no) gain.

Given these three points, we have an impasse. There are three possible
solutions to this impasse:

1. Providers realize that much of the policy at the heart of preventing
a leak is pretty much already public knowledge (if you're careful in
analyzing the BGP table), and hence #2 is a red herring.
2. Create a system that allows you to announce enforceable policy
without telling anyone what that policy is. I hear there is research in
this area, but I've never seen the problem actually solved.
3. Do nothing.

There might be a #4, but I imagine what it is.

Russ

-- 
<><
[email-masked]
[email-masked]

---

From: Russ White <[email-masked]>
Date: Fri, 09 Nov 2012 21:30:19 -0500

> There might be a #4, but I imagine what it is.

-- insert "can't" in the appropriate place. Fingers faster than brain
problem.

:-)

Russ

-- 
<><
[email-masked]
[email-masked]

---

From: Danny McPherson <[email-masked]>
Date: Sat, 10 Nov 2012 11:46:19 -0500

> _anyone_ (even, "this peer is not a transit AS").

Actually, some subset of providers allegedly said this.  I've not seen any actual catalog of who, but it is certainly NOT everyone.  Lots of other folks do this today, via the IRRs, warts et al.  You can get "valid origin" capabilities anywhere without touching the protocols at all.  

> very minimal (or no) gain.

Concur.

> analyzing the BGP table), and hence #2 is a red herring.

Agreed.  And given that providers don't even have a system that allows them to automatically configure their customers based on certificated data, well, can't necessarily blame them when these event occur. 

Proceeding directly to RPKI-enabled BGPSEC and ignoring this problem as acceptable residual would mean you're more concerned about what's routed on the Internet, as opposed to the broader operational security implications.  

I could understand why governments or RIRs might find utility in that, but given that neither is in the current operational system and now will be, this gives me pause.  Especially with the weight of what's being proposed, where "large scale" measurements don't even represent 1% of today's Internet, or consider things like rollover and other soft state that routers would need to process and effectuate reachability upon.

-danny

---

From: Russ White <[email-masked]>
Date: Sat, 10 Nov 2012 21:05:38 -0500

> please do not send me any more email without a proposed solution.

Generally speaking, the best path to good engineering is to define the
problem first, then suggest solutions. I understand this isn't the way
SIDR works --solutions are proposed, to be followed by problem
statements, but we are talking about the way engineering should be done,
not the way it's been done here historically.

Please do not send any more email (or drafts) without a clearly defined
problem.

Russ

-- 
<><
[email-masked]
[email-masked]

---

From: Russ White <[email-masked]>
Date: Sat, 10 Nov 2012 21:26:34 -0500

> solution, quite the opposite.

You're walking through the office and see someone picking papers up off
your desk. Do you ask if they are properly signed in, and through which
door they entered? Or do you ask what their intent is and whether or not
they're authorized to be there (which is still intent)? If you receive a
route, you need to know more than who touched it to know if it's correct
or not. You must know the intent so you can compare it to the reality
you see in front of your face.

We've been walking around this problem of intent for years, trying to
mask it out of the problem to be solved, because we somehow think it
can't be solved. The latest attempt is to call it an operational problem
and push it to GROW.

Three points:

1. The problem of intent was always going to come back and bite us where
it hurts. This small incident just illustrates the scope of the problem.

2. Including signed "evil bits," doesn't solve anything in the long run,
because they're still just "evil bits." Are you planning on having a new
bit for every possible intent? And carry them all the way through the
system although someone four hops away really doesn't care?

3. It's sweet that everyone is trying to push the problem onto GROW, but
if you do that, expect to take GROW to take over your entire charter (or
all the meaningful work in this space), because knowing intent is the
only problem worth solving here.

Suggestions have been made before and rejected in this space, and more
suggestions are available (if you take five minutes and poke around
looking for them). However, it's always going to be difficult to get
alternate options through a working group founded on the premise of
standardizing on specific solution, rather than solving a problem.

Don't ask for suggestions unless you really mean it. And if someone
gives you one, listen, rather than throwing them out on their ear.

Russ

-- 
<><
[email-masked]
[email-masked]