Subject: Re: Documents Ready for DS (RFC2473)

From: Erik Nordmark <[email-masked]>
Date: Fri, 3 May 2002 17:23:39 +0200 (CEST)

> - icmp message relay/translation (8) does not seem to be widely
>   implemented/operated, and could even be abused (open relay of packet - it
> is
>   not mentioned in security issues section).  if my observation is correct,
>   i'd suggest removing the rule.

Is your concern that in order to relay/xlate ICMP errors from routers
inside the tunnel the encapsulator
has to accept them independently of their source address?
(unlike data packets which would have their address verified against
the peer address of the tunnel).

If so, what threats can be caused in addition to those
that can be caused by the ICMP errors without any tunneling being used?
(I'm not sure there are any.)

Without any tunneling the sender needs to accept ICMP errors from any source
address since it doesn't know what routers are on the path
to the destination.

The only possible verification that can be done on e.g. an ICMP dest unreach
or an ICMP packet too big is to see if the packet in error is one
that the node has recently sent.
E.g. if it is a TCP packet one could envision verifying that the connection
exists and that the seq and ack numbers seem to be "recent". UDP
is harder especially without an IP id field.
But the point is that these techniques apply whether or not there was
a tunnel doing relay/xlate of ICMP errors.

  Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------