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

From: "Bound, Jim" <[email-masked]>
Date: Mon, 1 Jan 2007 09:58:32 -0500

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

Thats my assumption today and has to be for end-to-end encryption of the
IP layer or the transport layer.  There are products that perform what
is called deep packet inspection (DPI), far beyond what traditional
routers are capable of today in their fast path, on the market today and
could with security offload processers perform a decrypt and re-encrypt
at the edge and maintain line rates, thus that is an option in the
market but not our concern as the IETF SDO working on this new
architecture.

/jim

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

---

From: Andrew McGregor <[email-masked]>
Date: Tue, 2 Jan 2007 18:55:33 +1300

That middleboxes should be able to determine the identifiers in use  
was a design decision in HIP; perhaps unfortunately, they're  
compressed into an SPI, so the middlebox does have to keep state to  
do it.  The state is just a binding between identifier, known  
locators and SPIs, however, and the protocol is designed to make it  
fairly convenient and secure (in the sense that spoofing is extremely  
difficult) for a middlebox to maintain that.

Andrew

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 2 Jan 2007 17:01:26 +0100

Yes, i think we can learn from the  HIP work on firewall traversal. 
AFAIK, the middle box keeps track of the HIP base exchange, and then it 
learns what identifiers match to following data packets, right?
So, you can do filtering based on HITs, but you need to allow the 
middle box to keep track of the hip base exchange and you need to 
distribute that information through all potentail middel boxes that 
following packets can traverse (due to a path change)

I think hip work has done the first thing (allow middle boxes to keep 
track of the hip base exchange) but not the second one (deal with path 
changes), right?
in any case, i think their experience is very useful to have a fleshed 
example of how to do this and the complexity involved (which is one of 
the prices to pay to allow portability based on PI identifiers)

Regards, marcelo

El 02/01/2007, a las 6:55, Andrew McGregor escribió:

> compressed into an SPI, so the middlebox does have to keep state to do 
> it.  The state is just a binding between identifier, known locators 
> and SPIs, however, and the protocol is designed to make it fairly 
> convenient and secure (in the sense that spoofing is extremely

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 4 Jan 2007 16:11:27 +1300

Actually, transfer to subsequent paths does give middleboxes on the  
new path a chance to learn identifiers, because the necessary  
information is carried in the packets used for the return-routability  
check.

Andrew

On 03/01/2007, at 5:01 AM, marcelo bagnulo braun wrote:

> AFAIK, the middle box keeps track of the HIP base exchange, and  
> then it learns what identifiers match to following data packets,  
> right?
> I think hip work has done the first thing (allow middle boxes to  
> keep track of the hip base exchange) but not the second one (deal  
> with path changes), right?
> in any case, i think their experience is very useful to have a  
> fleshed example of how to do this and the complexity involved  
> (which is one of the prices to pay to allow portability based on PI  
> identifiers)
>
> Regards, marcelo
>
>
>> That middleboxes should be able to determine the identifiers in  
>> use was a design decision in HIP; perhaps unfortunately, they're  
>> compressed into an SPI, so the middlebox does have to keep state  
>> to do it.  The state is just a binding between identifier, known  
>> locators and SPIs, however, and the protocol is designed to make  
>> it fairly convenient and secure (in the sense that spoofing is  
>> extremely difficult) for a middlebox to maintain that.
>>
>> Andrew
>>