Subject: Re: [NSIS] WGLC: draft-ietf-nsis-nslp-natfw-16.txt

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 5 Dec 2007 00:06:44 +0200 (EET)

Hi,

I have reviewed that draft. I don't have any major objections to the 
document, just some miscellaneous comments and clarification requests.

Here goes:

- p.6, bullet 1: at this point in the document, it is not clear to the 
  reader what the NSIS initiator/receiver are. Propose to use simpler 
  terminology at this early phase in the intro.

- p.6, end of page: propose to clearly say wo sends which message, e.g.:

"CREATE message: send by the data sender for..."

"EXTERNAL message: used by data receiver to ..."

Related comment: why abbreviate EXTERNAL to "EXT"? 
	* None of the other message are abbreviated
	* EXTERNAL is as long a word as "RESPONSE" (both abbreviated?)

Suggest to drop the EXT-term

Related to the above the document presents over and over again that 
EXTERNAL is EXT ("EXTERNAL (EXT)") and is a bit inconsistent in when to 
use EXTERNAL and when just EXT (both used here and there).

- p.7.: s/body of the document, covers/body of the document cover/

- p.23: s/inSection/in Section/

- p.27: "if the node runs _it_ garbage collection cycle."? 

- p.27: "appropriate error of class 'Protocol error' (0x1)": 0x1 is 
  Informational, ox3 is protocol error.

- p.32: "is thus managed NSLP hop-by-hop"?

- p.41: "session created by REA."?

- p.41: "using CREATE Section 3.7.1" > "(see Section 3.7.1)"?

- p.43: "if the like to aggregate"?

- p.46, whole Section 3.7.6.1: should NR be actually DR? Including Figure 
  18?

- P.46-47, Section 3.7.6.1: I don't really get this operation at all. 
  Sounds a bit complex to have the EXT-session trigger a CREATE-session. 
  Maybe some more discussion/description is needed to open up the 
  scenario. Also, the NATFW_NONCE sounds a bit wierd, somehow. In the QoS 
  NSLP, we have the same functionality, but it is called "session binding" 
  and uses a similar object where the content is the SID of the primary 
  flow. Achieves the same thing, and you can be sure there are no 
  collisions with nonces. Does the value need to be a random value? Or 
  could you perhaps re-use the QoS NSLP object since we have common object 
  repository anyway? The concept in the QoS NSLP session binding is that 
  the secondary session is valid as long as the primary session is.

- Related to the above, p.48 (middle): if you have the "internal" 
  CREATE+NONCE session and also get the e2e CREATE session, do you run 
  both simultaneously? Or do you kill one of them? I guess you can't kill 
  the EXT-session, since you need the forwarding at the NAT? Perhaps this 
  needs some more description.

- p.49: "back to NI according [to] the situation"

- p.49: "NSLP node and the of the policy rule."?

- p.51: Do the route changes really work as you describe? This may need 
  some thinking, and probably add text to the mobility draft.

- p.51: s/and sends it/and send it/

- Whole Section 4: the text talks about error cases and mandating "MUST" 
  to send various error messages? If you must always send error messages, 
  isn't this a use case for DoS attacks? I guess some words about when to 
  send error messages would be needed (rate limiting, etc.).

- p.57 (top of page): "Further version of this memo may allow other values 
  for the 'sub_ports' field." I think suggestions like this should not be 
  in a draft going to WGLC.

- p.58-60: there are a lot of error codes. Should somewhere be written how 
  and when these are used? Some of these are quite clear, but e.g.  I 
  don't understand Permanent failures 0x03, 0x05 and 0x06. Where would 
  these be used?

- p.61, Section 4.2.7: where is this object used actually? text says 
  "possibly needed", sounds a bit wierd for a draft in WGLC. Is it needed, 
  and where/when/why? Should this be also available for IPv6?

- p.62, 3rd line: "according [to] these rules:"

- p.64, Sections 4.3.1 and 4.3.2: what are these "(O)" and "(M)"? Optional 
  and mandatory? Say it clearly.

- p.64, Section 4.3.2: point c) as use case for EXT: you lost me here? Was 
  this presented earlier? Actually, in general about EXT, should it always 
  have the proxy bit P=1? What happens if I send an EXT message towards 
  the DS with P=0? Does the EXT reach the DS? What happens then?

