Subject: [mobile-ip] Mipv6 issue #234: roadmap of coa usage scenarios needed?

From: Jari Arkko <[email-masked]>
Date: Tue, 18 Feb 2003 12:56:53 +0200

Pekka Savola writes:

 >    The Alternate Care-of Address option is valid only in Binding Update.
 >    The Alternate Care-of Address field contains an address to use as the
 >    care-of address for the binding, rather than using the Source Address
 >    of the packet as the care-of address.
 >
 > One should consider having a better roadmap of different care-of address
 > usage scenarios.  To me, this ACoA option seemed a bit puzzling at least.

Alternate Care-of Address is treated mainly in 6.2.5 and
also mentioned in 5.2.6, 6.1.7, 9.5.1, 11.7.1, and 11.7.2.
I do agree that the description of this option doesn't
clearly outline the reasons of its existence, even if the
normative part of the text may be sufficient.

Here's my new text for the Section 6.2.5:

    Normally, a Binding Update specifies the desired care-of address
    in the Source Address field of the IPv6 header. However, this is
    not possible in some cases:

    o  When the mobile node wishes to indicate a care-of address
       which it can not use as a topologically correct source
       address. For instance, if a mobile node de-registers
       from its current location it will set the care-of address
       to its home address, but it may not be able to use the
       home address as a source address when away from home.

    o  When the mobile node uses IPsec ESP to protect a
       Binding Update, the protection offered by ESP does
       not extend to the IPv6 header. Still, it is important
       to protect the care-of address against modifications.

    The Alternate Care-of Address option is provided for these
    situations. This option is valid only in Binding Update.
    The Alternate Care-of Address field contains an address
    to use as the care-of address for the binding, rather than
    using the Source Address of the packet as the care-of address.

(Note that the return routability procedure requires the care-of
tests to be run using the specified care-of address, so this
option can not be used for launching attacks against 3rd parties.)

Jari

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 19 Feb 2003 06:11:34 -0800

Hello Pekka,

I have some comments in issue 12 (and the others, but not here).

>   The vulnerabilities for off-path attackers are the same as in
>   regular IPv6.  Those nodes that are not on the path between
>   the home agent and the correspondent node will not be able
>   to receive the probe messages.
>
> ==> the last sentence is not entirely accurate.  Was it really
> meant to say that probe messages cannot be received unless
> you're on path HA<->CN,  _not_ MN<->HA _or_ MN<->CN 
> (care-of test init could be considered as a probe IMO).

I think it is accurate, because the CoTI is not a probe for the
home address.  The point of the discussion is that, for any
particular IPv6 address, packets using that address have the
stated vulnerability.  I don't think it has to be stated that, for
a node using an IPv6 address, that its use of some (a priori
unrelated) IPv6 address may introduce a vulnerability along
some other path.  For the purposes of IPv6 addressing and
associated vulnerabilities, that is unrelated.

If more words are required (not so in my opinion, but anyway):

> The vulnerabilities that off-path attackers may be able to
> exploit, affecting the home address, are the same as in regular IPv6. 

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 19 Feb 2003 06:19:11 -0800

Hello Pekka,

> 11)
>
>    If the mobile node wants to ensure that its new care-of address has
>    been entered into a correspondent node's Binding Cache, the mobile
>    node MAY request an acknowledgement by setting the Acknowledge (A)
>    bit in the Binding Update.  In this case, however, the mobile node
>    SHOULD NOT continue to retransmit the Binding Update once the
>    retransmission timeout period has reached MAX_BINDACK_TIMEOUT.
>
>    The mobile node SHOULD create a Binding Update as follows:
>
> ==> Shouldn't this be a MUST (or remove upper case normative 
> completely)?  

I'm O.K. with either choice here, with a preference towards the
latter, or even "A Binding Update is created as follows:".

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 19 Feb 2003 06:40:08 -0800

Hello Jari,

I think it's dangerous to put all the scenarios and processing rules
in section 6.2.  It would be better to cross-reference the scenarios
but leave them in the other parts of the specification, so you might
say in section 6.2.5:
    The Alternate Care-of Address Option is used as described
    in sections 10.3.2, 11.7.1, and 11.7.2.

I don't think it's necessary to cross-reference _every_ appearance
of the option -- just the ones that are related to the two scenarios
in the two bullets of your text.  I reckon that section 10.3.2 should
be updated to reflect the point of the first bullet -- I'll try to look
closer later to see if there's a better place.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 19 Feb 2003 06:46:02 -0800

Hello Pekka,

> 11.5 Movement
>
> 11.5.1 Movement Detection
>
> ==> one thing that may have to be considered is, when MN moves on to a new
> link, or detects it's also on range of a different link, should it 
> re-perform
> DAD for _already existing_ addresses?  If so, on which addresses (probably
> link link-locals/site-locals would be enough).
> This is a new situation brought by movement.

Since it is assumed that the mobile node is running IPv6, it is also
assumed that it follows the rules for address configuration that are
part of the IPv6 specification.  That already includes link-local
address configuration and so on.  It would be unwise to repeat
those parts of the IPv6 specification again within the Mobile IPv6
specification.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 19 Feb 2003 06:56:40 -0800

Hello Pekka,

>    o  The state of any retransmissions needed for this Binding Update,
>       if the Acknowledge (A) bit was set in this Binding Update.  This
>       state includes the time remaining until the next retransmission
>       attempt for the Binding Update, and the current state of the
>       exponential back-off mechanism for retransmissions.
>
> ==> not necessarily a question to be answered here, but is this
> retransmission mechanism also valid for other kind of BU's which MUST be
> acknowledged (like home registrations, IIRC) -- ie, ones where BA 
> should be
> received?

