Re: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt

Hi Hesham,

Sorry for the late reply. Some additional comments below and then some
text proposals for the draft (w/ a question).

Hesham Soliman <hesham@elevatemobile.com> writes:

>>> => I'm trying to make it clear that the document is not inventing this API
>>> but inheriting it. In order for anyone to be able to implement this document
>>> they need to read 3775/6, 4877 and understand the interactions with IPsec.
>>> If people do that, then they *already* know that an API exists.
>> 
>> No. They know that there is a need for tight interactions between
>> IPsec/IKE and MIPv6: for bootstrapping, for tunnel endpoint updates, for
>> internal IKE daemon structures updates. All they get is a pointer to the
>> old MIGRATE draft in 4877 as a possible hint for solving the second point:
>> 
>>       Such address changes can be implemented, for instance, through an
>>       API from the Mobile IPv6 implementation to the IPsec
>>       implementation.  One such API is described in [12].
>
> => That's right, and I think that's all that can be done in standards if we
> need internal APIs. The IETF typically doesn't standardise APIs, with the
> except of the pseudo standard socket API.

which includes PF_KEY but I basically agree w/ you.

>> Or they do not have additional needs associated w/ the API.
>
> => Ok, so I gather from these comments that you're only concerned about
> clearly identifying the extensions. So if you can go through the security
> section and let us know if any of the extensions are not clear that would be
> helpful.

that would be possible if we had an initial *defined* set of extensions
and a specific API. At best, RFC 3775 introduce the need for an API
between MIPv6, IKE and the IPsec stack. See my small proposal
below. It's probably not perfect but at least this make clear that
*work* is required and that it is left as an implementation issue.

>>> => There is no guessing in the MN, it's provided the home address as part of
>>> the src address selection. If you're talking about running IKE for NAT
>>> traversal and securing all traffic then it re-uses the SAs for the home
>>> address.
>> 
>> Sorry, but I fail to understand the whole paragraph. What I say is the
>> following: when a common Mobile Node negotiates its initial transport
>> mode SA (for securing signaling traffic, i.e. BU/BA w/ the HA), it needs
>> to perform the IKE negotiation using the CoA. A common IKE
>> implementation is not expected to do that (SP uses the HoA, which is
>> not available at that time) and need to be modified to support that. One
>> possible solution is to have the right address (CoA) provided to the IKE
>> daemon by the MIPv6 module. Obviously, you are aware of that. Now what
>> are the exact steps on a DSMIPv6-compliant MN using IKE when it starts
>> operating in an IPv4-only network? I just reread 6.2.1 and it still
>> seems unclear to me how the IKE implementation will decide that it
>> should use a V4ADDR and then which V4ADDR it will use.
>> 
>> Does the IKE implementation take the first v4 address available to do
>> that? What if it has multiple interfaces with privates IPv4 address?
>> 
>> It is possible I missed some part in the document that explain that
>> precisely.
>
> => You didn't miss it, it's not in the draft. The issue of the "right" CoA
> is a policy issue that needs to be addressed by src address selection. If
> the MN is multihomed then there must be a number of factors involved in
> making this decision, none of them can be attributed to DSMIPv6.

Well, the MIPv6 module is usually expected to be the one selecting the
CoA so I respectfully disagree w/ you on that point. Once a CoA has been
selected (based on some preferences, policies, connectivity price,
capabilities, ...), I think failing to let the small number of apps
(IKE for instance) that need to use that CoA instead of the HoA is just
leaving room for trouble.

> Of course once an SA is established, then that information needs to be
> passed to MIPv6 in order choose the right CoA.

The CoA is selected by the MIPv6 module, before SA are
negotiated. Basically, this is the first BU which triggers the
negotiation of the SA. IKE has nothing to do with CoA selection. It is
just there to negotiate the protection. 

> The initial choice between a number of CoAs is basically irrelevant to
> DSMIPv6.

Well, considering what is in section 5.4 of the draft, and more
precisely in 5.4.1 ("Selecting a Care-of address"), I disagree.

> Do you think DSMIPv6 needs to specify which CoA should be chosen

It does, when there are IPv6 and IPv4 addresses available.

> and how? I don't think that would fit into the scope of the spec.

I don't know. Maybe this is a local matter (based on various policies)
but that local matter may become a problem if there is no sync between
IKE and MIPv6.

