[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-van-beijnum-multi6-odt-00.txt

On 14-jan-04, at 22:06, Brian E Carpenter wrote:

I didn't include address rewriting in routers in ODT because although
the idea is very interesting, I don't think the potential gain is big
enough to justify all the additional trouble.

And that is an architectural choice the WG may have to make at some point.

Yes. I think it helps to have non-too-dissimilar approaches that do and don't include this to be able to see what the consequences of including it are.

But in any case, I don't see how it helps. You
can't tell by looking at an address whether it's been rewritten, so
you can't tell if it's OK for checksum purposes.

Which checksum do you mean here?

Any, really. We use addresses in TCP checksums or crypto checksums, and when
they get NATted things break unless somebody knows to recreate the checksum.

I thought I was reasonably clear about this... In order to maintain compatibility with most hardware checksum calculation offload mechanisms, the TCP and UDP checksums are always recomputed such that each TCP or UDP packet has a valid checksum as computed using the addresses present in the packet. Non-TCP and -UDP packets aren't changed because in this case the ODT implementation would have to be aware of *every* upper layer protocol. The ODT hash/checksum is only calculated over the ODT header, so the addresses are irrelevant here. IPsec authentication information isn't changed by ODT, but IPsec processing at the receiver happens after ODT has replaced the outer / locator addresses with the inner / identifier addresses so this doesn't affect regular IPsec operation. Obviously someone in the middle who does know the keys but isn't aware of ODT will see IPsec AH packets with invalid hashes.

As for NAT+ODT+IPsec, this isn't going to be easy. If the initial session is NATed, then IPsec won't really work but that's old news. So let's assume the initial session uses public addresses and only the backup address for one host is NATed. So:

- host A has initial (public) address A1 and backup (NATed) address A2 which B sees as X
- host B has initial (public) address B1 and backup (public) address B2

When ODT kicks in, B announces B2 to A1 and A announces A2 as an implicit address to B1, so B sees X. (Aside: will the NAT box do its thing for sessions for which it hasn't seen the initial SYN?) A checks out B by sending A1 -> B1, A1 -> B2, A2 -> B1, A2 -> B2. B replies with B1 -> A1, B2 -> A1, B1 -> X, B2 -> X. (Hm, rethink this, maybe all the replies shoud be B1 -> A1.) Then B initiates the same thing the other way around.

So after 18 packets have been sent A knows which addresses of B it can reach from which of its own addresses, and which source/destination combos B is prepared to handle. The same the other way around. If A and B are now communicating using IPsec but A1 -> B1 stops working, A may try A2 -> B2. So the TCP layer on A generates a packet with an A1, B1 TCP checksum, and an A1, B1 IPsec AH hash. The ODT layer picks up this packet and slaps on the addresses A2, B2. If the packet is encrypted using IPsec ESP, that's the end of it as the resulting packet isn't TCP or UDP (anymore). However, if only IPsec AH is used, the TCP header is still visible so the TCP checksum is recalculated with A2, B2 in the pseudo header. The packet is transmitted and then ends up in the NAT box. The NAT box replaces A2 with X and also recalculates the TCP checksum. Then the packet is received by B. If B employs checksum offload in the NIC, the NIC sees a valid X, B2 checksum. The ODT layer recognizes the X, B2 address pair and remaps this to A1, B1. The TCP checksum is updated to reflect the address change. Then the packet is handed off to the IPsec layer. IPsec AH is done over the packet and succeeds because all the fields defined as immutable that were in fact mutated were changed back to their original values.