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

Hi Jukka,

Thanks for the review and more inline.

   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.

Fixed. E.g., s/NSIS initiator/initiator of the NSIS signaling

>
> - 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 ..."

Fixed.

>
> 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

Done and I have changed to EXTERNAL in all occurrences,

>
> 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).

Fixed, as it is called EXTERNAL only now.

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

Fixed.

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

Fixed.

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

Fixed.

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

Fixed.

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

Fixed.

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

Fixed.

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

Fixed.

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

Fixed.

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

I prefer to leave NR in the text, but have added the term DR to  
figure 18. This should make it clear.

>
> - 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.

That's the best way ensure faith sharing between both of them. The  
CREATE session should die together with the EXTERNAL-PROXY 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

Added some text to actually describe the dependency between the  
sessions of EXTERNAL and CREATE.

>   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.

Actually it is a good idea to use the SID of the primary flow as  
content for the NONCE object. Fixed.

For the shared object: I would like to keep two separate objects, as  
this proxy mechanism is quite new and probably needs to be refined in  
the future, i.e., good to have no dependency here.

>
> - 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.

There is text on page 48 describing the possible way of tearing down  
the proxy session. The non-proxy CREATE session is still alive but  
can be also torn down by the data receiver (i.e. using NOTIFY).   
However, there is now a new NOTIFY reason to have a better handle to  
this:
'NATFW signaling session terminated' (0x05).
Added text about using this to CREATE.

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

Fixed.

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

Fixed.

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

Yes, route change works as defined. The handling is a bit different  
from the QoS NSLP but this is due the different signalling models used.
This will for sure need some text in the mobility draft (which I  
still owe...)

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

Fixed.

>
> - 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.).

If a DoS attack is possible by sending error response something has  
already be gone wrong on the GIST level, isn't it?

It is also not possible to get some amplification as a single request  
message results in a single error response message. And the error  
response is anyhow sent back via the existing GIST messaging  
association.

Also, I'm quite uneasy to tell which error message should be sent and  
which not. This selection is quite tough.

>
> - 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.

Hmm, right. Removed.

>
> - 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?

0x03 Unable to agree transport security with peer.
0x05 No NAT here.
are really not used in the document at all. They are some left-overs  
and have been removed.

0x06 No edge-device here.
is used in section Reserving External Addresses.


>
> - 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,

The "possibly needed" refers to the information carried in the  
object, as not all of the information is always needed but only  
sometimes (as highlighted in section Reservation message flow for DR  
behind NAT or firewall).

>   and where/when/why? Should this be also available for IPv6?

Nope. For IPv6 the IP address in the object is not meaningful, as  
IPv6 does not have NATs and therefore the rules for firewall only  
applies. This implies using the PC-MRM for signaling where the DTINFO  
address is anyway not used.

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

Fixed.

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

Clearly stated in 2nd para in 4.3.

>
> - 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

Yes, this is in a bit hidden in the policy rule section. You can send  
around policy rules with action 'deny'. That is point c).
I could add references to the particular sections if this helps  
reading it?

>   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?

DS generates an error response (see EXTERNAL section).

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

Fixed.

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

Fixed.

Once again: Thanks a lot!

   Martin

[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