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

Here are some replies:

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

Done, i.e., added note right after the table.

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

This information is carried in the NATFW_DTINFO object.

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

Policies are applied for a particular direction, thus a bi-directional flow needs to be signalled by both ends (where an end may be a proxy).

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

Yeah, this is really an issue not yet covered. 

I guess the solution is to stop request  messages with 'deny' at the first NATFW NSLP hop. This will protect the NI as requested. Otherwise, the situation as described above might occur and I don't see a workable solution right now. 

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

Even more difficult question and this one I cannot answer. Any help from the WG.

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

Added text in the security section (5.3.  Implementation of NATFW NSLP Security).

 Martin