Subject: [BEHAVE] Additional comments on draft-ietf-behave-nat-icmp

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Oct 2008 15:11:18 +0100

Hi,

I did a review of what it really meant to follow the following text in
Section 7:

In addition, a NAT device is RECOMMENDED to conform to the following
   implementation considerations in [RFC1812]:
       d. TOS and Precedence, as described in Section 4.3.2.5 of
          [RFC1812],

the section of RFC 1812 reads like following:

4.3.2.5 TOS and Precedence

   ICMP error messages SHOULD have their TOS bits set to the same value
   as the TOS bits in the packet that provoked the sending of the ICMP
   error message, unless setting them to that value would cause the ICMP
   error message to be immediately discarded because it could not be
   routed to its destination.  Otherwise, ICMP error messages MUST be
   sent with a normal (i.e., zero) TOS.  An ICMP reply message SHOULD
   have its TOS bits set to the same value as the TOS bits in the ICMP
   request that provoked the reply.

   ICMP Source Quench error messages, if sent at all, MUST have their IP
   Precedence field set to the same value as the IP Precedence field in
   the packet that provoked the sending of the ICMP Source Quench
   message.  All other ICMP error messages (Destination Unreachable,
   Redirect, Time Exceeded, and Parameter Problem) SHOULD have their
   precedence value set to 6 (INTERNETWORK CONTROL) or 7 (NETWORK
   CONTROL).  The IP Precedence value for these error messages MAY be
   settable.

   An ICMP reply message MUST have its IP Precedence field set to the
   same value as the IP Precedence field in the ICMP request that
   provoked the reply.

As RFC 1812 talks about TOS and IP precedence and RFC 2474 redefined
these field the text is not correct. In addition there is a good
question about the traffic class marking recommendations in RFC 1812 is
relevant today. First the classes that are recommend are now made legacy
by RFC 2474. There is the class selector to deal with this to certain
degree, see RFC 4594. The second is if anyone really prioritize their
ICMP error messages to another class then what the traffic was. Some may
even send it with best-effort only to avoid DoS issues.

My personal suggestion on how to fix this is the following. Comments and
better suggestions are really appreciated. So replace the whole
reference to d. with a new paragraph saying the following:

The NAT SHOULD copy the diffserv class of the message that causes the
sending of an ICMP error message. A NAT MAY allow configuration of the
diffserv class to use for the different types of ICMP messages.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave