Subject: [rohc] RE: IPsec Processing & HCoIPsec

From: "Jasani Rohan" <[email-masked]>
Date: Mon, 25 Sep 2006 12:05:32 -0400

Stephen:
I've included my comments inline. Thanks

Rohan Jasani
Booz | Allen | Hamilton
703.984.0337 (office)
832.452.3241 (mobile)

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Monday, September 25, 2006 10:26 AM
> To: Tero Kivinen
> Cc: Jasani Rohan; [email-masked]; Ertekin Emre
> Subject: RE: IPsec Processing & HCoIPsec
> 
> 
> The concern Jasani cited is not a valid one, i.e., we already 
> allow a sender to establish multiple SAs with the same 
> traffic selectors so that the sender can use different SAs 
> for different classes of traffic.  The receiver need not be 
> aware of this distinction. 

I understand what you are saying now.

> However, Tero's observation is correct; we have already 
> selected an outbound SA before we would know whether a given 
> packet can be compressed, so it is not feasible to use two 
> pairs of SAs to accommodate compressed vs. uncompressed 
> traffic on a per-packet basis.

Correct, I agree.

> So, despite my concerns about getting a new protocol ID 
> assigned for this purpose, I agree that it is the simplest 
> and cleanest approach.

Looks like you, Tero, Emre and I prefer Approach 1, which is to allocate
a generic compressed headers IANA value.  Thanks for the input.

> Steve

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

---

From: Jan Vilhuber <[email-masked]>
Date: Mon, 25 Sep 2006 13:16:50 -0700

> a generic compressed headers IANA value.  Thanks for the input.

