Subject: [MEXT] Re: [nemo] RE: Security considerations text

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 20 Nov 2007 13:25:17 +0000

Hi Hesham,
As both Karen and Vijay already indicated, when MOBIKE is not available, the
SA renegotiation can only start after the MN receives the BACK from the HA.
This is already clear at the end of the text you provided but maybe the
first paragraph causes some confusion and could be clarified...possibly as
follows:
"> 5.1 Handover interactions for IPsec and IKE
>
>    After the mobile node detects movement it updates its tunnel
>    information depending on the network capability. If the new link is
>    IPv4-only then the mobile node updates its tunnel to UDP using the
>    DSMIPv6 port and the local IPv4 address.
After the mobile node registers its IPv4-CoA to the HA, it also updates its
local Security Association information to include its local IPv4 address,
with the remote address being the home agent's IPv4 address."

Finally, for what is worth, I also agree with Vijay (had the same thought
while reading your text) that when the MN moves to IPv4 network, it should
revtunnel BUs to CNs to delete any RO sessions.

Thanks
George
P.S.: Per Jari's suggestion I am moving this to mext mailing list. Good lack
to the new chairs ;-)

On 11/20/07, [email-masked] <[email-masked]>
wrote:
> Hi,
>
> A few comments below.
>
> > -----Original Message-----
> > From: Hesham Soliman [mailto:[email-masked]]
> > Sent: Monday, November 19, 2007 2:37 PM
> > To: [email-masked]; [email-masked]
> > Cc: Nielsen Karen E; [email-masked]
> > Subject: Security considerations text
> >
> >
> > Folks,
> >
> > This is the current text in the draft. If there are comments
> > we can add them
> > to the IESG comments, provided there are no major problems
> > here. Thanks for
> > all the comments. Special thanks to Pasi and Karen for developing the
> > solution.
> >
> > Hesham
> >
> >    This specification allows a mobile node to send one binding update
> >    for its IPv6 and IPv4 home addresses. This is a slight
> > deviation from
> >    [MIPv6] which requires one binding update per home
> > address. However,
> >    like [MIPv6], 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 mobile node has an IPv6 home address
> > and the right
> >    credentials for sending an authentic binding update for
> > such address.
> >
> >    In cases where this specification is used for NAT traversal, it is
> >    important to note that it has the same UNSAF vulnerabilities
> >    associated with RFC 3519. 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 MUST 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 [TUNSEC].
> >
> >    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.
> >
> > 5.1 Handover interactions for IPsec and IKE
> >
> >    After the mobile node detects movement it updates its tunnel
> >    information depending on the network capability. If the new link is
> >    IPv4-only then the mobile node updates its tunnel to UDP using the
> >    DSMIPv6 port and the local IPv4 address.
>
> I am still not sure that the tunnel (the MN=HA tunnel)
> should be updated already before the BU/BACK exchange.
> I would much prefer a wording which says something like the following:
>
>   "After the mobile node detects movement it must prepare to send a BU
> using the new care-of-address.
>    How the binding update is sent depends on the network capability. If
> the new link is
>    IPv4-only then the mobile node much send the BU in a tunnel to UDP
> using the
>    DSMIPv6 port and the local care-of-address IPv4 address. This may be
> achived by the mobile node updating
>    its tunnel to the HA in accordance with the new Ipv4 care-of-address
> and the UDP tunnelling or it may be achived
>    by other means. Note that if the tunnel in between the mobile node
> and the home agent is updated, the mobile node MUST NOT accept
>    any traffic om this tunnel, except for the BACK itself, before the
> BACK from the Home Agent has been received."
>
> Furthermore, the
> > mobile node
> >    updates its local Security Association information to include its
> >    local IPv4 address and with the remote address being the
> > home agent's
> >    IPv4 address.
>
> I think this should only be done after the receipt of the BACK from the
> Home Agent.
> IN FACT this needs to be done after the receipt of the BACK (or be
> completed at this time),
> because only then will
> the MN know whether there is a NAT or not, so only at this point in time
> can it appropriately update
> the IPSEc SAs to be RFC 3948 ones (if required).
>
> >The mobile node also removes binding update list
> >    entries for correspondent nodes since route optimisation cannot be
> >    supported while the mobile node is in an IPv4-only
> > network. This may
> >    cause inbound packet losses as remote correspondent node
> > are unaware
> >    of such movement. Following this, the mobile node sends the binding
> >    update message to the home agent.
> >
> >    Upon receiving the binding update message, the home agent
> > updates it
> >    security association
>
> --> security associations
>                        -
>
> locally to include the mobile node's remote
> >    address as the IP address received in the outer header. When the
> >    mobile node is located in a private IPv4 network (which is detected
> >    as described above), this address is the public address
> > allocated by
> >    the NAT. Based on the setting of the K flag in the binding update,
> >    the home agent updates its IKE security association to include the
> >    remote address as that received in the outer header of the binding
> >    update message. If the mobile node were located in a private IPv4
> >    network this address is likely to be wrong as the NAT would likely
> >    allocate a different address to the IKE messages.
>
> There is no mentioning of the ports here. Shouldn't that also be
> mentioned ?
> Further shouldn't we also say that the type of the tunnel SAs may need
> to changed from
> 4301 ones to 3948 ones ( [TUNSEC] ?)
>
> Hence, the mobile
> >    node MUST update the IKE SA in one of two ways as follows.
> > 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. 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.
> >
> >    The mobile node MAY use [MOBIKE] 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 need 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.
> >
> >
> BR, Karen
>
>
_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 21 Nov 2007 00:42:01 +1000

