> - 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 PROTECTED] --------------------------------------------------------------------
