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

From: [email-masked] (Noel Chiappa)
Date: Sun, 31 Dec 2006 08:32:55 -0500 (EST)

> From: marcelo bagnulo braun <[email-masked]>

    > you would still need to include the security information to bind
    > them in the packet itself...

No, you only need to include the security stuff when you *change* the
binding (or add a new one to a set of "authorized" ones).

	Noel

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 31 Dec 2006 15:53:41 +0100

> binding (or add a new one to a set of "authorized" ones).

but then the middle box needs to keep track of the authorized locator 
set associated to each ID, which implies state, which need to be learnt 
from somewhere, for instance, inspection of packets carrying such 
information. This is possible but it has problems of its own, like what 
happens if a new path is used, and the middle boxes there haven't seen 
the initial packets...?

I guess this disucssion may be becoming too into details, but bottom 
line is that you cannot make filers and ACL based on identifiers unless 
you can trust them. In the case of routing names, you can have some 
level of trust, because, if you trust the routing system, then you know 
this packet will only be delivered to the destiantion locator. However, 
you do not have this level of trust if you use identifiers and you need 
to provide additional mechanism (that result in additional overhead or 
state) to achieve it imho

Regards, marcelo

Regards, marcelo

---

From: Tony Li <[email-masked]>
Date: Sun, 31 Dec 2006 10:21:13 -0800

> but then the middle box needs to keep track of the authorized  
> locator set associated to each ID, which implies state,

A middle box implies state already.  Having a middle box that does a  
locator lookup per packet is not going to scale and therefore the  
middle box at least has to cache an ID to locator mapping.

> which need to be learnt from somewhere, for instance, inspection of  
> packets carrying such information. This is possible but it has  
> problems of its own, like what happens if a new path is used, and  
> the middle boxes there haven't seen the initial packets...?

Well, one of the things that's implied in a middle box solution is  
that there is a protocol exchange between all of the site border  
routers, so that all changes are uniformly communicated.   
Effectively, you need shared state across all of your site border  
routers.

Tony

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 31 Dec 2006 14:11:26 -0500

> I guess this disucssion may be becoming too into details, but 
> bottom line is that you cannot make filers and ACL based on 
> identifiers unless you can trust them. In the case of routing 
> names, you can have some level of trust, because, if you 
> trust the routing system, then you know this packet will only 
> be delivered to the destiantion locator. However, you do not 
> have this level of trust if you use identifiers and you need 

It is not trusting the routing system but the entire notion of the
network security system using Intrusion Detection.  IMHO it is
un-necessary to secure the identifiers (whether transport or routing
name space in the model emerging here) cryptographically (and I do not
believe it will ever scale from engineering view point).  Access to the
identifiers is what must be secured and then if they change as stated
above.  Anything else is overhead.

Best,
/jim

---

From: Roland Dobbins <[email-masked]>
Date: Sun, 31 Dec 2006 12:41:38 -0800

On Dec 31, 2006, at 11:11 AM, Bound, Jim wrote:

> IMHO it is

An optional capability to encrypt or obfuscate identifiers is  
something which is nice to have for reasons of privacy and anonymity,  
but I agree with you completely that this is not a base requirement.   
Hopefully, we can come up with a solution which, while not  
necessarily supporting this functionality initially, won't preclude  
it in later phases.

It's also important to note that the conflation of encryption/ 
obfuscation with 'security' has in fact been harmful by a) providing  
the incorrect impression that all one has to do to secure one's host/ 
application/network is to encrypt various random things, with no  
thought or effort required apart from that, and b) encouraging the  
overuse of encryption where it really isn't needed, with the net  
effect that opsec personnel end up losing the ability to analyze and  
filter undesirable network traffic.  So, we should work to avoid  
promulgating a misimpression similar to that in which some folks drew  
the incorrect inference that because of 'mandated' IPSEC that IPv6 is  
magically 'secure'.

[ Of course, one operator's undesirable network traffic is another  
customer's BitTorrent, but that's a different discussion for a  
different forum, heh. ]

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

		All battles are perpetual.

     		   -- Milton Friedman

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 31 Dec 2006 22:41:14 +0100

El 31/12/2006, a las 19:21, Tony Li escribió:

>> set associated to each ID, which implies state,
>
>
> 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)

>  Having a middle box that does a locator lookup per packet is not 
> going to scale and therefore the middle box at least has to cache an 
> ID to locator mapping.
>
>
>> problems of its own, like what happens if a new path is used, and the 
>> middle boxes there haven't seen the initial packets...?
>
>
> routers, so that all changes are uniformly communicated.  Effectively, 
> you need shared state across all of your site border routers.
>

we are on the same page, just wanted to make sure that we were thinking 
about the same thing when we said middle box/border router approach

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 31 Dec 2006 22:43:38 +0100

> above.  Anything else is overhead.

exactly, hence, it is not obvious to me if we can assume that a middle 
box will be able to even see the identifier in order to use them in 
filters and ACLs, right?

---

From: Tony Li <[email-masked]>
Date: Sun, 31 Dec 2006 16:53:50 -0800

> exactly, hence, it is not obvious to me if we can assume that a  
> middle box will be able to even see the identifier in order to use  
> them in filters and ACLs, right?

That's certainly possible.  However, that means that the locator is  
necessarily host-specific, which I'm certainly not convinced is a  
requirement, or necessary.

The locator could only specify a particular LAN or area, for example,  
and within that, individual identifiers could be used for the final  
bit of routing.  In this scenario, you would want the destination  
identifier in each packet.

Tony

---

From: Tony Li <[email-masked]>
Date: Sun, 31 Dec 2006 16:59:32 -0800

> 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.

Tony