Subject: [Mip6] granularity and draft-ietf-mip6-ikev2-ipsec

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Oct 2005 14:16:06 +0200

I propose to insert this section at the end of 4 (Requirements) before
5 (Manual Configuration) even the only thing which is required is to
have compatible policies on the MN and the HA.
Of course the wording can (should! :-) be improved... and someone
can have a good proposal for the last issue (but please don't open
a can of worms, it doesn't really matter if the IPv6 tunnel is a
(very) virtual interface as payload protection is (very :-) optional).
Another point: I don't know if we have to mention that the HoT[I] selectors
make possible to put the HA IKE in "passive mode", i.e., the HA is never
the initiator (good for IKE, bad for the MN-MN case :-).

Thanks

[email-masked]

<section title="Selector Granularity Considerations">
<t>
IPsec implementations are not required to support fine grain selectors.
More, applying fine grain selectors on forwarded packets is known to
raise specific problems when some involved fields are not present in
initial fragments, so some implementators may choose to support only
coarse grain selectors (i.e., addresses and in some case protocol) for
forwarded traffic. As finer grain selectors give a better control,
i.e., the protection is only applied when required, the examples in
the document always use the finest granularity.
</t>
<t>
The protection of Binding Updates and Acknowledgement and the protection
of Mobile Prefix Discovery Messages are in transport mode where fine
grain selectors are likely supported.
</t>
<t>
But the protection of Return Routability Messages and the protection of
the Payload Packets are in tunnel mode where fine grain selectors can be
unavailable. In any case the mobile node and the home agent MUST use
compatible policies.
</t>
<t>
The choice is between three profiles:
<list style="symbols">
<t> 
Finest grain selectors, including Mobility Header message type, are available.
This is the case assumed in the examples of the document.
<vspace blankLines="1"/></t>
<t>
The finest grain selector which is available is the protocol selector.
The protection of Return Routability Messages uses a setup similar
to the Payload Packets with the protocol selector set to Mobility Header
messages.
<vspace blankLines="1"/></t>
<t>
The last case is where the protocol selector is not available or for
privacy considerations the whole traffic tunneled between the mobile node
and the home agent is protected. The setup is the same than for
the Payload Packets with the protocol selector set to 'any'.
</t>
</list>
<t>
The last case (protection of all tunneled packets) introduces two new
difficulties:
<list style="symbols">
<t>
This protection can cover the Return Routability Messages so either there is
no specific IPsec database entries for the Return Routability Messages and
the protection for all tunneled packets MUST fulfill the requirements for
the Return Routability Messages, or there are some specific SPD entries
for the protection of the Return Routability Messages with a higher
priority.
<vspace blankLines="1"/></t>
<t>
The standard setup gives the same packet layout and applies to the same
traffic than a transport mode applied to the IPv6-in-IPv6 tunnel.
This document does not try to solve this issue, i.e., it only signals it.
</t>
</list>
</t>
</section>

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 23 Oct 2005 21:56:25 -0700

hi Francis,

thanks for the new text.

> IPsec implementations are not required to support fine grain selectors.

there is a problem here, since we mention early in the document
that the home agent and mobile SHOULD support Mobility Header
message type as an IPsec selector.

> initial fragments, 

I am not sure what fragment means here? do you expect a HoTi
message to fragment ever? maybe we could say

   For various reasons, some implementations may choose to support....

> unavailable. In any case the mobile node and the home agent MUST use

hmm.. arent't return routability messages always protected by
tunnel mode whether you support MH message type as a selector?

do we need the above two sentences?

> This document does not try to solve this issue, i.e., it only signals it.

I cant figure out what you wanted to say in the last paragraph.
so I excluding this for now

here is the re-written section.

5.  Selector Granularity Considerations

    IPsec implementations are compatible with this document even if they
    do not support fine grain selectors such as the Mobility Header
    message type and ICMPv6 message type.  For various reasons, some
    implementations may choose to support only coarse grain selectors
    (i.e., addresses and in some case protocol field) for forwarded
    traffic.  As finer grain selectors give a better control, i.e., the
    protection is only applied when required, the examples in the
    document always use the finest granularity.

    There following describes different ways of setting up IPsec policies
    for protecting Mobile IPv6 messages.

    o  The IPsec implementations on the mobile node and the home agent
       support fine grain selectors, including the Mobility Header
       message type This is the case assumed in the IPsec SPD and SAD
       examples in this document.

    o  The IPsec implementations only support selectors at a protocol
       level.  The protection of Return Routability Messages uses a setup
       similar to the regular payload packets to the correspondent node
       with the protocol selector set to Mobility Header messages.  All
       tunneled Mobility Header messages will be protected.

    o  The last case is where the protocol selector is not available or
       for privacy considerations all traffic tunneled between the mobile
       node and the home agent is protected.  This uses IPsec tunnel SA
       with the protocol selector set to 'any'.

    The last case where all tunneled traffic is protected introduces some
    additional considerations.

    o  If there is just one IPsec SA providing protection for all
       traffic, then the SA MUST fulfill the requirements for protecting
       the Return Routability messages which require confidentiality
       protection.  There can alsco be separate tunnel mode SPD entries
       for protecting the Return Routability messages with a higher
       priority.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Mon, 24 Oct 2005 09:17:07 +0200

=> yes, please add a reference to 2401bis after "required".

   
=> I agree HoTi message should be never fragmented but as in general
a forwarded message can be fragmented some implementors already chose
to support only coarse grain selectors.

=> I prefer to give an example of the various reasons but good wording
is the first goal...

   
=> yes, they MUST be protected by tunnel mode.

=> the first one is an introduction and the second one a requirement.

   
=> there is an implementation choice between a tunnel mode and a transport
mode over a tunnel a la John Touch. We only signal this as the second has
many advantages but is clearly not standard.

   

   

   
   
=> ok, we can publish this.

Thanks