Subject: RE: Source address selection insufficient?

From: "Christian Huitema" <[email-masked]>
Date: Thu, 11 Mar 2004 18:20:30 -0800

> > > Once you modify the hosts at both ends why not also provide
connection
> > > rehoming?
> >
> > Sure. But how does this relate to the problem at hand currently?
> 
> I'm trying to understand whether we need ingress filtering avoidance
> (such as the general case of source-based routing) even once we
> have a connection rehoming solution.
> 
> One reason we might need that is when only one end of the
communication
> implements multi6.

This is indeed a scenario that we must support! 

I personally find that a solution to ingress filtering is the necessary
first step to multi-homing.

The normal approach to multi-homing is multi-addressing: provide each of
the site's hosts with the possibility to configure multiple IPv6
addresses, from each of the providers' prefixes. But in the absence of a
proper solution to ingress filtering, a site doing that will experience
a loss in service: after multi-homing, some connections will
mysteriously fail. This is bad. 

As an industry, we should consider the multi-homing sites as our best
customers: they are buying more services from more providers, deploying
more equipment, probably running more software. The minimum we can do
is, make sure that someone who buys more does not experience a loss in
service!

-- Christian Huitema

---

From: "Kanchei Loa" <[email-masked]>
Date: Fri, 12 Mar 2004 10:24:26 -0700

indeed, the ingress filtering is a separated problem space from other multi6
solutions. No matter what we choose to implement at the host side, when the
IP packet with (src/dst) locators is routed to "wrong" exit router, the ISP
will drop the packet because of access control policy.

The following are solutions that won't break non-multi6 TCP and UDP (only
one end of the communication  implements multi6):

(1) Match the source address to ISP.

(1.1) Create or modify IGP to colored default route with a source address
prefix and modify each router to forward packets based on matching default
route and source address prefix.
(1.2) Create and maintain N**2 tunnels among N exit routers. Modify those
routers to exchange source address prefix through the tunnel and forward
packets through the tunnel to the "correct" ISP (incoming ISP for the return
packet) based on matching source address prefix.
(1.3) Create and maintain N VLAN for N ISP. Each host create a virtual
interface in order to participates in the VLAN where the source address is
acquired. The host sends packets to a VLAN based on matching source address
prefix.
(1.4) Create and maintain N VPN for N ISP. Each host create a virtual
interface in order to participates in the VPN where the source address is
acquired. The host sends packets to a VPN based on matching source address
prefix.

(2) Fake the source address to ISP.

(2.1) The site is assigned internal address (site-local address or others);
create and maintain N**2 tunnels among N NAT for N ISP. The NATs
exchange/share mapping state through the tunnel and  forward packets through
the tunnel to the "correct" ISP (incoming ISP for the return packet) based
on matching mapping state.
(2.2) The site is assigned internal address (site-local address or others)
and combine NAT with (1.3). The host makes sure that the same virtual
interface is used by a address pair (src/dst and dst/src).
(2.3) The site is assigned internal address (site-local address or others)
and combine NAT with (1.4). The host makes sure that the same virtual
interface is used by a address pair (src/dst and dst/src).

Before we talk about pros, cons and other issues, It is beneficial that we
have a complete list of possible solutions for ISP ingress filtering that
won't break non-multi6 TCP and UDP (only one end of the communication
implements multi6). My opinion is that any multi6 solution that breaks
existing non-multi6 TCP and UDP at another end of the connection will face
deployment difficulty.

Am I missing something?

---------------
Kanchei Loa
[email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Christian Huitema
> Sent: Thursday, March 11, 2004 7:21 PM
> To: Erik Nordmark; Iljitsch van Beijnum
> Cc: [email-masked]
> Subject: RE: Source address selection insufficient?
>
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 12 Mar 2004 20:15:44 -0600

I'm probably late to the party, but don't (1) and (2) break
transport-mode IPsec?

So IPsec transport mode would be a non-goal?

Just curious,

Spencer

From: "Kanchei Loa" <[email-masked]>

---

From: "Kanchei Loa" <[email-masked]>
Date: Sun, 14 Mar 2004 00:02:59 -0700

> I'm probably late to the party, but don't (1) and (2) break

(1) depicts schemes to forward IP packet to the "correct" ISP such that the
source address is matching ISP's ingress filter. There is no IP src/dst
rewriting during the process. So, transport-mode IPsec won't be affected.

(2) use NAT to rewrite the locators (IP src/dst) in order to pass through
ISP's ingress filter and provides consistent src/dst address pair for
non-multi6 host at another end of the communication. It is no better (or
worse) than existing NAT deployments regarding IPsec compatibility issues.

> So IPsec transport mode would be a non-goal?

I can't speak for the WG. But I believe one of the goal is not to introduce
new threats.

This is quote from "Goals for IPv6 Site-Multihoming Architectures (RFC
3582)".

4.  Security Considerations

   A multihomed site should not be more vulnerable to security breaches
   than a traditionally IPv4-multihomed site.

   Any changes to routing practices made to accommodate multihomed sites
   should not cause non-multihomed sites to become more vulnerable to
   security breaches.

--------------
Kanchei Loa
[email-masked]