Subject: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt

From: [email-masked]
Date: Mon, 18 Nov 2013 15:01:46 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Global Routing Operations Working Group of the IETF.

	Title           : Route-Leaks & MITM Attacks Against BGPSEC
	Author(s)       : Danny McPherson
                          Shane Amante
                          Eric Osterweil
                          Dave Mitchell
	Filename        : draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt
	Pages           : 8
	Date            : 2013-11-18

Abstract:
   This document describes a very simple attack vector that illustrates
   how RPKI-enabled BGPSEC machinery as currently defined can be easily
   circumvented in order to launch a Man In The Middle (MITM) attack via
   BGP.  It is meant to serve as input to the IETF's Global Routing
   Operations Working group (GROW) during routing security requirements
   discussions and subsequent specification.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-simple-leak-attack-bgpsec-no-help

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Geoff Huston <[email-masked]>
Date: Fri, 22 Nov 2013 09:48:26 +1100

On 19 Nov 2013, at 10:01 am, [email-masked] wrote:

Abstract:

In the unfortunately rich and lengthy saga relating to efforts to secure BGP, I
understood that the way things were arranged in the IETF to tackle this topic was
that the RPSEC working group was tasked with documenting the requirements for
work on technology for securing BGP. The WG managed to achieve consensus on
requirements for origination, but never managed to completely resolve some
difference of opinion over AS Path requirements. Some WG members evidently
felt strongly that what was necessary and sufficient was that the AS PATH
attribute should accurately reflect the sequence of AS's traversed in the
propagation path taken by the NLRI, and that this was necessary and sufficient.
Others disagreed. Some disagreed on the basis that the update path was not necessarily
precisely aligned to the asserted AS Path. and others disagreed because even correct
protocol operation was still vulnerable to behaviours that looked like policy
violations (e.g. customers transforming themselves into transit ASs for certain
prefixes).

The SIDR WG at the time was chartered to work on requirements as they were provided
by the RPSEC WG, and at one point, as I understood it, the Routing ADs at the time  got
impatient with RPSEC and effectively directed the SIDR WG to commence work on securing
the AS Path attribute in the absence of agreed requirements from RPSEC, and placed into
the charter of the SIDR WG a set of requirements that were aligned to the "protocol
correctness" perspective, and thereby ignored the other considerations relating to
path validation.

The ideas presented in this route leaks draft are by no means novel - the archives of
RPSEC probably contain this same material many times. But the underlying issues it
exposes are very real, and it does expose what for me is a critical weakness in the
decision by the Routing ADs at the time: hasty decisions that attempt to gloss over
deep divisions are generally very poor decisions.The deeper issue in the path discussion
in RPSEC was a discussion over policy intent vs protocol correctness.

This draft contains a good example of this - in terms of protocol a customer propagating
to one (or more) of its transit upstreams routes learned from other upstreams is not
incorrect in terms of protocol operation - and non-policy-based AS Path security mechanisms
will not detect the anomaly.

So what ARE the requirements for path validation in a secure model for BGP? Is it like
DNSSEC where, if I paraphrase the DNSSEC objective: "If everybody signed everything
in the DNS, then any form of lies in DNS responses would be readily exposed as such by
anyone who cared to  look"? Or is it a far weaker requirement: "We just want to reduce,
but not eliminate, the number of ways in which actors can lie in BGP"?

We have the latter form of outcome. All this work in SIDR is intended to reduce the
ways in which you can lie in BGP, not to allow any party to detect any form of perversion
of routing updates. Its by no means a "complete" solution to securing inter-domain
routing, but in our haste to comply with the timelines dictated by DHS's project funding
I guess we've got what DHS were prepared to pay for, and not what we actually
wanted or need. And for many its an unsatisfactory outcome.

So with this WG draft, it looks to me GROW is now hosting a re-opening a discussion of the
requirements for AS Path validation in BGP, and once again examining the differences
between correct protocol operation vs correct alignment to routing policy intent.

Why are we using GROW to host this discussion?

What are GROW's intended objectives in considering this draft?

And if I ignore the WG / Area IETF procedural gunk, on a more general level, are we ready
to admit that the work performed by SIDR has been performed to such a level of haste that
the quality of the underlying security mechanisms are compromised by attempting
to drive the process according to a timetable largely dictated by the requirements of the
major external funding agency at the time, namely the DHS?

And if we are ready to reopen this consideration of requirements for securing the operation
of BGP, just how much of this are we willing to re-consider? Is it all the way back to
RPSL and RPSS?

Geoff

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 21 Nov 2013 23:43:40 -0500

On Thu, Nov 21, 2013 at 5:48 PM, Geoff Huston <[email-masked]> wrote:
> but in our haste to comply with the timelines dictated by DHS's project
> funding

just asking about one part here... so DHS aside, because i'm not sure
that who the funder is is relevant to the work, exactly...  what
options are there for securing more than the aspath?

for example: origin ?
                  metric
                  communities
                  pick other attributes...

all of these are subject to change today, none of them seem to have a
great deal of useful meaning beyond the first as-hop? This topic came
up a bit with discussion about the threats document in SIDR recently,
and I was able to find:
  http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-04#section-2.4

which at least talks about the reason no other attriibutes were added
to the secured part of the process.

Additionally, the draft in question here still doesn't say how you'd
know 'thats a route leak' more than 1 as-hop away form the 'leak'. (it
also doesn't take into account any of the comments I provided to the
authors :(  which is another matter entirely)

-chris

---

From: Geoff Huston <[email-masked]>
Date: Fri, 22 Nov 2013 17:33:12 +1100

Geoff

---

From: Geoff Huston <[email-masked]>
Date: Fri, 22 Nov 2013 20:47:47 +1100

> options are there for securing more than the aspath?

As I understand the draft correctly, the draft is saying even if you secure ASPATH
along the lines proposed in secure BGP, there are still ways in which an attacker can
inject a path that was not intended by the originator.

So the question that the draft raises in my head is is it possible to communicate
routing policies in a secure manner?

> authors :(  which is another matter entirely)

so we get back to RPSL.

But I am still wondering:...

 [...]

Geoff

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 22 Nov 2013 10:57:49 -0500

> inject a path that was not intended by the originator.

inject a path... hrm, I'm not parsing that properly I bet.

Did you mean prepend on random asns? (no, don't think so, not and stay
validated)
Did you mean pull a route down a customer link and pass it back up the
hill to the other transit? (sure, but that's known, right?)

> routing policies in a secure manner?

so far this keeps coming up and keeps ending in a deathspiral of:
  "People don't want to share their byzantine routing policy stuff 'publicly'"

or:
  "sure, you could make a global registry of routing policy... isn't
rpsl that? and it's working out how well so far?"

>> authors :(  which is another matter entirely)

maybe? though I'm not sure that it's any more helpful than just IRR
based filtering with prefixes only and no policy-foo. People have to
be willing to be pretty damned specific in their policy language
there.. Is 702 going to publish that they are a transit of NTT in
Japan?

> Why are we using GROW to host this discussion?

So.. I think part of this is:
  1) no one has published a good definition of 'route leak' (that
'people' agree upon)
  2) without the definition (which might not be 'required', debate
later pls) 'operations people' can't say (or haven't said): "Hey, this
route leak thing is a problem, could you ietf-smarty-pants figure out
how to fix it for us?"
  3) IDR can chew on this requirement and spit out 'Yes, you should do
XXX' or 'OH HAI! we changed the bgp protocol to add this widget you
can use to signal intent!' (or something)
  4) SIDR can then whack that with authentication/etc bits

in essence the 4 steps there are what was agreed upon by the
routing-ads, idr/sidr folks + grow folks... it looks like things that
smell rolling downhill a bit :) but, welp there you have it.

> What are GROW's intended objectives in considering this draft?

I hope:
  1) define in a useful fashion route leak
  2) get grow folks to agree (or not) that 'route leaks' (as defined)
are some form of operational problem that needs ietf assistance in
solving.

If we don't agree that they are a problem then ... nothing happens, I suppose.

