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