[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comment on unmanaged analysis presentation/doc
- To: v6ops@ops.ietf.org
- Subject: Re: comment on unmanaged analysis presentation/doc
- From: Rob Austein <sra+v6ops@hactrn.net>
- Date: Tue, 24 Sep 2002 11:43:18 -0400
- Delivery-date: Tue, 24 Sep 2002 08:44:30 -0700
- Envelope-to: v6ops-data@psg.com
- User-agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4(Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0(HANANOEN)
At Tue, 24 Sep 2002 12:08:03 +0200 (CEST), Erik Nordmark wrote:
>
> Any IPv4 ingress filtering will happily let such packets through since
> the IPv4 src is not spoofed.
> The 6to4 router at the victim's site will blindly decapsulate and
> loose all track of the IPv4 source.
There's a piece missing from this picture. Every packet filtering
system I have ever used allows one to make filtering decisions based
on the interface on which a packet has been received or will be
transmitted.
So, conceptually, if you can divide the total set of interfaces into
discrete sets and write down straightforward rules about which
interfaces may be used as receive and transmit interfaces when
forwarding packets, this becomes a small matter of writing (a whole
bunch of) filtering rules.
For example, in the KAME 6to4 edge router I'm using right now, the
rule is (conceptually) simple: if the packet came in on an external
interface, it may not be forwarded back out an external interface. In
KAME it happens that encapsulation shows up as one of several types of
virtual interfaces, but the other obvious alternative implementation
just keeps track of the original interface all the way through
decapsulation. It works either way, so long as you don't end up with
any interfaces that you can't assign to exactly one partition.
Relays are a harder problem, because as far as I know there is no
useful partition one can apply to a relay's interfaces. I'd like to
be proven wrong about this.