Subject: [mobile-ip] comments on MIPv6 draft-17

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 28 May 2002 18:18:37 +0200

Hi, 

I've read the draft and have the following comments/questions.

1. General comments:

- In general I think the draft has redundant text and in 
some cases, significant overlaps between sections. It's 
good to have some overlap, but in many cases it is too
repetetive. I'll try to mention specific examples in my
editorial comments. But this could be something to consider
before the final draft is done. The draft is very large
so it is good to remove as much as possible while maintaining
a good level of clarity.

2. Specific technical comments

- I wonder if it's worth referencing some way of creating
the nonce, or making a recommendation on how to do it. Mike
Thomas' last draft had a reference. It might be good to do
that, since it (the nonce) is a pretty significant part of RR. 

- I don't understand why MAX_RR_BINDING_LIFE is fixed 
to 300 seconds. I would appreciate a reference or a reason.
The attack that Pekka sent a few months ago should not 
require the 5 min limit. It simply requires that the BCE
cannot be refreshed without performing RR. In fact there
is probably more hazard in allowing the updates within
the 5 min than if we extend (or remove) the upper time 
limit. 

- Busy CNs will struggle with maintaining the Nonce
and Kbu lifetimes for several (hundreds or thousands?)
of MNs. Do you think this is a valid concern? If so
we need to add some recommendation on how to do this.
I haven't read the state machines in the appendix
yet, so my answer might be there.

- I might have missed this in an earlier discussion, 
but why us the checksum needed for the MH? 
It should always be authenticated. 

- Section 6.1.3: Why is the HA tunnelling the HOT a SHOULD?
It seems that this is one of the assumptions that the
protocol is based on (see the security design section).
Shouldn't this be a MUST? Not making this a MUST will
allow attacker on the MNs link to do some nasty stuff.

- It seems like there was a concious decision to separate
the 'reserved' fields in all messages (e.g. section
6.1.5 (HoT) and 6.1.6), why is that?

- Why are certain values skipped for the BA status 
codes? e.g. between 133 and 137. I suggest we place them
in order. It looks like some magic is attached to those
missing numbers :)

- I think that setting the A flag has to be a MUST
or at the very minimum a SHOULD. It is very clear to
me that the protocol is much weaker and non-deterministic
without mandating the Ack. I would suggest that we mandate
it. There are several examples in the draft the provide
a good reason for mandating the BA.

- I don't really get this unique identifier option, but
  more on that later. 

- Either we explain how the Mobile Prefix sol and adv
  can be done securely (using PKI and dynamic SA establishment), 
  or remove them from the draft. I don't think we should 
  keep them and say that they must be authenticated 'if possible'. 
  what does that mean? Either they must be authenticated
  or not. I think that they must be. 

- Section 8.1,what is the point of mandating the HAO
  when the  spec says that it must not be received
  without a BCE, and the entire RO is a 'should'.? 
  The HAO should follow the same recommendation as RO.

- In section 8.1: I think we should add a line that
  if RR is supported, the CN MUST be able to return
  a BA in response to a BU.

- Section 9.1: Remove all the references to mobile routers.
  E.g. the fifth bullet. Also remove the sixth bullet, 
  the prefix length does not exist anymore.

- Section 9.2.2: First sentence, 'MAY' is unnecessay. 
  If the MN has a BCE, it's pretty strange that it doesn't
  use RO and decide to not include the HAO. 

- Section 9.4.1: Shouldn't the order of the last 2 bullets
  be reversed.(Half editorial).

- Section 9.4.1: Perhaps we should add some text to specify that 
  'normally' the CoA nonce index and Home Nonce index are the same, 
   and that sending both  is a precaution for changing the nonce while
   RR is in progress. Or am I missing something?

- Section 9.6, first paragraph. I thin we should replace
  the first SHOULD with MUST. There is no point in having a 
  binding cache if it doesn't get chacked. 

- Section 9.7: Remove the third paragraph, it no longer
  applies.

- Section 9.7: Fourth paragraph: Do we need to say how
  persistent is 'persistent'? or Specify a default rate?

- Section 10.1: Last sentence in the second paragraph, says
  ' it SHOULD NOT be deleted by the HA ...' In section 9.5, 
  the same action was a 'MUST NOT'. Either MUST NOT, or SHOULD
  NOT (accompanied with 'MUST inform the MN') are ok with me.

