Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Mar 2011 16:29:57 -0500

Randy, would you be willing to be wording like this, with your 
corrections, into section 1 of the document?

Thank you,
Joel

On 2/26/2011 6:47 AM, Randy Bush wrote:
>> o To prevent any advertiser from sending an advertisement that would
>> cause other properly behaving parties to send traffic iin a way that
>> they are not "entitled" to cause
>
> close, but i am not entirely comfortable with this
>    o we can not hope to prevent the advertisement, only detect it is
>      bogus.
>    o it is the bgp receiver's policy decision on where to send traffic.
>      a security researcher may specifically want to send traffic toward
>      a bogus announcement.
>    o i.e. 'cause' is too strong a word, perhaps 'lure'
>
> but you have the essential point
>
> randy
>

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 1 Mar 2011 16:59:33 -0500 (Eastern Standard Time)

On Tue, 1 Mar 2011, Joel M. Halpern wrote:

> Randy, would you be willing to be wording like this, with your corrections, 
> into section 1 of the document?
>
> Thank you,
> Joel
>

Clarification here.  "they" are not entitled to cause -- do you mean the 
"other properly behaving parties"?  If you mean "any advertiser" the text 
should read "it is not entitled to cause" not "they".

Not just a nit -- the difference changes the meaning.

--Sandy

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Mar 2011 17:05:15 -0500

Thanks Sandy.  Yes, I mean "it", not "they".
Thanks for catching that.
Joel

---

From: Randy Bush <[email-masked]>
Date: Wed, 02 Mar 2011 07:15:25 +0900

> corrections, into section 1 of the document?

lemme try to reword it, but later in the day.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 02 Mar 2011 08:07:36 +0900

something like

        A BGPsec design MUST allow the receiver of an announcement to
	detect that one or more ASes on the AS-Path is attempting to
	lure the receiver into sending traffic in a way that an
	announcer is not entitled to receive.

?

randy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Mar 2011 18:25:32 -0500

I think that would help, and it is good enough for me.
Thank you,
Joel

---

From: Randy Bush <[email-masked]>
Date: Wed, 02 Mar 2011 08:30:06 +0900

actually, a bit more coffee inclines me toward an even more restrictive
statement

	  A BGPsec design MUST allow the receiver of an announcement to
	  detect that one or more ASes on the AS-Path is attempting to
	  lure the receiver into sending traffic to an incorrect next
	  hop.

randy

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 1 Mar 2011 20:31:46 -0500

Andrew,
Response inline.
Sriram

> -----Original Message-----
> From: Andrew Lange [mailto:[email-masked]]
> 
> Sriram,
> 
> Why would you accept a route de-aggregated by an upstream?  If signed route-object says
> AS_A owns and announces only the route 1.2.3.0/20 and I'm seeing 1.2.3.0/21 from AS_B,
> the route filter should be configured not to accept more specifics.   If AS_A wants to de-
> aggregate, it can split it's route-objects into the more specifics and register them.
> 
> Andrew

I am sure you understand that ROA allows the prefix owner to 
register not only a prefix-origin pair (say, {1.2.0.0/20, AS_A})
but also a maxlength to allow any subprefixes (more specifics) 
that she may originate at times from the same AS_A.
So the registered ROA info may look like {1.2.0.0/20, AS_A, maxlength = 22}.
Then if AS_A needs to announce more specifics 1.2.0.0/21 and 1.2.8.0/21,
it can readily do so while depending on the same ROA for validation.
The reason for this may be traffic engineering, e.g., when AS_A 
is multihomed to two other upstream ASs, say, AS_X and AS_Y, then
AS_A can announce more specifics 1.2.0.0/21 and 1.2.8.0/21 to 
AS_X and AS_Y with some clever prepending so that inbound traffic 
is equally distributed over the links from AS_X and AS_Y to AS_A.
This is just one example of the usability of maxlength.

Now as one can see, there are meaningful uses of maxlength 
for the legitimate originator, but then that opens the door for
subprefix hijacks (with your proposed approach 
to securing partial path) as I explained before.
Such subprefix hijacking would be detectable in a different
approach, for example, if the whole update were signed including 
the NLRI (prefix) and AS_PATH 
(in addition to use of the normal ROA information).

Sriram     
   
> 
> On Feb 24, 2011, at 3:51 PM, Sriram, Kotikalapudi wrote:
> 
> > Andrew,
> >
> > Comment below.
> >
> > Sriram
> >
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew
> Lange
> >> Sent: Wednesday, February 23, 2011 6:17 PM
> >> To: Sandra Murphy
> >> Cc: [email-masked]
> >> Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work
> >>
> > --- snip ---
> >>
> >> From a work item perspective, it would be useful to have a relationship object signed
> that
> >> says "I'm AS_A, and I have AS_B and AS_Q as legitimate connections."  This
> information,
> >> combined with AS_A's signed route-objects means that downstream ASes would be able
> to
> >> verify that a route 1.2.0.0/16 coming in with an AS PATH of [AS_A, AS_B] or [AS_A,
> >> AS_Q] would be AS PATHs that could be authorized.  Effectively solving the Origin +
> >> Upstream issue would solve most of the problems.  Yes, someone could then spoof an
> >> announcement of origin+upstream+self, but then we're looking at a minimum of a 3-AS
> >> path and the likelihood of that being best drops.  We can also do this with a simple
> route-
> >> filter and does not require on-system crypto calculations.
> >>
> >> Andrew
> >>
> > Yes, the path length goes up by 2.
> > But normally an adversary would spoof an announcement with a subprefix (more
> specific)
> > of the prefix that the legitimate prefix owner has announced
> > (while still trying to keep within the maxlength as specified in the ROA).
> > I that case the increased path length would not matter.
> > The spoofed announcement would be accepted and propagated widely.
> >
> > Sriram
> >

