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

Re: visibility of identifier in shim6 payload packet


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


Tom,
I am on vacation Aug 7-28 but doing some of my non day job work at times 
to clean up. My response below.  I cannot stay mail for mail but
hopefully this will help.


Basically, you (and Jim) seem to be arguing that, with IPsec,
there can not be any packet transformation below the IPsec
layer that cannot be undone by an intermediate device that
looks only at the individual packets and doesn't have access
to other context negotiated by key management or shim
protocols, and that either:
i) shim6 should be layered above IPsec and just work on the
basis of locators and perhaps use mobike techniques or just
create new SAs when locators change, or
ii) shimmed packets must carry the ULID in each packet for the benefit
of BITW/BITS implementations


The flaw in IPsec is the use of addresses, but we cannot agree in the
IETF or elsewhere what is the best identity.  If IPsec is used the
issues for RFC 4218 are highly reduced,


not really
IPSec without pre shared key or PKI does not provides identity protection. This means that basically IPSec without pre shared key or PKI mostly allows the peers to be certain that they are communicating with the same peer all the time and that nodody has hijacked the ongoing communication.
However, IPSec without pre shared keys or PKI does not provides protection for future attacks on the identity meaning that it is trivial to hijack all future communications that a hosts wants to do with a given identity. 

I don't think this is acceptable


 as IPsec Architeture does
provide security in depth defense at layer 3 for the node, use, and LAN. 
I am not saying we do not need multi-layered security above layer 2 or
TLS, in fact we do and far more than we have today.  But, for shim6
IPsec is fine to secure the negotiations of the locators.  PKI or
Pre-Shared keys issue are orthogonal to the securing of ULIDs completely 
and unlike some here I don't see a problem for the evolution of PKI for
IPsec between peers.


yes, we disagree on this point

i don't see PKI as a realistic option in the mid future



Regarding end-to-end.  No IPsec did not say that exactly the Internet
architecture states it is the best scenario.  I want the ability to
encrypt my packet to you so that no one on the planet, except with
proper law enforcement, can see anything in my IPv6 packet but the IP
header and hop-by-hop or destination options.
yes, but i guess you also want that it is not trivial to hijack all the future communication tht are addressed to your IP address 

using the current shim and IPSec you can have both





 If an intermediate box
has the authority to decrypt (meainging permission from the end-nodes or 
the authority of the end-nodes) the packet that is fine, but I suggest
that decryption not interfere with the line rates of the communications
NIC and IO communications between the end-nodes.



But I think the above is a limiting view of IPsec, and is not
consistent with reality that there may be IPsec (native
end-to-end) within IPsec
(BITW) that changes the selectors available to BITW, or NATs.


Today implementations are built to decrypt as fast path with the IP
header.  That is simply the case today.
yes, but the point is that those implementations have decided to implement in hardware everything below the IPSec. So this means that any change in the stack in IPsec or below, will result in updating this piece of hardware. So, yes, if you want to implement shim or if you want to implement MIP HoA processing or MIP routing header processing or SeND processing or additional IPSec crypto algorithm or any other protocol that is below IPSec you need to update these pieces of hardware, but i guess this is normal, since the implementation is in hardware. 


CGA further exacerbates the broken issues of IPsec by relying on an IP
address based keying and also cannot support multi-prefix scenarios as I 
understand the method. HBA uses CGA spec and is still address based
keying.  We need to remvove HBA from the core shim6 spec and leave a
template for multiple solutions that are TBD.
I don't think this is an option. I mean shim without proper security is simply inacceptable. We must provide a security mechanism (at least one) from the start of the shim will not fly. And saying use IPSec in the security considerations section will not fly, because oportunistic IPSec does not make a proper job and pre shared keys and PKI are not feasible in the short term. 

I mean, consider the MIPv6 experience.
In the early versions of the draft you can find the following the security cosniderations 

this is from draft-ietf-mobileip-ipv6-09.txt

13. Security Considerations

13.1. Binding Updates, Acknowledgements, and Requests

   The Binding Update option described in this document will result
   in packets addressed to a mobile node being delivered instead to
   its care-of address.  This ability to change the routing of these
   packets could be a significant vulnerability if any packet containing
   a Binding Update option was not authenticated.  Such use of "remote
   redirection", for instance as performed by the Binding Update option,
   is widely understood to be a security problem in the current Internet
   if not authenticated [1].

   The Binding Acknowledgement option also requires authentication,
   since, for example, an attacker could otherwise trick a mobile node
   into believing a different outcome from a registration attempt with
   its home agent.

   No authentication is required for the Binding Request option, since
   the use of this option does not modify or create any state in either
   the sender or the receiver.  The Binding Request option does open
   some issues with binding privacy, but those issues can be dealt with
   either through existing IPsec encryption mechanisms or through use of
   firewalls.

   The existing IPsec replay protection mechanisms allow a "replay
   protection window" to support receiving packets out of order.
   Although appropriate for many forms of communication, Binding Updates
   MUST be applied only in the order sent.  The Binding Update option
   thus includes a Sequence Number field to provide this necessary
   sequencing.  The use of this Sequence Number together with IPsec
   replay protection is similar in many ways, for example, to the the
   sequence number in TCP.  IPsec provides strong replay protection but
   no ordering, and the sequence number provides ordering but need not
   worry about replay protection such as through the sequence number
   wrapping around.
basically they were saying "use IPSec" for this and the problems are solved
This turned out to not be the case since IPSec is not an option because the reasons i mentioned above
the case was that the IESG returned the protocol to the wg and they needed to work out a deployable real solution 

i think we are in the same case here
shim without security is simply inacceptable because of the vulnerabilities that it introduces 

IPSec is not a realistic option (or it requires pre shared key or a PKI)

regards, marcelo




Best,
/jim



Tom