- Section 10.1: Remove '(or has recently)' from the fourth 
  paragraph. 

- Section 10.1: it would be good to show the order of 
  HAs in the HA list (last bullet in 10.1 doesn't say
  in what order). 

- Section 10.1: In response to the question in the draft, I'd
  say that as long as the HA discovery is in the draft, 
  we have to keep the preference. I think HA discovery is 
  a nice idea.

- Fifth bullet in 10.2: Shouldn't DAD be done for all addresses?
  RFC 3041 might be a problem here if we only do DAD
  on link-local addresses.

- Page 93: Bullet starting with 'However, if the 'S' bit
  .....'. This strikes me as a problem when renumbering 
  the Home network is going on. If the HA always chooses 
  the smallest lifetime, doesn't that mean it will always
  be choosing the lifetime of the prefix being deprecated?
  Some clarification would be good.

- Section 10.4: I don't think ND says anything about 
  'gratuitous' NAs. We should replace that with Proxy NA
   or some other terminology used in IPv6.
  
- Somewhere in section 10 it should be mentioned that 
  if the S bit is cleared (request the HA to act on behalf
  of all the MNs HoAs) then the HA should create an SA in the
  SAD for each one of those home addresses. 

- Page 96: In the four bullets there, I have the following
  comments: 
          - Second bullet, the llA should be there IF the link 
            layer has link layer addresses.
          - A pedantic question: What happens if ND is secured
            with pre-configured SAs. Shouldn't the HA be configured
            to act on behalf of MNs and send secure ND messages?

- Remove the last paragraph before 10.5 (the part about the R bit).

- Section 10.5: Second paragraph, remove all reference to prefix
  length.

- General comment on multicast: I lost the emails that Dave
  Thaler sent on the topic and haven't had time to look them
  up. But I thought I'd remind the authors to look them 
  up and see if they are applicable. 

- Section 10.7: Second paragrpah, Again, why is ESP
  optional here ? What is the default behaviour?

- Section 10.9.3: 'If a security association ....'
                   --
  No ifs pleasejust make sure it's secure (MUST).
  This goes for the entire section.

- Page 108: Remove any reference to previous-CoA.

- Section 11.1: Te bullet starting with, 'A flag when 
  set, indicates that future Binding Updates .....'
  What does this mean?? The MN will keep an entry in
  the BUL anyway for a CN that doesn't accept BUs? 

- Page 113: Last bullet, 'other implementation 
  stragies maybe more appropriate' Like what?
  I don't think we need to state this do we?
  I would suggest removing this approach and 
  making the standard more concretein what it
  says. 

- Page 115: 'The segments left in the RH is either
  0 or 1'. Zero? why is Zero ok?

-  Chapter 11.2.4 assumes that the MN can send 
   BUs to a 'router' in the local domain. I'm
   not sure we can keep this in the spec without
   specifying how to secure this BU.

- Section 11.3.3/4: Same comment on securing the messages.

- Add somewhere in Section 11 that the MN MUST NOT
  let BCEs in CNs or HA timeout after the MN has 
  moved. I.e. It MUST deregister.

- Remove section 11.6.6.

3. Editorial comments

This is not an exhaustive list, but I assume the 
draft will be revised and grammar ...etc will be 
checked again.

- secion 5.5: Second sentence 'without creating major new ..'
  Should be changed to '..new major...' or reworded.

- Same section: All the references to, e.g., [1] ...are
they going to be RFCs ? Otherwise they can't be referenced.

- Section 5.5.1: Second sentence: '...to accept only...'
  reword. 

- Section 5.5.9: Second sentence, remove 'only'

- Section 6.1.1: Last paragraph Add 'the' after
'Mobility Header are' in the first sentence.

- Why are sections 6.2.2 and 6.2.3 needed? 
can't we refer to 2460? The less text the 
better for this spec.

- In 6.2.4 and 6.2.5 and other sections, please
  write either 'Type', 'Length' ...etc in the 
  option format or 'Type = X', 'Length = Y', 
  but not just the numbers.

- Page 56: Repeated text: 'A packet MUST NOT contain....
  associated with each encapsulating IP header'

- Section 6.4: Second paragraph: 'This uses...'
  Replace 'This' with 'The Routing Header' or 
  'The new RH' ....

