Subject: [MOBILE-IP] New version of Mobile IPv6 draft

From: Dave Johnson <[email-masked]>
Date: Tue, 26 Oct 1999 12:28:15 -0400

On Friday, I submitted a new (and hopefully final) version of the
Mobile IPv6 draft, draft-ietf-mobileip-ipv6-09.txt.  Someday soon,
the official announcement of it should come out, but I haven't seen
an announcement yet, so here's an unofficial announcement: Copies of
the new draft are now available from the CMU Monarch Project web pages
at http://www.monarch.cs.cmu.edu/ .  The URL for the new draft is:

http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietf-mobileip-ipv6-09.txt

Here's a brief list of most of the changes in the draft since the
previous version:

    -  Added a new section (Section 10.2), giving guidance to
       implementors on the interaction between outbound Mobile IP
       processing and outbound IPsec processing for packets sent by a
       mobile node while away from home.

    -  Changed the optional Care-of Address field in the Binding Update
       option format (Section 5.1) to instead be a sub-option.  This
       better matches the use of other sub-options to encode optional
       information in an option, and also makes the specification of the
       alignment requirement for the Binding Update option easier.

    -  Also removed the Care-of Address Present (C) bit in the Binding
       Update option format, as it is no longer needed with the use of a
       sub-option to specify the alternate care-of address.  NOTE: This
       change also resulted in moving the Router (R) bit over by one bit
       position in the Binding Update option format.

    -  Added explicit specification of the alignment requirements [5]
       for each of the Mobile IPv6 destination options and sub-options.

    -  Introduced Pad1 and PadN sub-options (Section 5.5) to allow
       the sub-options in Mobile IPv6 options to be aligned properly.
       To match the option numbering used for the Pad1 and PadN
       options defined for use in Hop-by-Hop Options and Destination
       Options extension headers [5], these two sub-options have been
       numbered 0 and 1, respectively.  NOTE: This change also resulted
       in changing the sub-option numbers of the other Mobile IPv6
       sub-options.

    -  Added an explicit specification of the units in which
       the Lifetime and Refresh fields are expressed in the
       Binding Acknowledgement option (Section 5.2).  As with the
       corresponding Lifetime field in the Binding Update option and the
       Valid Lifetime and Preferred Lifetime in the Prefix Information
       option used by Neighbor Discovery [14], these fields in the
       Binding Acknowledgement option are expressed in seconds.

    -  Rewrote Section 10.9 to indicate that the Binding Update is sent
       to any home agent on the link on which the specified previous
       care-of address is located, rather than (necessarily) to the
       router that it used as its default router on that link.  Also,
       the mobile node can establish packet forwarding from any previous
       care-of address, not just from its previous primary care-of
       address.

    -  Removed the Status value of 129 (Poorly formed Binding Update)
       for the Binding Acknowledgement option, since this value is not
       used.  Instead, poorly formed Binding Updates have already been
       defined (Section 8.2) to be silently discarded.

    -  Removed the Status value of 134 (Sequence Number field value too
       small) for the Binding Acknowledgement option, since this value
       is not used.  Instead, received Binding Updates in which the
       Sequence Number field is not greater than the Sequence Number
       received in the previous Binding Update for this home address,
       if any, have already been defined (Section 8.2) to be silently
       discarded.

    -  Corrected a few more minor typographical errors in places.

                                        Dave

--
David B. Johnson                         [email-masked]
Associate Professor                      http://www.cs.cmu.edu/~dbj/
Computer Science Department              http://www.monarch.cs.cmu.edu/
Carnegie Mellon University               Phone: (412) 268-7399
5000 Forbes Avenue                       Fax: (412) 268-5576
Pittsburgh, PA  15213-3891

---

From: [email-masked]
Date: Wed, 27 Oct 1999 02:31:12 +0900

>       mobile node while away from home.

        First of all, thanks for compiling section 10.2, it was what I always
        wished!
        It would be better if you can talk more about IKE issue (maybe
        separately from mobile-ipv6 draft) in bullet 4.  To setup a IPsec
        secret key between home address and destination address, IKE packet
        (UDP port 500) would need to have home address as a source (correct
        me if I'm wrong on this), and this causes chicken-and-egg problem.

itojun

---

From: Xinhua Zhao <[email-masked]>
Date: Tue, 26 Oct 1999 12:23:56 -0700

Section 10.9 describes a mechanism for establishing forwarding of packets
from a previous care-of address to the new care-of address. This is a
useful new feature. But since redirection is a serious security concern,
I'd expect to see some specifics in the draft on how the authentication
between the mobile host and the home agent in its previously visited
network is carried out. Especially, given that the mobile host in IPv6
can even obtain care-of addresses statelessly, verifying that the mobile
host was the legitimate owner of this temporary IP address is a unique
issue. It appears that there ought to be some requirements and/or
restrictions in order to use this feature.

Would it make sense to have a separate paragraph to address the security
issues associated with this redirection apart from the other general
discussion on security for binding updates?

Regards,

===========================================================
Xinhua Zhao              MosquitoNet Mobile Computing Group
Room 416, Gates Building 4A            [email-masked]
Stanford University                    phone: (650)723-9427
Stanford, CA 94305                     fax:   (650)725-2588

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Oct 1999 00:45:04 +0200

In your previous mail you wrote:

=> this new section is a real improvement but this doesn't fix
Itojun's problem (how to establish a SA using IKE when the mobile
is booted in visit)...
 I have found another issue with the Home Agent discovery, all
binding updates and binding acknowledges must be secured with AH or ESP
but the Home Agent address is not known before (an anycast address is
used) then I believe to establish SAs using IKE in this case (discovery)
will be more than hairy...
 An obvious fix is to remove the need for security on the request.

Regards

[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Thu, 28 Oct 1999 08:14:47 -0700

> An obvious fix is to remove the need for security on the request.

so if an anycast is used on a packet, then IP Security (which as I
understand it is currently is appropriate to point to point conversations)
shouldn't be used? Seems appropriate at first blush. Once you find a device
to talk with, you can set up a security association with it. What that will
tell you, of course, is that you are still talking with the same device; it
won't tell you who the device is.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 29 Oct 1999 22:26:25 +0200

shouldn't be used?

=> I think it can't be used (and in this case security is not needed
but is mandatory because the discovery request (re)uses the binding
update option which MUST be secured in the standard case).

   Seems appropriate at first blush. Once you find a device
   to talk with, you can set up a security association with it.

=> the problem is the security association must be established
before to discover a device to talk with. There are some "chicken
and eggs" issues in the bootstrap phase of mobility, this one is just
the most obvious.

   What that will tell you, of course, is that you are still talking
   with the same device; it won't tell you who the device is.

=> there are many problems :
 - anycast addresses mayn't be used as source then an IKE tool can be
   easily confused by the first answer
 - IKE exchanges use many packets (9 with standard modes) then
   it is possible to talk to different devices
 - some IKE packets can carry large certificates and be fragmented,
   again reassembly will be difficult (:-) if fragments are received
   by different devices
 - path MTU discovery relies on upper layer retransmission, IKE uses
   UDP and doesn't recover from messages losses very well.
Some issues are generic anycast issues (and will be discussed at the
anycast BOF at the next IETF) but the real problem is the home agent
discovery request doesn't need to be secured (the only threat is denial
of services by request flooding)...
The flaw is not in the discovery mechanism itself but in the inherited
security requirement. Anycast addresses are used only because they are
a good way to do this kind of service discovery.
 I currently believe the best solution is to replace the special
binding update used for the discovery request by something else which
doesn't mandate IPSec authentication.

Regards

[email-masked]