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
need to be a full fledged example for a receiver proxy case with
indication where an application would do the signaling to exchange
information.

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

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?

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.

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

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.

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.

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

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?

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?

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?

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.

Comments?

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email protected]
----------------------------------------------------------------------