Subject: [mobile-ip] Last Call Review of draft-ietf-mobileip-ipv6-18.txt

From: "James Kempf" <[email-masked]>
Date: Mon, 8 Jul 2002 15:41:42 -0700

I read through the MIPv6 spec last week and this note contains some suggestions. The spec is really long, and I think anything that
could be done to reduce the size without compromising an accurate and detailed description of the basic protocol would be very
beneficial. On the plus side, most of the technical details look good, the authors have done a good job of collecting WG opinion and
forging it into a new and interesting technology. Of the following suggestions, only 2) would really need to be completed before RFC
if there is an urgent need to get it out now, the rest could follow as incremental changes, with the proper attention to requirement
level, IMHO.

                jak

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

1) Editorial

The spec is in need of being worked through by a technical editor with an understanding of IETF specifications. In some cases, MUST
and SHOULD language is missing where it would be useful to designate requirement level. Section 5.2 contains much detail on RR,
exactly at the right level for an IETF specification, but unfortunately some of the other sections aren't up to that level. Also,
there are cases where information on particular operations are spread across a number of sections making it difficult to see what is
required to implement. The material in Appendix A should either be incorporated into the text or dropped. Similarly, the other two
appendicies should be dropped. Appendix C would be good for the WG to use as a guide for future work, but doesn't belong here. There
are lots of other such editorial changes that could be done to tighten the spec up.

2) Security with CN needed for RO

On pg. 65 in Section 9.2.2, there is this statement about security for RO:

    Due to the threat of reflection attacks, this specification requires that packets containing a Home Address option
    MUST be dropped if there is no corresponding Binding Cache Entry for the given home address and the
    packet was not protected by IPsec.

This sentence seems to imply that an IPsec SA is required between the CN and MN in order to perform RO (for which the Home Address
option is used). However, in the requirements for all IPv6 nodes in Section 8.2 there is no such requirement.

The practical difficulty of requiring an IPsec SA between the CN and MN was one of the motivating factors for developing the RR
algorithm for securing the routing change. Requiring it in order that the actual routing itself can be done faces exactly the same
practical issues. I think it would be helpful to change the "and" to an "or".

3) Security between the MN and HA

There are various bits and pieces of text that deal with the security required between the MN and HA for Mobile IP signaling. For
example, Section 5.1 contains a very sketchy description of the IPsec SA required for RR, where either ESP or AH is allowed. There
is also some material in Section 6.1.3 along the same lines when the HoTI message is described. Section 6.8 requires an AH header
for the Mobile Prefix Advertisement message (though this is not required by the SA for RR). And Section 10.7 requires ESP for RR,
but not AH. In Section 11.2.2, there is a short discussion on pg. 97 about using IKE for key distribution.

I think this material should be collected into a single section in which the details of the security association between the MN and
HA for purposes of securing MIP signaling should be described. This section should be very specific and detailed, so there is no
question of ambiguity or interoperability problems, and should deal with key management as well. Also, there should be some
consideration whether the same SA can be used for securing tunneled traffic as well, in the interests of economizing the amount of
processing and code.

4) Alternate Care of Address?

Throughout the spec, there are occasional references to this, but I was unable to pin down exactly why this was there, and how it
might be used by the HA. In Seamoby, there have been some proposals to use it for hosts that are in dormant mode, but I really
couldn't tell whether it could be used from this spec. I think that a section should clearly explain why this was included in the
spec, what this is, and when it can and can't be used. If the AltCoA can't be well motivated, it should be dropped.

5) HA Service Discovery and MN Address Provisioning

I was suprised to discover that MIPv6 defines its own protocol for service discovery of the HA and address provisioning of the MN.
In particular, Sections 6.5 and 6.6 describe HA service discovery messages and Section 6.7, and 6.8 describe the address
provisioning messages. Sections 10.9, 11.3.2, 11.3.3, and 11.3.4 describe the operation of these new protocols.