Thanks George, 
 
I must be missing some emails because I only saw one email from Karen on
this. I'm noting all these comments for the meeting. 
 
Hesham

  _____  

From: George Tsirtsis [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2007 11:25 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [MEXT] Re: [nemo] RE: Security considerations text

Hi Hesham,

Thanks
George

---

From: <[email-masked]>
Date: Wed, 21 Nov 2007 12:33:03 +0200

Hesham Soliman wrote:

> Folks, 
> 
> This is the current text in the draft. If there are comments we can
> add them to the IESG comments, provided there are no major problems
> here. Thanks for all the comments. Special thanks to Pasi and Karen
> for developing the solution.

Couple of small comments:

>    In cases where this specification is used for NAT traversal, it
>    is important to note that it has the same UNSAF vulnerabilities
>    associated with RFC 3519.

"The same NAT-related security vulnerabilities as RFC 3519" would 
be more accurate, as neither this nor RFC 3519 is actually an 
"Unilateral Self-Address Fixing" (UNSAF) mechanism.

<snip>

>    information depending on the network capability. If the new link
>    is IPv4-only then the mobile node updates its tunnel to UDP using
>    the DSMIPv6 port and the local IPv4 address. Furthermore, the
>    mobile node updates its local Security Association information to
>    include its local IPv4 address and with the remote address being
>    the home agent's IPv4 address.

Tunnel mode SAs have two distinct fields, "local address" and "tunnel
header IP source address" (also "local tunnel header address" would be
IMHO acceptable), and it's the latter we're updating here.  Same bug
occurs also later in the text (and also with "remote address").

<snip>
>    The mobile node also removes binding update list entries for
>    correspondent nodes since route optimisation cannot be supported
>    while the mobile node is in an IPv4-only network.

And also "binding cache" entries.

<snip>
>    If the mobile node were located in a private IPv4
>    network this address is likely to be wrong as the NAT 
>    would likely allocate a different address to the IKE messages. 

Should also mention port number, which is certain to be wrong.

As Karen already pointed out, DSMIPv6 also needs to update
the "NAT traversal" state of the IKE_SA, and "UDP encapsulation"
mode of IPsec SAs.

Best regards,
Pasi