Subject: Revised Mobile IPv6 draft available

From: Dave Johnson <[email-masked]>
Date: Thu, 01 Jul 1999 13:49:15 -0400

On Friday of last week, I submitted a revised version of the Mobile IPv6
draft to fix and clear up some of the minor things pointed out at the
last meeting and on the mailing list since.  I sent an announcement of
it to the Mobile IP mailing list then, but I forgot to include the IPng
list in my announcement.  Here is the list of changes since the
previous version of the draft:

    -  Changed the listed Option Type codes for the destination options
       and Type codes Router Advertisement options to their official
       values, now that IPv6 has finally officially assigned these.

    -  Added a Router (R) bit in the Binding Update option format, for
       use in "home registration" Binding Updates.  This flag bit tells
       the home agent that the mobile node is a router, so that the
       home agent can set the corresponding bit correctly in all proxy
       Neighbor Advertisements that it sends on behalf of this mobile
       node.  Also added a bit to save this flag in the definition of
       the Binding Cache entry format, and defined how it is used in
       sending proxy Neighbor Advertisements.

    -  Added a bit of text in a few places to clarify the meaning of
       MAX_UPDATE_RATE.

    -  Added to Section 7.3 a requirement that every home agent SHOULD
       support a configuration mechanism to allow a system administrator
       to manually set the value to be sent by this home agent in the
       Home Agent Preference field of the Home Agent Information Option
       in Router Advertisements that it sends.

    -  Added a suggestion in Section 6.4 that the Home Agent Preference
       field in a Home Agent Information option being sent by a home
       agent could be set dynamically by the sending home agent based
       on factors such as the number of mobile nodes it is currently
       serving or the remaining resources it has for serving additional
       mobile nodes.  However, the details of such dynamic settings
       are beyond the scope of this document since they do not involve
       protocol standardization issues.

    -  Normalized all references to the "Mobile IPv6 Home-Agents"
       anycast address to use the full name of this specific anycast
       address and to point to the new definition of reserved IPv6
       subnet anycast addresses, RFC 2526.

    -  Updated all references to their most recent versions, including
       changing old Internet-Draft references into new RFC references
       where available.  Changed remaining specific Internet-Draft
       references to be generic "Work in progress" references.

    -  Updated the "Status of This Memo" section to the new official
       version of this text.

    -  Corrected a few minor typographical errors in places.

This new version of the draft is draft-ietf-mobileip-ipv6-08.txt.  I
still haven't seen an official announcement of it on the IETF list,
but I assume one will be posted sometime soon.  For those who would
like a copy of the draft now, a link to it is available on one of the
CMU Monarch Project web pages at

    http://www.monarch.cs.cmu.edu/ietf.html

or you can get a copy directly from the much longer URL

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

					Dave
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Fri, 02 Jul 1999 03:06:53 +0900

>previous version of the draft:

	There were several questions arose for relationship of mobile-ipv6
	and ipsec (in here, and ipsec mailing list).  Do you have any plan
	to update that part?  Without that update we can't make a complete
	implementation of mobile-ipv6 (with security considered).

itojun

---

From: Dave Johnson <[email-masked]>
Date: Thu, 01 Jul 1999 14:27:48 -0400

>	implementation of mobile-ipv6 (with security considered).

Yes, I believe that is the only remaining place where clarification is
needed, although I haven't had enough time to read through all the
IPsec documents myself enough times, and haven't had a chance to talk
enough with IPsec experts about it, to really get the definitive text
writtin into the draft for this.  I hope to be able to talk with
implementers and IPsec experts about this in Oslo.  Will you be there?

					Dave

---

From: [email-masked]
Date: Fri, 02 Jul 1999 03:29:11 +0900

>implementers and IPsec experts about this in Oslo.  Will you be there?

	Yes I will.

itojun

---

From: "Aaron Griggs" <[email-masked]>
Date: Fri, 2 Jul 1999 11:47:51 -0400

>   We agree with Aaron that the IP home address must be used but this
>  one can be hidden in the case where ESP is used causing the difficulty
>  to retrieve the SA for this address.
>

The triple used to find the SA uses the destination address so this is not a
problem when the mobile node sends to the correspondent node
(IP(MN->CN)_ESP_HmAddrOpt_Data).  The correspondent node receives the ESP
packet and uses its own address for the lookup.  So the SA is found.  When
the correspondent nodes sends to the mobile node, there isn't a problem
because a routing header is used which is before the ESP header
(IP(CN->MN)_RH_ESP_Data).  When the mobile node hits the ESP header and does
the SA lookup, the destination address is the home address.

>   We think the probleme is where has to be the Home address header
>   extension. It is not described enough in the draft.
>
>   It is why we suggest to process the destination  option Home Address
>   like the Routing header as described in the IPSEC RFC but this should
>   be added in the current IPSEC and MobileIPv6  RFCs or drafts.
>
>   Like the routing header before the AH or ESP header, that will allow
>   in any case to retrieve the SA with the Home address IP. After, it
>   should be only a implementation issue.

Again, the SA triple uses the destination address and not the source address
so the home address option isn't an issue.  For the inbound SP verification,
make the remote IP address wildcarded so the home address option affect
(source address changed from mobile to home) doesn't make the verification
fail.

Aaron

---

From: [email-masked]
Date: Sat, 03 Jul 1999 00:49:33 +0900