Coming back to IKE, MIPv6 is expected to do that for IKE. The problem
is introduced in section 1 of RFC 3776:

   Great care is needed when using IKE [4] to establish security
   associations to Mobile IPv6 home agents.  The right kind of addresses
   must be used for transporting IKE.  This is necessary to avoid
   circular dependencies in which the use of a Binding Update triggers
   the need for an IKE exchange that cannot complete prior to the
   Binding Update having been completed.

And later section 5.3.1 of RFC3776 for the negotiation of the SA
protecting BU/BA contains this: 

   We require IKE version 1 to be run using the care-of addresses but
   still negotiate IPsec SAs that use home addresses.

Section 4.4 contains:

   o  In addition to the rules above, if dynamic keying is used, the key
      management protocol MUST use the care-of address as the source
      address in the protocol exchanges with the mobile node's home
      agent.

Those are also in RFC 4877.

> You can make the same argument about a multihomed IPv6 MN and reach
> the same conclusion, no?

Yes. Exactly.

>>> => Because the ideal scenario is to support this mechanism in order to
>>> minimise traffic disruption. Therefore, we had to propose this as the
>>> default for the HA. The mechanism itself is a SHOULD in the IKE spec.
>>> You need to specify a default common to all MNs. Now, if an MN doesn't
>>> support it or doesn't care then there is nothing we can do about that. There
>>> is no point in mandating something when ignoring that mandate makes a
>>> difference to only one side of the protocol and has no impact on the node it
>>> communicates with.
>> 
>> It does not seem logical to me. Sorry. It just creates a situation where
>> client will undergo traffic disruption with a compliant implementation
>> even if the one on the HA support the feature.
>
> => Yes of course but that can always happen for many features in MIPv6. It
> makes no sense to mandate something that, when not followed, has no impact
> on interoperability. We need to mandate the support in the HA, so MN's can
> assume a certain level of support and therefore interoperable
> implementations. If the HA initiated the requests we would have mandated the
> support in the MN.

Still not convinced, but if I am the only one complaining, I will stop
arguing on that.

>>>>> => Ok, I'm guessing (because you didn't say) that this is related to the
>>>>> API
>>>>> concern you have. My point on that is that it's a bit too late to worry
>>>>> about it since it's already out there in implementations.
>>>> 
>>>> What can I say: I worked on the API (MIGRATE), made a followup draft
>>>> correcting problems found during the implementation, implemented support
>>>> for racoon, UMIP, additions for Linux Kernel and helped strongSwan
>>>> people during their implementation of my draft.
>>> 
>>> => Ok, so what are you asking me to do?
>> 
>> I don't know. What about taking a look at the draft [1] and see if the
>> API can easily be used/extended for some of the needs you have in the
>> doc. I let you decide.
>> 
>> [1]: http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00
>
> => I'm happy to discuss that with you in a separate thread, but I fail to
> see how this will improve the quality of DSMIPv6, which is our highest
> priority now. I.e., if, for whatever reason, the changes needed don't fit
> into your draft, that will not give me any indication as to how to improve
> DSMIPv6. 

ack.

Below is the text proposals for the draft (based on version 07):

> 6.  Security Considerations
> 
>    This specification allows a mobile node to send one binding update
>    for its IPv6 and IPv4 home addresses.  This is a slight deviation
>    from [RFC3775] which requires one binding update per home address.
>    However, like [RFC3775], the IPsec security association needed to
>    authenticate the binding update is still based on the mobile node's
>    IPv6 home address.  Therefore, in order to authorize the mobile
>    node's IPv4 home address binding, the home agent MUST store the IPv4
>    address corresponding to the IPv6 address that is allocated to a
>    mobile node.  Therefore, it is sufficient for the home agent to know
>    that the IPsec verification for the packet containing the binding
>    update was valid provided that it knows which IPv4 home address is
>    associated with which IPv6 home address.  Hence, the security of the
>    IPv4 home address binding is the same as the IPv6 binding.
> 
>    In effect, associating the mobile node's IPv4 home address with its
>    IPv6 home address moves the authorization of the binding update for
>    the IPv4 address to the Mobile IPv6 implementation, which infers it
>    from the fact that the mobile node has an IPv6 home address and the
>    right credentials for sending an authentic binding update for the
>    IPv6 address.
> 
>    This specification requires the use of IKEv2 as the default mechanism
>    for dynamic keying.

