Subject: [Mip6] comments on draft-ietf-mip6-nemo-v4traversal-00 (2)

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 04 Nov 2005 19:50:46 +0900

Hello,

I've reviewed the v4traversal protocol document.  First of all, thanks
for writing this up.  I think this technology is really useful.  I have
following comments and questions as below.

Technical Comments:

- In Section 2.2, there are descriptions about use of IPsec for sending
and receiving MPS/MPA.  However, I found the texts are not clear about
how the IPsec should be applied to the MIPv6 messages.  Does the
specification recommend to use IPsec as similar to the MIPv6's case
(RFC 3776) ?  Or does it (intentionally) leave it to operation ?

>    A dual stack mobile node MAY send a Mobile Prefix Solicitation
>    message encapsulated in IPv4 (i.e. IPv6 in IPv4) in the case where
>    the mobile node has no access to IPv6 within the local network.
>    Securing such messages would require the mobile node to have security
>    association with the home agent, using IPsec (AH or ESP) and based on
>    the mobile node's IPv4 care-of address as described in [MIPv6]. Since
>    the mobile node needs to encapsulate all IPv6 traffic sent to the
>    home agent into IPv4, while located in an IPv4-only visited network,
>    such SA would affect all packets if the selectors were based on the
>    information in the outer header. That is, the SA selectors being the
>    protocol number (protocol is always IP in IP), as well as, source and
>    destination addresses are all common to all packets. If this effect
>    is not desired, the mobile node can base the SA on the information in
>    the inner header (i.e. using the home agent's IPv6 address, the
>    mobile node's home address and the ICMP protocol number). Such
>    security association would use transport mode ESP protection.

- Related to the above question, I found there is few description about
IPsec processing.  How should IPsec be applied to v4traversal scenario
should be provided, IMHO.  If it is expected to be similar to MIPv6 case
(RFC 3776), the spec should say so.

- In Section 3.1.1, header format of IPv4 home address option is defined.
If I understand it correctly, the option allows BU to carry both IPv4
home address and MNP in a common formant.  Let me clarify a little bit
more: I assume that the single IPv4 home address option is allowed in a
BU message but is it right ?  As for IPv4 MNP, does the spec allow BU
message to carry multiple IPv4 MNPs as in NEMO base protocol (I hope so) ?

- There is no description about the case where MN returns home.  Does
v4traversal also support MN returning home ?  Or is it outside of the
scope ?

- From security perspective, I believe HA should perform strict validity
check for the incoming v4-tunneled traffic.  Since the HA has no choice
but to accept IPv4-tunneled packet from any IPv4 address (as the packet
may contain BU from MN which has just moved to IPv4 network), decapsulation
of the IPv4-tunneled packet should be carefully done.  Otherwise,
adding v4traversal feature may cause a security hole in HA, IMHO.  So,
the spec should state the need for the verification, and the steps of
the validity check should be provided.  For instance, [If the next header
indicates that the inner packet is IPv6, then HA should first check its
BCE and see if corresponding entry exists.  If not, HA proceeds the validity
check and see if the packet looks like BU (ESP protected packet) or not.
If yes, pass the packet to IPsec processing.  If not, discard the packet.
If the inner packet is IPv4, HA should first check BCE and see if there
is corresponding entry.  If yes, pass the inner packet to the IPv4 input.
If not, discard the packet.]

Regards,
Shinta

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

---

From: Vijay Devarapallli <[email-masked]>
Date: Fri, 4 Nov 2005 14:48:27 -0800

> (RFC 3776), the spec should say so.

actually that is still being discussed. whether to provide transport
mode ESP protection for the BU and MPD messages and then
tunnel them or provide tunnel mode protection directly. I guess
both should be possible. I would like to hear what you think

> message to carry multiple IPv4 MNPs as in NEMO base protocol (I hope so) ?

we might need another option to carry the IPv4 MNP. I think
for now draft-shima-nemo-v4prefix-01 is the most complete
one for supporting IPv4 MNP.

> v4traversal also support MN returning home ?  Or is it outside of the

the home link supports IPv6. what needs to be specified?

> If not, discard the packet.]

agreed. we can do it the next revision.

Vijay

---

From: Shinta Sugimoto <[email-masked]>
Date: Sun, 06 Nov 2005 07:06:15 -0800

On Fri, 4 Nov 2005 14:48:27 -0800

> both should be possible. I would like to hear what you think

Hmm, I am not sure if the tunnel mode protection can/should be
applied to all of signaling messages.  Assuming that the issue is
how to apply IPsec to MIPv6 signaling messages and payload while
MN is at IPv4 networks, suppose if the MN establishes IPsec tunnel
with its HA.  From MN's perspective, outer source address of the
IPsec tunnel should be MN's IPv4 CoA.  Both MN and HA should never be
able to update the tunnel endpoint prior to the home registration
and BU should be the trigger for updating the tunnel endpoint
(no matter if the tunnel is IPsec or IP-in-IP).  So, I believe that
IPsec SAs for protecting BU/BA can/should not be dependent on the
IPsec tunnel, which means that we should follow RFC3776 in order to
protect them.  As for MPS/MPA, there should be no problem with applying
transport mode IPsec SA (based on MN's IPv6 HoA and HA's address)
so why not simply use them.

On the other hand, I think it makes sense to leverage IPsec tunnel
(IPv4-IPv6-combined) to protect MIPv6 signaling messages (HoTI/HoT)
and the payload.  Once the tunnel endpoint is successfully updated
after BU/BA exchange, IPsec tunnel should become available for
protecting payload and some of MIPv6 signaling messages.  In order
to achieve this, I guess that IPsec SA (tunnel mode) based on MN's IPv4
HoA and HA's IPv4 address should be managed in addition to the IPsec
SA sets required by RFC3776.  Similar to the other tunnel mode SAs,
tunnel endpoint should be updated in accordance with MN's movement.

So, to summarize, in my view:

- BU/BA/MPS/MPA can/should be protected by transport mode IPsec SA
  which is based on MN's IPv6 HoA and HA's IPv6 address.
- HoTI/HoT and payload may be protected by IPv4/IPv6 combined IPsec
  tunnel.

I believe important thing is to keep required modifications (in terms
of operation and protocol) for v4traversal minimum.

> one for supporting IPv4 MNP.

I took a quick look at draft-shima which defines an IPv4 MNP option.
In order to make the mapping between IPv4 HoA and corresponding IPv4 MNP
more flexible, it may be good to incorporate the IPv4 MNP option.  I
think the design choice is dependent on whether if the v4traversal
supports MR to own multiple IPv4 MNPs which is bound to its IPv4 HoA.
So, that's why I brought up the above questions.  What do you think ?

> the home link supports IPv6. what needs to be specified?

Yes, home link supports IPv6.  But it also supports IPv4 right ?
My question is it possible for MN to return home and keep using its IPv4
HoA ?

> agreed. we can do it the next revision.

OK.

Regards,
Shinta