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

Hi,

Removed the issues where resolution seems completed and there where no
question.

Martin Stiemerling skrev 2010-01-27 09:37:
> 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.
> 

Thanks, placement at your discretion.

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

I think that is ok.

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

Sounds to resolve this issue.

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

Thanks, that is much clearer.

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

Ahaa, didn't get that when I looked at it.

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

Yes, but can you add a definition in the document?

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

My question is where the transport protocol for which the port number
applies is specified when this object is included?


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

I think I am meaning 4.2.3, the Extended Flow Information Object. I
think it has to do with the policies. Are the policies bi-directional or
only applying in particular 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?
> 
> 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}.
> 

So there are two layers here I think. The first one is the obvious
control the middlebox should perform, don't allow different users to
affect the other users rules.

However, the second layer is for example a setup that looks like this.

 T ---
      |
      NAT  --- FW
      |
 A ---


If A asks for blocking a range on the FW that covers a port "owneded" by
T on the NAT, what happens in that case? Also does this become a
question of timing? If T was before A, A can put in place a rule, but if
A is before T then T can't open up its port?

Also what about the legacy case, where the NAT is not NSIS capable?

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

Ok


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