> of BGP, just how much of this are we willing to re-consider? Is it all the way back to

not sure... :)

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 22 Nov 2013 16:10:50 +0000

Prevent this:

http://www.renesys.com/2013/11/mitm-internet-hijacking/

I suspect that is what Chris is talking about. I know it concerns me.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
________________________________
From: GROW [[email-masked]] on behalf of Christopher Morrow [[email-masked]]
Sent: Friday, November 22, 2013 8:57 AM
To: Geoff Huston
Cc: [email-masked] [email-masked]
Subject: Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt

or:

I hope:

> of BGP, just how much of this are we willing to re-consider? Is it all the way back to

not sure... :)
_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 22 Nov 2013 11:42:44 -0500

> I suspect that is what Chris is talking about. I know it concerns me.

yea, but this is: "Y PROVIDER NO FILTER??"

because now, in 2013 ... what excuse is there left? :)

>  [email-masked]
> Subject: Re: [GROW] I-D Action:
> draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt
>

---

From: Geoff Huston <[email-masked]>
Date: Sat, 23 Nov 2013 06:43:55 +1100

> hill to the other transit? (sure, but that's known, right?)

Chris, you have READ the draft I assume?

> rpsl that? and it's working out how well so far?"

I hear different responses in other parts of the network, where communities have invested
significant levels of effort in publishing routing policies and attempting to
compute across them.

It seems to me that ensuring that the protocol operates correctly does not provide 
sufficient levels of assurance that a BGP speaker can reliably distinguish between 
routing information that is in some sense "genuine" and routing information that
is intended to corrupt the speaker's forwarding state.

> based filtering with prefixes only and no policy-foo.

I'm not sure its worth repeating the arguments that lead to the work in RPSL.

Apparently, folk at the time who worked on RPSL held the belief that it was more helpful.

> People have to

good question - the folk in Japan seem to have been one of the communities that invested
heavily in populating a local route registry with current information. But its tue that in
many communities a local route policy registry is variously populated with current and
lapsed information, as well as large gaps.

I think that the draft that triggered this interchange is spot on when it observes:

  "This document describes an attack on an RPKI-enabled BGPSEC and is
   meant to inform the IETF community that this vulnerability exists as
   a result of route-leaks and attacks that conform to this type of
   behavior, and that operators should not assume that that work items
   and designs address these operational security issues."

The next sentence was what motivated me to respond:

  "The authors believe the capability to prevent route-leaks and leak-
   attacks should be a primary engineering objective in any secure
   routing architecture."

i.e. the concepts of a "secure routing architecture", as envisaged by SIDR,
are inadequate.

> smell rolling downhill a bit :) but, welp there you have it.

As I read your thoughts I am left with the impression that you hold the
view that IDR that inherited the "requirements  for securing the routing 
system" task. Have I got this right?

> If we don't agree that they are a problem then ... nothing happens, I suppose.

If one is allowed to assume that "leaks" redirect traffic, then isn't one
AS operator's "route leak" indistinguishable from another AS operator's
attack via the inter-domain routing system, as the draft itself clearly
points out? Or is your use of the term "leak" in this context intended
to distinguish between the two forms of corruption of the inter-domain
routing system based on the assumed purity of motives of the perpetrator? 

Or do we currently have a collective belief that if we assign the same problem
space to enough working groups one of them will eventually have a bright
idea? :-)

>> of BGP, just how much of this are we willing to re-consider? Is it all the way back to

neither am I - which is why I asked the question.

    Geoff

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 22 Nov 2013 20:03:50 +0000

Wasn't there once a proposal along the lines of:

The originator adds a signed attribute that says "this update is going up the chain".
Each AS signs it before passing it on.
When an AS sends the update down the chain, it removes the attribute.
When an AS receives an update clearly "from below", it checks for the presence of the attribute.

What were the objections to this?

--Jakob.

-----Original Message-----
From: GROW [mailto:[email-masked]] On Behalf Of Geoff Huston
Sent: Friday, November 22, 2013 11:44 AM
To: Christopher Morrow
Cc: [email-masked] [email-masked]
Subject: Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt

