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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jan 2004 07:55:30 +0100

Two comments.

1. It seems to me that if you ignore the way each of them is described, there
is actually a very strong resemblance between ODT and NOID. In effect they both
treat the first address used for a session as the ID, and dynamically switch
to using alternative addresses as the locator, with a stateful shim concealing
the switch from upper layer protocols. Am I confused?

The only real difference is that NOID turns out to need a rewrite OK/Not OK flag
in the IP header and ODT doesn't, but it does need an ODT protocol exchange.
(Which has the consequence that ODT claims to work for IPv4 too.)

If NOID didn't include the case of a router doing the rewrite in flight, it
wouldn't need that flag anyway. So the crude description of ODT is as a 
degenerate case of NOID.

I think the security issues are therefore very similar too. In fact
the discussion between Iljitsch and Marcelo would largely apply to
NOID.

2. One remark that I really don't understand:

> 8 Tunnel Creation
...
>     1. Host A announces its addresses to host B
> 
>     The addresses may be of different address families. Each address is
>     accompanied by preference information. In order to not unnecessarily
>     trigger NAT incompatibility, a "current source address" address
>     family is used to refer to the source address in the IP packet,
>     which may have been rewritten. 

Firstly, we aren't designing for IPv6 NATs, so this would only apply
to the IPv4 case, right? 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. So the fact that you
know an address *might* have been rewritten is no use, as far as I can see.
The only useful information is to know for sure what the address was at
the source, without even caring whether it has been rewritten in the
active IP header. And in ODT (as in NOID) that information is in local
state at the destination.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 Jan 2004 14:06:42 +0100

On 14-jan-04, at 7:55, Brian E Carpenter wrote:

> 1. It seems to me that if you ignore the way each of them is 
> described, there is actually a very strong resemblance between ODT and 
> NOID. In effect they both treat the first address used for a session 
> as the ID, and dynamically switch to using alternative addresses as 
> the locator, with a stateful shim concealing the switch from upper 
> layer protocols. Am I confused?

Yes, this part is the same. However, I wouldn't say that

> the crude description of ODT is as a degenerate case of NOID.

The shim idea wasn't new in NOID either.

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. Also, NOID uses a 
three-way handshake while ODT uses a model where each end announces 
information to the other end that may or may not be ignored.

> to the IPv4 case, right?

I hope so.  :-)

> But in any case, I don't see how it helps. You
> you can't tell if it's OK for checksum purposes.

Which checksum do you mean here?

Iljitsch

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jan 2004 22:06:37 +0100

> > the crude description of ODT is as a degenerate case of NOID.

No, I didn't think you would say that :-) But I think when we start
the architectural analysis, ODT and NOID will come out very similar.

> The shim idea wasn't new in NOID either.

Certainly not.

> enough to justify all the additional trouble. 

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

> Also, NOID uses a

Yes, so the state machines are a bit different too.

> 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.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 15 Jan 2004 10:48:32 +0100

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

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.

> they get NATted things break unless somebody knows to recreate the 

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.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 15 Jan 2004 15:58:04 +0100

Hi Brian,

> described, there

I am not sure about this NOID ODT similarity...

IMHO the big difference is the mechanism to validate addresses to be used in
a communication.

ODT by design beleives the addresses that the other end of the communication
claims to have as its own addresses. Moreover, an add address mesage can be
sent and accepted if properly validated by a return routability like
procedure.

NOID is IMHO conceptually very different (perhaps in practice the difference
it is not so big, i'll come back later)
In NOID, the valid addresses of an endpoint are obtained from a trusted
third prty i.e. the DNS
So a NOID endpoint doesn't has to beleive what the other endpoint is
claiming to have as available addresses, but it contacts the third party and
obtains the addresses from it. (Note that even when the "server" node (lack
of a better way to call it) also verifies the addresses from the "client"
node against the DNS through a reverse+direct lookup)

That is, IMHO, the trust model is completely different.

However, the DNS is also susceptible to time shifted attacks. i.e. if you
fake the DNS query you can store malicious state in a host. But, this is
already here now in fixed IPv4 internet, so not a new attack here. Besides,
NOID allows that when secure DNS is available the security of the solution
improves.

In summary, IMHO the concepts are quite different and the trust model is
quite different.
In practice, the real attacks can be similar.

I find ODT much more similar to a MIP style solution, where all the nodes
are peers and you have to trust to all the nodes that you talk with.

Regards, marcelo