ingress filteing problem

["Kanchei Loa" <loa@ieee.org>]

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
loa@ieee.org

> -----Original Message-----
> From: owner-multi6@ops.ietf.org
> [mailto:owner-multi6@ops.ietf.org]On Behalf Of Christian Huitema
> Sent: Thursday, March 11, 2004 7:21 PM
> To: Erik Nordmark; Iljitsch van Beijnum
> Cc: multi6@ops.ietf.org
> Subject: RE: Source address selection insufficient?
>
>
> > > > 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
>