On 23 Nov 2013, at 2:57 am, Christopher Morrow <[email-masked]> wrote:

>>>> but in our haste to comply with the timelines dictated by DHS's 
>>>> project funding I guess we've got what DHS were prepared to pay 
>>>> for, and not what we actually wanted or need. And for many its an 
>>>> unsatisfactory outcome.
>>> 
>>> just asking about one part here... so DHS aside, because i'm not 
>>> sure that who the funder is is relevant to the work, exactly...  
>>> what options are there for securing more than the aspath?
>> 
>> 
>> As I understand the draft correctly, the draft is saying even if you 
>> secure ASPATH along the lines proposed in secure BGP, there are still 
>> ways in which an attacker can inject a path that was not intended by the originator.
> 

> 
>> So the question that the draft raises in my head is is it possible to 
>> communicate routing policies in a secure manner?
> 

I hear different responses in other parts of the network, where communities have invested significant levels of effort in publishing routing policies and attempting to compute across them.

It seems to me that ensuring that the protocol operates correctly does not provide sufficient levels of assurance that a BGP speaker can reliably distinguish between routing information that is in some sense "genuine" and routing information that is intended to corrupt the speaker's forwarding state.

>>> know 'thats a route leak' more than 1 as-hop away form the 'leak'. 
>>> (it also doesn't take into account any of the comments I provided to 
>>> the authors :(  which is another matter entirely)
>> 
>> so we get back to RPSL.
> 

> there.. Is 702 going to publish that they are a transit of NTT in 

good question - the folk in Japan seem to have been one of the communities that invested heavily in populating a local route registry with current information. But its tue that in many communities a local route policy registry is variously populated with current and lapsed information, as well as large gaps.

i.e. the concepts of a "secure routing architecture", as envisaged by SIDR, are inadequate.

> smell rolling downhill a bit :) but, welp there you have it.

As I read your thoughts I am left with the impression that you hold the view that IDR that inherited the "requirements  for securing the routing system" task. Have I got this right?

    Geoff

---

From: Geoff Huston <[email-masked]>
Date: Sat, 23 Nov 2013 10:20:32 +1100

If you are referring to the proposal that "valley free paths are all instances of
unintended routing", then as I recall there is a line of argument
that says that some paths that contain valleys are intentional.

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 22 Nov 2013 23:40:55 +0000

I think you mean "paths with valleys are all instances of unintended routing".

Surely, that can be fixed:
A provider can reject valleyed routes from a customer BY DEFAULT,
but allow some through if so configured.

The point is that such a valley attribute can provide good information to prevent
the majority of route leaks without leaking customer relationship information.

--Jakob.

-----Original Message-----
From: Geoff Huston [mailto:[email-masked]] 
Sent: Friday, November 22, 2013 3:21 PM
To: Jakob Heitz
Cc: Christopher Morrow; [email-masked] [email-masked]
Subject: Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt

If you are referring to the proposal that "valley free paths are all instances of unintended routing", then as I recall there is a line of argument that says that some paths that contain valleys are intentional.

On 23 Nov 2013, at 7:03 am, Jakob Heitz <[email-masked]> wrote:

>>> secure ASPATH along the lines proposed in secure BGP, there are 
>>> still ways in which an attacker can inject a path that was not intended by the originator.
>> 
>> Did you mean pull a route down a customer link and pass it back up 
>> the hill to the other transit? (sure, but that's known, right?)
> 
> 
>>> So the question that the draft raises in my head is is it possible 
>>> to communicate routing policies in a secure manner?
>> 
>>>> Additionally, the draft in question here still doesn't say how 
>>>> you'd know 'thats a route leak' more than 1 as-hop away form the 'leak'.
>>>> (it also doesn't take into account any of the comments I provided 
>>>> to the authors :(  which is another matter entirely)
>>> 
>>> so we get back to RPSL.
>> 
>> later pls) 'operations people' can't say (or haven't said): "Hey, 
>> this route leak thing is a problem, could you ietf-smarty-pants 
>> figure out how to fix it for us?"
> If one is allowed to assume that "leaks" redirect traffic, then isn't 
> one AS operator's "route leak" indistinguishable from another AS 
> operator's attack via the inter-domain routing system, as the draft 
> itself clearly points out? Or is your use of the term "leak" in this 
> context intended to distinguish between the two forms of corruption of 
> the inter-domain routing system based on the assumed purity of motives of the perpetrator?
> 
> Or do we currently have a collective belief that if we assign the same 
> problem space to enough working groups one of them will eventually 
> have a bright idea? :-)
> 
> 
>>> [...]
>>> 
>>> And if we are ready to reopen this consideration of requirements for 
>>> securing the operation of BGP, just how much of this are we willing 
>>> to re-consider? Is it all the way back to RPSL and RPSS?
>> 
>> not sure... :)
>

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 22 Nov 2013 20:54:07 -0500

