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

From: Erik Nordmark - Sun Microsystems <[email-masked]>
Date: Thu, 30 May 2002 08:43:20 -0000

A few responses.

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

There are some MH packets (binding missing etc) that are not protected by
authentication.

> - 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?

My answer to the last sub-bullet is that worrying about IPsec protected
(or otherwise secured ND) is for further study, since there isn't a
deployable IETF standard for how to secure ND.

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

If an implementation processes RH type 2 the same way as type 0
(i.e. first swap addresses and decrement segments left and then feed the packet
back into IP) then it will internally (but never on the wire) have
RH type 2 with segments left being zero.
Do we need to make this more clear in the document?

   Erik

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 31 May 2002 18:55:42 +0200

Vijay, 

 > > - 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 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.

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.

=> This is not an update of an RFC, this is 
a draft. The least that people will have to
worry about is changing constants for error
codes in their implementation. There is an
entire new protocol in the draft. I don't 
think this reason is valid. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 31 May 2002 19:00:53 +0200

=> Well it is a pedantic comment, but if manual
configuration of SAs (granted not scalable)
is used, I'm not sure if we need a new standard
for it. Anyway, it is an unlikely scenario.

(i.e. first swap addresses and decrement segments left and then feed the
packet

=> I think it would be nice to clarify that
in the draft. 

Hesham

   Erik

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 31 May 2002 19:06:46 -0700 (PDT)

> There are two types of attacks that I thought
> were relevant:
> 
> 1. An attacker on the CN-HA path, initiates RR 
> using the victim's HoA, hijacks the traffic. 
> Then moves somewhere else and keeps refreshing
> the CNs BCE to deny service between the CN and 
> the victim MN. This can be avoided if RR is 
> performed for any refreshing of the BCE. 
> 

You mean the attacker is able to see both COTI/COT
and HOTI/HOT message ?  If the attacker is only on
on CN-HA path, it will not be able to see the COA
key, thus will not be able to form a correct Kbu
and thus cannot install a BCE on CN. 

> 2. The attacker does RR and sends a BU and 
> moves away, to bomd the network he was in. 
> This is what you mention above and we agree
> it will be likely to end way before the 5 min
> are over. 
> 
> So are you talking about a variation of 1)
> above, where the attacker is on the CN-HA
> path and he installs a BCE in the CN for 
> a long time?
> 

For that reason should not the MAX_RR_BINDING_LIFE should be
a smaller value?  Do we need to define a MIN_RR_BINDING_LIFE
as well to ensure that binding will last at least this amount
of life?

> > - 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.
> 
> 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.
> 
> => Yes it is for the benefit of the MN. It
> makes the protocol more secure. Especially
> against attackers on the MN's link. 
> But I don't understand the relation between
> 'good for the MN only and not other nodes'
> and the 'SHOULD'. I might just need some 
> coffee :) but it sounds like you're saying
> that being good for the MN alone does not 
> justify a MUST.
> 

Agree. Without having ESP tunnel mode for both
HOT/HOTI, the HOA is prone to hijacking. I am
not able to understand the logic behind having
optional ESP tunnel mode for HOT message.
This leaves a security hole in the protocol. If a MN can send
HOTI message in ESP tunnel mode, then it should
be able to process incoming HOT message in
ESP tunnel mode.

Besides, making it optional means more complicated
implemenation on MN (and HA) and more lines of unnecessary code.

I am not able to see any merrit of having ESP tunnel
mode optional in HOT path. Making ESP tunnel bidirectional
for both HOTI/HOT seems simple, secure and reasonable 
from the protocol perspective.

Thanks,
-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 31 May 2002 19:40:52 -0700 (PDT)

Hi Vijay,

> > I think Hesham has a good point here. If you look at the
> > "More comments on Draft16 -CLARIFICATION " thread (issue #19), where
> > I asked the same question that both HOTI/HOT messages
> > must use ESP tunnel and I thought the decision was 'yes'.
> 
> issue #14 was about "Require encryption on HA-MN tunnel for MH 
> messages?". the issues list says the adopted concensus was MUST 
> implement and SHOULD be used.

Ok. Then do we know what is the default behavior in the spec ?
If the implementation is  MUST (which is quite logical), then
the draft should make it MUST too. That means the implementation
SHOULD be able to disable this functionality optionally.

Thanks,
-Samita