Subject: RE: ingress filteing problem

From: "Christian Huitema" <[email-masked]>
Date: Sun, 14 Mar 2004 10:52:15 -0800

> By "NAT" I trust we mean reversible NAT... this WG is not about to
> suggest traditional NAT for IPv6, I don't think. Solutions that
rewrite
> the locator(s) and then set them back to their original value before
> final processing at the destination will not break IPSEC and will not
> require any transport checksums to be recalculated.

What you describe here is "rewrite at both ends", which supposes that
both ends are somehow upgraded. My contention is that the solution to
ingress filtering should be "single site", i.e., not force any special
processing on the other end, which may well be running a non-updated
IPv6 network. Single site solutions allow sites to multi-home at will;
multi-site solutions create a zero-day issue.

Think of the following case: vanilla IPv6 host A sends a TCP/SYN to
address B:X of host B, multi-homed to providers X and Y. Host B sends a
SYN-ACK back to A, from source B:X. The internal routing is such that
the packet is sent through exit Y, and fails ingress filtering at Y.

Clearly, in my example, if A retries a TCP connection using address B:Y,
the connection will eventually succeed. However, the trial and error has
a cost. And some dumb applications do not even retry all addresses. In
this example, B is "punished" because its site is multi-homed.
 
> Of course, how the source knows which rewrite will be accepted by
> the relevant ingress filters is a little piece of magic TBD.

With the same amount of magic, you probably can devise a single site
solution.

-- Christian Huitema

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 15 Mar 2004 10:59:30 +0100

> IPv6 network.

Yes, additionally, a solutions that supports "old" IPv6 hosts (i.e. without
any specific multihoming support) within the multihomed site would be
preffered, i guess, since it doesn't impose a flag day in the multihomed
site when all the internal hosts have to be upgraded.

So backward compatibility on external hosts (and sites) and also in internal
hosts

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Mar 2004 11:43:17 +0100

> So backward compatibility on external hosts (and sites) and also in internal

Of course I agree that the solution should not make things *worse*
than today for non-multihoming-aware sites. But the ingress filtering
problem that Christian describes surely exists today on such sites,
which have no mechanism for choosing the appropriate exit router.

   Brian