RE: Gen-ART (belated) LC Review of draft-ietf-nsis-nslp-natfw-23

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of
> Ben Campbell
> Sent: Tuesday, March 16, 2010 12:24 AM
> To: Martin Stiemerling; Hannes (NSN - FI/Espoo) Tschofenig;
> cedric@xxxxxxxxx; elwynd@xxxxxxxxxxxxxx; General Area Review Team
> Cc: magnus.westerlund@xxxxxxxxxxxx; IETF-Discussion list;
> jukka.manner@xxxxxx
> 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.stiemerling@xxxxxxxxx

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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]