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

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



Hi Brian,

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

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

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