Subject: [MEXT] review of draft-ietf-monami6-multiplecoa-04.txt

From: "Hui Deng" <[email-masked]>
Date: Sun, 16 Dec 2007 21:43:36 +0800

Dear authors,

I think that this document has been been in good shape for publication.
Although I have several comments regarding to IPsec/IKE.

1) Section 8.3.2, for tunneled IPsec traffic from the HA to MN,
Since RFC 4306 do require check based on the destination address.
In that case, MCOA may be able to use only 1 CoA for this direction
packet delivery. If this is true, MCOA could support multiple interfaces
for MN to HA direction, but could support only 1 HA to MN connection.
Would be better if it could be described more clearly.

2) Section 8.3.2, for tunneled IPsec traffic from the MN to HA,
>From reading, it seems fine without source address checking.
But I am not sure whethere there is already implementation
which could verify it is workable or not.

3) about which interface MIP6 will use in MCOA scenario, it is mainly about
how to operate SPD, but this document may lack basic description about it.

4) As the basic RFC 3775, RFC 4877 lacks interface between MIP6 and IKEv2
this document may also need consider it.

Many thanks

-Hui

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

---

From: "Hui Deng" <[email-masked]>
Date: Mon, 17 Dec 2007 17:12:27 +0800

Dear all,

Based on the discussion before the last time IETF meeting in ML.
We (co-authors of both drafts) had a joint discussion offline,
made the following proposal about text of work item and
explanation of motiviation of this work,

Thanks Sugimoto-san, Francis, Nakamura-san, and Yang's
hard work for the below text,

Proposed text:
---
Interaction between Mobile IPv6 and IPsec/IKE by PF_KEY extensions

Address problems and need for interaction between the Mobile
IPv6 and IPsec/IKE.  Work on solution for the interface between
the Mobile IPv6 and IPsec/IKE by extensions to the PF_KEY framework
and flexible way to do information share.
---

With regard to the arguments justifying our work, namely
the reason why it is needed for MIPv6/NEMO deployment,
we come up with the following arguments:

---
* Usefulness of the document

First of all, an informational RFC which defines the
problems and solutions of MIPv6 and IPsec/IKE interaction
is considered to be useful for software vendors and/or
Mobile Service Operators who are going to implement a
system of MIPv6/NEMO with dynamic keying.  The document
tells exactly what information needs to be exchanged
between the MIPv6/NEMO and IPsec/IKE protocol stacks.

* Potential benefit for the Mobile Service Operators

Secondly, there is a potential benefit for Mobile Service
Operators to have an informational RFC which defines the
problems and solutions of MIPv6 and IPsec/IKE interaction.
As MIPv6/NEMO and IPsec/IKE are inherently different protocols,
the software may be developed by different software vendors.
Therefore, even though the interface between the MIPv6 and
IPsec/IKE is an issue inside a node (MN/HA), there is an
interoperability issue.  By defining the interface between
the said protocols, Mobile Service Operators will have wider
variety of choices on combinations of MIPv6/NEMO and
IPsec/IKE software suites (i.e., higher possibility of
constructing multi-vendor system).
---