Jari Arkko wrote:
The sequence number works in
this case as a sort of a weak cookie, which as you point out,
the attacker doesn't know. Perhaps this could be enough.
An update: It was pointed out to me by Tuomas that we don't want to repeat
the problems we have with TCP sequence numbers as cookies. Sequence
numbers are too predictable. Instead, a cookie should be added.
And it does look like the approach #3 is preferred by many folks,
on the basis of giving some protection but still being easily understood
and analyzed.
The one attack that this doesn't protect against is someone on the
visited network who can see the cleartext C2 going to the CN, and could
spoof an answer BA. However, an attacker on this link could also do lots
of other bad things, such as sending TCP RSTs on the traffic between
the MN and the CN.
Question: in BR, we don't have a sequence number. If the BR
is more like a binding refresh request, should we add the sequence
number also there?
One idea is that since we have a very BR-like functionality already in
BM, and since there is no way we can authenticate a BM, we should just merge
this functionality and not have any authentication.
Jari
| 
