Subject: [mobile-ip] Comments on Draft 16

From: Brian Haley <[email-masked]>
Date: Mon, 25 Mar 2002 18:07:22 -0500

Hi,

Here are my initial comments on mipv6 draft 16 changes, I will do
a more thorough reading later...

-Brian

------------------------------------------------------------------------

4.5.4 Securing Binding Updates to Home Agents
> Both the mobile node and the home agent MUST use non-volatile memory
> to store the sequence number so that a reboot does not prevent the
> acceptance of new Binding Updates.

Why is this a MUST and not a SHOULD (or MAY)?  A reboot of the Home
Agent
will not prevent it from accepting a Binding Update from a Mobile Node
with
*any* sequence number, and we already have an error code (141 - Sequence
number
out of window) to re-synchronize the sequence number, since the
last-used
number is sent in the BAck.

This section also incorrectly assumes a sequence number is 32-bits, but
it's
only 16.

------------------------------------------------------------------------

5.1.4 Care-of Test Init (CoTI) Message
> If no actual parameters are present in this message, no padding is
necessary.

This isn't correct, there are 4 bytes of padding necessary.  BTW, the
HoTI
Message section has this right.

------------------------------------------------------------------------

5.1.7 Binding Update (BU) Message
> If no actual parameters are present in this message, 4 bytes of Pad1
or
> PadN parameters are needed to make the length of the message a
multiple
> of 8.

I don't believe any padding is necessary.

------------------------------------------------------------------------

5.1.8 Binding Acknowledgement (BA) Message
> Lifetime section
> Correspondent nodes SHOULD also retain a BCE entry for the purposes of

> accepting Home Address Options somewhat longer than they keep on using

> the entry for Route Optimization of outgoing packets. This helps to
> avoid dropped packets, particularly when clock drift can be a problem.

This can be problematic, and is in disagreement with Section 8.3 - "Any
Binding Cache entry MUST be deleted after the expiration of this
lifetime
in the Binding Cache entry."  I would propose:

 "Mobile Nodes SHOULD send a new Binding Update before the expiration of
this
  period in order to extend the lifetime and not cause a disruption in
  communications".

And regarding the Refresh field, I'm the one that proposed removing this
field,
since the onus should be on the Mobile Node to choose an adequate amount
of
time before the lifetime expires, account for RTTs, etc., to refresh the

binding.  Charlie asked if it could be moved into a sub-option if
removed,
and that is fine with me - I guess it could be a way for a CN to
implement
an LRU cache replacement policy.

Same section:
> The Binding Acknowledgement is sent to the source address of the
> Binding Update message, regardless of whether the Binding Update
> succeeded or failed.  No Routing Headers are inserted to the message.

This looks wrong, the BAck should be sent to the home address via the
care-of
address with a Routing Header, which accomodates use of the Alternate
COA
option.  This is a change from draft 15.

------------------------------------------------------------------------

General comment about Section 5.1.* - it would be nice if every Message
description section included the length (or minimum length) requirement
for the Mobility Header "Header Len" field, this way it's obvious to
implementors.  For example in Section 5.1.7:

"The Header Length field in the Mobility Header for the Binding Update
 message MUST be set to 32 plus the total length of all parameters
present."

------------------------------------------------------------------------

5.3 Home Address Option
> A packet MUST NOT contain more than one Home Address option, except
that an
> encapsulated packet [?] MAY contain a separate Home Address option
associated
> with each encapsulating IP header.

Ok, I'll go down this path again - it was found at Connectathon 2001
(yes, 2001)
that "conformance" tests that sent a packet with two back-to-back HAOs
caused
some vendors to send an ICMPv6 Parameter Problem message, and others to
accept
it, over-writing the old HAO with the new.  Now that we must lookup a
BCE to
accept the HAO, it seems prudent that we should reject this case.

------------------------------------------------------------------------

10.3 Receiving Packets While Away from Home

This section mentions "Routing header", but should be specific that it's

a type 2 Routing header that's to be used for CN->MN RO communications.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Mar 2002 22:51:31 +0200

Thanks Brian for your comments! Some answer below:

> Why is this a MUST and not a SHOULD (or MAY)

The nv memory allows for protection against replays. If there's
no nv memory, we'll have to provide a resynch procedure, which could
be used by attackers in a replay too.

But I'm not sure either whether this should be a MUST. Perhaps a SHOULD
would be sufficient?

> Message section has this right.

Thanks for pointing this out. But isn't it the other way around? HoTI
and CoTI are 2 bytes, MH has a fixed overhead of 6, total is 8 => ok?

> I don't believe any padding is necessary.

This too.

Sounds good.

> And regarding the Refresh field,

I'll let Charlie and others comment on this.

> option.  This is a change from draft 15.

I understand your issue, but the change was done in an effort to make
MIPv6 reflection-proof by eliminating all messages that are replied to
another address than they were sent from.

By the way, the use of Alt-CoA is still an open issue. But perhaps you
could help me in understanding it. If Alt-CoA is used from a new CoA
to refer to the old-CoA, this kind of use seems fine. However, if it
is used from the old CoA to refer to some activity that should be done
towards a new, yet untested CoA then there may bombing attack concerns.
Which kind of use is the Alt-CoA designed for?

Good suggestion.

>>A packet MUST NOT contain more than one Home Address option, except that an
> associated with each encapsulating IP header.
> 

Hmm... is the problem in using multiple HAOs in the same packet, or
multiple HAOs at different layers in a tunneled packet? What if an
MN and a CN would be running an IP-in-IP tunnel for some reason, and
then someone sends a packet with a HAO to this tunnel? Shouldn't it
work?

> a type 2 Routing header that's to be used for CN->MN RO communications.

Right.

Jari

---

From: Brian Haley <[email-masked]>
Date: Tue, 26 Mar 2002 16:36:01 -0500

Hi Jari,

> But I'm not sure either whether this should be a MUST. Perhaps a SHOULD

Ok, I understand the reason now, it's because we could be using
manually-configured
IPsec keys.  But  later on in that section it says you don't have to update the
nv
memory every time you get a BU, which itself could lead to a replay attack if
the HA crashes.  I'm fine with a SHOULD.

> and CoTI are 2 bytes, MH has a fixed overhead of 6, total is 8 => ok?

Yes, you're right.  I knew I was going to screw-up one of these...

> Which kind of use is the Alt-CoA designed for?

I believe it was the latter, where you are moving to a new location, but I'm
not exactly sure of Charlie's intention.

> then someone sends a packet with a HAO to this tunnel? Shouldn't it

Using multiple HAOs without an intervening tunnel is the problem, i.e. both
in the same Destination Option.

Thanks,

-Brian

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 26 Mar 2002 14:24:25 -0800

> But I'm not sure either whether this should be a MUST. Perhaps a SHOULD

There was something in draft 15 to handle the case when the 
MN reboots. If the MN sends a BU with a sequence number smaller
than the one it had sent before the reboot, the HA rejects the
BU and sends a BAck with error status 141 (sequence number too 
small). In addition to this, the HA includes the sequence number 
from its binding cache in the BAck. For the next BU, the MN 
chooses a sequence number greater than the sequence number in 
the returned BAck.

When the HA reboots and comes up, it accepts whatever sequence
number the MN sends.

We have tested this.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sat, 30 Mar 2002 19:14:09 +0200

> the HA crashes.  I'm fine with a SHOULD.

There are ways to update the NVM in a manner that this isn't a problem.
But I'm fine with a SHOULD too.

> in the same Destination Option.

How about this:

The Home Address Option MUST not appear more
than once in any given packet, except inside the payload part of the
packet if tunneling is involved.

Jari