Subject: Re: [RPSEC] BGP Requirements Draft

From: Sandy Murphy <[email-masked]>
Date: Mon, 26 Sep 2005 09:46:23 -0400 (EDT)

>Isn't the counter proposal also going check that 7018 is allowed to
>announce the prefixes concerned? Ie the "would work for any prefix in
>the world" part is not true.

True, true.  As I said, I'm talking only about the peering adjacency
test here.

So I'll amend my statement to "any prefix in the world that 7018
validly originated".

>OTOH, if 7018 *did* authorise 1239 to carry traffic to it then what
>exactly is the problem with the example above? :)

The problem is that 7018 might not announce every single solitary prefix
it validly originates to 1239.

But  1239 could claim that it did, just on the basis of the fact that
the peering existed.

(You know, I remember a IETF way, way, back, when Brandon Smith was
talking to Sue Hares about a similar proposal and Sue very much
discouraged him by noting that the existence of peerings did not
mean that the path would transit the traffic.  I got it and I've
remembered it.)

--Sandy

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Russ White <[email-masked]>
Date: Mon, 26 Sep 2005 09:57:27 -0400

> mean that the path would transit the traffic.  I got it and I've

*sigh*

Again, can you prove:

- -- Verifying each AS along the path has touched the route actually 
proves authorization to transit? No.

- -- Verifying each AS along the path has touched the route is the only 
mechanism whereby someone could prove authorization to transit? No.

Since the answer to both questions is "no," I don't see how someone can 
assign "relative security capabilities" to these two checks.

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

---

From: Paul Jakma <[email-masked]>
Date: Mon, 26 Sep 2005 15:25:28 +0100 (IST)

On Mon, 26 Sep 2005, Sandy Murphy wrote:

> The problem is that 7018 might not announce every single solitary 
> prefix it validly originates to 1239.
>
> But 1239 could claim that it did, just on the basis of the fact 
> that the peering existed.

Indeed.

> mean that the path would transit the traffic.  I got it and I've 

ACK.

However, I don't see any technical reason why the counter-proposal 
(So-BGP, right? :) ) could not be made more fine-grained. It 
currently proposes to validate only the peerings (AIUI), however I 
don't see why you could not include prefix information. If that were 
done that you could construct whether a path was plausible for the 
given AS_PATH, the given originating AS and the prefix concerned.

What does that lack exactly that requires in-line hop-by-hop signing 
of UPDATEs?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Message from Our Sponsor on ttyTV at 13:58 ...

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Sep 2005 10:38:32 -0400

Paul,

(Not speaking about the current state of any given proposal.)

On Mon, Sep 26, 2005 at 03:25:28PM +0100, Paul Jakma wrote:
> It 

Given:
The graph of all inter-as connections at all peering points.
Given the NLRI egress policy at each of those points.

It is possible to derive path plausibility.

That's a *lot* of state, albeit potentially very stable in computer-time
terms. :-)

Additionally, the BGP protocol as currently stands only provides
AS level granularity.  Sure, you could extend the prepended AS
to include the peering information.

If you reduce the state to the graph of inter-as peering and the
union of all viable egress NLRI policy, it's more managable.

> What does that lack exactly that requires in-line hop-by-hop signing 

Using something like the above, in either form, you can prove
plausibility of a given update.  This will prune the number of
paths with which you can inject fake updates.  However, there are
still man-in-the-middle attacks.  Some form of chained signature
(as one method) mitigates that particular attack.

-- 
Jeff Haas 
NextHop Technologies

---

From: Paul Jakma <[email-masked]>
Date: Mon, 26 Sep 2005 16:16:08 +0100 (IST)

> The graph of all inter-as connections at all peering points. Given 
> the NLRI egress policy at each of those points.
>

It is indeed. I think there are large amounts of state and 
computation involved regardless of which approach is chosen though, 
right?

The above might involve even more state and computation, but only 
needs to be imposed on one or two speakers within an AS - hence is 
likely feasible even with todays hardware. The signing-approach might 
involve less state, but burdens all edge (at least) speakers in AS.

One approach would burden all with "big" state and computation, the 
other would burden a select few with "very big" state and 
computation. :)

> Additionally, the BGP protocol as currently stands only provides AS 
> level granularity.  Sure, you could extend the prepended AS to 
> include the peering information.

No, not the AS-Path - it'd be in the PolicyCert's AIUI. Completely 
seperate. AS_PATH wouldn't be touched.

> (as one method) mitigates that particular attack.

True.

But if a MITM is hostile to you, does it really matter whether or not 
you were able to validate the ASN they put in the AS_PATH? :)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Research is to see what everybody else has seen, and think what nobody
else has thought.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Sep 2005 11:28:09 -0400

> computation involved regardless of which approach is chosen though, 

If the state is limited to per-AS rather than per-AS-peer, I think
that puts a much lower bound on the amount of state involved. :-)

> involve less state, but burdens all edge (at least) speakers in AS.

I think you misunderstood.  I'm talking about distributing this graph
to the entire Internet. 

> seperate. AS_PATH wouldn't be touched.

I'm not talking about any particular proposal, especially not sobgp.

In the general case where you must sign the contents of something
resembling a BGP update, you certainly would change things.

> you were able to validate the ASN they put in the AS_PATH? :)

You can secure your routing.  You can't readily prove that the
routing is tightly coupled with the forwarding.  Our goal is to
work on the routing attacks, not the forwarding attacks. 

-- 
Jeff Haas 
NextHop Technologies

---

From: Paul Jakma <[email-masked]>
Date: Mon, 26 Sep 2005 16:36:00 +0100 (IST)

> that puts a much lower bound on the amount of state involved. :-)

I was thinking more per-AS, eg 'authorisation' object (whatever it 
would be) would simply list which prefixes are originated to it (or 
not list any specifically for 'all which I originate').

*Not* per-AS-peer. Ye gods :).

> I think you misunderstood.  I'm talking about distributing this 
> graph to the entire Internet.

There are a myriad of ways, including via BGP itself.

> resembling a BGP update, you certainly would change things.

Of course.

> work on the routing attacks, not the forwarding attacks.

Sure, and I meant the routing side. :)

You can't prevent MITM with the plausible-paths approach, however you 
should at least be able to tell the hostile MITM is there (you just 
wouldn't know what else they had done). But that is sufficient 
knowledge...

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
I wish a robot would get elected president.  That way, when he came to town,
we could all take a shot at him and not feel too bad.
 		-- Jack Handley