Subject: [mobile-ip] Re: MIPv6 Internet Draft

From: [email-masked]
Date: Tue, 19 Mar 2002 14:41:50 -0800

I argee with most of the things that the design team have done in
mipv6-modified-parts-pre16, but I noticed a few technical issues that
ought to be fixed, plus a bunch of typos:

Technical Comments
==================

4.5.5, step 5

We need to be able to support alternative methods for calculating K_BU (e.g.
CGA schemes, manually configured keys, IPSEC ...). This document does not need
to specify the details of these alternative mechanisms, but it does need to say
two things:

  (a) It needs to say that there might exist alternative schemes that have
      most of their protocol steps in common with the protocol described in
      this document, but have a different step 5.

  (b) It needs to describe how a CN node knows that this particular scheme (RR)
      is being used, rather than one of the others that have a different step
      5.

      The obvious way to do this is to have a field in the BU that indicates
      which  crypto scheme is being used. This needs to be combined with some
      mechanism to prevent bidding down.

4.5.5, steps 6 and 7.

The key K_BU should not be used to protect messages from the CN to the MN.
The way in which K_BU is constructed means that it isn't suitable for
protecting messages in this direction: The MN has no reason to believe that K_BU came from the CN or that it is fresh. I recommend not authenticating
BA's - the threat of forgeed BAs is not very great.

5.2.7

The SPI isn't necessary. At least, it isn't necessary if you're just using RR.
It might be needed in an alternative crypto scheme that used IPSEC somehow.
The SPI should be an option.

8.3.2

"Any Binding Update which fails to satisfy all of these tests for any other
reason (than insufficiency of the Sequence Number) MUST be silently ignored,
and the packet carrying the Binding Update MUST be discarded."

  - There are other situations in which the CN must be sent back an error
    message, rather than dropping the packet. If the nonce indices are too
    old, the CN needs to tell the mobile to re-run the RR tests.

Re-use of HoT

I believe that it is not necessary to test HoA RR every time a BU is sent. In
particular, when the mobile's CoA changes, the MN can send a BU as soon as it
has received a COT at its new CoA. The MN does not need to wait for a new HOT,
as long as it can remember a previous recent HOT. This optimization is
important, as it makes hand-offs faster. The  HOT will take longer to arrive
than the COT, because (a) it has to take a longer path through the network
(b) the MN won't be able to receive HOT messages via its home agent until the home agent has accepted a binding update for its new CoA --- in the meantime,
the HA will be forwarding HOT messages to the MN's old CoA, and they won't actually reach the MN.

Other points on fast hand-offs

If a MN has two interfaces, it can send COTI and receive COT for (potential)
CoAs on both interfaces, but only send a BU for a CoA on its preferred
interface. Then, if the preferred interface dies suddenly, the MN already has
the COT response that it needs to change its CoA to the other interface.
This should be explained somewhere. (Possibly in another document).

Editorial Comments
===================

4.5.4

"Therefore the protection against replays and reordering attacks works
when the attacker remembers up to a maximum of 2ˆ31 Binding Updates."

  - How many bits are there in the sequence number field?
    The above suggests that the sequence number is 32 bits, but
    5.1.7 which says it's 16 bits.

  - The "2^32" is very badly typeset in the PDF version of the document

4.5.5

"4. CN -> MN(CoA): CoT(K1, l)
5. MN(CoA) -> CN: BU(HoA, CoA, MAC, j, l)

   - Why is this variable called l? It's called i elsewhere.
   - The font used in the PDF makes it hard to distinguish this from a 1.

4.5.5

"The cookie and the value i are sent directly the mobile node."

Missing word "to".

"Older values can be discarded, and messages using them will can be rejected
as replays."

Extra word "can".

                              ==========================

I think that we should be able to get this document into good shape very soon,
possibly by the end of the week.

Michael Roe
Microsoft Research

Hush provide the worlds most secure, easy to use online applications - which solution is right for you?
HushMail Secure Email http://www.hushmail.com/
HushDrive Secure Online Storage http://www.hushmail.com/hushdrive/
Hush Business - security for your Business http://www.hush.com/
Hush Enterprise - Secure Solutions for your Enterprise http://www.hush.com/

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople

---

From: Alexandru Petrescu<[email-masked]>
Date: 20 Mar 2002 17:24:36 +0100

> ought to be fixed, plus a bunch of typos:

I also have plenty of technical remarks.  I would leave reporting
typos to later.

The RR described in on pages 12-13 of the pdf looks sound, but there
are many issues with converting this to the actual message, the bits
and bytes.  For example, HoT:
-the K0 is a HMAC-SHA1, then the output length is 96 I suppose, no
 reason to make it 128 as the message description on page 19, section
 5.1.5 would suggest.
-"The final 0 inside the MAC function": I think there's no need to
 code it on 32 bits, 1 bit would be sufficient.
-the HoT message has a bizzare look with the 4 reserved bytes not
 being contiguous.
I think that most of those aspects are currently under review.

> The key K_BU should not be used to protect messages from the CN to
> the MN.  The way in which K_BU is constructed means that it isn't
> suitable for protecting messages in this direction: The MN has no
> reason to believe that K_BU came from the CN or that it is fresh.

I had sent a remark to Jari on adding new K2 and K3 to be put in HoTI
and CoTI such that when MN receives HoT and CoT it knows they were
initiated by itself.

