Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4

From: Fred Templin <[email-masked]>
Date: Tue, 02 Sep 2003 11:11:35 -0700

Follen, Stephen wrote:

>On one hand, yes, this would be a packet being filtered,
>suggesting that it should be dropped silently;
>
>however, the "filter" here is not something purposely set
>up by a system admin - its not a firewall or similar.
>The filtering here is happening because of the
>incomplete configuration of a tunnel - more like a
>broken link, where a DU would be appropriate.
>
If the decapsulator (and filtering node) B sends the DU as an IPv6/IPv4
encapsulated packet to A who was the encapsulator of the original packet,
it should be OK *provided* the IPv6 dst of the DU (which is the same as
the IPv6 src of the original packet) is one of A's IPv6 addresses. 
Otherwise,
A might forward the DU onward to some unsuspecting node C, i.e., if the
IPv6 src of the original packet was spoofed.

>I'm not sure about the security issues, hopefully
>someone more qualified in that area can chime in here...
>
I think it might be nice for A to learn that B is dropping the packets due
to ingress filtering, but I don't see a way to send a DU that is guaranteed
to stop at A and not be forwarded onward to some unsuspecting node C.
Do you?

Fred
[email-masked]

---

From: "Follen, Stephen" <[email-masked]>
Date: Tue, 2 Sep 2003 09:26:02 -0400

-----Original Message-----
From: Fred Templin [mailto:[email-masked]] 
Sent: Friday, August 29, 2003 4:35 PM
To: Follen, Stephen
Cc: [email-masked]
Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4

On further consideration, isn't the situation here logically equivalent 
to the
case of  the filter occurring somewhere in the network between the IPv6 
source
and the tunnel decapsulator; for example, at a firewall? What do 
firewalls do
when they discard a packet due to filtering? I don't know this for 
certain, but
don't they simply do a silent discard w/no ICMP sent back to the source?
In any event, I don't see why the tunnel decapsulator should do anything
different. Your thoughts?

Fred
[email-masked]

P.S. I could be wrong, but wouldn't sending back an ICMP DU run the risk
    of a reflection attack when the original packet uses a spoofed IPv6 
source
    address?

Follen, Stephen wrote:

> A question related to Ingress Filtering of decapsulated [tunneled]
> IPv6-in-IPv4 packets:
>  
> Section 3.6 of RFC 2893, IPv6 Transition Mechanisms, indicates that
> "... a decapsulated packet MUST NOT be forwarded unless the node has 
> been explicitly configured to forward such packets ..." and in section

> 4.3 "The decapsulating node MUST verify that the tunnel source address

> is acceptable before forwarding decapsulated packets ..."
> (the more recent draft-ietf-v6ops-mech-v2-00.txt, Basic IPv6 
> Transition Mechanisms provides similar guidance in sections 3.6, 3.9 
> and 4.1)
>  
> The question is what to do in the case that the packets are filtered
> / not forwarded:
>  
> 1. silently drop the packet - simple, but provides no feedback of the
> "broken link" (see below);
>  
> 2. send a v4 ICMP, Destination Unreachable (DU) - this seems like a
> poor approach since
>    (a) the IPv4 [tunnel endpoint] address was reached and
>    (b) a response may never get back to the originating IPv6 host
>        (section 3.4 of RFC 2893 indicates that an encapsulating node 
> MAY generate
>        a v6 ICMP when it gets a v4 ICMP back);
>  
> 3. send a v6 ICMP DU - this probably won't get back to the originating
> host either since
>     its unlikely that there's a path back to it (the do not forward 
> decision occurred because
>     the tunnel was not set up);
>  
> 4. send a ICMPv6 DU encapsulated in IPv4 - there is enough information
> in the incoming
>     IPv6-in-IPv4 packet to generate this, and it would likely get back

> to the originating host,
>     but to do so would effectively send a packet via a tunnel which 
> had not been configured.
>  
> "broken link" - [in the case of legitimate traffic] the filtering
> which would occur here is not
> the result of a specifically configured ingress filter, rather, it is 
> the result of not fully configuring
> the tunnel; a tunnel is effectively a link, so I see the filtering to 
> be similar to a broken link.
>  
> Any thoughts would be greatly appreciated.  - Thank you
>  
> Steve Follen
> [email-masked] <mailto:[email-masked]>
>  
>  
>  
>