- p.67: "In Section 5.1 we describe [how] the ..."

- p.73: s/located to the/located at the/

Jukka

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

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 5 Dec 2007 15:53:17 +0100

Hi Jukka,

Thanks a lot for your review! I will go through the comments today  
and come back if I need more information.

Thanks,

   Martin

> - p.73: s/located to the/located at the/

[email-masked]

NEC Laboratories Europe - Network Research Division

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,  
London W3 6BL | Registered in England 2832014

---

From: Takako Sanda <[email-masked]>
Date: Tue, 11 Dec 2007 09:49:41 +0900

Hi all,

Regarding NAT traversal, NSIS Mobility Applicability draft also has two
open issues (as shown below). But I am not sure Mobility draft is proper
place to handle these issues. I would like to ask whether these two
issues can be discussed in NATFW draft.

Issue 1:
When MN moves, IP address and routing are changed.  In this case, new
NAT/FW pinhole need to be opened and old one should be torn. When and
how should NSIS tear old pinhole?

(For this issue, some comments were already made that the old pinhole
should be torn by time out, and this prefer to be mentioned in Mobility
draft.)

Issue 2: In mobility scenario, it is possible that MN attaches to
private network. But MN cannot know if the NAT is NSIS aware or not.
Therefore should it be mandatory that MN sets S-flag when it detect
attaching a private network?

cheers,
Takako

On Fri, 23 Nov 2007 13:44:20 +0100
Martin Stiemerling <[email-masked]> wrote:

> [writing as WG chair]
> 
> Dear all,
> 
> The authors believe that the NATFW NSLP
> (draft-ietf-nsis-nslp-natfw-16.txt) is ready for WGLC.
> 
> The WGLC starts today and will run until December 14th.
> 
> Please review the draft, and comment if you feel that this draft
> is ready to be sent to the IESG.  A simple mail saying that the
> draft is ready for publication would be great.
> 
> Of course, if you read the draft and find open issues, then please
> send a summary of your issue with the current draft.
> 
> Thanks,
> 
>    John and Martin
>

---

From: Niklas Steinleitner <[email-masked]>
Date: Tue, 11 Dec 2007 12:22:43 +0100

Hi Martin, all,

i have reviewed the NATFW NSLP draft. Overall i think the draft is in a 
good shape.

My three major comments:

    * p24: Redraw the picture! Add administrative domains or point out
      with node belongs to which network! Also rewrite the first
      paragraph! Use a easier example! This section indicates (at least
      to me) the usage of the proxy mode in a way which is not supported
      by NATFW!
    * p26/section 3.2.3: Why do you have this section within the draft?
      The listed states are not enough to implement the NATFW NSLP and
      may confuse reviewers/implementers. You could point to the
      statemachine draft! If you want to have this section inside the
      draft, you should update it. What is the "Dead" state good for?
      Such a session has to be deleted directly and not "... and the
      NATFW NSLP signaling session can be deleted."
    * regarding section 3.7.2: this section is a little bit confusing!
      Even with knowledge about the NATFW NSLP it is hard to follow.
      Maybe you should re-structure it a little bit, e.g. creating
      several sub-sections. You should also clearly point out that EXT
      can also be used to install pinholes in FWs (and not only deny
      rules as described later, if i don't understand this wrong (see
      below)).

