RE: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4

["Follen, Stephen" <sfollen@enterasys.com>]

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.

I'm not sure about the security issues, hopefully
someone more qualified in that area can chime in here... 


 


-----Original Message-----
From: Fred Templin [mailto:ftemplin@iprg.nokia.com] 
Sent: Friday, August 29, 2003 4:35 PM
To: Follen, Stephen
Cc: v6ops@ops.ietf.org
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
ftemplin@iprg.nokia.com

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
> sfollen@enterasys.com <mailto:sfollen@enterasys.com>
>  
>  
>  
>