[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 08/08/2006, a las 17:00, Bound, Jim escribió:


HBA does not prevent attacks that IPsec does.  See IPsec.



i agree with this

let's see if you agree with the following statements:
- in any case, some of the attacks that are prevented by IPSec are not prevented by HBA
- It is possible to build a security mechanisms to protect the shim6 protocol using IPSec with preshared keys or with PKI that actually prevents all the threats described in RFC4218
- It is not possible to build a security mechanisms to protect the shim6 protocol using IPSec without preshared keys nor PKI that prevents all the threats described in RFC4218 (in particular, it is not possible to provide protection against redirection of future communications to a given identifier)
If you do not agree with the last bullet, please describe how would you build a security mechanisms for the shim6 protocol that actually protects from this type of attacks using IPSec without using pre shared keys or PKI. I mean if you can provide an actual solution that works, it would be really useful because we could compare them and see the pros and cons. Comparing a full fleshed silution like HBA with some undocumented solution based on IPSec is extremely hard...
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. 



but this is not the case...
i mean the shim6 is completelly compatible with IPSec (or it should be). The goal is that you can use shim6 and IPSec toghether in the same communication, i don't think there is any doubt about it.
The problem is that IPSec does not provides all the protection that it is required by the shim protocol if there are no pre shared keys or PKI, so we need additional tools in this case. It would be irresponsible by us to accept a solution that introduces critical vulnerabilities like identify hijacking by supporting opportunistic IPSec as a security solution for the shim protocol
So, i fully agree that shim6 and IPSec must run together, Moreover, i think it is a good idea that if the peers are already using IPSec and they have a preshared key or a pki with a common anchor point available, they use IPSec to protect the shim6 protocol. What is more, i am willing to work with you to design such approach and write it down in an ID and see that it fits in the shim6 protocol. However, we must provide an alternative solution for the case where the pre shared kay and the PKI are not available and a security solution based on IPSEc in not secure enough for this case. So far this solution is based on the HBAs
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.
again i don't think that we can send a protocol wihtout proper security, it is just a useless protocol, since it cannot be deployed (and i guess that the IESG will reject it)
my suggestion is let's discuss the security solutions now... we have been working on this too long to delay it further.
we can design a security solution based on IPSecfor the case were it can be used safely (preshared key or PKI)
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. 

this is already the case
the current version of the shim6 protocol does support multiple security mechanism and can be extended to other security mechanisms that is why i say that it would straight forward to design a solution based on IPSEc with preshared keys or PKI 

regards, marcelo
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. 

Best,
/jim




-----Original Message-----
From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]
Sent: Tuesday, August 08, 2006 2:45 AM
To: Bound, Jim
Cc: Henderson, Thomas R; shim6@psg.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: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