Further comments:

    * p2/p4: If you introduce NAT, you should do the same for FW
    * p8/p10: you introduce the terminology "middlebox" twice, in
      section 1.2. and section 1.3
    * p11: meaning that there is a middlebox on the => meaning that
      there is _at least one_ middlebox on the
    * p22, first paragraph: (check local policies for authorization and
      authentication, possibly create policy rules) that is not right,
      the NF only notice the policy rules
    * p22, third paragraph: the NF installs the policy rule when
      receiving a success RESPONSE msg
    * p22, fourth paragraph: Ni => NI
    * p27: 'Protocol error' (0x1) => (0x3)
    * p29/p30: many recurrences here: Requested signaling session
      lifetime is too big, Requested signaling session lifetime is too
      small, with codes, the same on page 30
    * p32: section 3.7:  ... how to create NATFW NSLP signaling
      sessions, maintain them, and how to reserve addresses. => and delete
    * p34: NSLP forwarder: what happened if the NF can not install the
      pinhole? e.g. it is already installed
      looks like you forgot this case, there is also node error code for
      this case on page 58.
    * p40:  ... an error RESPONSE of class 'Protocol error' (0x3) ... =>
      of class signaling session failure (0x6)
    * p40: "The policy rule is remembered, but not activated, if the
      action in the NATFW_EFI object is set to 'allow'." Why? In
      general, i don't understand the "Firewall" paragraph.
    * p41: "Reservations with action 'allow' made with EXT MUST be
      enabled by a subsequent CREATE message." What happens if the
      pinhole isn't use for reservation of an external address or a
      NAT-binding? In this case no CREATE msg will follow.
          o or is this in general not allow within the NATFW NSLP? The
            next sentence indicates that:
          o "The only function of EXT is to ensure that subsequent
            CREATE messages traveling towards the NR will be forwarded
            across the public-private boundary towards the DR."
          o One earlier version of the NATFW NSLP supports this with the
            use of U-CREATE. Or is this completely remove?
    * p41: ...created by REA. => ... created by EXT.
    * p42: "The lifetime extension of a NATFW NSLP signaling session is
      calculated as current local time plus proposed lifetime value",
      really local time _*plus *_proposed? This would increase the
      lifetime step by step as the local lifetime is always >0!
    * p44: "'NATFW node is going down soon' (0x03) The NI and other NFs
      should be prepared for a service interruption at any time."
      What is this good for????
    * p48/49, section 3.7.6.2: you should make clear where are the
      differences to the EXT msg.
    * p52: ... of this memo => ...of this memo.
    * p56: ... of class 'Signaling session error' (0x6) with ... => ...
      of class 'Signaling session failure' (0x6) with ...
    * p58: you forgot 0x04 (see 3.7.5) 'NATFW signaling session lifetime
      expired'
    * p59(and whole doc) => signaling session failures => signaling
      session failure (as for the other classes).
    * p62: The fields MUST be interpreted according these rules: => The
      fields MUST be interpreted according _*to *_these rules:
    * p62: with response code 'Mandatory object missing' (0x02) MUST =>
      (0x04)
    * p76: Open issues. Should this be part of a WGLC document?

Regards,
Niklas

Martin Stiemerling schrieb:
> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

-- 
Niklas Steinleitner          Tel: +49 551 3913583
Institute for Informatics    [email-masked]
University of Göttingen      http://www.tmg.informatik.uni-goettingen.de
Lotzestrasse 16-18
D-37083 Göttingen, Germany

---

From: Lauri J T Liuhto <[email-masked]>
Date: Thu, 13 Dec 2007 02:08:27 +0200 (EET)

Hi, 

 I have read the document, and I did not find any big issues, mainly 
just some editorial things. I did not repeat findings already 
provided by Jukka or Niklas.

 Some parts of the text, mainly Section 3 (Protocol Description), was 
such, that I can not be sure whether I understood it completely. The 
text itself was quite easy to read, but I think those who have 
implemented this protocol can say more accurately how well the protocol 
actually is described. 

 To make it short: I think the specification is in quite nice state, and 
needs just some editorial fixes.

Here are my comments on the draft:

 * At page 11, line 571: 'routeable' --> 'routable' (?)
 
 * Examples in Section 2 use mainly 'MB' in figures to represent NAT
   and/or FW nodes. However, I think the use is not always
   consistent. For example, in the figure 2 'FW' is used (and I think
   it is ok, because the text explicitly states that this example is
   about FW-only cases), but figure 9 in section 2.8 has 'MB's
   instead. If those middle boxes in scenario 2.8 may be also NATs, I
   think it would be nice to have it in text. If those middle boxes
   are always firewalls as I think the text states, then the figure
   should be changed.

   However, I think that the text is clear enough already, and the
   easy fix would be to change the 'FW' boxes to 'MB' boxes in the 
   figure 2 :)

 * Section 3.1 Policy Rules, first paragraph:

 "For firewalls the policy rule usually consists of a 5-tuple, source/
  destination addresses, transport protocol, and source/destination
  port numbers, plus an action, such as allow or deny."

  At least before reading the rest of the document, the word 'usually'
  seems a bit odd here. Do real alternative policy rules that do not
  contain the 5-tuple and action exist?

  I also think this sentence is not too clear, some kind of
  reformatting would be nice. For example, something like this (still
  having the word 'usually'):

 "For firewalls the policy rule usually consists of a 5-tuple and an
  action such as allow or deny. The information contained in the tuple
  includes source/destination addresses, transport protocol and
  source/destination port numbers."

 * In addition to comments Niklas already gave on figure 11 on page
   24, I want to add that the figure and its legend do not
   match. There is no MB2 in the figure, and NF is present in the
   legend only in the text. As Niklas, I also think that it would be
   good to point out which node belongs to which network.

 * Page 28, last bullet:
  "the lease time of the NI's IP address.  The chosen NATFW NSLP
   signaling session lifetime must be larger than the lease time,
   otherwise the IP address can be re-assigned to a different node.
   This node may receive unwanted traffic, although it never has
   requested a NAT/firewall configuration, which might be an issue in
   mobile environments.

   I just can not get the idea :) Should it be 'must be smaller than
   the lease time' ? If not, then I think some more text is needed.

 * Page 45, middle bullet:
   "and outbound messages MUST be forwarded further inbound." 
   ->
   "and outbound messages MUST be forwarded further outbound." ?

  * Table 1 on page 50, the last row, capitalization:
    left column: "IPsec SPI", right column: "ipsec-SPI"

 Best Regards,
 Lauri

