Re: Comments draft-ietf-nsis-nslp-natfw-20

Hi Magnus, all

Thanks for the comments and see in-line how the comments were addressed:

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Magnus Westerlund
> Sent: Monday, November 30, 2009 2:06 PM
> To: [email protected]; NSIS
> Subject: [NSIS] Comments draft-ietf-nsis-nslp-natfw-20
> 
> Hi,
> 
> This email are capturing various comments I have on the document when
> reviewing it.
> 
> 1. I am missing detailed examples that indicate what information that
> are included in the messages at various points. Especially I think
> there

A table (such as in RTSP) could be helpful IMO. I can include this.

> need to be a full fledged example for a receiver proxy case with
> indication where an application would do the signaling to exchange
> information.

I can add this to the appendix or in the particular section.



> 
> 2. Section 3.2.8. When requiring random number, I would make this into
> cryptographically random number, and point at RFC4986.

Done.

> 
> 3. Section 3.4: If I understand the session refresh timer setting, the
> only way for a on path to increase the refresh period is to send an
> error message. This is a difficult security vs load trade-off that I am
> not certain what even a reasonable default is. Can you provide a better
> recommendation on default value?

I would recommend a rather high default value for the refresh timer,
i.e., 5 minutes, and apply the proposed formula (*) to calculate also
the lifetime. This may be considered a long time in the case that a node
drops out and leaves resources blocked, but starting with considerable
high value still leaves the chance of the NFs to lower the lifetime
(and thus impacting also the refresh time). 

The text should say that the 5 minutes are RECOMMENDED, unless the NI
has other requirements (e.g., flows lasting very short.)

(*)lt >= (K + 0.5)*1.5*R, where K is a small integer.

> 
> 4. When reading the spec, it requires quite a good knowledge about what
> information is included in various GIST messages. For example CREATE is
> routed using the MRI. Not making clear which MRI is used, although the
> path coupled MRI seems to be needed to be able to find the correct
> binding/reservation in a NAT. Also you need to remember that the path
> couple MRI do contains both source and destination ports.

I guess you were asking for textual clarification what MRI must be used
and what information is contained therein.

The information what is included in the MRM is described in Section 4.3.1
and 4.3.2. There is also the Appendix C (in the updated version it's D),
describing where what information about the flow signalled for is stored. 

However, this appendix is not cited at the appropriate parts of the spec.
Added some info text in the beginning of 3.7.  Protocol Operations.

Fixed and hopefully done. 


> 
> 5. Page 40, last paragraph.
> a. In first sentence: It is the EXTERNAL request, rather than respond
> that is discussed? Can you clarify that by adding request in that case.

Yep, fixed.

> b. "An edge-NAT will use the information provided in the
>    NATFW_DTINFO object to allow only NATFW CREATE message with the MRI
>    matching ('src IPv4/v6 address', 'src port number', 'protocol') to
> be
>    forwarded."
> 
> My brain gets confused from what view point and direction these source
> address + port and protocol are. To me it seems that they are in the
> wrong direction. Clarify please.

This was very clear to me at the time of writing ;) but it is indeed confusing.

Here is the clarified sentence:
   An edge-NAT will use the information provided in the
   NATFW_DTINFO object to allow only a NATFW CREATE message with a
   matching MRI to be forwarded.  The MRI of the NATFW CREATE message
   has to use the parameters set in NATFW_DTINFO object ('src IPv4/v6
   address', 'src port number', 'protocol') as the source address/port
   of the flow from DS to DR.

> 
> 6. Section 3.8: "The policy rule uses the LE-MRM
>    MRI source-address (see [I-D.ietf-nsis-ntlp]) as the flow
> destination
>    IP address and the network-layer-version as IP version. "
> 
> "network-layer-version" what field is that. The LE-MRM does have IP-Ver
> as a field, so this seem confusing.

Ah, that is a twist in GIST: In the textual description it says
"network-layer-version" and in the packet level description it
says "IP-ver". (does actually the same for PC-MRM also).
I would prefer to write :
"and the network-layer-version (IP-ver) as IP version."

> 
> 7. Table 1: In right column IP-protocol are confusing. Are you meaning
> the L4 protocol running on top of IP here, i.e. transport protocol?
> Please use a better term.

That term is taken from GIST. It is not necessarily the L4 protocol, as
it could be also ICMP, RSVP, etc.

Can we stick with the term, otherwise we need to go back to GIST to
fix this.

> 
> 8. Section 4.2.2: so the binding to what protocol the port is for is
> provided by the MRI?

The port in the 4.2.2 is the port number that is reserved by the edge-NAT
as part of the external binding (IP+port). The NATFW_EXTERNAL-IP carries
this information and is used with EXTERNAL. There is no port in the MRI 
if LE-MRM is used. For PC-MRM, the port used in the  MRI is reflecting
the flow, as seen by the NI+. However, the MRI port is not reflecting
the external binding at the edge-NAT. 

> 
> 9. Section 4.2.3: I am bit confused here by the directionality of the
> rules. Shouldn't that be made explicit in relation to the Create
> request
> direction?

I cannot correlate your question with the section. Do you refer to a
different section?

> 
> 10. Section 4.2.3: What if the additional port isn't being mapped
> towards the same host as the first one, i.e. is it possible to use this
> as attack vector to block a port that isn't used by oneself?

Hmm, the intention is that the ports are all opened for the *same*
IP address, i.e., getting all to the same host.
Your cases would be clearly an implementation bug, as one NI is
asking for a configuration for IP-address + {number of ports}.

> 
> 11. Section 5: I think the security model is extremely heavy weight,
> especially requiring egress nodes to have trust relationship with other
> networks egress nodes. Are there any way that can make the proxy-mode
> usage and scaling that to dual mode work in such way that the
> complexities are primarily about authentication and authorization
> within
> ones own network?

You describe actually the intention of the proxy mode, i.e., the 
authentication and authorization should be done locally. I guess
this needs a better write-up to show how this will work.

> 
> 12. Section 7:
> I think the document needs to be more explicit what information that
> are
> present in the registries. For example the Message type registry seems
> to be a Name, values and reference. Also what the current values are
> which can be addressed either by explicit tables in the IANA section or
> a pointer to the relevant section.

Yes, indeed. Will fix this.

Thanks,

  Martin