Subject: Re: IPCOMP and IPSEC

From: Naganand Doraswamy <[email-masked]>
Date: Thu, 28 May 1998 08:54:28 -0400

>If this is supported, is it detailed anywhere?  For example, if an
>Explicit IV is used, would it come after the ESP header or after the
>IPCOMP header?
>

You construct the ESP payload in the same fashion for any protocol payload
you are carrying. ESP treats IPCOMP as an other protocol- IP, TCP.
--Naganand

-----------------------------------------------------------------
Naganand Doraswamy				(978)916-1323 (O)
Bay Architecture Lab				(978)916-0620 (Fax)
3 Federal St, Mail Stop BL3-03
Billerica, MA 01821

---

From: "Saroop Mathur" <[email-masked]>
Date: Thu, 28 May 1998 17:02:18 -0700

Eric,

The compression ration depends a lot on the type of data and the packet
size. Using IPSEC will not change the compression ratio since compression
is done before IPSEC.

- Saroop

----------
> From: Eric Dean <[email-masked]>
> To: Daniel Harkins <[email-masked]>
> Cc: Stephen Waters <[email-masked]>;
[email-masked]; [email-masked]
> Subject: Re: IPCOMP and IPSEC 
> Date: Thursday, May 28, 1998 3:39 PM
> 
> > Anybody out there want to test IPSec and IPCOMP together? Send me an
> > email.
> > 
> 
> Sure, we tried IPCOMP without IPSec and got about 1.05:1 compression
ratio
> though.  I can't wait for after IPSec.
>  
> _______________________________________________________________
> Eric Casey Dean    
> Supervisor: IP Product Engineering
> Tel#: 703-689-5298  Fax#: 703-478-7852  Mobile#: 703-598-0962
>

---

From: [email-masked] (Marc Hasson)
Date: Thu, 28 May 1998 13:40:53 -0700

Dan,

 > 
 > I guess you could say that ESP is in transport mode, but what about the
 > case where both AH and ESP are applied to the same packet:
 > 
 > 	[IP2][AH][ESP][IP1][data]
 > 
 > Is AH in transport mode? 

Good point.  I can hear people arguing it both ways and am sorry I
raised that side tidbit.  Whats more important is that we all understand
how to process the above, which I think is pretty clear in the specs.

 > Roy's would correct if the compression was being done by the host before
 > passing the packet to the SG, but Stephen (in the original post that started
 > this all) stated that the original packet received by the SG was:
 > 
 > 	 [IP1][TCP][data]

Agreed, and a later post of Roy's corrected his response to Steve.  I had
just wanted to confirm that Roy's packet description was correct *if* the
original host had instead emitted:

 	 [IP1][IPCOMP][TCP][data]

which the first SG turns into Roy's:

 	 [IP2][ESP][IP1][IPCOMP][TCP][data][ESP trailer]

Your paragraph above confirms this, thanks.

 > 
 > In this case I don't think it's legal for a SG to add anything-- IPSec or
 > IPCOMP-- in transport mode. 

You sound right to me.  One would certainly complicate the SG's job as well
as one is more likely to experience topology-related problems if this was
permitted since the SG containing the SA (or CA) is not explicitly addressed.
I believe the group has rejected this SG "transport mode addition" before.

   -- Marc --

---

From: Stephen Waters <[email-masked]>
Date: Thu, 28 May 1998 18:55:40 +0100

Ah, so there is some confusion then.   I think (thought) the right thing
to do was put the IPCOMP header outside the original IP header though -
that makes it obvious that the peer SG need to strip it off before
forwarding the original packet.  If the IPCOMP was inserted after IP1 by
a SG, how would the receiving SG know whether to extract it again - it
looks identical to a packet that has been compression by the original
host.

Steve. 

IPComp may be added by a security gateway just like IPSec ESP/AH is
added.  It would probably look like this though:
[IP2]
[ESP spi+replay+iv]
	[IP1]
	[IPCOMP]
	[TCP]
	[data] 
	[ESP padding+next protocol+auth]

	> -----Original Message-----
	> From:	Stephen Waters [mailto:[email-masked]]
<mailto:[mailto:[email-masked]]> 
	> Sent:	Wednesday, May 27, 1998 6:19 PM
	> To:	[email-masked];
<mailto:[email-masked];>  [email-masked] <mailto:[email-masked]>

	> Subject:	IPCOMP and IPSEC
	> 
	> 
	> 
	> Is IPCOMP restricted for use by Hosts (at packet origin), or
can it be
	> appended by a Security Gateway as part of the process of 
	> adding an IPSEC
	> tunnel header?
	> 
	> e.g.
	> 
	> Original host packet [IP1][TCP][data]
	> 
	> After passing through a security gateway/IP tunnel:
	> 
	> [IP2][ESP][IPCOMP][IP1][TCP][data][padding/next protocol][ESP
auth]
	> Stephen Waters
	> DEVON, UK
	> National: 01548 551012 / 550474
	> International: 44 1548 551012 / 550474
	> [email-masked] 
	>

---

From: Roy Pereira <[email-masked]>
Date: Thu, 28 May 1998 14:41:36 -0400

My appologies Stephen, you were correct.  I got a little confused and
wrote things backwards.  Your original layout is the correct mechanism
to use when the gateway is handling both IPSec and IPComp.

To answer you question of where the explicit IV goes; it must go right
after the ESP header (spi+replay), thus it is before the IPComp.  This
is because IPComp is really another protocol and not part of IPSec, thus
it is treated as protocol data just like TCP/UDP to IPSec.

> Sent: Thursday, May 28, 1998 1:56 PM
> To: Roy Pereira
> Cc: [email-masked]; [email-masked]
> Subject: FW: IPCOMP and IPSEC
> 
> 
> 

can it be
auth]