[support] Re: [Dsmip] Implementation of UMIP and Dyanamic key estabilishment through IKEv2 in IPV4-only network

Fri Feb 27 22:57:57 JST 2009

 Hi  Sebastien ,

Thanks so much for your valuable information.

Just for  Curiosity ,I have some inputs regarding the implementation, need
your thoughts upon this.

You are right DSMIPv6 deamon internally uses v6-mapped-v4 address. But as
per draft When MN move to FL(IPv4) it should use IPv4 address in IKE
messages rather then using v6-mapped-v4 address. Now to fix this issue there
are may be two way to go for it.

*Solution A *

As suggested by you I was thinking of changing strongswan code to alter IKE
messages to use real IPv4 address instead of using v6-mapped-v4 address.

*Concerns*:

As there is no security policy installed by mip6d for IPv4 address, this may
create problem. Current implementation of mip6d only accepts only IPV6
address in IPSec Policy section.

*Solution B*

          I was thinking of making the following code change in mip6d when
MN move to FL(IPv4):

1.      Enhanced the behavior of KMADDRESS to support IPv4 address also. I
have already verified that strongswan support KMADDRESS having IPv4 or IPv6
addresses.

2.      Insert corresponding IPv4 xfrm policies and templates to the kernel.
Which is missing currently. Current implementation push v6-mapped-v4 policy
to the kernel when MN moves to FL(IPv4).

Changes will be made when the new CoA address is v6-mapped-v4. The following
functions may be affected to support the above requirement.

Ø       _mn_trns_update

Ø       _mn_tnl_update

Ø       _mn_tnl_pol_mod

Ø       xfrm_sendmigrate

Ø       …And some more to be identified...

Kindly let me know if I am thinking on the right direction to fix the issue.
I will appreciate if you can send me some more pointers which Solution I
should go for.

Any Further pointers will be of great Help.

-Regards

satya

On Fri, Feb 27, 2009 at 8:05 AM, Sebastien Decugis <
sdecugis at hongo.wide.ad.jp> wrote:

> Hello,
>
> Thank you for your mail. I think that so far almost nobody tried to use
> dynamic keying with DSMIPv6 and IPv4 bootstrapping, you're a precursor ;)
>
> For historical reasons (evolution of DSMIPv6 draft) the DSMIPv6 daemon
> uses v6-mapped-v4 addresses internally, and this will not be changed
> easily. It is also easier to keep v6-mapped addresses in kmaddress
> extension, but this could eventually be changed.
>
> Therefore, the conclusion is that the IKEv2 daemon should be able to
> interpret the v6-mapped v4 addresses and use real v4 addresses instead,
> for IKEv2 messages.
>
> When I was working on this topic last year, it was not really possible
> (but I used racoon2, I am not familiar with strongswan) in IKEv2
> (implementation or protocol, I am not sure...) to switch from v6 to v4
> addresses. By that time, the MOBIKE project seemed to be promising to
> provide a solution, independent of DSMIP (in which case a race condition
> could occur, so one should be prudent here). I have not followed more
> recent evolutions, so I cannot tell if there has been any advance in the
> specification for this matter. In particular, I am not sure what is the
> correct IKEv2 packet format to be expected, nor correct IKEv2 module
> behavior.
>
> Sorry I cannot be of better help here. Has this already been discussed
> during the specification of DSMIPv6? I have not followed discussions for
> a long time...
>
> Best regards,
> Sebastien.
>
> satya sahu a écrit :
>  >
> > Hi Sebastien,
> >
> > I have some doubts regarding the implementation of mip6d and Dyanamic
> > key estabilishment through IKEv2 in IPV4-only network.
> >
> > MY packages in HA and MN:
> >
> >  kernel: 2.6.28 kernel with proper patched to support DSMIP udp and
> > TLV  encapsulation.
> >         UMIP-0.4: properly patched to support enhanced migrate support
> > ,NEMO IIPV4 traffi support and  bug fixe patches  given by you.
> >         IKEV2- strongswan-4.2.9
> >
> >         I have configured the strongswan and mip6d.conf to support
> > ipsec encryption of         BU/BA messages between HA/MN.
> >
> >
> > current Behaviour obeserved:
> >
> >  When MN moves from HL to IPV4 link, new coa is assgined to MN ,then
> > MN sends migrate messages to kernel(messages shown in syslog) as
> > KMADDRESS is ipv4 mapped ipv6 address.then IKE starts negotiations by
> > sending packet form <ipv4 mapped ipv6 address> to <ipv6 homeagent
> > address> but on HA side this packet is not recevied by IKE(BY digging
> > more i found that this packet reaches upto INPUT chain and after that
> > it drops some where) hence IKE negotiation fails.
> >
> >
> > I suspect that current mip6d daemon support this approach for
> > integrating IKE and DSMIPv6[Approach got from GROUP]
> >
> > Allow DSMIPv6 to look like a virtual link for IKE. Hence, IKE will simply
> > run over IPv6 and will not be aware of IPv4 at all.
> >
> >
> >
> > Message format for solution 1:
> > ------------------------------
> >
> > IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
> > UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT)
> > IPv6 header (src=V6HOA, dst=HAADDR)
> > ESP header
> > Mobility header
> > BU [IPv4 HAO]
> > IPv4 CoA option
> >
> > And IKE messages would look like:
> >
> > IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
> > UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT)
> > IPv6 header (src=V6HOA, dst=HAADDR)
> > UDP header (src=500, dst=500)
> > IKE message...
> >
> >
> >
> > I have configured the strongswan and mip6d.conf with  IPV6 HoA and
> > IPV6 homeagent address. There is no ipv4 address in both configuration.
> >
> >
> >
> > At this point I have two questions in my thought :
> >
> >  1) Could we use IPV4 home address and IPV4 home agent address in
> > ipsec policy set with IPV6 home address.
> >
> >  2) Is there any code level change in mip6d.
> >
> > *PS: Every thing is fine with movement from HL to IPV6 ,IPV6 to IPV6
> > ,IPV6 to IPV4 .IPSEC SA is properly estabilshed and IKE tunnel end
> > points are also successfully updated on movement.
> > *
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Dsmip mailing list
> > Dsmip at ml.nautilus6.org
> > http://ml.nautilus6.org/mailman/listinfo/dsmip
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.nautilus6.org/pipermail/support/attachments/20090227/146d4d12/attachment-0002.htm 