I'm having a difficult time understanding why Mobile IP can't use standard IPv6 protocols in this area. In particular, it seems like
DNS SRV records would be ideal for discovering the HA. Typically, an MN would have an NAI for the user's home network, and it could
use the domain name as a way to look up the SRV record for the HA's address. This seems much more consistent with the typical way
that IP services are discovered. As for address configuration, many of the operations described for the HA in handling MN home
address assignment are exactly the same kinds of operations that a DHCP server would be expected to perform. So I'm wondering if
DHCP might not be a better solution than a special Mobile IP protocol. Both DNS and DHCP would be expected on most IPv6 hosts,
though, I suppose one could argue about the latter since stateless autoconfig might be expected to handle many cases.

In any event, regardless of whether these suggestions are useful or not (and I don't really think this is the right thread to debate
that issue) I think the spec could be profitably shortened by removing these items and taking them as separate work items for a
seperate specification describing how a MN away from home configures itself.

6)   Forwarding from Previous Care of Address

In Section 2, the following design goal for Mobile IPv6 is stated prominently:

    -There is no longer any need to deploy special routers as "foreign agents" as are used in Mobile IPv4. In
    Mobile IPv6, mobile nodes can make use of IPv6 features, to operate in any location without any
    special support required from the local router.

Yet, once we dive into the document, we find specifications for forwarding from previous care of address, which requires an access
router to interpret Mobility Headers in a way different from a  standard IPv6 node, that makes it an "on link" home agent. In
particular, Section 11.6.6 contains most details, but others are scattered through out the specification.

Since forwarding from previous care of address is meant to be a handover optimization, I think it could easily be removed from the
base specification if the working group is serious about maintaining consistency to the original design goals in the base
specification. There is already ongoing work on handover optimization, and forwarding from previous care of address could be folded
into that work. The debate about whether an access router should support just generic IPv6 functionality or some special Mobile IP
signaling could then take place within the handover optimization work, and the base spec could remain deployable with any IPv6
router, as was the original design intent.

7) BA return

Section 6.1.8 says that a BA MUST be sent if the A bit is set, but it does not say what should happen if the A bit isn't set. Can a
node send a BA if the A bit isn't set?

8) PadN

Would it be worthwhile to specify that the PadN bits must be zeroed?

9) MaxRtAdvInterval

In Section 7.5, this number is defined to be 1.5 seconds, but there may be certain wireless links where periodic multicast router
advertisements are unnecessary or expensive for reasons of spectral efficiency. I think the network administrator should have the
option of configuring this off in such cases.

10) Using the CoA

On pg. 94 in Section 11.2.1, the second bullet item allows the MN to use the CoA for certain communications, but I have a difficult
time seeing how this could be done given the standard socket API. Perhaps this is not an issue for this spec, but it does need some
consideration.

On the next page, the direct delivery option should mention that the described technique won't work without a Binding Cache entry or
an IPsec SA.

11) NS or RS?

On pg. 106, an NS message is recommended for probing the router, but wouldn't an RS be more appropriate, since the mobile node is
interested in the router function?

12) Value judgement on security infrastructure

In Section 14.2, pg. 130 contains a paragraph with a value judgement on whether security infrastructure might be deployable or not.
It is too early to tell whether this value judgement is correct and, in any event, it does not belong in this specification. The
infrastructureless approach can be motivated by the simple statement that deploying an IPsec security association between two
arbitrary node in the Internet in the absence of a global PKI is a hard problem, and so a solution that does not require such was
developed in the interests of maintaining the minimum requirements for deployable MIPv6. Whether or not an infrastructure based
solution can be developed for some subproblem is an open question.

13) References

The nonnormative references should be removed or converted into normative references.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Jul 2002 12:55:48 +0300

Hi James and thanks for your in-depth comments.
I assigned issue #55 for this. Some discussion follows
in-line.

> could be done to reduce the size without compromising an accurate and detailed description of the basic protocol would be very

I agree. We did quite a bit of work on this already for draft 18, in an editorial sense. Further
editorial suggestions on reducing the length and/or suggestions about the general scope of the
protocol are of course highly appreciated.

