[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4
Pekka,
I'd rather not get into specifics on your questions just yet in the interest
of not bringing confusion into the discussion. But, I have one question
relative to a message you posted to this thread on 09/04/2003 where
you said:
> 1) "node receives packets from an unknown ("unconfigured") tunnel endpoint"
>
> ==> the node should _not_ "acknowledge" the existence of the tunnel,
> otherwise this could be used to probe the acceptable tunnel endpoint
> addresses. That is, node should either silently discard the packet, or
> send an ICMPv4 Protocol Unreachable message.
My question is, why should the node send ICMPv4 *Protocol* Unreachable
instead of ICMPv4 *Port* Unreachable? To send "Protocol Unreachable" would
seem a bit disingenuous in that it would seem to indicate to the peer that
the node's IPv6 stack is down and that future attempts to establish a tunnel
with the node would be unsuccessful. "Port Unreachable" would indicate
that the node's IPv6 stack is up, but that the tunnel endpoint was not
configured.
In either case (Protocol vs. Port Unreachable), malicious nodes can probe
for acceptable tunnel endpoints, so I see no little value in sending
Protocol Unreachable from a security standpoint and the potential for
interoperability issues if a legitimate peer wrongly infers that the node's
IPv6 stack is down.
Comments?
Fred Templin
On Tue, 7 Oct 2003, Fred Templin wrote:
> Pekka Savola wrote:
> >Huh? Which node do you refer by decapsulator -- the one sending ICMPv6
> >DU, or the one receiving it (over the tunnel) and decapsulating it?
>
> The former (i.e., the one sending ICMPv6 DU). But, you seem
> to be assuming that it would be sent back over the bidirectional
> tunnel from which the original packet arrived. I am not.
What are the scenarios where you wouldn't use bidirectional tunneling? It
has been considered to kill unidirectional tunnels from trans-mech-bis,
and it would be useful to know whether they're really relevant.
> >If the former, I don't really understand how sending a reply would help.
>
> Well, it could elicit an ICMPv6 Redirect from a router that would
> provide information satisfying future ingress
filter checks in the
> decapsulator, it could provide a traceback mechanism to detect
> IPv6 source address spoofing attacks, etc.
Do you have more information on these? I fail to see how Redirects would
help here, as the source address selection is already done at that phase,
and Redirects only look at the destination addresses, as far as I've
understood.
I'd like to understand how useful this would be before going forward with
it. Sending packets to ingress-filtered sources may only aggravate the
problem.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings