[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPCOMP and IPSEC

To: Roy Pereira <rpereira@TimeStep.com>
Subject: Re: IPCOMP and IPSEC
From: Daniel Harkins <dharkins@cisco.com>
Date: Thu, 28 May 1998 09:52:50 -0700
Cc: Stephen Waters <Stephen.Waters@digital.com>, ippcp@external.cisco.com, ipsec@tis.com
In-Reply-To: Your message of "Thu, 28 May 1998 12:25:17 EDT." <319A1C5F94C8D11192DE00805FBBADDF1244E2@exchange.timestep.com>
Sender: owner-ipsec@ex.tis.com

  Roy,

> 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]

  Why would it look like that and not:

  [IP2]
    [ESP spi+replay+iv]
      [IPCOMP]
        [IP1]
        [TCP]
        [data] 
      [ESP padding+next protocol+auth]

  I have a rule that says "for traffic from foo to bar apply IPCOMP then
IPSec" so why would my IPCOMP be effectively a transport mode application
while my IPSec would be tunnel. They're both part of the same rule so
they're both done in the same mode.

  An intermediate gateway shouldn't muck with the inner packet. If you
did what you propose the packet would be forwarded on to the destination
address of IP1 who most likely doesn't have the IPCOMP SA to decompress
it.  The IPCOMP "SA" is negotiated along with the IPSec SA so they both 
have to be targeted to the same destination and be applied in the same mode. 

  Dan.

References:

RE: IPCOMP and IPSEC

From: Roy Pereira <rpereira@TimeStep.com>

Prev by Date: Re: mutiple phase 1 tunnel and proxy ID issues
Next by Date: FW: IPCOMP and IPSEC
Prev by thread: RE: IPCOMP and IPSEC
Next by thread: RE: IPCOMP and IPSEC
Index(es):
- Main
- Thread