Subject: Re: [mobile-ip] Question about MIPv6 draft 18

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 13 Aug 2002 19:44:02 -0700 (PDT)

>       can then retry the return routability procedure.  However, it is
>       recommended that correspondent nodes try to keep these cookies
>       acceptable as long as possible and SHOULD NOT accept them beyond
>       MAX_COOKIE_LIFE seconds."
> 
>     I find this paragraph highly confusing from the point of view of a
>     correspondent node.  This paragraph implies that the correspondent
>     should timeout and therefore cache cookies, but the whole assumption
>     behind RR is that correspondent doesn't keep state per mobile node until
>     BU had happened.  So, in effect, the corresondent times out nonces every
>     MAX_COOKIE_LIFE seconds.  Is my understanding correct?

I am assuming you are referring to K0/K1 cookies.

Well, it seems CN needs to keep track of N(j)s, N(i)s for
COOKIE_MAX_LIFE time in a sliding window scale. So at a
given COOKIE_MAX_LIFE time, there will be X number of N(j)s
and Y number of N(i)s around in the system depending on
the nonce generation frequency. 

Since K0 or K1 are  fn(Ni, Hoa), fn(Nj, Coa) respectively,
CN does not need to keep the cookies saved for their lifetime,
but it needs to compute everytime it processes a request.

I thought about the possibility of keeping K0/K1 as well, but
then it means more memory and then in a way it's keeping state
of MN, before accepting the BU for that MN--which is not 
recommended.

-Samita

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 14 Aug 2002 13:46:00 -0400

Samita

> the nonce generation frequency.

Well, that's what I was asking.  The correspondent keeps nonces
instead of cookies.  However the paragraph I quoted implies that
cookies are kept, which is actually not true and against previous
recomendations.  And, in effect, a nonce may remain valid up to
a maximum of "nonce generation interval" + MAX_COOKIE_LIFE (that's
how far the time window may slide).

Additionally, it would be nice to recomend a nonce generation frequency
that is more specific then "... at regular intervals,for example every few
minutes".

> but it needs to compute everytime it processes a request.

Yes, but the time window on the nonce only slides when the cookie
for a CoT or a HoT are computed, not everytime.

> of MN, before accepting the BU for that MN--which is not 

That would actually be really bad, because you would need K0/K1 pair
for each mobile node talking to you and that can be a very large
number.  This would also open for yet another DOS attack, where
all an attacker would do is run RR with different addresses and
consume all your cookie space and cause another redirect attack
that would result for HoT and CoT messages.

-vlad
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich	       Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 	       Tel: (603) 884-1079
Nashua, NH 03062	       ZKO3-3/T07

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 14 Aug 2002 11:48:23 -0700

hi Vlad,

Vladislav Yasevich wrote:

> This would also open for yet another DOS attack, where
> consume all your cookie space 

I am not sure I understood this DoS attack. how is this possible? 
the attacker can be at only one CoA at a time. the purpose of 
Care-of test is to prevent an attacker from claiming any 
arbitrary CoA. right?

> and cause another redirect attack

didnt understand this.

Vijay

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 14 Aug 2002 15:29:19 -0400

Vijay

This was an attempt to say that storing K0/K1 cookies on
the CN is a bad idea.

If the correspondent caches K0/K1 (the bad behavior), an attacker
can send CoTI and HoTI messages from bogus source addresses.
this would cause creation and caching of cookies and a response of
CoT and HoT messages respectively.   Thus the attack is two-fold.
One part consumes memory/cookie space.  The attacker has 4 minutes
(240 sec) in which the cookies cached on the CN will be valid.
That can be a lot of cookies.   The other part sends HoT or CoT
messages to some hosts that doen't expect them and may result in
additional ICMP errors.

All in all, bad situation.

This all really points to a paragraph is Section 5.2.7 that implied
(to me on my first few reads) that a CN keeps cookies.  It might be
better to talk about nonces from the CN point of view and stick to
cookies from the MN point of view.

-vlad

--

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 15 Aug 2002 11:30:33 -0700

hi Vlad,

> This was an attempt to say that storing K0/K1 cookies on

I was not disputing the above statement. but the DoS attack 
that you described as the reason is not correct (or atleast 
I did not understand it).

> That can be a lot of cookies.   

how can it be a lot of cookies? the CN would be storing only 
one K0/K1 per MN. a new pair of cookies can be created only if 
the MN moves and does CoTi and HoTi for a new CoA and a new HoA. 
how can one MN launch this DoS attack?

regards
Vijay

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 15 Aug 2002 14:52:00 -0400

Vijay

It does not have to be a mobile node.  It can be any node.

-vlad

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 15 Aug 2002 12:22:12 -0700

> It does not have to be a mobile node.  It can be any node.

you are right. it can be any node. but the CN still stores
only one K0/K1 pair at any time per node, right? one single 
node cannot fill up memory at the CN by generating a large 
number of K0/K1 pairs.

I dont know what I am missing.

Vijay

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 15 Aug 2002 15:40:54 -0400

Vijay Devarapalli wrote:
> only one K0/K1 pair at any time per node, right? 

No, the cookies are generated per address.  If the address
changes, the cookie changes.  In the end, to the correspondent,
it will look like a large number of mobile nodes are trying to
do RR.  How many times can 1 node run RR in a 240 sec interval?
(240sec == MAX_COOKIE_LIFE).

The atack is defeated however by ingress filtering and other RFP
checks.

> 						one single

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 15 Aug 2002 14:02:13 -0700

hi Vlad,

> The atack is defeated however by ingress filtering and other RFP

exactly. this is what was I was trying to say. I know that
storing K0/K1 is a bad idea. but for other reasons. and not
the DoS attack you mentioned.

Vijay

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 15 Aug 2002 17:32:52 -0400

Hi Vijay

> the DoS attack you mentioned.

That's assuming these RFP checks are used.  Do
you think this should be mentioned in the security considerations?

-vlad

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 15 Aug 2002 14:42:25 -0700

> you think this should be mentioned in the security considerations?

hold on Vlad. we came down this dicussion path assuming CN
stores K0/K1. if it does not (which is the case now), we
dont have to mention it anywhere.

RPF checks need to be there anyway. MIPv6 does not have to 
say anything about them.

Vijay