Subject: [MEXT] (Quick) Review of draft-patil-mext-mip6issueswithipsec [was: Revised I-D: Problems with the use of IPsec as the security protocol for Mobile IPv6]

From: Jean-Michel Combes <[email-masked]>
Date: Wed, 15 Jul 2009 14:30:25 +0200

Hi,

Here is my first (quick, especially on the section 6 where some points
must be checked more deeply) review of this draft.

At first, the new version of this draft is clearly more detailed than
the previous one, thanks a lot!

Comments:

o Section 4
Regarding the interaction between MIPv6 and IPsec/IKEv2, I agree that
IPsec/IKEv2 must be "MIPv6 aware" but the main reason is not explained
in the draft.
This last one is that, when doing Route Optimization, a packet sent by
a MN must follow this process (I omit the process for a packet
received/sent by the CN and a packet received by a MN: the goal is
just to illustrate the interaction between MIPv6 and IKEv2):
1.	MIPv6 daemon builds of the IP packet with the HoA in the IP Header
and the CoA in Home Address Destination Option
2.	IPsec daemon applies IPsec policy
3.	MIPv6 daemon switches the HoA and the CoA and sends the packet
So, if a MN wants to do RO with a CN and wants to set up an IPsec
connection with this CN, no choice: IKEv2 must interact with MIPv6.
The arguments described in this section, IMHO, should not be more
valid if an API would be standardized between the MIPv6 daemon and the
IPsec/IKEv2 daemon (cf. my comments for the section 6).

o Section 5
- Issue (1)
Based on RFC4294 and the draft RFC4294bis, IPsec, and specially ESP,
is mandatory on every IPv6 node.
Based on RFC4294 and the draft RFC4294bis, when on-demand creation of
Security Associations (SAs) is required, automated keying is mandatory
on every IPv6 node.
- Issue (2)
The IPsec policy for MIPv6 is set up on dedicated entities so I must
admit I don't understand this issue.
- Issue (3)
I agree that today there is a lack of figures regarding how many IPsec
SAs a HA can maintain.
- Issue (4)
Cf. my comments about the section 6.
- Issue (5)
Cf. my comments about Issue (1)
- Issue (6)
Cf. my comments about the section 6.
- Issue (7)
IMHO, this argument is not a technical one and could generate, at
middle-long term, interoperability issues (e.g. HA-HA mechanism, HA
reliability architecture, HMIPv6 scenarios, etc.).
- Issue (8)
The problem doesn't exist anymore (i.e. Traffic Selector have been
modified to set up MIPv6 policy).
BTW, I know at least another application using IPsec.
- Issue (9)
Cf. my comments about the section 6.
- Issue (10)
Only the MIPv6 signaling is secured with IPsec and there is no
encapsulation (i.e. transport mode). Regarding IKEv2 messages, the
number of messages depends on the authentication method but IKEv2
exchanges are only for the SAs creation or renewal.

o Section 6
- Triggering IKEv2 on the MN
For the MIPv6 bootstrapping, IMHO, IKEv2 could be launched without a
needed SPD, exactly as we do today when we set up a VPN to our
company.
Regarding the SPD update, again, this is more or less the same
scenario with a VPN connection: our laptop doesn't know in advance
which internal address will be provided by the IPsec Security Gateway
and so will have to update the SPD once this internal address is
provided.
- Instructing IKEv2 to ask for the MN HoA/prefix
IMHO, this could be configured in the IKEv2 config file. Now, I am not
sure that IKEv2 implementations support today the MIP6_HOME_PREFIX
Attribute
- Providing the MN prefix to the IKEv2 daemon
Same as above, IMHO, that could be configured in the IKEv2 config file.
- Registering the MN's FQDN in DNS
This issue is the same with the VPN scenario (i.e. once an internal IP
address has been provided, the DNS should be updated with this one)
- Providing the Home Network Prefix to the MIP6 application
Here, I must admit that maybe there is an issue and so an standardized
API between the MIPv6 daemon and the IKEv2 daemon may be needed.
- SPD Entry for the HoA on the MN side
Same issue as the VPN scenario (cf. above)
- SPD Entry for the HoA on the HA side
Same issue as the VPN scenario (cf. above)
BTW, a critical point is not mentioned: the PAD must be updated also.
- The K bit
I agree that "K bit" is an issue and an API must exist
- UDP encapsulation of DSMIP6 signaling
Cf. my comments about section 4

Best regards.

JMC.

2009/7/13  <[email-masked]>:
>
> FYI,
>
>
> A new version of I-D, draft-patil-mext-mip6issueswithipsec-01.txt has been
> successfuly submitted by Basavaraj Patil and posted to the IETF repository.
>
> Filename:        draft-patil-mext-mip6issueswithipsec
> Revision:        01
> Title:           Problems with the use of IPsec as the security protocol for
> Mobile IPv6
> Creation_date:   2009-07-13
> WG ID:           Independent Submission
> Number_of_pages: 15
>
> Abstract:
> Mobile IPv6 as specified in RFC3775 relies on IPsec for security.  An
> IPsec SA between the mobile node and the home agent provides security
> for the mobility signaling.  Use of IPsec for securing the data
> traffic between the mobile node and home agent is optional.  This
> document analyses the implications of the design decision to mandate
> IPsec as the default security protocol for Mobile IPv6 and
> consequently Dual-stack Mobile IPv6 and recommends revisiting this
> decision in view of the experience gained from implementation and
> adoption in other standards bodies.
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>