-- 
Lauri Liuhto

---

From: Teemu Huovila <[email-masked]>
Date: Wed, 19 Dec 2007 16:39:39 +0200 (EET)

Hello

I have read the draft and I do not have any major objections. I think it
is very extensive and considers, in great detail,  all necessary aspects
of the protocol.

I am very sorry, that my comments are overdue. I hope they can still
be of some use for the working group. This was my first review of
the draft and it took much longer to read, than I had estimated.

I have divided my comments into two categories. One group of regular nits
and another of more insignificant details. I include the comments below.

Before nits I will just add my 2 cents to the 5-tuple/policy rule
discussion. As mentioned by Lauri, it is defined somewhat unclearly on
page 20. It is, however, in my opinion defined more clearly on page 10.
It is also worth to note, that the first definition uses "and", where the
second uses '/'.

-----
nits:

* page 6, paragraph 2:
"This message .... intercepts these messages," -> *this message*

* page 7: 
"If the data receiver resides in a private addressing realm or
firewall" --> *behind a* firewall ?

* page 8: 
the second sentence in the definition of "Firewall" is superfluous.

* page 9: 
In bullet about NATFW NSLP peer the term "NSIS adjacency" is vague.
I suggest "NSLP adjacency" (or GIST/NTLP adjacency, if that was intended). [2]
defines GIST adjacency and "adjacent peer"

* page 25, 3.2.1, 3rd bullet: 
What are "inbound NATFW peers"? Does "inbound"
here mean towards the NI?  (it became clear later, in section 3.7.5)

* page 30, 2nd paragraph: 
Error conditions are quite correctly defined for both
too low and too high session lifetimes, but the text states:

"The forwarders MUST accept the granted NATFW NSLP signaling session lifetime,
as long as this value is less than or equal to the acceptable value."

later "lower or equal" is mentioned.

Should these maybe be "if the lifetime value is within the acceptable range",
or something similar? If not, I have great trouble understanding this.

How are NFs on the path towards NR informed, if a node rejects the lifetime
suggested in the RESPONSE? A NOTIFY with the same error code?  Can NOTIFY be
sent towards NR? Page 66 says "The NOTIFY message is routed towards the NI..."

Im very sorry, if I have overlooked some central detail about this.

* page 33, 5th bullet, sub-bullet: 
"If no matching reservation can be found, i.e. no reservation has been made in
advance, the NSLP MUST return an error RESPONSE of class 'Signaling session
failure' (0x6) with response code 'No reservation found matching the MRI of the
CREATE request' (0x03) MUST be generated."  --> "MUST be generated" is
superfluous? (already "MUST return")

* page 39-40: 
processing of EXT on NI(page 39) says: "When the data sender's IP address is
not known, the NI+ MUST NOT include a NATFW_DTINFO object."

later, on page 40 it is stated:
"The edge-NAT or any other NAT MUST reject EXT messages not carrying a
NATFW_DTINFO object..."

Was the "LE-MRM, DS unknown etc" case DTINFO object added by somebody in the
middle? A NAT before the edge-NAT? But arent those included in "or any other
NAT"?