---

From: "t.petch" <[email-masked]>
Date: Wed, 2 Mar 2011 09:27:47 +0100

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: "Randy Bush" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 02, 2011 12:25 AM

> > announcer is not entitled to receive.

Worded like this, with the emphasis on the consequences, would seem
to include such things as inserting spurious communities, as opposed to just
modifying the AS-Path in an unacceptable way.  Is that the intention?

It is quite a shift from the focus of 10 days ago, which I read as
solely securing the AS-Path, as opposed to anything else that might
be in the advertisement.

Tom Petch

---

From: Randy Bush <[email-masked]>
Date: Wed, 02 Mar 2011 19:04:05 +0900

> Worded like this, with the emphasis on the consequences, would seem to
> include such things as inserting spurious communities, as opposed to
> just modifying the AS-Path in an unacceptable way.  Is that the
> intention?
> 
> solely securing the AS-Path, as opposed to anything else that might be
> in the advertisement.

this is a good and possibly important point i missed.  first, to be as
clear as possible, here are the words as i now have them in my edit
buffer.

   3.1 A BGPsec design MUST allow the receiver of an announcement to
       detect that one or more ASes on the AS-Path is attempting to lure
       the receiver into sending traffic to an incorrect next hop.

i could make it something like

   3.1 A BGPsec design MUST allow the receiver of an announcement to
       detect that one or more ASes have manipulated the AS-Path in an
       attempt to lure the receiver into sending traffic to an incorrect
       next hop.

whatcha think?

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 03 Mar 2011 06:59:37 +0900

>        attempt to lure the receiver into sending traffic to an incorrect

in a private email, a friend pointed out that we neither know nor do we
care why charlene falsified the path.  the point is that we must be able
to detect that she did.

so the wording i think i'll go with is

   3.1   A BGPsec design MUST allow the receiver of an announcement to
         detect that one or more routers have falsified the AS-Path.

last chance for word-diddling.

randy

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 2 Mar 2011 15:03:00 -0700

Ignorance is Bliss. "Bliss (Basic Language for Implementation of System Software) was a
systems programming language originally for the PDP-10 and DECsystem-20 written at CMU." K-Oberman
[email-masked]

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Randy Bush
> Sent: Wednesday, March 02, 2011 3:00 PM
> To: t.petch
> Cc: [email-masked]

Falsified or manipulated?
The falsified implies someone is telling a lie while manipulated means they changed elements for some reason right?

I would lean towards manipulated or modified portions that they are not authoritative for or something along those lines.

> last chance for word-diddling.

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 02 Mar 2011 17:25:20 -0500

Unfortunately, that change shifts things just enough to miss an 
important part of what I was hoping to achieve.
While it is true that we can not know why anyone does anything, the 
reason we care about it is that certain  kinds of path falsification can 
result in traffic being lured to places that any reasonable model of 
authorization (not necessarily just the strict mathematical sense, but 
the more general operational sense) says it aught not go.

The purpose of the whole exchange was to try to get a motivation into 
the picture, rather than just another assertion that we want to protect 
the AS path.  There is no need for new text just saying "we are 
protecting the AS path because we are protecting the AS path."

Yours,
Joel

---

From: Randy Bush <[email-masked]>
Date: Thu, 03 Mar 2011 07:36:05 +0900

> While it is true that we can not know why anyone does anything
> ...
> the picture

a conundrum wrapped in a cabbage leaf.  the draft can not meet the
desires of both directions here, and the new version needs to get out.
being lazy, i will choose the simplest one for the moment and the
discussion can continue.

randy

---

From: "t.petch" <[email-masked]>
Date: Fri, 4 Mar 2011 11:58:50 +0100

---- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: "Randy Bush" <[email-masked]>
Cc: "t.petch" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 02, 2011 11:25 PM

> protecting the AS path because we are protecting the AS path."

I am easy about motivation, whether it is there or not; I wanted to
be clear about scope, AS_Path or everything in the advertisement
which the modified wording is.

I like Donald's addition so while I am content with what is suggested 
below, I would also go for  

"   A BGPsec design MUST allow the receiver of an announcement to
     detect that one or more routers have modified 
     the AS_Path in a way that they are not authorised to do ... "

Leaving Joel to add something like
" ...with the objective of causing traffic to be misdirected. 

And yes, I do think it is worth spending a few days on being 
clear in our words, as opposed to our thoughts:-)

Tom Petch

---

From: Randy Bush <[email-masked]>
Date: Fri, 04 Mar 2011 22:03:35 +0900

the current, yet to be pushed, text is

   3.1   A BGPsec design must allow the receiver of a BGP announcement
         to determine, to a strong level of certainty, that the received
         PATH attribute accurately represents the sequence of eBGP
         exchanges that propagated the NLRI from the origin AS to the
         receiver.

discussion of intent is simply inappropriate, you can not know it.  and we
want to protect against path prevarication where there was no intent at
all.

bgp has so many wonderful knobs, such as the one to masquerade as a
different asn.  mistype it and ...

randy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 04 Mar 2011 15:23:54 -0500

I agree that intent can not be known.

Which is why I had asked that the motivation / intent related text be 
included in the introduction, not in the requirements.  I was not trying 
to change the requirements.  Rather, I am asking that the document 
include some context, to help the reader accurately understand the 
requirements.  One can argue that formally that is irrelelvant.  Based 
on history, it seems very useful to me.

Yours,
Joel

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Mar 2011 09:27:24 +0900

> included in the introduction, not in the requirements.

i have done so in the yet-to-be-released version

   3.19  A BGPsec design SHOULD NOT presume to know the intent of the
         origintor of a NLRI, nor that of any AS on the AS Path.

cool?

randy