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

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

Jari, 

I'll just respond to a couple of issues. Email is 
a rare commodity for me this week :) 

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

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.

=> Agreed.

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. 

=> Not if my HA tunnels the HOT message securely
to me. That's one of the reasons I was suggesting 
a MUST for ESP tunnelling of HOT messages.
Does that answer your attack scenario? 

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.

=> But I'm not sure how you could claim my HoA
and CoA if there is a secure tunnel for RR messages
between the HA and MN. 

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. 

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?

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

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.

=> I'm not sure I understand what you mean. 
My concern was that there will be overlapping
lifetimes for the nonces and the CN's keys
for the different BCEs. So it wasn't a question
of lack of memory, but rather the frequency
of generating new keys and remembering which
keys are valid for which BCE. But after  I 
thought about it some more, I realised that 
it's probably not a big issue. 

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

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

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.

=> It's not for graphics ;) it might be easier
to introduce a new field, for instance if someone 
wants to add a 32-bit field later, it's easier to
have it in one field, instead of 2 16-bit fields. 

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.

=> I don't have a strong opinion either, I was 
curious.  

> - Section 9.4.1: Shouldn't the order of the last 2 bullets
>   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?

=> OK.

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

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

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

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?

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

Create or have?

=> Well, I suppose create if it doesn't already
have it. I guess, except for the IP address
of the MN, everything else can be copied, right?

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

See above, where did we agree to remove this?

=> I assumed that this was agreed on (now that
you ask, I can't pin point an email, but I
thought it was discussed when Erik published
his draft (foresight to hindsight) ). 
But anyway, securing the BU to the local
HA has not been discussed, and I'm not sure
if the same security model would apply. 
I've been thinking about this, perhaps
I can send a separate email on it, unless
you've already go some info on securing the
BU to the previous default router.

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

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

=> Sure, but how long is this entry kept for?

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

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.

=> Agreed. 

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

This is a CN-BU. 

=> I thought it was a HA BU. I'll re-read it
then

Thanks, 
Hesham

---

From: Jari Arkko <[email-masked]>
Date: Sat, 01 Jun 2002 00:11:13 +0300

> Does that answer your attack scenario? 

Yes, partially.

But if your office has just one LAN, an ESP tunnel between
the HA and the MN will not help, as the CN's packets will
be arriving in cleartext on that LAN.

> performed for any refreshing of the BCE. 

Yes.

> it will be likely to end way before the 5 min

Yes.

> path and he installs a BCE in the CN for 

Yes. So, if I'm on your home LAN or on the CN-hA
path for a small amount of time and there is no
limit on the BCE lifetimes, I'll install a BCE
that redirects your traffic to, say, my server
at some other location.

> it's probably not a big issue. 

If you have a suggestion on how this could be made
clearer for implementers, it would be very useful.

> that being good for the MN alone does not 

Something that prevents bad things from happening
to other nodes would be a sufficient condition for
a MUST. There might of course be other reasons to
make something a MUST, such as a security advantage
for the node in question. I suppose it's a judgement
call in this case. The earlier debate showed that
people had different opinions about this particular
situation.

> of the MN, everything else can be copied, right?

I'm a bit uneasy on spending too much effort on us
creating lots of IPsec SAs in some dynamic fashion.
Could be easier to just require that these SAs exist,
and have been manually configured.

> => Sure, but how long is this entry kept for?

I can't find any other explanation than... the lifetime in the BU.
This would actually make sense to me.

> => I thought it was a HA BU. I'll re-read it

I clarified the text.

Jari