Yes, the retransmission mechanism is also valid for other
such binding updates, but I don't see that any text is needed
to say so.  Perhaps it would be better to delete the second
sentence, to avoid giving the impression that this state is somehow
particular for correspondent nodes...

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 19 Feb 2003 07:08:02 -0800

> 7)
>
>    Regardless of the setting of the Acknowledge (A) bit in the Binding
>    Update, the home agent MUST return a Binding Acknowledgement to the
>    mobile node, constructed as follows:
>
> ==> there seem to be some confusion throughout the draft on when exactly
> BA's are sent.  This surely does not reflect to the general overview 
> in the
> first chapters ("if requested").  Some roadmap should be nice?
>

What is the need for a roadmap?  If the 'A' bit is set, a
Binding Update is always sent.  If the home agent gets a
Binding Update, it always sends a Binding Update.

Do you really think this is unclear?  I don't see how
adding more text would help.  Do you have a suggestion?

Regards,
Charlie P.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Feb 2003 17:36:53 +0200

> adding more text would help.  Do you have a suggestion?

Charlie, he is right in the sense that Section 4.2 claims
the BAs are sent upon request, which isn't quite the case.
I have fixed this as follows:

	A Binding Acknowledgement is used to acknowledge
	receipt of a Binding Update, if an acknowledgement was
	requested in the Binding Update, the Binding Update
	was sent to a home agent, or an error occurred.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Feb 2003 17:46:14 +0200

Charlie Perkins wrote:
> Pekka Savola wrote:
>> you're on path HA<->CN,  _not_ MN<->HA _or_ MN<->CN (care-of test init 
>> could be considered as a probe IMO).

The text says HA-CN path, so it seems to be correct in
this sense already.

> associated vulnerabilities, that is unrelated.

Yes.

>> exploit, affecting the home address, are the same as in regular IPv6. 

Pekka has a point though in that care-of tests are also probes.
The text is a bit weak here. But I'd rather avoid description
of the whole probing sequence here, so why don't we just add
use "home address probe messages" instead "probe messages".

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Feb 2003 18:20:05 +0200

You are right -- it just didn't occur to me that this would be
considered as a part of the normative behaviour rules. Pekka
was asking basically for an introduction, I think.

Modifed text below that takes in account the introductory
nature but avoids duplication of rules:

    Normally, a Binding Update specifies the desired care-of address in
    the Source Address field of the IPv6 header. However, this is not
    possible in some cases, such as when the mobile node wishes to
    indicate a care-of address which it can not use as a topologically
    correct source address (Sections 6.1.7) and 11.7.2) or when the
    used security mechanism does not protect the IPv6 header (Section
    11.7.1).

    The Alternate Care-of Address option is provided for these
    situations. This option is valid only in Binding Update. The
    Alternate Care-of Address field contains an address to use as the
    care-of address for the binding, rather than using the Source
    Address of the packet as the care-of address.

Also, 6.1.7 text has been updated a little:

    The care-of address MUST be a unicast routable address.

=>

    The care-of address is specified either by the Source Address field
    in the IPv6 header or by the Alternate Care-of Address option, if
    present. The care-of address MUST be a unicast routable address.
    IPv6 Source Adress MUST be a topologically correct source address.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Feb 2003 18:55:44 +0200 (EET)

> latter, or even "A Binding Update is created as follows:".

I'm ok with any of these, but I also prefer the last wording you propose; 
this seems more natural to me in lists like these.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Feb 2003 18:54:35 +0200 (EET)

On Wed, 19 Feb 2003, Jari Arkko wrote:
[...]
> use "home address probe messages" instead "probe messages".

The point was indeed about the unclear term "probe messages".  This change 
would seem to fix the (minor) ambiguity?

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Feb 2003 18:59:40 +0200 (EET)

> those parts of the IPv6 specification again within the Mobile IPv6

I'm not sure if I didn't elaborate the point enough.

The _problem_ (which is IMO more than just an editorial issue), is the 
fundamental change of stationary/mobile nodes.

Stationary node makes DAD once, when it is booted up in a network.  No 
duplicates there.

Mobile node could visit 1000 networks in a day using the same link-local
address.  There might be a clash in even one of them.  Does this change in
model have to be taken into consideration?  IMO, it needs to be at least
described somewhere (security considerations, if there is no better
location -- easy way to DoS MN's in local networks!), if not "solved" by
specifying that DAD must be run every time a node detects it's on a new
link.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Feb 2003 19:02:06 +0200 (EET)

> was asking basically for an introduction, I think.

Yes, this would appear to be perfect -- no need to have every detail both 
in the introduction and the gritty details.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Feb 2003 19:06:54 +0200 (EET)

> 	was sent to a home agent, or an error occurred.

Sounds ok -- I assume the text at the top of 5.2.6 is sufficiently clear 
already, or are minor edits necessary there: ?

   This section provides an overview of this binding procedure.  The
   below figure shows the message flow.  The Binding Update creates a
   binding, and the Binding Acknowledgement is optional.

[...]

   Binding Acknowledgement

	The Binding Update is optionally acknowledged by the correspondent
      node.  The contents of the message are as follows:

==> this is highlighted slightly by the fact that 5.1 (BU's to HA's) did 
no have a section like this.