Subject: RE: [Mip6] DSMIPv6 and IKE

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 19 Oct 2007 20:25:18 +1000

I'll reply to both comments below.

 > > This solution would work, but I am not too comfortable with the
 > > temporary tunnel being setup for IKEv2 messages. We don't have
 > > such a thing for a MIPv6 home agent today. All tunnel state is
 > > created only after the successful exchange of a BU/BAck.
 > 
 > I'm not also quite sure what exactly would be the tunnel 
 > state created. For example, a message seen by the IKE daemon 
 > would be  simply:
 > 
 >   IPv6 header (src=V6HOA, dst=HAADDR)
 >   UDP header (src=500, dst=500)
 >   IKE message (IKE_SA_INIT request)
 > 
 > and the reply sent would be
 > 
 >   IPv6 header (src=HAADDR, dst=V6HOA)
 >   UDP header (src=500, dst=500)
 >   IKE message (IKE_SA_INIT response)
 > 
 > How would this actually get routed to the tunnel? To the kernel,
 > this looks just like an ordinary UDP packet going to V6HOA, and
 > would get sent out as usual (if we haven't done BU for the new 
 > V4ADDR yet, it won't get sent there).

=> Basically the DSMIP6 code would have to capture any packet sent by the
IKE daemon (known port)to the IPv6 home address that has already sent the
original message. I think that would work. As you (Pasi) said, we would not
create a route in the routing table, it would have to be treated as
temporary state in the DSMIPv6 implementation. 

 > In theory, we could have a modified DSMIPv6-only IKE daemon 
 > that would understand the tunnel headers, and construct appropriate
 > replies, but then we're not talking about standard IPsec anymore.

=> I think we can do it without touching the IKE daemon.

 > 
 > One solution that might work is putting the state information for
 > reply in the packet (as seen by IKE) itself: e.g. the source address
 > (as seen by IKE) would be "magic prefix:V4_ADDR:V4_PORT".  But this
 > would be IPv6 NAT (although just inside a host -- so maybe not that
 > different to what e.g. HIP does by exposing just HITs to
 > applications)...

=> That's another way of doing it but we've been advised by the AD to not
use mapped addresses at all and this is basically a mapped address.

 > 
 > > > In this option we run IKE over port 4500, but add
 > > > "DSMIPV6_UDP_ENCAPSULATION"
 > > > notification when negotiating ESP SAs. Those ESP SAs would 
 > > > use src/dst port DSMIPv6-PORT.
 > > 
 > > I would like to know more about the "cons" of this solution. 
 > 
 > One obvious "con" is that it requires extensions to IPsec/IKE 
 > (or in other words, IPsec/IKE implementation with DSMIPv6-specific
 > changes).

=> Agreed.

 > 
 > > In this solution the BU/BAck is always sent over port 4500 
 > > using UDP ESP encapsultion, but actual DS-MIPv6 tunnel uses
 > > "DSMIPv6-PORT". This should work fine.
 > 
 > Well... if the BU/BAck is sent over port 4500, we need some other
 > "BU-like" message that is sent over DSMIPv6-PORT.

=> Exactly.

Hesham

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 19 Oct 2007 21:24:15 +1000

> > => Basically the DSMIP6 code would have to capture any packet sent
 > > by the IKE daemon (known port)to the IPv6 home address that has
 > > already sent the original message. I think that would work. As you
 > > (Pasi) said, we would not create a route in the routing table, it
 > > would have to be treated as temporary state in the DSMIPv6
 > > implementation.
 > 
 > This requires some special kernel tweaks to capture all traffic 
 > sent by the IKE daemon (and apply special processing to some part 
 > of it). 
 > 
 > If this special requirement only applies to IKE traffic (but not 
 > ESP), it might be almost doable...but it's not exactly nice,
 > as all the messages at this point are unauthenticated.

=> Right, no disagreement about that it's not nice :) I just don't think any
of the solutions we came up with are nice. At least with this option we can
do everything with one message and without modifying IKE. I guess the lack
of authentication affects things for a very short time. That is, if state is
stored for T then
T = P where P is the time it takes the IKE daemon to process the message.
It's not that bad really, just a little bit longer than any connection
request that a server would receive. 

 > 
 > BTW, ESP actually has a similar problem vs. the virtual link
 > tunnel. When the BU arrives in the HA, it would look like this:
 > 
 >   IPv4 header (src=NATTED_V4ADDR, dst=HA_V4ADDR)
 >   UDP header (src=NATTED_DSMIPv6-PORT, dst=DSMIPv6-PORT)
 >   ESP header
 >   Mobility header
 >   BU [IPv4 HAO]
 >   IPv4 CoA option
 > After doing the "virtual link" decapsulation the packet
 > would look like this:
 > 
 >   ESP header
 >   Mobility header
 >   BU [IPv4 HAO]
 >   IPv4 CoA option
 > And after IPsec processing, the module actually parsing 
 > the MH will see:
 > 
 >   Mobility header
 >   BU [IPv4 HAO]
 >   IPv4 CoA option
 > In other words: it won't see the information it really needs
 > (NATTED_V4ADDR and NATTED_DSMIPv6_PORT)! Again, the host 
 > clearly has this information, but getting it might require 
 > some serious architectural tweaking of IPsec and TCP/IP 
 > stack in general....

=> I don't think this needs architectural changes to IPsec implementations. 
The module that calls IPsec will already have this information. When the
packet comes back from IPsec to the calling module it can append this
information for the next function. This is totally transparent to IPsec and
limited to the DSMIPv6 implementation. 

Thanks,
Hesham