> if there is an urgent need to get it out now, the rest could follow as incremental changes, with the proper attention to requirement

Yes... perhaps we should go through the spec with this particular aspect in mind. Do you
have any particular complaints about sections that don't do well in this aspect?

> appendicies should be dropped.

Appendix A is, I believe, inline with the textual descriptions earlier. The question is if people
feel that a relatively short description of states helps them understand what the protocol does,
or if they will be reading only the text. How does the list feel about this? I'm ready to
remove appendix A or make it part of earlier sections.

Change lists (appendix B) are normally removed by the time a spec reaches the RFC editor. I think
we should do so here as well, but keep it until we actually are sending the I-D version to the
editor.

> Appendix C would be good for the WG to use as a guide for future work, but doesn't belong here. There

Yes. (We actually considered this in the last moments before the I-D deadline but didn't
finally have time for removing it.)

> practical issues. I think it would be helpful to change the "and" to an "or".

Right. That was the intention.

We do not require IPsec for CN communications. RR is used to establish a binding, and then
HAO, RH, and direct communication can be used. (However, even folks who are not using RO
at all can use HAO if they have IPsec.)

> consideration whether the same SA can be used for securing tunneled traffic as well, in the interests of economizing the amount of

In general I agree about this concern.

We've been working with Vijay on a separate note (that I hope to post to the list soon)
which describes the IPsec processing, SPD configurations, SAD contents, and so on.

Same SAs can't be used for multiple purposes, due to the need to specify address-based
selectors in the SAD/SPD.

> spec, what this is, and when it can and can't be used. If the AltCoA can't be well motivated, it should be dropped.

I'll let others comment on this.

> seperate specification describing how a MN away from home configures itself.

DNS SRV records might work, but I'm uncertain about DHCP. Wouldn't DHCP be deployed locally, in the visited domain?
This would imply some relationship between the visited and home domains which we may not always want.

> router, as was the original design intent.

I agree. How do others feel?

> node send a BA if the A bit isn't set?

I removed the text in 6.1.8 about the BA, since there is more specific rules in the corresponding
behaviour sections later in the draft. For instance, a home agent always returns a BA regardless of the A bit
setting.

> Would it be worthwhile to specify that the PadN bits must be zeroed?

Yes.

> option of configuring this off in such cases.

Yes.. we debated about this a while ago. I wonder if the current text is perhaps sufficient?
It does say after the recommendations that the limits MUST be configurable. Or perhaps you
are suggesting to turn it off completely. Yes, that capabability would be useful on some link
types.

> time seeing how this could be done given the standard socket API. Perhaps this is not an issue for this spec, but it does need some

I believe we could (1) skip the description of the CoA usage and leave it as obvious for
implementors to figure out, avoiding the API discussion altogether, (2) include the current
text but add a note somewhere that this requires API support, or (3) leave this issue for
the general source address selection work. There's an IPv6 draft (becoming an RFC) on address
selection.. I wonder if it says anything about this subject...

> On the next page, the direct delivery option should mention that the described technique won't work without a Binding Cache entry or

Yes.

> interested in the router function?

Perhaps the NA messages are typically shorter than RA messages. Secondly, unreachability detection
in general uses NS/NA rather than RS/RA, even if we are tracking a router. Of course, here we are
going a bit beyond regular NUD, but still...

> solution can be developed for some subproblem is an open question.

Yes.

> The nonnormative references should be removed or converted into normative references.

Hmm... why? Other standards track RFCs appear to have normative and non-normative references,
see for instance the SIP, RFC 3261.

Jari

---

From: "James Kempf" <[email-masked]>
Date: Tue, 9 Jul 2002 11:30:39 -0700

Jari,

Just a few replies.

> have any particular complaints about sections that don't do well in this aspect?

I've marked up the spec with some particular cases, and I have some others I could cite, but I think I would rather not take up list
bandwidth on it. I've cited the ones that I felt were most in need of attention in the original note, and can send others to you
offline if there will be a technical editing effort.

> remove appendix A or make it part of earlier sections.

I feel comfortable with the state machine descriptions, but I think this is a question that implementors should answer.

