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

Re: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006


El 07/08/2006, a las 17:31, Bound, Jim escribió:


Tom, I explained in my last mail. Ipsec should not have used IP
addresses but it is all we have today and cannot achieve consensus on
identifiers anywhere in any SDO or consortia.  Today it is a fast path
for IPsec to parse the IP header off the IP stack interrupt queue and
permits us to drop the packet immediately if SA issue is found. HBA does 
not give me enough comfort or the shim6 protocol to alter that
implementation behavior and also creates additional security problems.
could you describe what are the security problems introduced by the shim protocols what HBA CGA are used? 


Just leave it encapsulated under IP and decrypt from IPv6.


this doesn't provide protection against identity hijacking attacks


  The PKI and
Pre-Shared key issue is a red herring,


what do you mean by this?
Do you think that using IPSec without PKI or preshared keys is good enough? 

regards, marcelo



 once we have an established IPv6
address between nodes IPsec works just fine.  From there shim6 can use
IPsec to pass locators.

Best,
/jim


-----Original Message-----
From: Henderson, Thomas R [mailto:thomas.r.henderson@boeing.com]
Sent: Wednesday, August 02, 2006 12:02 PM
To: Bound, Jim; shim6@psg.com
Subject: RE: IPsec Issue Discussed for Shim6 at IETF Meeting
July 10, 2006




-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Tuesday, July 11, 2006 3:44 AM
To: shim6@psg.com
Subject: IPsec Issue Discussed for Shim6 at IETF Meeting

July 10, 2006


Per the Chairs to WG,

Currently for Shim6 the ULIDs are used to encrypt and decrypt the
Shim6 packet per discussions on this with the authors for IPsec.
This is done
and possible because there is a context associated with the locator
pair from out-of-bound message exchange at each end point

to identify

the ULIDs for location pair association.  This means the

locator pair

in the IP header are not used for IPsec encyrpt and decrypt

as is done

today according to IPsec.

This is using out-of-bound signals to set up IPsec and was
specifically rejected as a method for IPsec when defining the IPsec
architecture back in 1995 at IETF Danvers meeting. In addition this
type of use of IPsec should be verified and supported by

the IPsec WG

within the IETF.



Jim,
Can you clarify this historical note?  I wasn't around for
the IPsec discussions then but I did go back to look at the
mail list at the time and it seems that, in fact, IPsec did
adopt an out-of-band signaling exchange (IKE), and that
in-band (SKIP proposal) was rejected.  Here is the start of a
thread on this subject:
http://www.sandelman.ottawa.on.ca/ipsec/1995/02/msg00096.html
but you seem to be using the terminology differently.

I can't find it written down anywhere that the locator pair
in the IP header on the wire must be those used at the point
of IPsec processing for encrypt and decrypt.

Tom