Also, NATFW_DTINFO is specified as mandatory, in 4.3.2 (page 64) Maybe I have
overlooked something here as well. The section, as Niklas mentioned, is not
very easy to read.

* page 46: 
"This proxy mode of operation must terminate the NATFW NSLP signaling as
topologically close to the terminal for which it is proxying and proxy all
messages."  --> *as possible* or something similar seems to be missing from
that sentence. (It only says "as close..." )

Also, what does this sentence mean? All proxy mode signaling is terminated at
the NI+/NI side edge-device, if I understood the section correctly.

------------------------
insignificant/uncertain:

* page 7:
"one or other" --> one or *the* other ?

* page 9: 
The "SDA" did not become clear to me until page 36( with dr, dr+ etc). Though
admittedly it is difficult to write a clear terminology section, if no
knowledge can be expected from the reader, i.e. me. :)

* page 11: 
"on the data path from... and the external network" "and" could be *to*?
(i.e. on the data path from ...to) or change "from" to *between*?

* page 22, bullet 4:
"Ni" -> *NI*
* page 31, 3rd paragraph:
  "NSLP MUST update its stored state accordingly, if permitted by all security
  checks (see Section 3.6), and stores"
  --> *store*?

* page 53:
"The NSLP header is carried in all NATFW NSLP message and objects... "
--> *messages*

* page 63:
  "Objects defined in this memo carry always the flag combination"
  --> *always carry* ?

* page 80:
  "The rest of this section is giving"
  --> *gives* ?

* page 80:
  "It necessary to differentiate" --> It *is*

best regards, 
Teemu Huovila

-- 
Teemu Huovila

---

From: Ali Fessi <[email-masked]>
Date: Fri, 21 Dec 2007 16:57:40 +0100

Dear Martin and NATFW NSLP co-authors,

I have read the draft and have only few comments:

- First, I think the draft needs some editorial polishing and needs to 
become a bit more reader-friendly where possible. As already mentioned 
in some emails before, some sections are difficult to understand even 
with background knowledge in NATFW NSLP. Some more cross references to 
different sections within the draft itself or to sections in other 
drafts considered as background knowledge, e.g. GIST, could be helpful 
to make life easier for the reader.

- The solution described for the scenario "2.6 Both End Hosts Behind 
Same NAT" is not efficient. I guess you know what I am talking about 
here. All the traffic will go through the external gateway. I remember 
we had some discussions with Cedric about 4 years ago about using 
something like ICE (at that time ICE was pretty new, I think) in order 
to discover whether the peer is within the same network in order to 
perform direct signaling and route the traffic directly between the peers.

- The text in "C.4.  NSLP Handling of Twice-NAT" is a bit confusing. 
e.g. "The dynamic configuration of twice-NATs requires application level
    support, as stated in Section 2.5.  The NATFW NSLP cannot be used for
    configuring twice-NATs if application level support is needed."

does this mean that the NATFW NSLP does not supports twice-NATs and it 
is left to application layer support?

or "The NSLP is probably able to traverse the twice-NAT" (I guess with 
"probably" here, you mean it depends on whether the twice-NAT is NATFW 
NSLP aware or not. This could be clarified better).

- The text about CMS in the security section is a bit confusing:

"Additionally, security protection of certain
    payloads may be required between non-neighboring signaling entities
    and the Cryptographic Message Syntax (CMS) [14] might be a potential
    solution.  Payload protection using CMS is not described in this
    document."

This sounds like: "you could use CMS, but we are not sure if it will 
solve your problems, or we don't know even how to use it here, and which 
message parts you will need to protect".

I am not sure here, but I think that if you use CMS, you will use it to 
protect the authorizations tokens, so the use of CMS could be moved the 
NSLP authorization draft. What do you think?

Otherwise, I hope that the effort of several years will be fruiful and 
that we will have a successful protocol! :-)

Cheers and Merry Christmas,
  Ali

Martin Stiemerling wrote:
> Hi Jukka,
> 
> Thanks a lot for your review! I will go through the comments today and 
> come back if I need more information.
> 
> Thanks,
> 
>   Martin
> 

-- 
Ali Fessi
Computer Networks and Internet
University of Tuebingen, Germany
Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220
EMail: [email-masked]
Web: http://net.informatik.uni-tuebingen.de/~fessi/