Subject: [BEHAVE] AD comments on draft-ietf-behave-icmp-04

From: Magnus Westerlund <[email-masked]>
Date: Tue, 04 Sep 2007 15:37:47 +0200

Hi,

I have now done my AD review. Here are my comments.

1. Section 1, third paragraph:

"Traditional NAT inherently mandates a certain level
   of firewall-like functionality. However, firewall functionality in
   general or any other middlebox functionality is out of the
   scope of this document."

I assume that the firewall-like behavior is the filtering behavior. I
think there might be some benefit to express it that way and to refer to
the terms in UDP NAT RFC.

2. Section 2, last sentence:

"A NAT MAY drop
   or appropriately handle a post-1122 ICMP messages. "

I think a normative statement of this type do not belong in the
terminology section. Please find a better place to locate it.

3. Section 3.2, REQ-2:

  "Setting the ICMP NAT session timeout to a very large duration (say,
   240 seconds) could potentially tie up precious NAT resources such as
   query mappings and NAT Sessions for the whole duration. On the other
   hand, setting the timeout very low can result in premature freeing
   of NAT resources and applications failing to complete gracefully.
   The ICMP Query session timeout needs to be a balance between the two
   extremes. 60 seconds timeout is a balance between the two extremes.
   ICMP query session timer MUST not expire in less than 60 seconds. We
   RECOMMEND however that the administrator(s) be allowed to configure
   the timer.

   REQ-2: An ICMP Query session timer MUST NOT expire in less than 60
   seconds.
   a) It is RECOMMENDED that the ICMP Query session timer be made
   configurable."

Once more we use NATs as a motivation to redefine what our constants
are. I can't understand the motivation behind making the requirement to
anything other than 2xMSL, i.e. 240 s. I fear that people will start use
lower values for MSL, due to the fact that they know that if there are a
NAT there is anyway no possibility for the packet to live. Yes, it is a
long time, but MSL exist for being a real outer boundary for how long
packets can live.

If a NAT get too many querys aren't there better ways to deal with that?
After all we are talking about requests comming from the internal side
of the NAT. Are there ways of providing error response to query style ICMP?

4. Section 4.1,
"This
   requirement is meant primarily for future applications. Current
   applications may not be checking for mismatched checksum."

I don't find these two sentences providing much benefit. I think it is
well motivated that payload validation checking is supported for current
and any future applications.

5. Section 4.2, first paragraph:
"Section 4.3 of RFC 3022 describes the fields of an ICMP error
   message that a NAT device translates. In this section, we describe
   the requirements a NAT device MUST conform to while performing the
   translations. Requirements identified in this section are necessary
   for the current applications to work correctly."

I interpret this as an normative reference. This would be a normative
reference from a BCP to a informative document, which I like to avoid.
Can we please rework this, for example by including how the translation
is done in this document instead.

6. Section 4.2.2, page 12, second paragraph:

   In addition, if the ICMP Error payload contains ICMP extensions
   ([ICMP-EXT]), the NATs are encouraged to support ICMP extension
   objects.

I think this sentence is strangely formulated. Please reword it.

Please comment if there are any unclarities or disagrement. But I do
expect a revision.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 17 Sep 2007 07:09:32 -0700 (PDT)

Magnus,

Thank you for the review. Apologies for the delay in responding. Please see my
responses inline below.

regards,
suresh

> the terms in UDP NAT RFC.

[suresh] OK. Would the following rewording work for you?

  "Traditional NAT inherently mandates firewall-like filtering behavior 
   [BEH-UDP]. However, firewall functionality in general or any other 
   middlebox functionality is out of the scope of this document."

> terminology section. Please find a better place to locate it.
[suresh] OK. I will move this to the first paragraph of section 8 (Summary of
Requirements).

> long time, but MSL exist for being a real outer boundary for how long
[suresh] I didnt understand the comment - "I fear that people will start use
lower values for MSL, due to the fact that they know that if there are a NAT
there is anyway no possibility for the packet to live."  Why is there no
possibility for the packet to live when there is a NAT?