> This would imply some relationship between the visited and home domains which we may not always want.

Like I said, I don't think now is the time to get into a discussion about what exactly these protocols could be. In the end, we may
actually come up with justification for inventing custom service discovery and/or address configuration protocols for Mobile IP. I
do think, however, these protocols are seperable from the basic routing change protocol, and therefore could easily be treated in a
separate document, thus reducing the bulk of the basic spec.

> are suggesting to turn it off completely. Yes, that capabability would be useful on some link

It could say "and periodic advertisement MAY be turned off completely if desired if the network or mobile node supports solicited or
unsolicited unicast RAs upon detection of handover" or something like that.

> going a bit beyond regular NUD, but still...

OK.

> see for instance the SIP, RFC 3261.

OK, I wasn't aware of the precedent. This must be new, the RFC editor never allowed nonnormative references before.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Jul 2002 17:01:09 -0700

> spec, what this is, and when it can and can't be used. If the AltCoA can't be well motivated, it should be dropped.

I dont know exactly why it was introduced (was done a long time ago).
the general idea is that it is used when an MN wants to bind a HoA to 
CoA, but cant use the CoA as its source address (yet). I know this 
sounds a bit vague.

there is atleast one concrete use of AltCoA option. it has to be there
if the home registration BU is protected by ESP. thats the only way
the CoA can be protected if ESP is used. if AH or Binding Authorization 
Data (Section 6.2.7) is used to protect the BU, then the CoA as the 
IPv6 source address is protected automatically.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Wed, 10 Jul 2002 08:29:39 -0700

> CoA, but cant use the CoA as its source address (yet). I know this

It does sound a bit vague. I think there needs to be some stronger motivation, and a section that clearly specifies how the
AltCoA is used. Below sounds like a start on this.

> IPv6 source address is protected automatically.

So it sounds like the MN sends the BU to the HA with ESP and with the AltCoA as the source address on the packet, is that
right?

I'm a little confused on this. I thought the security association with the HA was based on the home address so a packet
protected by ESP could be sent through a reverse tunnel.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Jul 2002 10:26:02 -0700

hi Jim,

> So it sounds like the MN sends the BU to the HA with ESP and with the AltCoA as the source address on the packet, is that

Home Registration BU, if protected by ESP, is protected in transport
mode. heres how the packet will look like

IPv6 hdr (CoA, HA)
Dst opt
   HoA
ESP hdr
Mobility Hdr
   Binding Update
      AltCoA option

here the IPv6 src and AltCoA contain the same address. without the
AltCoA option, the care-of address cannot be protected by the ESP hdr.

> protected by ESP could be sent through a reverse tunnel.

the security association with the HA is beased on the home address,
thats why you include a HAO. the reverse tunnel is used to send
packets to CNs through the HA. not to the HA itself.

if you want to send a home registration BU in ESP tunnel mode 

IPv6 hdr (CoA, HA)
Dst opt
    HoA
ESP hdr
IPv6 hdr (HoA, HA)
Mobility Hdr
    Binding Update
       AltCoA option

this packet has two disadvantages. 1) more bytes 2) by the time the 
inner packet is processed, the CoA is lost. the outer header is no
longer available. again you need an AltCoA option.

hope I am not missing anything.

regards
Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Jul 2002 03:12:08 +0300

Regarding the use of alt coa... I can't name any other
reason than possible use with ESP. Are there any situations
where we would not have the possibility to use the new coa
yet? It seems that at least for CN BUs, this isn't even possible,
since we already require RR to test the CoA with CoTi/CoT. For
HA BUs, it still remains a theoretical possibility.

And then to the ESP-reason: as Vijay stated, SPD entries are
used for restricting the right SA/HoA to be used. And these
entries can't be used for restricting the right CoA, as obviously
the HA has no knowledge of the current location of the MN yet.