- Section 9.4.2: Last sentence in the second last 
  paragraph, add 'of' before 'its lifetime'.

- Section 9.6: Third paragraph, first sentence, add
  'in' before '6.4'.

That's all I have for now.

Hesham

---

From: "Kalyan" <[email-masked]>
Date: Wed, 29 May 2002 13:11:35 +0530

Hi ,
     In section 6.4.1,You had clearly mentioned that the segments left field
is always equal to 1.
Then why does a node check for either '0' or '1' in the segments left field
of the routing header type 2, while
processing a packet received for one of its addresses.

Any info regarding this is welcome.

Regards,
Kalyan.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 May 2002 01:02:11 +0300

Thanks Hesham for your in-depth review and comments!
We'll take care of the editorial modifications. I will treat
other parts inline below. Most of your comments can be
taken in account immediately. But you may be satisfied
with an additional explanation on some specific ones,
and some others may require more discussion.

The whole issue is registered as #35 unless otherwise noted below.

> so it is good to remove as much as possible while maintaining

I agree.

> that, since it (the nonce) is a pretty significant part of RR. 

At the moment we only say that it is random. This is
a sufficient condition, but may not be fully necessary.
A weaker constraint, such as the time-bound variable in
Mike's draft might do as well. This is because the use of
Kcn hides any regularity in the nonce (if the MAC
function was vulnerable to known plain text attack this
would be a problem, but they usually aren't).

> the 5 min than if we extend (or remove) the upper time 

A future DoS attack would likely die off quite soon (before
5 mins) if there was no TCP ACKs or something like from the
victim. For these attacks the limit does not buy much.

However, there are other types of attacks. For instance,
I could visit your office and install a BCE at some CN
that claims your PC is somewhere else. Allowing long BCE
lifetimes makes this "hijack" attack possible for a longer
time. Note that unlike in the DoS case, no refresh is
needed for the attack proceed. Ideally, the effects of
my visit should not last too long after my departure.

> yet, so my answer might be there.

This may be a valid concern, though (1) you can always
deal with it by either bying more memory or declining
more RO requests (2) we have some text in 9.4.3. Do
you think that text is sufficient:

   A possible way to implement this is to mark the binding cache entry
   so that it does not effect sending and receiving of packets, but
   so that it is found when a binding update is received.

> It should always be authenticated. 

Yes, but not all of the messages are authenticated: BM, HOTI, COTI, ... 

> allow attacker on the MNs link to do some nasty stuff.

There was a separate thread about this a couple months
ago. It seems that the added benefit of encrypted tunneling
is quite useful, but mainly for the benefit of the mobile
node. Not absolutely necessary perhaps for the security
of other nodes. Hence SHOULD.

> 6.1.5 (HoT) and 6.1.6), why is that?

Well, drawing the boxes together would look graphically
better but the fields would still be at different positions,
so that is probably not a good idea.

Placing the index on the first two bytes would make sense
as the next word would be completely reserved, and the
field might even be removed. However, we wanted to keep
some reserved space at the beginning of messages to store
some future flags. This would be inline with the format
of BUs.

We could also move the index field to the second part
of the first full word, making the reserved field
continuous.

Anyway, I don't feel strong either way we format the
messages.

> in order. It looks like some magic is attached to those

I don't know. Comments on the source files seem to indicate
some old (now removed) status field values occupied these
positions. Why don't we go and compress the list now.

> a good reason for mandating the BA.

Yes, not using the acks might get you in trouble, having
to deal with BEs later.

>   or not. I think that they must be. 

Ok, let's create a separate issue for that. #36.

>   The HAO should follow the same recommendation as RO.

I agree. Should be the same as the rest.

>   a BA in response to a BU.

Seems right. If you do something, you must do it completely.

>   the prefix length does not exist anymore.

Yeah.

>   use RO and decide to not include the HAO. 

Hmm... the sentence could also be read from the point of view
of the correspondent node. That is, even if the CN has a BCE,
the mobile node may have rebooted and lost its binding information.
Ok, let's make the sentence clearer!

>   be reversed.(Half editorial).

You mean doing auth first and then sequence number check? Why?
Wouldn't it be better to do the cheaper tests first, such as
the sequence number check is?

>    RR is in progress. Or am I missing something?