Maybe it is just my english but, it reads: "when dynamic keying is used,
IKEv2 MUST be used". From previous discussions, I thought the level of
requirement to be different and read "DSMIPv6 implementations are
required to use IPsec with dynamic keying using IKEv2". 

>    In cases where this specification is used for NAT traversal, it is
>    important to note that it has the same vulnerabilities associated
>    with [RFC3519].  An attacker is able to hijack the mobile node's
>    session with the home agent if it can modify the contents of the
>    outer IPv4 header.  The contents of the header are not authenticated
>    and there is no way for the home agent to verify their validity.
>    Hence, a man in the middle attack where a change in the contents of
>    the IPv4 header can cause a legitimate mobile node's traffic to be
>    diverted to an illegitimate receiver independently of the
>    authenticity of the binding update message.
> 
>    In this specification, the binding update message MUST be protected
>    using ESP transport mode.  When the mobile node is located in an
>    IPv4-only network, the binding update message is encapsulated in UDP
>    as described earlier.  However, UDP SHOULD NOT be used to encapsulate
>    the binding update message when the mobile node is located in an
>    IPv6-enabled network.  If protection of payload traffic is needed
>    when the mobile node is located in an IPv4-only network,
>    encapsulation is done using tunnel mode ESP over port 4500 as
>    described in [RFC3948].  During the IKE negotiation with the home
>    agent, if the mobile node and home agent support the use of port
>    4500, the mobile node MUST establish the security association over
>    port 4500, regardless of the presence of a NAT.  This is done to
>    avoid the switching between ports 500 and 4500 and the potential
>    traffic disruption resulting from this switch.
> 
>    Handovers within private IPv4 networks or from IPv6 to IPv4 networks
>    will have impacts on the security association between the mobile node
>    and the home agent.  The following section presents the expected
>    behaviour of the mobile node and home agent in those situations.  The
>    details of the IKE negotiations and messages are illustrated in
>    Section 6.2
> 
> 6.1.  Handover Interactions for IPsec and IKE
> 
>    After the mobile node detects movement it configures a new care-of
>    address.  If the mobile node is in an IPv4-only network, it removes
>    binding update list entries for correspondent nodes since route
>    optimisation cannot be supported.  This may cause inbound packet
>    losses as remote correspondent nodes are unaware of such movement.
>    To avoid confusion in the correspondent node, the mobile node SHOULD
>    deregister its binding with each correspondent node by sending a
>    deregistration binding update.  The deregistration binding update
>    message is tunnelled to the home agent and onto the correspondent
>    node.  This is done after the mobile node updates the home agent with
>    its new location as discussed below.
> 
>    The mobile node sends the binding update message to the home agent.
>    If the mobile node is in an IPv6-enabled network, the binding update
>    is sent without IPv4/UDP encapsulation.  If the mobile node is in an
>    IPv4-only network, then after IPsec processing of the BU message, it
>    encapsulates the BU in UDP/IPv4 as discussed in sections 5.2 and 5.4.
>    In order to be able to send the binding update while in an IPv4-only
>    network, the mobile node needs to use the new IPv4 care-of address in
>    the outer header, which is different from the care-of address used in
>    the existing tunnel.  This should be done without permanently
>    updating the tunnel within the mobile node's implementation in order
>    to allow the mobile node to receive packets on the old care-of
>    address until the binding acknowledgement is received.  The method
>    used to achieve this effect is implementation dependent and is
>    outside the scope of this specification.  This implies that the IP
>    forwarding function (which selects the interface or tunnel through
>    which a packet is sent) is not based solely on the destination
>    address: some IPv6 packets destined to the home agent are sent via
>    the existing tunnel, while BUs are sent using the new care-of
>    address.  Since BUs are protected by IPsec, the forwarding function
>    cannot necessarily determine the correct treatment from the packet
>    headers.  Thus, the DSMIPv6 implementation has to attach additional
>    information to BUs, and this information has to be preserved after
>    IPsec processing and made available to the forwarding function, or
>    additional DSMIP processing added to the forwarding function.
>    Depending on the mobile node's implementation, meeting this
>    requirement may require changes to the IPsec implementation.
> 
>    Upon receiving the binding update message encapsulated in UDP/IPv4,
>    the home agent processes it as follows.  In order to allow the
>    DSMIPv6 implementation in the home agent to detect the presence of a
>    NAT on the path to the mobile node, it needs to compare the outer
>    IPv4 source address with the IPv4 address in the IPv4 care-of address
>    option.  This implies that the information in the outer header will
>    be preserved after IPsec processing and made available to the DSMIPv6
>    implementation in the home agent.  Depending on the home agent's
>    implementation, meeting this requirement may require changes to the
>    IPsec implementation.
> 
>    The home agent updates its tunnel mode security association to
>    include the mobile node's care-of address as the remote tunnel header
>    address, and 4500 as the port number.  The IPv4 address and port
>    number are likely to be wrong; the mobile node provides the correct
>    information in a separate exchange as described below.  When the
>    mobile node is located in a private IPv4 network (which is detected
>    as described above), the new address and port number are allocated by
>    the NAT.  The home agent will also enable or disable UDP
>    encapsulation for outgoing ESP packets for the purpose of NAT
>    traversal.
> 
>    If the Key Management Mobility Capability (K) bit was set in the
>    binding update, and the home agent supports this feature, the home
>    agent updates its IKE security associations to include the mobile
>    node's care-of address as the peer address and 4500 as the port
>    number. The home agent may also need to change NAT traversal fields
>    in the IKE_SA to enable the dynamic update of the IP address and port
>    number based on the reception of authenticated IKE messages, or
>    authenticated packets using tunnel mode ESP.  The dynamic updates are
>    described in section 2.23 of RFC 4306. As described above, when the
>    mobile node is located in a private IPv4 network, the address and
>    port number used for IPsec and IKE traffic is not yet known by the
>    home agent at this point.
> 
>    The mobile node updates the IKE SA in one of two ways.  If the K flag
>    was set in the binding acknowledgement message, the mobile node
>    SHOULD send an empty informational message, which results in the IKE
>    module in the home agent to dynamically update the SA information.
>    The IKE implementation in the home agent is REQUIRED to support this
>    feature.  Alternatively, the IKE SA should be re-negotiated.  Note
>    that updating the IKE SA MUST take place after the mobile node has
>    sent the binding update and received the acknowledgement from the
>    home agent.
>
>    It is important to note that the mobile node's IPv4 care-of address
>    seen by the DSMIPv6 module in the home agent upon receiving the
>    binding update may differ from the IPv4 care-of address seen by the
>    IKE module and the care-of address used for forwarding IPsec tunnel
>    mode traffic.  Hence, it is probable that different modules in the
>    home agent will have a different care-of address that should be used
>    for encapsulating traffic to the mobile node.
> 
>    After successfully processing the binding update, the home agent
>    sends the binding acknowledgement to the mobile node's care-of
>    address as received in the outer header of the packet containing the
>    binding update.  Note that if the BU was rejected, the BAck is sent
>    to the same address where the BU was received from.  This may require
>    special treatment in IP forwarding and/or IPsec processing which
>    resembles sending of BUs in the mobile node (described above).
> 
>    Upon receiving the binding acknowledgement, the mobile node updates
>    its local tunnel mode Security Association information to include the
>    tunnel header IP source address, which is the mobile node's address
>    and the tunnel header IP destination, which is the home agent's
>    address.  The mobile node may also need to enable or disable UDP
>    encapsulation for outgoing ESP packets for the purpose of NAT
>    traversal and the sending of keep alives.
> 
>    The mobile node MAY use [RFC4555] to update its IKE SA with the home
>    agent.  Using MOBIKE requires negotiating this capability with the
>    home agent when establishing the SA.  In this case, the mobile node
>    and the home agent MUST NOT update their IPsec SAs locally as this
>    step is performed by MOBIKE.  Furthermore, the use of MOBIKE allows
>    the mobile node to update the SA independently of the binding update
>    exchange.  Hence, there is no need for the mobile node to wait for a
>    binding acknowledgement before performing MOBIKE.  The use of MOBIKE
>    is OPTIONAL in this specification.

What about inserting the following text here ?:

"Note that providing the features described in this subsection is
 expected to require very tight interactions between MIPv6 and IKE. It
 may require substantial extensions of the API expected by [RFC3775] to
 be in place between the MIPv6 module, the IPsec stack and the IKE
 daemon. This possible extensions (and the expected level of
 interactions with the features provided by the IKE module) are outside
 the scope of this specification and are left as implementation
 dependent issues."

Note that I first inserted small disclaimers w/ specific comments at
various places in the subsection but this made the whole thing more
difficult to read w/o providing any additional interest. I dropped that
for a single more generic block.

If you think previous text proposal should be extended in some way, just
tell me.

Cheers,

a+

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext