Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 1 Jan 2007 12:24:01 +0100

El 01/01/2007, a las 1:59, Tony Li escribió:

>
>>> A middle box implies state already.
>>
>> GSE doesn't and that it is the beauty of it, but it doesn't work as 
>> such (that was my only point actually)
>
>
> Ummm...  I'm not Mike O'Dell, but I respectfully disagree.
>
> It is not a first-order clear requirement of the spec, but someone, 
> somewhere still needs to deal with destination locator selection.  You 
> can do it in the host, or in the border, and we know what folks think 
> about doing it in the host.
>

ok, let me rephrase
I think you can do the locator selection in the host or in the border 
router.
I think you can also let either the host or the border to border router 
to handle the rest of the protocol stuff that is needed (security of 
the id-loc binding, reachability verification, exploration of 
alternative paths and so on)

However, what i don't know how to do, is to do everything in the border 
router without requiring any specific id-locator context state (i.e. 
per communication state) in the border router, like GSE does it. I mean 
GSE just knows the globally routable prefix and simply rewrite the 
source prefix and the hosts are practically unaware (i.e. they are not 
involved in the creation of any state in the border router using a 
protocol, neither with the border router nor with the peer). In the 
case of GSE, it does not require any per connection state and does not 
require any protocol with any other element to create any state, (for 
instance for security reasons). I don't see how you can do this, 
securely.

I see how you can do this, if you run a protocol between the border 
routers or between the border router and a third element (like a third 
trusted party) that is used to create a per id/locator binding state. 
this will not be as nice or as simple as the GSE proposal currently is.

i am not saying i not ok with this, just want to make sure we are on 
the same page about the expected complexity of the resulting solution

regards, marcelo

> Tony

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

---

From: Tony Li <[email-masked]>
Date: Mon, 1 Jan 2007 15:17:33 -0800

Marcelo,

> I think you can do the locator selection in the host or in the  
> border router.
> I think you can also let either the host or the border to border  
> router to handle the rest of the protocol stuff that is needed  
> (security of the id-loc binding, reachability verification,  
> exploration of alternative paths and so on)

I agree with that much.

> However, what i don't know how to do, is to do everything in the  
> border router without requiring any specific id-locator context  
> state (i.e. per communication state) in the border router, like GSE  
> does it. I mean GSE just knows the globally routable prefix and  
> simply rewrite the source prefix and the hosts are practically  
> unaware (i.e. they are not involved in the creation of any state in  
> the border router using a protocol, neither with the border router  
> nor with the peer). In the case of GSE, it does not require any per  
> connection state and does not require any protocol with any other  
> element to create any state, (for instance for security reasons). I  
> don't see how you can do this, securely.

So, I think we should make a big distinction between per-connection  
state and other 'soft state' in the border router.  I agree that you  
can probably do a border solution without per-connection state.   
However, for security reasons and for locator selection reasons, I  
think that you're minimally going to end up with a cache inside of  
the border router.

> routers or between the border router and a third element (like a  
> third trusted party) that is used to create a per id/locator  
> binding state. this will not be as nice or as simple as the GSE  
> proposal currently is.

Well, GSE is certainly missing the security paraphernalia.  I think  
that we all pretty much agree on that.

> i am not saying i not ok with this, just want to make sure we are  
> on the same page about the expected complexity of the resulting  
> solution

I think we're pretty much in violent agreement.

Tony