Subject: [mobile-ip] MIPv6 Internet Draft

From: Jari Arkko <[email-masked]>
Date: Sat, 16 Mar 2002 08:35:41 +0200

Folks,

The design team has worked for the last couple of weeks on
updating draft-ietf-mobileip-ipv6-15.txt based on the
discussions on the mailing list, the consensus that
has been reached, and discussions in the team beyond the
major issues present in the recommendations. As you surely
have noticed, we didn't produce a new version before the
Internet Draft deadline. However, we are approaching a
new version soon and intend to submit it next week.

Even if the current text is not very mature and there are
many serious problems in it, we thought it would be useful
to start reviewing and discussing this. Also, once the basic
message flows and formats are out, it becomes easier to discuss
issues on the mailing list. For this purpose we have provided
an early version for your review:

http://www.piuha.net/~jarkko/publications/mipv6/mipv6-modified-parts-pre16.pdf

This file contains only the modified parts in PDF format.
I'll send the full new I-D version in text format as soon
as I get it.

The modifications have also been listed under Appendix A.1
on page 61. Please note that this very much work in progress.
The below list gives some of the currently open issues or
parts have not been edited right yet:

- Need to get IPv6 interface ID bit allocated to be able to prevent
   bidding down.

- Figure out if alternative CoA can work with the RR messaging.

- Home agent operation, how to secure: use ESP or AH?

- Max BCE entry lifetime has to be specified somewhere.

- Use of HAO or not for home registrations.

- Authentication data, BU, BA exact formats e.g. parameter
   vs. fixed field.

- Should we specify that the correspondent nodes MUST be able to keep
   nonces and hence also cookies fresh for at least 60 seconds, in
   order to ease retransmission implementation on the mobile node
   side?

- Need suboptions on HAO any more?

- Securing BRs with authentication data inherited from the BU/BA time?

- SPI necessary?

- What to put in the future functionality section on e.g.
   unvHAO or piggybacking?

- Need state tables or better behaviour descriptions in the
   cn, mn chapters?

Comments are very much appreciated.

Jari Arkko

---

From: Jari Arkko <[email-masked]>
Date: Sat, 16 Mar 2002 08:43:07 +0200

And it appears that we now have also I-D format (thanks to Charlie
for this). You can reach the files from the links below:

I-D format, full text:

  http://www.piuha.net/~jarkko/publications/mipv6/draft-ietf-mobileip-ipv6-pre16.txt

PDF format, modified parts only:

Jari

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 19 Mar 2002 08:44:35 -0600

Jari

I was just looking at this doc and noticed that it's requiring
a correspondent node to send Message 3 and 4 of the RR simultaneously.
That implies that the correspondent is supposed to wait for both
Message 1 and 2 of the RR to arrive (as they are not guaranteed to
arive at the same time).  Is that intentional?

Just looking for a clarification.
-vlad

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Mar 2002 16:23:40 +0100 (CET)

> arive at the same time).  Is that intentional?

Vladislav,

That isn't the intent so it seems like a clarification is needed.

The CN responds to the CoTI with a CoT and the HoTI with a HoT
independently (and without creating any state).

The MN then needs to wait for both the CoT and HoT before it has the
cookies necessary to send the BU.

  Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 20 Mar 2002 17:01:02 -0800

hi,

A question regarding section 9.6 (Protecting Return Routability
Packets). It says the home agent MUST protect the tunneled RR 
packets with an ESP header. IMO, this is pretty strong. Isnt it 
enough to say, "For additional security, the home agent should 
protect the RR packets with ESP in tunnel mode".

Imagine this. A MN has binding cache entries at multiple CNs.
Every time it moves, in addition to sending and receiving so 
many RR messages, it also has to decrypt the HoT messages from 
each of the CNs.

Also, it now becomes more important that we do the HoTI/HoT
test less often (by re-using cookie K0).

regards
Vijay

---

From: Alexandru Petrescu<[email-masked]>
Date: 21 Mar 2002 12:32:33 +0100

> protect the RR packets with ESP in tunnel mode".

I think the above is a good remark.  Moreover, it's not only about
HoT-2 (the part of HoT that is sent by HA) but also HoTI-1.  Both
those messages should be ESP'ed optionally.  IMHO.

> many RR messages, it also has to decrypt the HoT messages from 

...and to encrypt all HoTI messages to its HA.

Alex

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Mar 2002 16:25:12 +0200

Alexandru Petrescu wrote:

> Moreover, it's not only about

(Note: All parts of HOTI and HOT are sent by the MN and CN, the HA
just routes.)

Anyway, we originally didn't include any ESP on the HOTI message
because it didn't contain anything -- no cookies or anything beyond
the home address. However, we have since then considered adding
a cookie from the MN side, to be returned by the CN, as a means to
provide very weak form of authentication of the CN's responses. If
this is done, it would perhaps make sense to have ESP also for the
HOTI and not just HOT.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Mar 2002 16:25:12 +0200

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Mar 2002 16:32:01 +0200

> protect the RR packets with ESP in tunnel mode".

Is proposal a "should" or a "SHOULD"?

> many RR messages, it also has to decrypt the HoT messages from 

I'm not sure about the MUST vs. SHOULD yet but a couple of
comments:

- I believe in most practical cases RTT and bandwidth considerations
   are the limiting factors, not so much (symmetric) encryption
   of small packets.

- What is the security impact of doing or not doing encryption?
   Attackers can now exist also on the HA-MN path. In practise
   they would be on the MN's LAN, such as at a public airport WLAN
   or something like that. I think the question to ask in trying
   to figure out whether a MUST is necessary is who is going to get
   hurt if an attack is performed. If it's only the MN, then there
   are some grounds on making the MN able to make the decision itself.
   Which brings us to the question of use vs. implement.
   MUST implement sounds reasonable at least to allow the user to
   make the decision.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Mar 2002 16:32:01 +0200

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 21 Mar 2002 10:09:26 -0800

> Is proposal a "should" or a "SHOULD"?

should.

>    MUST implement sounds reasonable at least to allow the user to

I agree with 'MUST implement'. but selectively used. Maybe it 
can be indicated by the mobile node with a flag in the BU 
message.

If a particular wireless link is protected by IPSec ESP (between
the AR and the MN) or link layer encryption, the MN indicates to 
the HA that it does not want to protect HoTI/HoT messages with ESP. 
If the MN is moving too fast, it indicates the same to the HA.

And the earlier sentence now becomes "If additional security is
required (indicated by the MN in HA BU??), the HA and MN should
protect the RR packets with ESP in tunnel mode"

Does that sound good?

regards
Vijay