You are right. But aren't we already stating this somewhere else,
perhaps it shouldn't be repeated here?

>   binding cache if it doesn't get chacked. 

I think the SHOULD exists here in order not require the
use of some detail from a whole which is optional. Do
you think we should try to make the keywords requirements
more structured, i.e. SHOULD RO, IF RO THEN MUST RO-FEATURE-X?

> - Section 9.7: Remove the third paragraph, it no longer

I'm not sure why you think so. 11.6.6. still exists, no?

>   persistent is 'persistent'? or Specify a default rate?

I'm open to suggestions. Can you answer your own question?

>   NOT (accompanied with 'MUST inform the MN') are ok with me.

I'd like to reduce the overlap between 9.5 and 10.1, by stating
things only in 10.1 for home registrations.

> - Section 10.1: Remove '(or has recently)' from the fourth 

Yes.

>   HAs in the HA list (last bullet in 10.1 doesn't say

Yes.

>   we have to keep the preference. I think HA discovery is 

Ok, let's remove the note.

>   RFC 3041 might be a problem here if we only do DAD

I think this is being debated separately. Issue #37

>   Some clarification would be good.

Yes it will choose the smallest possible lifetime. Would
you like to clarify that this really is the case, or specify
some additional constraints that limit the use of prefixes
being deprecated through 'S' bit?

>    or some other terminology used in IPv6.

Yes.

>   SAD for each one of those home addresses. 

Create or have?

>             layer has link layer addresses.

Yes.

>             to act on behalf of MNs and send secure ND messages?

I think we can deal with this by stating that rules in the ND
RFCs are to be followed (which includes the potential use of SAs).

> - Remove the last paragraph before 10.5 (the part about the R bit).

Yes.

> - Section 10.5: Second paragraph, remove all reference to prefix

Yes.

>   up and see if they are applicable. 

Ok...

>   optional here ? What is the default behaviour?

This was already discussed above. I'm not sure we can
state much about the default behaviour, given that the
user has to configure things in the SPD. Oh well, I suppose
that means default is off...

> - Section 10.9.3: 'If a security association ....'

Yes.

> - Page 108: Remove any reference to previous-CoA.

See above, where did we agree to remove this?

>   the BUL anyway for a CN that doesn't accept BUs? 

This is for the MN to not retry RR/BU all the time.

>   making the standard more concretein what it

But this is internal implementation, isn'#t it? 
Let's remove the note about the other strategies.
But let's astill require that the behaviour must
look like this from the outside, don't care how
it's done.

>   0 or 1'. Zero? why is Zero ok?

I believe this is for dealing with an implementation strategy
where the RH is processed but left in its place in the packet,
with zero in the field.

>    specifying how to secure this BU.

This is a CN-BU.

> - Section 11.3.3/4: Same comment on securing the messages.

As above.

>   moved. I.e. It MUST deregister.

Ok.

> - Section 9.6: Third paragraph, first sentence, add

Thanks.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Wed, 29 May 2002 17:36:28 -0700 (PDT)

> would be a problem, but they usually aren't).

I see my name here... If this is about
constructing the stateless cookie, I'd suggest
taking a look at the JFK draft's variation on
this. As I recall, their approach was simpler
than mine. If you need it encoded into a single
field, you can concatenate the MAC with the nonce
and lose 12 bytes of nonce if you like.

	    Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 29 May 2002 19:41:33 -0700

> positions. Why don't we go and compress the list now.

values 133 to 137 had some kind of meaning in the earlier
versions of the MIPv6 ID. I am sure that there is still some
code in some implementations dealing with these sequence 
numbers. I would advise against compressing the list. it
is going to be a nightmare at the next interop.

> I agree. Should be the same as the rest.

isnt there a danger here? lets assume the MN sends a IPsec
protected BU to a CN. there is no BCE at the CN. but the CN
still has to process the HAO. the other two SHOULDs in 
section 8.1 do not affect the processing of HAO. 

I think it should left as MUST. we should be fine as long as 
the spec requires that the CN does not process unverified HoA.

Vijay

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Thu, 30 May 2002 12:12:37 +0900 (JST)

Hi Vijay, 

From: Vijay Devarapalli <[email-masked]>
> the spec requires that the CN does not process unverified HoA.

Really?

I think there are three type of CN.

(1) traditional IPv6 node
(2) HAO aware CN
(3) full MIP6 CN

The CNs will process HAO as follows,

	unprotected	IPseced
	HAO		HAO		
(1)	ICMP paramprob	ICMP paramprob	-> bidir-tunnel
(2)	BE		go ahead	-> triangular(?)
(3)	BE		go ahead	-> ROed communication

At least, (1) is not required to support processing HAO.  I think HAO
processing must be 'SHOULD'.  There is no reason to mandate it.

Am I correct?

Best Regards,

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 May 2002 10:06:16 +0300

> is going to be a nightmare at the next interop.

Ok, let's leave it as it is then.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 May 2002 10:26:42 +0300

> processing must be 'SHOULD'.  There is no reason to mandate it.

The question is, if we want to make the entry (2,ipsec) something
whose support is always required. With a SHOULD, even if you may
have an IPsec SA you might end up with the parameter problem ICMP.
The mobile node will then revert back to bidirectional tunneling.
With a MUST, a compliant implementation will process the packet.
Note that since there will always be "old" IPv6 nodes, there will
be cases where we have an SA and still get the ICMP back. So
functionality-wise the result in both cases is the same. We are
talking more about what instruction we give to implementers and
vendors rather than anything else. And we have an ongoing debate
about the right level of the instruction, on the IPNG list.

Personally, I feel that it is much more likely that two nodes
would be willing to be good-behaving mobilize citizens and
use route optimization, than that someone bothered to set up
a security association between those nodes. So I think it
would be rather unlikely that you'd find a situation where
the nodes have an SA, but are unwilling to use full RO.
For these reasons I believe the same keyword that we have
for RO could equally well apply to HAO.

Jari

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Thu, 30 May 2002 18:04:52 +0900 (JST)

Hi Jari,

From: Jari Arkko <[email-masked]>

> With a MUST, a compliant implementation will process the packet.

Umm, I (currently) think none of them should be must.  This is the
basic cecept of protocols.  If both supports something, something good
is occur (ex. RO :).  If one of them doesn't have such an
extention(?), we just use a traditional method.

> about the right level of the instruction, on the IPNG list.

I'm reading the discussion.  In my opinion, it is better for the basic
specification to keep as possible as small.  The needs will deploy
advanced extensions (even if it is specified as SHOULD) in the future.

> for RO could equally well apply to HAO.

I understand your opinion.  But, I think having an SA and the
intention for RO is a different problem.  Once all requirements is
satisfied (an SA and supporting HAO processing and BCE management), RO
occur.  Even if we lack one of them, we can still communicate with.

Best Regards,

---
Keiichi SHIMA

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 May 2002 13:52:14 +0300

> occur.  Even if we lack one of them, we can still communicate with.

I think we actually agree though you seemed to conclude that we
don't... I support the SHOULD RO approach myself, and would also
like to have a SHOULD HAO instead of the current MUST HAO.

Jari

---

From: Brian Haley <[email-masked]>
Date: Thu, 30 May 2002 10:09:56 -0400

> is going to be a nightmare at the next interop.

But there is no way a draft 15 implementation will ever work with
a draft 17 (or 18) one, so now is the perfect time to compress them,
especially since it's a one-line change to a header file.

-Brian

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 30 May 2002 10:51:36 -0700

Keiichi and Jari,
 
let me explain myself again.

unverified HAO MUST not be accepted because of reflection 
attacks. HAO verification at the CN can be done in two ways. 

1. checking for a valid BCE
2. an IPsec association between the CN and MN. ( I am talking
about triangle routing. it is possible because the CN knows the 
MN and trusts it not to do any reflection attacks). this also 
corresponds to the case (2) from you text.

> (2)     BE              go ahead        -> triangular(?)

here, HAO can infact be processed and accepted without RO.

so, thats why I am saying HAO processing got be a MUST. there
is no harm because unverified HAO is never accepted.

another example (you might consider it rare) is an intranet, in 
which CN can process and accept HAO from any MN inside the domain. 
here the HAO verification comes from fact that both the CN and the 
MN belong to the same domain and trust each other not to cause any 
reflection attacks.

also take a look at the thread "How to process HAO", in which we 
all agreed to Francis Dupont's suggestion. do the verification just 
before "upper layer" processing. and the verification routine uses 
IPsec match, BCE check or another appropriate mechanism. 

regards
Vijay