There's also place left for the HA to modify the HoTI and HoT that
pass through it.  Draft says on page 20 end of section 5.1.t that "HoT
should be protected by ESP", while the true fact is that only the
tunnelled part of the HoT message (the message sent from HA to MN and
not the HoT sent from CN to HA).  Similar arguments apply to HoTI.

This induces here another need (probably) to name HoT=HoT-1+HoT-2 and
HoTI=HoTI-1 and HoTI-2.  If this renaming is done, then it can be
simply stated that ESP is applied to HoTI-1 and HoT-2, but not to
HoTI-2 and HoT-1, for example.

Applying ESP brings clean and much security, but involves probably
much computation on the MN that receives HoT-2; a much lesser demand
might be that HA just increases j for example.

There are many many things that need detailed consideration in the new
RR.  And I've not yet assimilated entirely the 64 pages.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Mar 2002 18:28:15 +0100 (CET)

> not the HoT sent from CN to HA).  Similar arguments apply to HoTI.

Alexandru,

The document doesn't say that the HA modify these packets - it merely
forwards then from/tom the tunnel to the MN.

Are you saying that there is a requirement that the HA be able to modify them?
Or is the document just unclear on the fact that they pass through unmodified?

  Erik

---

From: Alexandru Petrescu<[email-masked]>
Date: 20 Mar 2002 18:36:57 +0100

> Or is the document just unclear on the fact that they pass through

The document is clear in that respect.

No, there's no requirement that HA be able to modify them.

It was just an idea that instead of applying ESP, HA might just
increase j.  If this doesn't bring anything valuable then that's fine.

Sorry for misunderstanding,

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 20 Mar 2002 15:15:43 -0800

> the HA will be forwarding HOT messages to the MN's old CoA, and they won't actually reach the MN.

Agree with the above strongly. The cookie K0 (in the HoT) can be 
re-used for a short time (maybe a few minutes). Kbu is then derived 
from the new K1 and the re-used K0.

regards
Vijay

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Mar 2002 18:23:40 +0200

>       this document, but have a different step 5.

Ok. I added text to this effect.

>       mechanism to prevent bidding down.

We are thinking of using the Reserved field in BU and possibly also in [HC]OT{,I}

messages as a place for new flags that would do this. Do you think this is

sufficient?

And another question: do you think we should immediately put in two algorithms
such as SHA1 and MD5 for doing the hashes involved in the RR procedure? This is
often done in security protocols, but in this case I'm thinking the strength of
RR is not so big that we should be thinking about breaking hash functions as the
easiest attack...

> BA's - the threat of forgeed BAs is not very great.

Ok. We have however considered also a nonce-scheme where the MN sends a nonce that is to be
returned by the CN in all of its responses messages (HOT, COT) or included in the hash
of the response messasage (BA). Do you think that would be acceptable?

> The SPI should be an option.

Agreed.

>     old, the CN needs to tell the mobile to re-run the RR tests.

Yes.

> important, as it makes hand-offs faster. The  HOT will take longer to arrive

I'm starting to think so as well. We do need to think about suitable
recommendations for the timers involved for home and coa cookie lifetimes
and so on.

Also, I think it was Erik who wondered if we might actually have a field
in the [HC]OT message to describe the expected (or committed?) lifetime of
the cookie, helping the MN decide whether it should redo something later or
not. This would bring some additional complexity though, and the MN has no
assurance in any case that the cookies really can be used anyway so perhaps
we should just have a recommendation and allow MNs to optimistically try these
things within those recommended limits. Or what do you think?

> the HA will be forwarding HOT messages to the MN's old CoA, and they won't actually reach the MN.

Interesting.

By the way, when an MN arrives at a new CoA, it could send a home BU immediately followed
by a HOT... hoping that there's no reordering. But I'm not sure this is a desireable
activity, since I don't know how the MN would recover if the messages were indeed
reorder. On the other hand, we could in theory design a home BU message that carried
a sequence of CN addresses to which the HA would create and send a HOTI on the behalf
of the MN.

> This should be explained somewhere. (Possibly in another document).

Yes. We may leave also some of this smart 'caching' of RR activity to
smart implementers.

> Editorial Comments

Thanks, fixed now.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Mar 2002 18:38:06 +0200

> -the K0 is a HMAC-SHA1, then the output length is 96 I suppose, no

SHA1 produces 160 bits I think, but usally folks are confident with
cutting hash outputs to 96 bits. 96/128 really doesn't matter so
we should pick the size based on alignment considerations.

>  reason to make it 128 as the message description on page 19, section

Ok, let's re-align and re-size the messages once we agree that we
have all the fields.

>  code it on 32 bits, 1 bit would be sufficient.

At least 8 is needed to make typical implementations work well.
But since that is anyway one memory operation, might as well make it
the current 32.

> -the HoT message has a bizzare look with the 4 reserved bytes not

Agreed. Changed now.

> not the HoT sent from CN to HA).  Similar arguments apply to HoTI.

Yes, but doesn't the draft say "... between the MN and the HA"?
I think that should be enough to clarify that we don't expect
to run IPsec between HA and CN.

> might be that HA just increases j for example.

This is an interesting suggestion, the security impacts have to
be thought out. I don't think changing j/i is sufficient since attackers
could easily observe the progress of these values on the cn (they are
same for all mns). Changing Home Cookie would do the job, but I wonder
if changing == encryption?

> RR

Your feedback is very much appreciated. Keep on commenting the rest
as well...

Jari