Hi Ben,
Thanks for your Gen-ART review!
Here we go with my replies/fixes applied.
They are also in the -24 version of the draft
http://tools.ietf.org/html/draft-ietf-nsis-nslp-natfw-24
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Ben Campbell
Sent: Tuesday, March 16, 2010 12:24 AM
To: Martin Stiemerling; Hannes (NSN - FI/Espoo) Tschofenig;
cedric(_at_)caoun(_dot_)net; elwynd(_at_)dial(_dot_)pipex(_dot_)com; General
Area Review Team
Cc: magnus(_dot_)westerlund(_at_)ericsson(_dot_)com; IETF-Discussion list;
jukka(_dot_)manner(_at_)tkk(_dot_)fi
Subject: Gen-ART (belated) LC Review of draft-ietf-nsis-nslp-natfw-23
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-nsis-nslp-natfw-23
Reviewer: Ben Campbell
Review Date: 2010-03-15
IETF LC End Date: 2010-03-12
IESG Telechat date: (if known)
[Apologies for the tardiness of this review. I somehow missed the
assignment until after the LC completed.]
I have received a comment from Magnus Westerlund about having the
ability in the NATFW NSLP to support future IPv6 NATs. This
has been addressed by adding a IP version field to
- External Address Object (NATFW_EXTERNAL-IP)
- External Binding Address Object (NATFW_EXTERNAL_BINDING)
However, the only defined value is IPv4 by this time.
Summary:
This draft is almost ready for publication as an experimental RFC.
There are a few minor issues and nits that should be addressed first.
Major issues:
Minor issues:
-- section 1.4, figure 1:
I'm not sure I understand the intent of the "application server"
element in the figure.
Clarified this in the text, as the app server are meant to be rendezvous
points where the local apps can find out about the other end's IP address
and port:
OLD:
Applications located at
these end hosts try to establish communication with corresponding
applications on other such end hosts. They trigger the NSIS entity
at the local host to control provisioning for middlebox traversal
along the prospective data path (e.g., via an API call).
NEW:
Applications located at
these end hosts try to establish communication with corresponding
applications on other such end hosts. This communication
establishment may require that the applications contact an
application server which serves as a rendezvous point between both
parties to exchange their IP address and port(s). The local
applications trigger the NSIS entity at the local host to control
provisioning for middlebox traversal along the prospective data path
(e.g., via an API call).
-- section 3.2.8, "transitory" bullet: "When a node has received a
NOTIFY message, it
marks the signaling session as 'transitory'."
I assume this is content dependent, right? That is, this is not true
for any arbitrary NOTIFY?
It is transitory for any NOTIFY.
NOTIFY is indicating that something did get wrong along the path and
that the NI should react immediately to this. However, making it
context dependent has the risk that, if the path back to the NI is
broken or if the path from the NI to the NFs is broken, that NFs will
keep state for a too long time (probably until the session expires -
which might be long time), despite the fact that the state is not
needed anymore.
-- 3.3, paragraph 1:
You offer guidance to reject a message for any syntax error. Are there
cases where you can have trivial syntax errors that could be processed
anyway? It's been my experience that coders often become protocol
police, and reject things that could have worked. Postel's law may
apply here.
True. I have added text to address this:
OLD
All NATFW messages are subject to some basic message processing when
received at a node, independent of the message type. Initially, the
syntax of the NSLP message is checked and a RESPONSE message with an
appropriate error of class 'Protocol error' (0x3) code is generated
if any problem is detected. If a message is delivered to the NATFW
NSLP, this implies that the NTLP layer has been able to correlate it
NEW:
All NATFW messages are subject to some basic message processing when
received at a node, independent of the message type. Initially, the
syntax of the NSLP message is checked and a RESPONSE message with an
appropriate error of class 'Protocol error' (0x3) code is generated
if a non recoverable syntax error is detected. A recoverable error
is, for instance, when a node receives a message with reserved flags
set to values other than zero. This also refers to unknown NSLP
objects and their handling, according to Section 4.2. If a message
is delivered to the NATFW NSLP, this implies that the NTLP layer has
been able to correlate it with the SID and MRI entries in its
-- section 3.4, 4th bullet:
I'm not sure what "data exchange duration" means. Is this the time over
which the DS expects to send exchange data with the DR, or is it the
time required for one round-trip data exchange? If the first, how is
the DS expected to know this in advance?
It is the time over which DS is sending its data. The formulation is bit
blurry, as neither of us can tell how long this time will actually be.
The time can range from few minutes (ftp download) to days (if used with
GRID stuff). The way how the DS learns this is up to the implementer.
-- section 3.4, paragraph before numbered list:
Should there be a normative statement about using this algorithm?
(MAY/MUST/SHOULD)?
I would say it should read RECOMMENDED. Is that fine?
-- section 3.4, first paragraph after numbered list:
Is "refresh timer" the same thing as "message refresh period"? (i.e.
"R", above?)
No, see text in 3.4:
" 1. The refresh message timer to be randomly set to a value in the
range [0.5R, 1.5R]."
" This duration is modeled as R, with R the message refresh period (in
seconds);"
-- section 3.4, paragraphs about signalling session lifetime being too
big or small
Does the RESPONSE carry hints about the largest or smallest allowed
value?
No it does not. However, there is no indication what the appropriate range is.
How about adding the NATFW lifetime object to that error response message, in
which the maximum session lifetime is indicated?
-- section 3.4, 2nd to last paragraph, starting with : "Each NSLP
forwarder processes the RESPONSE message..."
I'm a little confused here. Is the "received" lt value the one received
in the CREATE/EXTERNAL or the RESPONSE? What happens if the value in a
RESPONSE is not acceptable to an NF (i.e. two low) ? It can't respond
to a RESPONSE. Does this require a NOTIFY in the downstream direction?
It is the value received from the RESPONSE message.
However, the case that a NOTIFY has to be sent is not described.
I have added text for this, so that the NF can actually inform the
other NFs about that situation.
OLD:
For received
values lower than the values acceptable by the node local policy,
NSLP forwarders MUST generate a RESPONSE message of class 'Signaling
session failure' (0x6) with response code 'Modified lifetime is too
small' (0x12).
NEW:
For received
values lower than the values acceptable by the node local policy,
NSLP forwarders MUST generate a RESPONSE message of class 'Signaling
session failure' (0x6) with response code 'Modified lifetime is too
small' (0x12). In both cases, either 'Modified lifetime is too big'
(0x11) or 'Modified lifetime is too small' (0x12), the NF MUST
generate a NOTIFY message and send it outbound with the error class
set to 'Informational' (0x1) and with the severity class to 'NATFW
signaling session terminated.' (0x05).
-- section 3.7.1, "Firewall:" sub-bullet:
When is "later on"?
If the FW gets a success RESPONSE from downstream, generates an error
RESPONSE due to a local failure, how do downstream devices learn of
this? Does it need to send a NOTIFY towards the NR?
This is a mistake in the text - I guess this text got missed while
editing.
Changed to text to address the fact that error must be generated at the
time when the CREATE is received, as the policy rule is already reserved
and all checks whether it is compliant with local policies has to be
done at that time.
OLD:
When the initial CREATE message is received at
the private side, the NAT binding is allocated, but not
activated (see also Appendix D.3). An error RESPONSE message
is generated, if the requested policy rule cannot be installed
later on, of class 'Signaling session failure' (0x6) with
response code 'Requested policy rule denied due to policy
conflict' (0x4). The MRI information is updated to reflect the
NEW:
When the initial CREATE message is received at
the private side, the NAT binding is allocated, but not
activated (see also Appendix D.3). An error RESPONSE message
is generated, if the requested policy rule cannot be reserved
right away, of class 'Signaling session failure' (0x6) with
response code 'Requested policy rule denied due to policy
conflict' (0x4). The MRI information is updated to reflect the
Nits/editorial comments:
-- section 3.4, 3rd bullet:
unbalanced parenthesis
removed parenthesis. fixed.
-- section 5.3: paragraph 1:
s/typcial/typical
fixed.
... paragraph 2:
Please expand AA on first use.
done. fixed.
... paragraph 3:
s/"can use EXTERNAL"/"can use the EXTERNAL"
fixed.
2nd and 3rd sentence do not parse.
OLD
Each network edge that has the NATFW NSLP deployed can use EXTERNAL
request message to allow a secure access to the network. This will
allow to open the firewall/NAT on the receiver's side. However, the
edge-devices should not allow to be opened up completely, but to let
DR's to reserve very specific policies. For instance, a DR can
request to reserve an 'allow' policy rule for an incoming TCP
NEW:
Each network edge that has the NATFW NSLP deployed can use the
EXTERNAL request message to allow a secure access to the network.
Using the EXTERNAL request message does allow the DR to open the
firewall/NAT on the receiver's side. However, the edge-devices
should not allow to be opened up completely (i.e., applying an allow-
all policy), but to let DR's to reserve very specific policies. For
instance, a DR can request to reserve an 'allow' policy rule for an
s/"matching CREATE request"/"matching the CREATE request"
fixed.
2nd to last sentence does not parse.
At what part?
s/indepdently/independently
fixed.
... paragraph 4:
s/deploy/deployment
fixed.
s/completetly/completely
fixed.
-- idnits returned some warnings--please check it.
Checked:
- changed intended status to experimental
-There is one complain about using private IP addresses instead of the
example addresses. However, since this document is about NATs, private IP
addresses
are needed anyhow.
Thanks again for your time and your review!
Martin
martin(_dot_)stiemerling(_at_)neclab(_dot_)eu
NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3
6BL | Registered in England 2832014
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf