Subject: Re: Re[4]: IPv4 header modifications

From: Naganand Doraswamy <[email-masked]>
Date: Thu, 13 Nov 1997 14:25:01 -0500

Shawn,

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

In this case, the inner IP header has B as the destination. I am not sure I
understand why G should be snooping beyong the IP header in that case.
--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: Fri, 14 Nov 1997 11:43:30 -0500

> understand why G should be snooping beyong the IP header in that case.

You're right, it shouldn't.  I think we all agree on how it should
work, but maybe it just needs to be made explicit in the draft
somehow.  My concern is that some less-than-bright security
gateway might encapsulate "IP TCP" into "IP ESP IP IPComp TCP",
which wouldn't correspond to what a gateway on the other side
would be expecting.

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