[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
HBA does not prevent attacks that IPsec does. See IPsec.
By Red Herring for IPsec PKI I am saying that the issue of PKI is often used to not use end-to-end today (as I described it before) because of PKI and just a means to win another technology discussion point often to support the further use of mid-com boxes which is in the way of true end-to-end. It is an art of negotiations to position that which is not the issue against the real issue avoiding addressing the real issue. IPsec is now being used as strategy by every government and industry I know for those deploying not just IPv6. It provides defense in depth at layer 3. Not having it as an option for shim6 is irresponsible by us in an IETF shim6 WG.
The compromise I suggest to the WG is remove any security from base shim6 spec which will never be deployed at least for 3 years and permit the WG to work on multiple solutions as an exercise. In the interim for any testing or scoping IPsec can be clearly used in R&D labs to secure packets. And any shime6 IP stack implementation should be architected in products to be modular to support multiple means to secure Locator communications for session use for multihoming. We should also only conceptually specify the layer model whether above IP, above TCP, etc. (note do not assume a strict layering model IP can call TCP etc. at any point time and vice/versa).
The entire discussion regarding Security for shim6 should be required to be reviewed by the IPsec WG and IETF Security Area Directorate.
> -----Original Message-----
> From: marcelo bagnulo braun [mailto:firstname.lastname@example.org]
> Sent: Tuesday, August 08, 2006 2:45 AM
> To: Bound, Jim
> Cc: Henderson, Thomas R; email@example.com
> Subject: 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:firstname.lastname@example.org]
> >> Sent: Wednesday, August 02, 2006 12:02 PM
> >> To: Bound, Jim; email@example.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: firstname.lastname@example.org
> >>> 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