Philip,
Sorry, I missed your e-mail when it was posted. For some
reason, I did not see
this in my inbox until a kind soul refered me to it.
Anyways, sorry for the
delay. Please see my responses below inline.
regards,
suresh
> >X-ClientAddr: 72.232.205.74
> >From: Philip Matthews <philip_matthews magma.ca>
> >Date: Tue, 31 Oct 2006 16:25:03 -0500
> >To: Bryan Ford <bafordmit.edu>, Senthil
Sivakrishna <ssenthilcisco.com>,
> > Saikat Guha <saikatcs.cornell.edu>,
> > Pyda Srisuresh <srisureshyahoo.com>
> >X-Mailer: Apple Mail (2.752.2)
> >X-magma-MailScanner-Information: Magma Mailscanner
Service
> >X-magma-MailScanner: Clean
> >X-Spam-Status:
> >Cc: Dan Wing <dwingcisco.com>, Behave WG
<ietf-behavelist.sipfoundry.org>
> >Subject: [Ietf-behave] Comments on
draft-ietf-behave-nat-icmp-01
> >X-BeenThere: ietf-behavelist.sipfoundry.org
> >X-Mailman-Version: 2.1.9
> >List-Id: IETF Behave WG
<ietf-behave.list.sipfoundry.org>
> >List-Unsubscribe:
> <https://list.sipfoundry.org/mailman/listinfo/ietf-be
have>,
> >
> <mailto:ietf-behave-requestlist.sipfoundry.org?subject=unsubscribe>
> >List-Archive: <ht
tp://list.sipfoundry.org/archive/ietf-behave>
> >List-Post: <mailto:ietf-behavelist.sipfoundry.org>
> >List-Help: <mailto:ietf-behave-requestlist.sipfoundry.org?subject=help>
> >List-Subscribe: <https://list.sipfoundry.org/mailman/listinfo/ietf-be
have>,
> > <mailto:ietf-behave-requestlist.sipfoundry.org?subject=subscribe>
> >Sender: ietf-behave-bounceslist.sipfoundry.org
> >X-Greylist: IP, sender and recipient
auto-whitelisted, not delayed
> >by milter-greylist-2.0.2 (venus.xmundo.net
[201.216.232.56]); Tue,
> >31 Oct 2006 18:28:48 -0300 (ART)
> >
> >Dan Wing asked me to review
draft-ietf-behave-nat-icmp-01.
> >Below are my comments.
> >
> >- Philip
> >
[suresh] Thank you for reviewing.
> >Major comments
> >==============
> >
> >* (Section 3.2)
> > Is the query session freed up when the query
response is received
> >by the NAT,
> > or does it stay active for the duration of the
timer? If the former,
> > then the case for having having the mapping of
the query identifier
> > be endpoint-independent seems weakened.
> >
[suresh] ICMP query request/response sequence is similar to
the UDP datagram
request/response sequence. As such, the ICMP query session
idle timeout is
similar to the UDP session idle timeout.
> >* In section 4.2.2, the document contains the
following paragraph
> > "In the outer header, the
destination IP address will remain
> > unchanged, as the IP addresses for
Host-x is already in
> > the external
> > domain. If the ICMP error message is
generated by Host-y, the
> NAT
> > a NAPT device must simply use the NAT
Session to translate the
> > source IP address Host-y to Host-y'.
However, if the ICMP error
> > message is originated by the
intermediate node Router-y, and the
> > NAT device is a Basic NAT ([NAT-TRAD]),
and it has active
> mapping
> > for the IP address that sent the ICMP
error, the NAT device MUST
> > translate the source IP address of the
ICMP error packet with
> the
> > public IP address in the mapping.
Otherwise, the NAT device MUST
> > simply use its own IP address in the
external domain to
> translate
> > the source IP address."
> > It took me a few re-reads to understand what
this paragraph was
> >getting at.
> > If I understand correctly, it is talking about
the address that
> >should be
> > used as the public IP address in the ICMP Error
packet in the case
> >where the
> > NAT has more than one public address.
> > If the ICMP packet comes from the host, then
the paragraph says that
> > the choice is easy: use the public IP address
in the mapping for the
> > TCP or UDP session that caused the error.
> > The problem is when the ICMP error packet comes
from an intermediate
> > router behind the NAT. In this case, the above
paragraph talks
> > about an "active mapping for the IP
address that sent the ICMP
> >error".
> > The question is: What sort of mapping?
[suresh] Unlike NAPT, a Basic NAT has a pool of public IP
addresses and maps a
public IP address from the pool when a private host
initiates a new session via
the NAT. Unlike NAPT, which perfroms endpoint mapping, a
Basic NAT performs
address mapping. Subsequent to an address mapping, while the
mapping is active
on the Basic NAT, the NAT reuses the mapping for all new
sessions from the
private host.
I will reword the text to make this clearer. Thanks.
> > Does a
mapping for a UDP
> > or TCP session count? And what if the NAT does
not support the
> > Address Pooling behavior of Paired (which is
just a SHOULD in the
> > BEHAVE-UDP document) -- in this case, which
address is used?
[suresh] Please see my comment above. With a Basic NAT, both
TCP and UDP
sessions use the same address mapping. Ports are unchanged
from private
endpoint to public endpoint.
> >
> >* Section 6 talks about outbound flows that are
rejected by the NAT
> > and says that the NAT SHOULD send an ICMP
message back to the
> >internal
> > host when this happens.
> > However, some NAT designers may say "We
never reject an outbound
> >flow;
> > if we get close, we just steal the entry from
an existing flow".
> > By doing this, they may claim to conform to
REQ-8, while violating
> > the spirit of the requirement.
> > I would like to see the document discuss this
issue, and perhaps make
> > a recommendation discouraging this potential
practice.
[suresh] OK.
> >
> >* Should this document mandate support for
draft-bonica-internet-icmp?
> > Note that an early version of this work has
been widely
> >implemented in routers
> > (since about 2000).
> >
[suresh] I havent read the draft. DO any of the existing
requirements change by
mandating the support for this? Are there new fields that a
NAT has to modify?
Or, are the extensions completely transparent to a NAT
device?
> >
> >
> >Minor and editorial comments
> >============================
> >* Section 1 states:
> > "Even though ICMP is a transport
protocol on top of IP, ICMP
> message
> > processing is often considered an integral
of IP and is independent
> > of other transport protocols. As such,
many of the ICMP behavioral
> > requirements discussed in this document
apply to all IP protocols."
> > Three comments on this:
> > a) ICMP is not a transport protocol, but a
network control protocol.
> > b) "an integral of IP" -->
"an integral part of IP"
> > c) I don't understand what you are trying to
say with this paragraph.
> > When I review the requirements for ICMP,
they seem pretty ICMP-
> >specific,
> > and not applicable to UDP or TCP or some
other protocol running
> >on top
> > of IP.
> >
[suresh] Fernando made a similar comment on this text. Would
the followrded
text work for you? Thanks.
ICMP is a signaling protocol for IP. ICMP message
processing is
often considered an integral of IP and is independent of
other IP
protocols. As such, many of the ICMP behavioral
requirements
discussed in this document apply to all IP protocols.
> >
> >* In section 3.2
> > "an ICMP query transiting a NAT
device"
> > Not sure about "transiting". Suggest
replacing with
> > "an ICMP query that transits a NAT
device"
> >
[suresh] OK.
> >
> >* In section 4.2
> > "Section 4.3 of the RFC 3022
describes the various fields within
> > an ICMP error message a NAT device
translates."
> > Two comments:
> > a) Missing a "that" after message.
> > b) Everywhere else, the document say just
"RFC XXXX", not "the RTC
> >XXXX".
> >
[suresh] OK.
s/message a NAT/message that a NAT/
s/the RFC 3022/RFC 3022/
> >
> >* Also in section 4.2:
> > "domains. Whereas, the subnets in the
private network ..."
> > Suggest either changing the "." to a
",", or changing "Whereas" to
> >"By contrast".
> >
[suresh] OK. s/Whereas/By contrast/
> >* And more in section 4.2:
> > "... to Host-x, let us say that the
NAT device assigned a mapping
> of
> > Host-y' to associate with Host-y in the
external network."
> > This implies that the mapping is just an IP
address to IP address
> >mapping,
> > but in some cases it also involved the
Information field.
> >
[suresh] Would the following rewording work for you?
"... to Host-x, let us say that the NAT device mapped
the endpoint on Host-y to
an endpoint on Host-y'. "
> >* In section 4.2.2:
> > "If the ICMP error message is
generated by Host-y, the NAT
> > a NAPT device must simply use the NAT
Session to translate the ..."
> > Delete "a NAPT".
> >
[suresh] Yup. Thanks.
> >* In section 4.3
> > "By not effecting the NAT Sessions,
the NAT
> > device is able to retain them, even as
someone spoofs ICMP error
> > messages pertaining to the NAT
Sessions."
> > Here "effecting" should be
"affecting", but I really suggest
> > rewording this entire sentence to:
> > "This ensures that the NAT Session
will not be modified
> > if someone is able to spoof ICMP error
messages
> > for the session."
> >
[suresh] OK.
> >* In section 5
> > "REQ-7: NAT devices enforcing Basic
NAT ([NAT-TRAD]) MUST support
> the
> > traversal of hairpinned ICMP query
sessions. All NAT devices (i.e,
> > Basic NAT as well as NAPT devices) MUST
support the traversal of
> > hairpinned ICMP error messages."
> > I suggest replacing this with just
> > "REQ-7: NAT devices MUST support the
hairpin traversal of ICMP
> >messages."
> > The proceeding discussion mentions why this is
a bit more difficult
> > for Basic NAT devices, but I suggest that the
requirement itself
> >be stated
> > as cleanly and simply as possible.
[suresh] The requirement as stated refers to supporting
hairpinning for both
ICMP queries and ICMP messages explicitly. The requirement
is also explicit
that hairpinnig support for ICMP queries is is required only
for Basic NAT.
Your revised text is not explicit on either of these.
> >
> >"If the DF bit is not set and the MTU on the
forwarding interface
> > of the NAT device mandates fragmentation, the
NAT device must
> > simply send this fragmented, just as any
router does [RFC1812]."
> > Suggest rewording this as
> > "If the DF bit is not set and the MTU on
the forwarding interface
> > of the NAT device mandates fragmentation, the
NAT device MUST
> > fragment the packet and forward the fragments
[RFC1812]."
> >
[suresh] OK.
Thanks.
regards,
suresh
> >* In section 7.1.1:
> > "If the DF bit is not set and the MTU
on the forwarding interface
> > of the NAT device mandates fragmentation,
the NAT device must
> > simply send this fragmented, just as any
router does [RFC1812]."
> > Suggest rewording this as
> > "If the DF bit is not set and the MTU
on the forwarding interface
> > of the NAT device mandates fragmentation,
the NAT device MUST
> > fragment the packet and forward the
fragments [RFC1812]."
> >
_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave
|