| Newsgroups |
gmane.ietf.mobike |
| Message-ID |
<[email protected]> |
Tero Kivinen wrote:
> When you are sending packets outbound you do lookup from SPD-S
> based on the selectors (I1 or I2) and you get SA based on
> that. Then in the SA there is the SPI and destination IP to be
> used for the other end. Then you simply make tunnel
> encapsulation and send the packet along. I do not really see
> what is the problem there?
<snip>
> The 4.4.2 of the RFC2401bis says:
> ...
> For outbound processing, each SAD entry is pointed to by
> entries in the SPD-S part of the SPD cache.
It seems the issue is about how exactly this "pointing" is
implemented. I think Tuomas was saying that storing the (remote
tunnel header IP, remote SPI) pair is not a right way to implement
this pointing, since it does not always uniquely identify an
outbound SA.
And as you pointed out, this is not new to MOBIKE: it obviously
happens with NAT Traversal, but can happen without NAT-T too (one
peer goes away without deleting the SAs; another peer comes in,
gets the same address, and creates new SAs with that).
I'm not sure what, if anything, the spec should say about this.
2401bis itself is quite clear that it's describing a nominal
model, and is not intended to match any real implementations.
Clearly there are several ways to implement the pointer, depending
on e.g. how exactly the required information is stored (there's no
requirement that an implementation has two different data
structures, one called SAD and another called SPD), and what
programming language is used. But the details of C pointers,
Java references, Prolog clauses, or LISP expressions are really
beyond the scope of 2401bis (and MOBIKE).
So, my gut feeling would be that if something needs to be said
about this, the best place would be 2401bis, since the issue
is not specific to MOBIKE. Also, it's an implementation detail,
so there's no need to specify one single way to do it.
However... I think some IPsec implementations have actually got
this wrong. Mohan mentioned Linux, and based on a quick look,
yes, it seems the 2.6 kernel IPsec uses (remote tunnel header IP,
remote SPI, protocol) as the outbound SA lookup key. So maybe
it would be worthwhile to mention this, perhaps in a non-normative
"implementation considerations" appendix?
Best regards,
Pasi