There was much discussion on the ICMP timeouts on the list.  RFC 4787 (Req-5a)
also provided some precedence on this. The WG agreed on 60sec timeout. In
practice, users of query based applications (ex: ICMP ping and ICMP traceroute)
are likely to be impatient if the response packets took longer than 60 secs.
240 secs., woudl be longer than even the udp TIMEOUT (120secs).

> of the NAT. Are there ways of providing error response to query style ICMP?

[suresh] Most NAT sessions are initiated from the internal side, anyways,
right. In that sense, ICMP query based sessions are no different from other NAT
sessions. NATs could respond with  ICMP destination unreachable message (REQ-8)
when out of resources.

> and any future applications.

[suresh] I could remove the two sentences. Woudl that work for you?

> is done in this document instead.
[suresh] Implicitly, both [BEH-UDP] and [BEH-TCP] also defer to RFC 3022 for
the NAT translation. In that sense, this docuemnt is no different. Would it
work for you if I simply removed the first sentence.  

> I think this sentence is strangely formulated. Please reword it.
[suresh] would the following rewording work for you? 

   ICMP Error payload may contain ICMP extension objects ([ICMP-EXT]). 
   NATs are  encouraged to support ICMP extension objects.

> Please comment if there are any unclarities or disagrement. But I do
[suresh] If you are Ok with my responses, I could get the next rev out shortly.
Thanks.

regards,
suresh

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Sep 2007 17:09:57 +0200

See inline

>    middlebox functionality is out of the scope of this document."

Yes.

> [suresh] OK. I will move this to the first paragraph of section 8 (Summary of

Will that not be strange without having a requirement that only is
listed in the summary?

> possibility for the packet to live when there is a NAT?

Well, the packet may live, but the response will never reach the
requestor if the context needed to translate it has been timed out. That
is why I fear that one might start optimizing these timers for something
else.

> 240 secs., woudl be longer than even the udp TIMEOUT (120secs).

Well, the WG can consider my displeasure with this, but I do accept the
WG consensus on it.

> sessions. NATs could respond with  ICMP destination unreachable message (REQ-8)

Okay.

> [suresh] I could remove the two sentences. Woudl that work for you?

Yes, that seems to be a okay solution.

> work for you if I simply removed the first sentence.  

Well, I don't see how removing the sentence will make things better. It
seems that we likely need to apply RFC 3967 exception on this reference.
So please upgrade it to a real refence in the normative part.

>    NATs are  encouraged to support ICMP extension objects.

Yes.

Cheers

Magnus Westerlund

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 18 Sep 2007 07:05:33 -0700 (PDT)

Magnus,

Thank you for your responses. Please see my comments inline. I am only keeping
items needing additional clarity. Thanks.

regards,
suresh

<.... stuff deletec ...>

> Will that not be strange without having a requirement that only is
[suresh] I will preface by saying that the document focuses on the requirements
concerning ICMP queries and ICMP error messages. SO, i think, it is Ok to
follow this up and say that "a NAT MAY drop or appropriately handle a post-1122
ICMP messages". All this would be in the top paragraph of the summary section.

> NAT
[suresh] Ah, now I understand what you meant.

> Well, the WG can consider my displeasure with this, but I do accept the
[suresh] Got it. Thanks.

<... stuff deleted>

> So please upgrade it to a real refence in the normative part.

[suresh] You are saying that I should move [NAT-TRAD] to the normative section,
right. 

Thanks.

regards,
suresh

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Sep 2007 10:33:12 +0200

> ICMP messages". All this would be in the top paragraph of the summary section.

Okay, lets see how it looks.

Yes.

Cheers

Magnus Westerlund

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 19 Sep 2007 22:17:34 -0700 (PDT)

Magnus,

Thanks for all your comments and responses. I will fold in your feedback in the
next rev of the draft.

regards,
suresh

--- Magnus Westerlund <[email-masked]> wrote:

> >>> [suresh] OK. I will move this to the first paragraph of section 8
> (Summary
> >> of
> >>> Requirements).