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

Re: FW: tunnel mode

To: Roy Pereira <rpereira@TimeStep.com>
Subject: Re: FW: tunnel mode
From: Daniel Harkins <dharkins@cisco.com>
Date: Tue, 17 Dec 1996 20:11:19 -0800
Cc: "'IPSEC Mailing List'" <ipsec@ex.tis.com>, "'isakmp-oakley'" <isakmp-oakley@cisco.com>
In-Reply-To: Your message of "Tue, 17 Dec 1996 18:06:07 EST." <c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-961217230607Z-3520@tsntsrv2.timestep.com>
Sender: owner-ipsec@ex.tis.com

I'm not sure, but I believe this was Derrell Piper responding to Roy Pereira:
> >Derrell, how do we do DES-HMAC-MD5/SHA1 in tunnel mode?  Your 
> >current draft doesn't allow for this.  Am I missing something?  It also
> >doesn't include the newer 3DES-HMAC-MD5/SHA1.
> 
> Except for the old-style ESP, you can't in the current incarnation of 
> the drafts.
> 
> I made a note during the ipsec wg that I needed to add Tunnel and 
> Transport SA Attributes.  They'll be in the next version of the draft, along 
> with a proscribed set of defaults for the existing attributes.
> 
> Suggestions on what those defaults should be are most welcome...

  I don't see why Tunnel or Transport attributes need to be negotiated.
There shouldn't be anything wrong with using a single SA for both provided
there were no PFS restrictions on the SA.
  This seems to me to be an issue of the particular IPsec implementation's
policy engine, not of SA negotiation. If some packet needs security to go 
through an encrypting router, and a SA exists to that router then the policy 
defined in that SA is applied in tunnel mode. If some later packet needs to 
go to the router itself (not through it) why not just apply the SA in 
transport mode?

  Dan.

References:

FW: tunnel mode

From: Roy Pereira <rpereira@TimeStep.com>

Prev by Date: FW: tunnel mode
Next by Date: Re: key life attributes (Was: Re: FW: tunnel mode)
Prev by thread: FW: tunnel mode
Next by thread: Re: key life attributes (Was: Re: FW: tunnel mode)
Index(es):
- Main
- Thread