I'm still not convinced this is needed. Since the protocol ID is  
relevant ONLY to the two IPsec endpoints, it should be entirely  
feasible to just pick a random one out of a hat (making sure it  
doesn't conflict with any actual traffic on the ipsec-'link') and use  
that. There's quite a few IANA protocol numbers that are latent, not  
used, or whatever. Pick one and use it. No need to trouble IANA about  
it.

jan

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 28 Sep 2006 10:00:48 +0200

>> Looks like you, Tero, Emre and I prefer Approach 1, which is to
>> allocate a generic compressed headers IANA value.  Thanks for the
>> input. 
> 
> doesn't conflict with any actual traffic on the ipsec-'link')
> and use that. There's quite a few IANA protocol numbers that
> are latent, not used, or whatever. Pick one and use it. No need
> to trouble IANA about it.

I do not know enough about this specific scenario to say whether
this is feasible, but if it is, it sounds like an appealing idea.

/L-E

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Sep 2006 14:56:47 +0200

> this is feasible, but if it is, it sounds like an appealing idea.

I would caution against this. The issue is that you will need a dynamic 
collision handler in that case. You must be able to switch that number 
if you get incoming traffic with that protocol ID you where using. If 
you don't, you will prevent some other protocol being deployed. And if 
this is a configurable matter, it will make some protocol fail in some 
environment depending on the configuration. Please do remember that new 
protocol ID are handed out and will continue to be. Thus by do an 
assignment you at least protect the world from yourself. If the header 
compression solution gets in trouble by needing to do dynamic 
negotiation about meaning per flow, or adds another generic header and 
loose some efficiency to determine what protocol really is used that is 
at least only affecting your own protocols.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Jan Vilhuber <[email-masked]>
Date: Thu, 28 Sep 2006 21:14:11 -0700

On Sep 28, 2006, at 5:56 AM, Magnus Westerlund wrote:

> I would caution against this. The issue is that you will need a  
> dynamic collision handler in that case. You must be able to switch  
> that number if you get incoming traffic with that protocol ID you  
> where using.

Perhaps so, but like I said, there's a ton of numbers assigned by  
IANA that are no longer realistically in use. I've never even seen a  
CHAOS packet, nor a SWIPE packet (or KRYPTOLAN, IPPC, etc..).  
Granted, I don't run a large networ (heck.. other than my own home  
network, I don't administer ANY networks). I'd love to hear from some  
operators. They can no doubt tell us what typesof packets they see,  
and which they NEVER see (ever).

I would also argue that administrators should know what types of  
packet are likely to appear in their network, and can configure some  
protocol number they know won't appear. I don't think adding, say,  
CHAOSnet (or whatever it's called) to an existing network can be done  
just by accident, so presumably an administrator will know and be  
able to adjust.

Then there's a few others we probably can use safely:
     63                 any local network                    [IANA]
     99                 any private encryption scheme        [IANA]
    131     PIPE   Private IP Encapsulation within IP       [Petri]
    253     Use for experimentation and testing           [RFC3692]
    254     Use for experimentation and testing           [RFC3692]

Personally, I was going to use 99 or 131, if only initially to prove  
the technology works before going to IANA with some better arguments  
than "we think this'll work".

> If you don't, you will prevent some other protocol being deployed.  
> And if this is a configurable matter, it will make some protocol  
> fail in some environment depending on the configuration. Please do  
> remember that new protocol ID are handed out and will continue to  
> be. Thus by do an assignment you at least protect the world from  
> yourself.

Agreed, I'm not AGAINST getting IANA to assign one. Last time I asked  
some folks at the IETF about it, I was told there wasn't a chance in  
hell we'd get a new protocol number (or at least they are incredibly  
hard to come by). I certainly am not made out for political wrangling  
(as you can no doubt tell), so at that point I devised an alternate  
way, which I think is perfectly legitimate (with minimal risk).

> If the header compression solution gets in trouble by needing to do  
> dynamic negotiation about meaning per flow, or adds another generic  
> header and loose some efficiency to determine what protocol really  
> is used that is at least only affecting your own protocols.
>

All you need to do is kick IKE with a new proposed number. Heck...  
negotiate 3 of them to start with, and in case of emergency, skip to  
the next one! An IKE notify can be used for that (or ikev2... I'm a  
little behind the curve; if you don't use IKE or v2, then I'm sure  
whatever protocol you're using has some means to send a notify. If  
not, you need to rethink your connection establishment protocol), and  
maybe a few packets get lost (don't forget to dutifuly syslog the  
error so the administrator can reconfigure boxes to exclude the new  
packet we just saw (CHAOS NET! ABORT ABORT ABORT!).

jan

---

From: Jan Vilhuber <[email-masked]>
Date: Thu, 28 Sep 2006 21:17:09 -0700

On Sep 28, 2006, at 9:19 AM, Stephen Kent wrote:

> At 10:00 AM +0200 9/28/06, Lars-Erik Jonsson \(LU/EAB\) wrote:
> There is an obvious danger to reusing an assigned but dormant  
> protocol number, i.e., if we think it's a valid thing to do, then  
> others who think similarly may trigger collisions. If we really  
> believe that a candidate protocol number is dormant (and I agree  
> that there are several such assignments) then we ought to work  
> through the process to reclaim one of these numbers and have it  
> reassigned for this purpose.  I know this will take time, but I  
> think it is worth it.
>

Believe it or not, I do agree :) I just don't like going through so  
much trouble. If I wanted bureaucracy, I'd go get a visa for some  
obscure foreign country. It sounds easier and much more appealing  
(since I'd presumably go VISIT said obscure foreign country).

jan

---

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Sep 2006 12:19:13 -0400

There is an obvious danger to reusing an assigned but dormant 
protocol number, i.e., if we think it's a valid thing to do, then 
others who think similarly may trigger collisions. If we really 
believe that a candidate protocol number is dormant (and I agree that 
there are several such assignments) then we ought to work through the 
process to reclaim one of these numbers and have it reassigned for 
this purpose.  I know this will take time, but I think it is worth it.

Steve

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Sep 2006 10:28:34 +0200

Hi,

I think you should float your idea(s) with a larger group of people 
after you considered what the pro and cons of each approach is. I would 
recommend posting to relevant area mailing lists. That way you will get 
more feedback on what ever you consider before spending to much time on 
them.

Cheers

Magnus

-- 

Magnus Westerlund