Let's discuss the implications of an attack where the CoA (= BU src)
is changed. If the attacker is not a MitM, he can't forge the ESP MAC,
so the BU will be dropped. If the attacker is a MitM, he can change
the src address and the HA will not see the modification, and installs
a wrong BCE. However, the MN will not see an ack, and will retry.
For the MN, the effect is the same as any MitM could do anyway: DoS.
So in that sense this attack is not serious. However, for the innocent
bystander whose address is replaced as the CoA this may be more serious.
All traffic destined to the MN will be tunneled to him.

It looks like we need to deal with this, so in order for ESP to be used
we need to have the alt coa option in the spec. However, I dislike
format variants, especially when the choice depends on a user-configured
SPD entry in an another part of the system. This creates an unnecessary
restriction between IPv6 stack parts. Therefore, I'd like to suggest the
alt coa option to be made a fixed field in the BU messages instead, and
to be always used.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 12 Jul 2002 18:01:05 -0700

> alt coa option to be made a fixed field in the BU messages instead, and

I didnt quite follow the last paragraph. for Return Routability
protected
BUs, there is no need for the CoA to be present as a fixed field in the
BU. for ESP protected BUs, it needs to be there. so we would end up with
two formats for BUs.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Jul 2002 09:54:10 +0300

> BU. for ESP protected BUs, it needs to be there. so we would end up with

I agree that the alt coa is only needed in the BUs protected by IPsec, i.e.
those sent to the HA. What you say about two formats for BUs is of course
a possibility. On the other hand, we could just have a single format, the
alt coa field doesn't break anything in the CN BUs. Other than take up some
bits, of course.

But this discussion leads me to think about a possible solution: what if we
required the alt coa option to be present in all BUs that are not protected
by RR? In the current spec this would imply having them in all HA BUs. This
would keep the current formats, avoid the security problem, and avoid the
need for the MIPv6 module to know what kind of IPsec is being used to protect
the BUs.

Jari

---

From: "James Kempf" <[email-masked]>
Date: Sat, 13 Jul 2002 06:01:23 -0700

Why not have it be an option? There will likely be other algorithms that will be used for protecting BUs and they may need
other stuff.

            jak

---

From: Thomas Narten <[email-masked]>
Date: Sun, 14 Jul 2002 18:11:50 -0400

> > Hmm... why? Other standards track RFCs appear to have normative
> > and non-normative references, see for instance the SIP, RFC 3261.
> > > >

> OK, I wasn't aware of the precedent. This must be new, the RFC
>  editor never allowed nonnormative references before.

There is confusion here. the RFC editor has always allowed
non-normative references. What it doesn't allow is normative
references to IDs that are not ready for publishing yet. Thus, it is
important to distinguish between references that are normative and
those that are not. The publishing of an RFC is generally blocked
until all references to normative documents can be
satisified. References to non-normative documents are simply cited as
"works in progress".

Thomas

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 15 Jul 2002 10:14:10 -0700

> Why not have it be an option? There will likely be other algorithms that will be used for protecting BUs and they may need

It is an option currently. Jari, lets leave it like that instead
of making it a fixed field.

> need for the MIPv6 module to know what kind of IPsec is being used to protect

if the HA BUs were protected by IPsec AH or some other mechanism,
then there is no need for this fixed field. it is *only* needed
for ESP protected BUs. infact it would also be needed if a BU to
a CN were protected by ESP.

regards
Vijay

---

From: Greg Daley <[email-masked]>
Date: Wed, 17 Jul 2002 14:01:20 +1000

Hi All,

HMIPv6 uses Alt-coa extensively.

IMHO, sending should be optional, but processing should be
mandated as part of MIPv6.

The decision then becomes choice by the MN to advertise
a different CoA (which is what it really is for).

Greg Daley

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Jul 2002 14:47:45 +0300

> a different CoA (which is what it really is for).

I think we have reached a conclusion on when to send it. It
appears that we can easily accommodate both MNs that know and
MNs that don't know what kind of IPsec they are running on top
of.

Anyways, this translates to the Alt-CoA being optional in the
packet, but mandatory to send in certain circumstances. And
it will also be mandatory to be processed when received. We'll
clarify this as well in the draft.

Jari