> the majority of route leaks without leaking customer relationship information.

is this a default-on property? or do I configure bgp-peer-A as 'i am a
customer' and peer-b as 'I am a transit'? what is the default expected
value? how do I verify that the value is correct? or do I just trust
the 3-as-hops away path I see? how is this better than today's:
"filter your routes" situation?

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 22 Nov 2013 21:13:06 -0500

> Chris, you have READ the draft I assume?

yes, describes a transit->customer->transit path, AS7007 like situation.

I was asking for clarification of what ways (aside from 'leak the
internet from one transit to another') one could inject a path.

> significant levels of effort in publishing routing policies and attempting to

sure, but in aspac, emea, us, lacnic ... pretty much everywhere we
still see forms of not-valley-free networking by mistake happening. I
reckon we'll keep seeing that until there's a better way to
incentivize filtering and validation of the paths seen.

> is intended to corrupt the speaker's forwarding state.

right, so... fix bgp in some way? you seem to have jumped to step3
below, which is fine, but we are supposed to agree on 1 and 2 first.

> Apparently, folk at the time who worked on RPSL held the belief that it was more helpful.

ok, it's not working across the board, so... ok.

> lapsed information, as well as large gaps.

and there's not a way (today) to say: "Oh, that route for ConEdison
that NTT's customer put in 18 months ago shouldn't be in their
prefix-list AS-SET anymore"

L3 and plenty of other folks have had this problem as well, all folk
that filter strictly on their customer peerings.

>    and designs address these operational security issues."

So, one of my comments on the draft was that really a route 'leak' (a
valley where there ought not be one) isn't in itself a 'security'
problem. What you do after the valley is there COULD BE a problem for
someone's security, sure... but just the fact of traffic taking an
unintended path isn't a security problem.

It's not worth fighting that battle elsewhere, but it IS worth saying
that the unintended valley is an operational problem (latency issues,
congestion, customer problems, loss of revenue, etc) and it'd be nice
to find a solution for that. Ratholing on 'is security or not' is not
as critical as: "Crap, we defined a route leak and we agree on that
definition" and "Crap! we decided this is operationally relevant and
can someone please fix this."

>    attacks should be a primary engineering objective in any secure

sure, I want a pony too, but ... so far I'm not sure I've seen any
credible way out of the problem. I still can't identify a route-leak
from more  than 1 as-hop away... which I'd want to do so I don't
install paths with known unintended valleys.

> system" task. Have I got this right?

Your sentence didn't parse for me, one or more words are incorrect,
somewhere around:
  "view that IDR that inherited"

I believe the path set forth by routing and ops ADs was the 3-4 step
program above... is that your question?

> routing system based on the assumed purity of motives of the perpetrator?

I don't know that motives are important? whether a path drops into a
valley is what's important, right? Speculating on motivations isn't
going to be useful, I feel.

> space to enough working groups one of them will eventually have a bright

OPS ADs have traditionally tried to keep the spew level down. I don't
think anyone here is trying to move the problem around, there's a
fairly clear 3-4 step process to be followed, one might view the draft
in question as step1 of that process.

-chris

---

From: Geoff Huston <[email-masked]>
Date: Sat, 23 Nov 2013 13:17:23 +1100

> I think you mean "paths with valleys are all instances of unintended routing".

sorry, yes, that is what I meant to say! :-)

