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

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

[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