RE: visibility of identifier in shim6 payload packet

["Bound, Jim" <Jim.Bound@hp.com>]

I disagree with everything you support.  That is fine.  That is why we have WG discussions. No response.  This conversation at my end is over with you unless there are new data points we are going in a circle.  Much of it is projection for tomorrow. HBA should be removed from the core spec or I will object at IESG last call.  Sorry but I will not be able to keep up with this mail regularly until Aug 28th as best I can. THus silence is not acceptance or support from my end.

Best and Respectfully,
/jim 

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