RE: [NSIS] 3.2.2 in draft-ieft-nsis-nslp-natfw-02.txt

["Hancock, Robert" <robert.hancock at roke.co.uk>]

hi martin,

> Don't be shy ;-) , NATFW NSLP authors are waiting for comments!

I will see what I can do...

> | 3.2.2 describes the procedure for reserving an external
> | address; my question is whether this message needs to
> | be routed by GIMPS in a special way. (This was hinted
> | at in both my and Martin's Seoul presentations, but we
> | didn't go into any more detail.)
> |
> | The basic concept is that, for a receiver DR to reserve
> | an external address, it sends a message to NR+ (some
> | address in the 'outside world') which is intercepted at
> | an edge NAT and responded to with the address to be used.
> | The implication of the text in 3.2.2 is that the
> | DR --> NR+ message is sent using GIMPS downstream routing
> | (D mode discovery messages) which sets up reverse path
> | state in intermediate GIMPS nodes which will be used
> | in forwarding the response from the NAT --> DR. There
> | are two issues here:
> |
> | Firstly, I'm not clear that the NAT --> DR handling is
> | correct. Presumably if these messages are setting up
> | non-trivial state (e.g. in intermediate firewalls) then
> | they should be routed the same way as the flow from
> | NAT --> DR. In asymmetric routing cases, there is no
> | reason for this to be the same as set up by a DR --> NR+
> | message. Also, if the routing changes, refreshes from
> | DR will be no good at detecting it. Surely what is
> | needed is that the NAT --> DR message is sent as a *new*
> | _downstream_ message from the NAT along the correct flow
> | path (and not using any GIMPS state from the DR --> NR+
> | message).
> 
> In the reserve external address handling, firewall should not 
> remember any 
> NSLP state since they are not involved at this stage of the 
> NATFW NSLP 
> processing. Only NATs should participate; you have mentioned 
> above the 
> reason for this: asymmetric routing on the path NAT-->DR. The 
> path NAT-->DR 
> is found/configured via the create message from DS-->DR.

This leaves me even more confused than I was before. Let me ask
a more specific question: what is done about NTLP state for 
messages which pass between the DR and its *nearest* NAT, or 
between *adjacent* NATs (i.e. I know that the sequence of NATs
is pinned by the address reservation process):

*) does a Firewall between the NATs store state? Obviously it
doesn't store NSLP state (as you say above); however, the draft
says that for a DR->NAT message "They simply MUST forward the 
message and MUST keep NTLP state." Since the only interesting 
state in the NTLP is reverse routing state, this implies to me 
that the 'return external address' message from NAT->DR needs
that state in place to be forwarded correctly, which implies that
the NAT->DR message is being sent in 'upstream' mode using that
reverse routing state at the NTLP level. But (as argued above)
the NAT->DR should be sent in 'downstream' mode (which doesn't
require any pre-existing NTLP state at the FW node).

> 
> Routing changes are in general (at least I think so, but I 
> might be wrong) 
> not a concern for NATFW NSLP as long as the NATs stay alive.  
> Since the 
> path is pinned down by the NATs, routes may change in between of them.
> 
> |
> | (In general, in any case, it would be helpful to specify
> | what GIMPS mode is used more explicitly (hopefully this
> | will be easier to make clear once we have sketched an API
> | to describe this in terms of.)
> 
> Yes, indeed. The NATFW NSLP should state this in the next revision.
> 
> |
> | Secondly, the implication is that the initial message
> | from DR --> NR+ needs to be handled differently from
> | 'normal' GIMPS messages. There are at least two reasons:
> | the intermediate state storage issue, and the fact that
> | the message is not actually about a flow, so the rules
> | GIMPS imposes on message processing from analysing the
> | embedded flow identifier may no longer apply. (For example,
> | GIMPS can apply policy/ingress-filtering like rules to
> | ensure that messages are only accepted if they come from
> | the 'right' peer node for that flow-id. Such rules are
> | not valid or relevant for the DR --> NR+ message.)
> 
> One way of handling this is the usage of an extra NTLP field, 
> saying "bring 
> this message towards this destination, but that's not the real, later 
> source". I'm working currently on a more detailed description 
> for this 
> issue.
> 
> |
> | (The second point is the partial motivation for the
> | restructuring of GIMPS D mode which I will describe in
> | a separate email.)
> 
> Alright, looking forward to the email.

I already sent it ... maybe it got lost in the noise:
http://www.ietf.org/mail-archive/web/nsis/current/msg04054.html
It's really just a 'preview' of the discussion about 
message routing methods and message routing information
that we had at the interim (why the NTLP-02 says "MRI"
all over the place rather than "FRI", esp. in section 8.9).

r.

> 
>   Martin 
> 
> _______________________________________________
> nsis mailing list
> nsis at ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis