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

From: Martin Stiemerling <[email-masked]>
Date: Thu, 24 Jan 2008 15:02:56 +0100

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

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-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 24 Jan 2008 15:13:33 +0100

Hi Takako,

Am 11.12.2007 um 01:49 schrieb Takako Sanda:
e
> 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.)

Preferably this would be described in the mobility draft, as it is  
really a mobility issue.

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

That is a GIST issue and Section 7.2.1. Legacy NAT Handling of the  
GIST draft recommends S=1 to support legacy NAT detection.

   Martin

>
> 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: Martin Stiemerling <[email-masked]>
Date: Thu, 24 Jan 2008 16:07:09 +0100

Am 11.12.2007 um 12:22 schrieb Niklas Steinleitner:

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

> 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!
Para rewritten a bit. No idea why this is not supported by the NATFW  
NSLP...?

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

The listed state are for sure not enough for a real implementation,  
but they describe the conceptual states. The state machine draft is  
not a WG item.
> 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)).

This section has been rewritten some times already and it seems that  
it never ever gets to a point where it is understandable for  
everybody.  I do see the point, but I don't like to change it again,  
as we have cycled through the section already several times.
This is not really an argument, but if you have a real proposal send it!
>
> Further comments:
> p2/p4: If you introduce NAT, you should do the same for FW
The term firewall and NAT are well-known and also again defined in  
the terminology section. This should be enough of definition.

> p8/p10: you introduce the terminology "middlebox" twice, in section  
> 1.2. and section 1.3

Yes right. Removed it from 1.2 and put in front of 1.3. Fixed.

> p11: meaning that there is a middlebox on the => meaning that there  
> is at least one middlebox on the
Fixed.

> 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
Yes and no. Technically you are right, but I believe it is too early  
in the document to introduce the technical difference between  
remembered/reserved/installed policy rule.

> p22, fourth paragraph: Ni => NI

Fixed.
> p27: 'Protocol error' (0x1) => (0x3)
Fixed.

> 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
Not nice but required. This part is anyhow question in my mail sent  
Jan 24 with subject "Lifetime error messages".

> p32: section 3.7:  ... how to create NATFW NSLP signaling sessions,  
> maintain them, and how to reserve addresses. => and delete
Wouldn't be a sentence anymore w/o 'and'?

> p34: NSLP forwarder: what happened if the NF can not install the  
> pinhole? e.g. it is already installed
Added text about generating error response with  0x04: Requested  
policy rule denied due to policy conflict.
>
> looks like you forgot this case, there is also node error code for  
> this case on page 58.

See above. Fixed.
> p40:  ... an error RESPONSE of class 'Protocol error' (0x3) ... =>  
> of class signaling session failure (0x6)

protocol error is right.

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

The rule is just remembered and not activated, as this is just for  
telling the firewall about future incoming CREATE requests. This rule  
is activated by a later sent CREATE request.
See also the terminology section about the difference between  
remembered policy rules.

> 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.
> or is this in general not allow within the NATFW NSLP? The next  
> sentence indicates that:
> "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."
> One earlier version of the NATFW NSLP supports this with the use of  
> U-CREATE. Or is this completely remove?

There is now the proxy mode operation for this.
>
> p41: ...created by REA. => ... created by EXT.
Fixed.

> 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!
Good point the wording is misleading...
New text: "The new (extended) lifetime of..."
> 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????
This is a soft warning to others, i.e., the NI can change the refresh  
interval to a shorter period. This allows detecting route changes  
earlier. Sometimes nodes do have some knowledge about maintenance or  
so and this message could be sent if the operator is about to halt  
the device.

> p48/49, section 3.7.6.2: you should make clear where are the  
> differences to the EXT msg.
Isn't this clear by the division of the section into "proxy for  
sender" and "proxy for receiver"?

> p52: ... of this memo => ...of this memo.

fixed.
> p56: ... of class 'Signaling session error' (0x6) with ... => ...  
> of class 'Signaling session failure' (0x6) with ...
fixed.

> p58: you forgot 0x04 (see 3.7.5) 'NATFW signaling session lifetime  
> expired'
Fixed.

>
> p59(and whole doc) => signaling session failures => signaling  
> session failure (as for the other classes).

Fixed.
> p62: The fields MUST be interpreted according these rules: => The  
> fields MUST be interpreted according to these rules:
Fixed.

> p62: with response code 'Mandatory object missing' (0x02) MUST =>  
> (0x04)
Fixed.

> p76: Open issues. Should this be part of a WGLC document?
Nope! :)
Removed.

Thanks again!

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 24 Jan 2008 16:24:21 +0100

Hi Lauri,

Am 13.12.2007 um 01:08 schrieb Lauri J T Liuhto:

> On Fri, 23 Nov 2007, Martin Stiemerling wrote:
>  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.

Thanks! :)

>
> Here are my comments on the draft:
>
>  * At page 11, line 571: 'routeable' --> 'routable' (?)

Fixed.

>
>  * 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 :)

2.8 and 2.7 have a subtle difference and it is better to change MB to  
FW in figure 9.

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

This reads better! Replaced it.

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

Fixed.

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

Yep, you're right, it must be smaller. I also bumped in this when  
reading. Fixed.

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

Fixed to outbound.

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

That is intentionally, as the NATFW NSLP uses IPsec SPI as name and  
GIST uses ipsec-SPI.

Thanks a lot,

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 24 Jan 2008 16:45:41 +0100

Hi Teemu,

Am 19.12.2007 um 15:39 schrieb Teemu Huovila:

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

No problem, I also had trouble (w.r.t. time) to get to the NATFW NSLP.

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

I hope it got better readable with Lauri's text.

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

Fixed.

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

Yep, indeed. Fixed.

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

Removed 2nd sentence.

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

Fixed to NTLP adjacency.

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

towards NI. But this inbound is wrong at that place,as NOTIFY can run  
in both directions. Removed 'inbound' at this occurrence.

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

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

I also have some doubts about this and started a separated thread  
about this (but with special focus to the error handling).

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

No, you hit one remaining issues! :)

>
> * 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")

Fixed.

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

This part has been reworked, as there where multiple places  
contradicting each other.
Fixed.

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

Replace it with "...signaling topologically-wise as close as possible  
to the terminal..."
This is typical editing error after x revisions. :)

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

Yes. However, there is some difficulty in saying where the proxies  
are located, as this depends on the system where this is implemented.  
Therefore this complicated sentence.

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

Fixed.

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

But with page 36 it was clear? That's fair enough if it is clear at  
the point when it comes to importance.

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

"and" is indeed "to". Fixed.

> * page 22, bullet 4:
> "Ni" -> *NI*

Fixed.

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

Fixed.

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

Fixed. Again some editing bug...

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

Fixed.

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

Fixed.

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

Fixed.

Thanks!!!

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 28 Jan 2008 14:18:16 +0100

Am 21.12.2007 um 16:57 schrieb Ali Fessi:

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

Good to know that there are some parts which are hard to read.  
However, this is a WG document and all people are invited to propose  
new text for replacing existing text.
It is quite hard for me as a document editor to judge which parts are  
hard to read and which are not. Furthermore, text is usually written  
in the writer's style and only real replacement text can improve  
readability.

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

There has been an AD decision (back in Alison's days) to not go into  
ICE specifics.
Technically you are completely write, but protocol wise I would  
assume that interworking with ICE would require a new document, e.g.  
applicability statement.

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

Twice-NAT configuration is not supported, as twice-NAT is marked as  
historic (RFC 4966).

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

It is meant as, whenever people do consider twice-NATs and they are  
implementing the NATFW NSLP, they should at least take care that IP  
addresses are exchanged in a proper way. However, there is no text  
here which defines the standard way of doing so. The reason for this  
is the current status of twice-NAT (NAT-PT) in the IETF (RFC 4966).

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

I'm fine with removing it, as it really reads shaky...

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

Thanks! :)

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 28 Jan 2008 15:28:51 +0100

Just as an addendum:

IPsec SPI has been changed to IPsec-SPI.

  Martin

Am 24.01.2008 16:24 Uhr schrieb "Martin Stiemerling" unter
<[email-masked]>:

>> 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 
> 2.8 and 2.7 have a subtle difference and it is better to change MB to FW in
> figure 9.
> 
>> 
> Yep, you're right, it must be smaller. I also bumped in this when reading.
> Fixed.
> 
>> 
> That is intentionally, as the NATFW NSLP uses IPsec SPI as name and GIST uses
> ipsec-SPI.
> 
> Thanks a lot, 
> 
>   Martin
> 
>  
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3
> 6BL | Registered in England 2832014
>  
> 
> 
>