Re: WGLC: draft-ietf-nsis-nslp-natfw-16.txt

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
> 
> Am 04.12.2007 um 23:06 schrieb Jukka MJ Manner:
> 
>>
>> 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
> 
> [email protected] <mailto:[email protected]>
> 
> NEC Laboratories Europe - Network Research Division
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
> London W3 6BL | Registered in England 2832014
> 
> 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/nsis


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