geoff

---

From: Geoff Huston <[email-masked]>
Date: Sat, 23 Nov 2013 13:41:47 +1100

> sorry, yes, that is what I meant to say! :-)

and lest this be misunderstood, then I said: but "as I recall there is a line of argument
that says that some paths that contain valleys are intentional."

  Geoff

---

From: Randy Bush <[email-masked]>
Date: Sat, 23 Nov 2013 13:46:18 +0900

> customer' and peer-b as 'I am a transit'?

that can vary by prefix

randy

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 24 Nov 2013 22:44:52 +0000

> so we get back to RPSL.

I wouldn't look to RPSL as being the solution to a whole lot.

> Why are we using GROW to host this discussion?

because the WG has got a nice operator-friendly feel to the name and there
is no other document in the accumulated tomes of ietf lore which explicitly
states that prefix origin validation in its current form is operationally
limited in scope and that if there are organisations out there who feel
that they'll get a kwik-fix sticky plaster solution for their routing
security concerns by turning on rpki, they need to think again.  It's
probably not a bad idea to have a document like this although I'm not much
interested in the politics of whether it belongs in grow or even the ietf.

> securing the operation of BGP, just how much of this are we willing to
> re-consider? Is it all the way back to RPSL and RPSS?

draft-ietf-sidr-bgpsec-reqs is a good start.  Re: your comparison with
dnssec, the latter has the interesting property that it is fully
hierarchical with a single root and therefore the object relationship model
is relatively easy to handle - particularly when attempting to retrofit it
with a hierarchical trust model.  With bgp we have a highly fluid peer to
peer relationship mechanism which rpsl attempted to document, and here we
are trying to determine whether a top-down hierarchical pki could form part
of a trust mechanism to determine the validity of prefixes and paths so
that we dumb operators can reach the holy grail of being able to believe
what we see when we type "show bgp blah".  RPKI can work for prefix origin
validation because prefixes are assigned hierarchically.  AS paths -
transit and peering relationships - are not assigned hierarchically, so
there seems little reason to think that a hierarchical trust model would be
the most appropriate mechanism to use for securing this.  Or am I being
naive here?

Nick

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 26 Nov 2013 15:54:53 -0500

> program above... is that your question?

Geoff, did I get your question's sense correct or not?

---

From: Geoff Huston <[email-masked]>
Date: Wed, 27 Nov 2013 08:24:47 +1100

> Geoff, did I get your question's sense correct or not?

I reviewed the mailing lists of all three WGs from November last year, when this came up.
and I was searching for a proposed methodology of defining requirements, proposing mechanisms
and standardising one of more candidate technologies relating to the issue of path
control of the propagation of BGP announcements in order to allow BGP speakers
to detect unintended announcements. My search of the list archives was unsuccessful.

As I seem to be the only one interested in an answer, I give up.

geoff

(Of course the net value of the entire effort in "securing" a routing protocol that still cannot
discriminate between intended routing announcements and all forms of routing lies is in
itself another interesting question, but maybe that's best answered by those folk who will,
or will not, turn on this particular set of routing control knobs in their routers.)

---

From: "Russ White" <[email-masked]>
Date: Tue, 26 Nov 2013 16:33:28 -0500

> I reviewed the mailing lists of all three WGs from November last year,
when
> this came up.
> and I was searching for a proposed methodology of defining requirements,
> proposing mechanisms and standardising one of more candidate
> technologies relating to the issue of path control of the propagation of
BGP
> announcements in order to allow BGP speakers to detect unintended
> announcements. My search of the list archives was unsuccessful.

That's because there wasn't ever an actual requirements gathering process.
The process has worked from solution to requirements, so no formal
requirements were ever drafted. We made a bold attempt in another WG, but
those attempts were effectively shut down because the solution --S-BGP (aka
BGPSEC)-- was already in hand, and no other solutions were even seriously
considered.

Doesn't matter whether or not BGP-SEC meets "requirements," it's a solution
going someplace to happen (or not, as the case might be).

:-)

Russ