Subject: [mobile-ip] Comments/Questions to the Home Agent Cookie Draft

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Jul 2001 16:17:25 +0200

hi

reading the draft i have some comments/questions:

- i think that the protocol is vulnerable to a denial of service attack to
some extend since the cn has to keep state for a certain time before being
able to verify the response from the home agent? what prevents an adversary
from sending many bogus requests to the cn and therefore to force him to
allocate kernel memory etc. ?

- if the cn includes his public key then the mn and the cn share a shared
secret after the protocol exchange is finished.
subsequent binding updates however still have the same structure as the
first  (both cookie values).
such a bu could be simply protected by a keyed message digest attached to
the bu message .

- if the public key is not included then the cookie(mn,cn) cannot be
verified and the mn and cn do not share a key afterwards. maybe it is a good
idea to include the pk mandatory in the message from the cn to the ha. it is
obvious that the cn does not need to create a new pk/sk pair for every
session and hence there is not too much overhead associated with the
additional message part.

- if i understood the protocol correctly then two sequence numbers are used:
the binding update includes a sequence number field and the cookie(mn,cn)
value too. is this really necessary?
what happens if the sequence numbers are out-of-sync (there is no protocol
for re-synchronization)

- the term checksum inside the cookie should be changed to e.g. key message
digest

- the cookie checksum (keyed message digest computation) should be done with
a standard technique e.g. HMAC-MD5 ....

- is the hop-by-hop option really necessary? why not to address the home
agent directly with a message?

- the argumentation for the home less scenario seems to be a little bit
difficult: the main property of the home agent cookie draft is the usage of
the home agent and the shared secret between the mn and the ha.
hence i have some doubts that the homeless scenario is really useful.

- if the ha is supposed to verify the cookie(mn,ha) then the binding update
should be included since the home agent may not have the full information to
reconstruct the binding update e.g. because he does not know the sequence
number included in the BU from the mn to the cn. (however if the
cookie(mn,cn) is exactly set to the same sequence
number then it may be possible - but i think that this is not described
anywhere.)

what do you think?

ciao
hannes

---

From: Michael Thomas <[email-masked]>
Date: Thu, 12 Jul 2001 08:51:03 -0700 (PDT)

> allocate kernel memory etc. ?

The DoS is mitigated by the overall number of binding
cache entries, which is limited. I believe the draft
make some mention of that. There are probably other
measures that could be taken as well.

 > such a bu could be simply protected by a keyed message digest attached to

As I recall, the reason that it sends both was to not
make any assumptions of hard state on the CN. That is,
if the CN drops the binding from its cache, we'd like
to make certain that a subsequent BU works. There's no
real requirement that it behave this way, as it could
conceivably just fail and retry, but given the relatively
 small number of bytes for a cookie, it didn't seem like a big
deal. I'm not terrible attached one way or the other though.

 > session and hence there is not too much overhead associated with the

I mainly wanted to make the use of pk completely optional
for both the HA and CN; ie, the CN or HA doesn't need to have
any pk code on it at all. I guess I don't understand what
the advantage of including it would be if the CN doesn't
want to take the time to do a public key decryption... Note
that if CN doesn't want to do that, but HA provides that 
service, it will delay the response back for the amount of
time it takes HA to do that pk encryption...

 > value too. is this really necessary?

Maybe not... if I remember correctly, the sequence number
of the BU was too small though.

 > what happens if the sequence numbers are out-of-sync (there is no protocol

Can you describe a scenario that they'd get out of
sync? I _think_ this is taken into account in section
5.3.2.

 > a standard technique e.g. HMAC-MD5 ....

The actual crypto stuff isn't complete and needs
work. There were some odd considerations that I
can't think of off the top of my head of why a
standard HMAC wasn't the right thing, (NAT
traversal considerations? it was something weird).

 > agent directly with a message?

I think in the most recent version I nuked the hop-by-hop
option in favor of an anycast address.

 > hence i have some doubts that the homeless scenario is really useful.

Useful... questionable. Inevitable... definitely. The
problem is that if there isn't a HA between "MN"
and CN, then the "MN" will receive the queries,
etc. You can consider this a bug or a feature. The
bug is if it's a non-mobile attacker trying to
create bindings on CN. This scenario needs to be
considered (and is in the draft). But it's also
something of a feature too. Maybe not a great one,
but it falls out as a natural consequence.
 
 > number then it may be possible - but i think that this is not described

Yes, I think that in the most recent version using
anycast, I made the cookies stuff extensions of
the BU itself. I'm not sure that that is clear in
the draft, but it should be made to be clear if
not. I have another draft which explicitly
requires that the BU be self-describing (to use
ESP for BU's).

		thanks, Mike