>so the home address option isn't an issue.  For the inbound SP verification,

	Source address (whether it is ip6_src or home address option)
	is still very important.  When you negotiate the key
	with the peer, IKE runs between (src, dst) pair.

itojun

---

From: "Aaron Griggs" <[email-masked]>
Date: Fri, 2 Jul 1999 13:29:49 -0400

> (source address changed from mobile to home) doesn't make the verification

I messed up on this statement.  The SP address that can be wildcarded is the
local address.  I usually specify an SP as bidirectional with a remote and
local address.  The local address is the source address for outbound traffic
and the destination address for inbound traffic.

The result of a bidirectional SP is two SAs: one for inbound and one for
outbound.  The outbound SA has the destination address of the remote machine
and the inbound SA has the destination address of the local machine.  My
implementation only supports manual keys so I require the user to enter a
local address.

>with the peer, IKE runs between (src, dst) pair.

Couldn't the source just be selected by the sender?  For multiple address on
an interface, the best address is selected.  My statements above handles
specifying a source for the SA.  Since I am not implementing IKE, I might be
missing something.

Aaron

---

From: [email-masked]
Date: Sat, 03 Jul 1999 02:27:56 +0900

>specifying a source for the SA.  Since I am not implementing IKE, I might be

	IKE never select the address to use by its own.  IKE obeys the address
	the underlying communication is using.  IKE always use the address
	pair of the underlying communication.

	If the kernel would like to send a IPsec'ed packet with (src, dst)
	and found no key with it, it will make a upcall from kernel to IKE
	daemon for (src, dst) by using PF_KEY interface.
	IKE daemon will negotiate the key, using the (src, dst) pair.

		IPv6: "would like to throw a packet with src->dst,
			let's encrypt it"
		IPsec: "I have no key with me, need to ask IKE for key"
		  |
		  | kernel to userland message
		  v
		IKE: "I will negotiate the key for src->dst"

	The question here is: IPsec part must pick the source address to be
	used by IKE, and the IPsec part itself, from home address option
	or genine IPv6 source address.  Which is appropriate for which case?

itojun

---

From: Sham Chakravorty <[email-masked]>
Date: Fri, 02 Jul 1999 14:09:22 -0400

This is my second attempt, please ignore this message if you recieved it
earlier.

We are in the process of summarizing various Ipv6 implementation issues
including the status of the protocol, extent of its use around the
world, etc., for the US Army for use in mostly mobile, narrow
bandwidth environment.

We would most appreciate information on your experience with IPv6
implementation for large organizations in the DoD and other agencies. 
We would appreciate knowing about the extent of IPv4 (or other)
tunneling needs, interoperability issues, impact of narrow bandwidth
limitations (especially in the low bandwidth links such as radio links),
delays due to dual stacking at the hosts and/or routers if any, issues
for the mobile environment, and any other related issues such as impact
on security, training of the network managers/ops staff, etc.

Thanks much in anticipation of your inputs.

S. Chakravorty
*************************************

---

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Jul 1999 12:08:49 -0400

Itojun,

RFC 2401 et al. are quite clear on this point. The triple used for inbound
SA lookups does not include the source address.

Steve

---

From: [email-masked]
Date: Wed, 07 Jul 1999 01:15:04 +0900

>SA lookups does not include the source address.

	I agree that source address is not used in inbound SA lookups.
	I'm talking about outbound and IKE.

itojun

---

From: "A.Le_Rouzic" <[email-masked]>
Date: Fri, 02 Jul 1999 11:46:16 +0200

Hi,

   We are also looking at a  mobileipv6 plus ipsec implementation in
  AIX 4.3 as prototype and we met the same difficulties than Itojun and
  Aaron Griggs.

      Which IP address to use for the tunnel IP ? Home address or COA
      address?
      Where the DES OPT Home address has to be ?

  About, IPSEC on care-of-address. It can be written as optional or
  additionnal like also Aaron proposed in a previous mail.

  It is not possible for us to be in Oslo but we are interested by your
  conclusion if it impacts future IPSEC and MobileIPv6 specifications. 
  Nevertheless you can transmit to Francis Dupont we are working with.

    Patrice Romand  ([email-masked])
    Aime Le Rouzic  ([email-masked])

Dave Johnson wrote:
> > I will
> > Itojun

-- 
     ________________________Aime LEROUZIC____________________________
     BULL S.A ECHIROLLES FRANCE      mailto:[email-masked]
     http://www-frec.bull.com                tel: +33 (0)4 76 29 75 51
     Communications TCPIP                     http://intranet/lerouzic

---

From: [email-masked]
Date: Mon, 19 Jul 1999 20:31:12 +0900

>specifying a source for the SA.  Since I am not implementing IKE, I might be

	I may have replied this one, so ignore it if it is a duplicate.

	IKE must be run over src-dst pair which is to be used by IPsec.
	If IPsec needs a SA between (src home addr, dst), IKE must be run
	over (src home addr, dst) pair.  This causes nasty bootstrap problem,
	like:
	- mobile node wishes to send tcp packet with (src home addr, dst) in
	  the header
	- SA is looked up between (src home addr, dst)
	- since there's no SA, IKE daemon is invoked for new key
	- IKE daemon tries to send udp port 500 packet over (src home addr, dst)
	- infinite loop

	I've talked with Dave at Oslo IETF, about how mobile-ipv6 packet
	must be processed on inbound and outbound case, with regard to ipsec.
	He will be sending addition to the draft onto the list.

itojun