Subject: IPv4 header modifications

From: [email-masked]
Date: Wed, 12 Nov 1997 10:43:14 -0600

Since IPComp changes the total length and protocol fields in the IP 
     header, shouldn't the header checksum be re-computed?
     
     Thanks,
     
     Sumit A. Vakil
     Tunneling and Security
     3Com

---

From: Roy Pereira <[email-masked]>
Date: Wed, 12 Nov 1997 12:45:04 -0500

Of course.  If it isn't in the draft then it was assumed.  (but it
should be in the draft)

---

From: [email-masked]
Date: Wed, 12 Nov 1997 11:52:51 -0600

Yes, its not in there.

Sumit

______________________________ Reply Separator _________________________________
Subject: RE: IPv4 header modifications
Author:  Roy Pereira <[email-masked]> at Internet
Date:    11/12/97 12:45 PM

---

From: Avram Shacham <[email-masked]>
Date: Wed, 12 Nov 1997 22:05:16 +0200

In reality, the IP header checksum field is calculated just before leaving
the IP layer. For example, if ESP follows IPComp, the IP header checksum
will be calculated after ESP. There is no point in mandating the checksum
calculation in IPComp is such scenario. 

Unless the WG feels strongly that the obvious definition of the checksum is
really missing, I suggest to keep the reference implied.

avram

At 11:52 AM 11/12/97 -0600, [email-masked] wrote:
>>      3ComContent-Type: text/plain; charset=US-ASCII; name="RFC822 message
headers"
>Content-Transfer-Encoding: 7bit
>Content-Description: cc:Mail note part
>Content-Disposition: attachment; filename="RFC822 message headers"
>
>Attachment Converted: C:\Program Files\Eudora\RFC822 message headers8
>

---

From: [email-masked]
Date: Thu, 13 Nov 1997 08:30:03 -0600

Michael,
Please see my comments below.

Thanks,

Sumit

    svakil>         IP ESP IP IPComp TCP
     
  Why would we want to make the above assumption?
          IP ESP IPComp IP TCP
     
  makes much more sense to me. Most of the savings, I would think,
would be in compressing the IP header.

SUMIT>> We want to make the above assumption because the IPComp draft describes 
inserting the IPComp header between the IP header and the upper layer protocol 
payload.  As it stands today, the draft does not define IPSec like 'transport' 
and 'tunnel' modes.  All it says is, compress the ULP payload and insert the 
IPComp header between the IP header and the ULP payload.  From section 2.1 of 
the draft,

"In IP version 4 [RFC-0791], the compression is applied to the upper
layer protocol (ULP) payload of the IP datagram.  No portion of the
IP header or the IP header options is compressed."
                and,
"As defined in section 3, an IPComp header is inserted immediately
preceding the compressed payload.  The original IP header is modified
to indicate the usage of the IPComp protocol and the reduced size of
the IP datagram.  The original content of the Next Header field is
stored in the IPComp header."

svakil> I feel that the IPComp draft should explicitly mention updating the
IP header 
svakil> checksum.  An implied reference to anything is not good enough for a
document 
svakil> that's going to become an Internet standard.
     
  By strict layering, IPComp doesn't create the IP header. It gets
added afterwards, so the length and the size is correct. If you do 
things by putting wedges in the stack, then you need to know this. 

SUMIT>> I agree that IPComp does not create the IP header.  
However, the draft suggests that the IPComp header is added to the 
packet only after the IP header gets added.

Also, if we go by strict layering, IPComp should not be modifying 
any part of the IP layer header in the first place!

   :!mcr!:            |  Network and security consulting/contract programming 
   Michael Richardson |   I do IPsec policy code for SSH <http://www.ssh.fi/>
 Personal: <A
HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@
sandelman.ottawa.on.ca</A>. PGP key available.
 Corporate: <A
HREF="http://www.sandelman.ottawa.on.ca/SSW/">[email-masked]</A>. 
        ON HUMILITY: To err is human, to moo bovine.

---

From: [email-masked]
Date: Thu, 13 Nov 1997 08:46:29 -0600

Dan,
     By your argument, the text on modifying the length and protocol field 
     in the IP header must also go.  It is quite obvious that compressing 
     the payload and adding a new header changes the size of the payload 
     and hence the total length field in the IP header.  It is also obvious 
     that inserting a different protocol header between the IP header and 
     the ULP payload changes the protocol field in the IP header.  Why is 
     it that we are assuming that the reader knows to update the checksum 
     but not the total length and the next protocol fields?
     
     We can argue about this all day, but I feel that adding a note on 
     recomputing the checksum will make the draft complete, not pedantic.
     
     Sumit
     
     P.S. Going by IETF traditions, a DIRECT reference to RFC791 will do!

______________________________ Reply Separator _________________________________
Subject: Re: Re[4]: IPv4 header modifications 
Author:  Daniel Harkins <[email-masked]> at Internet
Date:    11/12/97 4:04 PM

  Sumit,
     
> I feel that the IPComp draft should explicitly mention updating the IP header 
> checksum.  An implied reference to anything is not good enough for a document 
> that's going to become an Internet standard.
     
  By following this road an incredibly pedantic document can be produced.
Shall a description of computing the checksum also be included or can we 
just imply reference to RFC791? If you change the header (the length for 
instance) then you recompute the checksum. A certain level of knowledge 
on the part of the reader must be assumed.
     
  This whole thread begs the question: where are you doing IPComp? Is
this a bump-in-the-wire compressor?
     
  Dan.

---

From: Naganand Doraswamy <[email-masked]>
Date: Thu, 13 Nov 1997 11:51:04 -0500

<SNIP>
>  Why would we want to make the above assumption?
<SNIP>

I would like to leave it for the implementation to decide where to add the
compression header in the above case. Obviously, the above combination
makes more sense. However, IP ESP IP IPComp TCP is also valid. Why we can
do is add an implementation note in the draft saying that if compression is
performed after IP header is added, then we should follow RFC791 in
recalcuating the changed header fields.
 
--Naganand

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

---

From: [email-masked] (Shawn Mamros)
Date: Thu, 13 Nov 1997 14:12:09 -0500

> >  Why would we want to make the above assumption?
[...]
> makes more sense. However, IP ESP IP IPComp TCP is also valid.
[...]

I'm not at all sure that I like this approach.  It means the receiver
has to test for both possibilities all the time, which only serves to
slow things down without adding any tangible benefit (IMO).

I can also see one potential scenario where it could cause confusion
and potential loss of interoperability.  Imagine three nodes, A, B,
and G, where G is a security gateway that A must go through to get to
B.  Node A establishes IPsec ESP security associations with G to get
to B.  Along with those, IP compression is also set up between A and G,
using algorithm X.

Now, for whatever reason, B also wants to set up compression with A.
Assume that A allows this.  Furthermore, assume that A and B decide
to use compression algorithm Y instead of compression algorithm X.

A sends a packet to B.  A first uses the IPComp association it has
established with B, resulting in IP IPComp TCP.  Then, realizing it
has to go through G to get to B, A either tries (and fails) to
compress the packet using its IPComp association with G, or realizes
it can't be compressed further and doesn't try.  It then applies ESP
and an outer IP header to the packet, so we have IP ESP IP IPComp TCP.

G receives the result, and successfully decrypts the packet into
IP IPComp TCP.  What happens next depends on the CPIs that B and
G chose.  If B is using a different CPI than G, G *may* send the
packet on, knowing that it can't uncompress the result, and hope
that B knows what to do.  Or it may discard the packet because the
CPI is "wrong" to G's point of view.

The situation is worse if both B and G chose the same CPI (remember,
they're using different compression algorithms!).  G either fails
completely, or sends garbage on to B.

For this reason alone, it may have to be mandated that, whenever
an IPComp association and an IPsec security association are
negotiated together, IPComp MUST be used as the Next Protocol
with IPsec; in other words, IP AH/ESP IPComp IP TCP is the only
allowable combination.

-Shawn Mamros
E-mail to: [email-masked]

---

From: Avram Shacham <[email-masked]>
Date: Thu, 13 Nov 1997 22:33:42 +0200

At 08:46 AM 11/13/97 -0600, [email-masked] wrote:
<snip>     
>     P.S. Going by IETF traditions, a DIRECT reference to RFC791 will do!
<snip>

The original wording of the draft agrees with Dan Harkins, that the
requirement to send an IP header with a valid checksum is obvious. But
Sumit's above call is reasonable, so how about adding the following 3 lines
(11 words, 93 characters) to sec 3.1

      Header Checksum

         The Internet Header checksum [RFC-0791] of the IP header.

avram

---

From: Roy Pereira <[email-masked]>
Date: Thu, 13 Nov 1997 16:07:48 -0500

Agreed.  Lets not make IPComp inflexible.

---

From: Roy Pereira <[email-masked]>
Date: Thu, 13 Nov 1997 16:11:23 -0500

Your scenario is valid, but I believe that it would be up to the
implementation and its policy to make the 'right' decision on where to
place IPComp.  If we have "IP ESP IP IPCOMP", then the IPComp
association was not with the gateway, but with the internal node.  "IP
ESP IPCOMP IP" would be for the gateway.  

I don't see an issue here, except maybe for some text in the document to
describe different scenarios and what they would mean.