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

[Martin Stiemerling <stiemerling at netlab.nec.de>]

Hi Robert,

[...]
|>
|> 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)

Right, that's how the message forwarding is currently intended.

| the NAT->DR should be sent in 'downstream' mode (which doesn't
| require any pre-existing NTLP state at the FW node).

The message NAT-->DR is not enabling a path (i.e., not opening any firewall 
pinholes or NAT bindings) on the way back, this message is just to confirm 
that an external address has been reserved, thus being uninteresting for 
intermediate firewalls and only interesting for DR. The response message 
traveling upstream from NAT-->DR is need to confirm to intermediate NATs. 
This could be done via a new downstream message NAT-->DR, because this 
message will hit intermediate NATs anyway (path might be 
edge-NAT-->NAT-->DR).  Doing this would generate more state at this point 
of time as actually needed.

The real path between NAT-->DR is generated by the subsequent create 
message (traveling downstream) coming from the real NI: NI-->NAT-->DR. This 
message will be processed at intermediate firewalls and create NSLP state 
there.

Hope that this is not that confusing, or I may have missed the point.

[...]

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


Got it, but I have been late with reading emails...

Thanks,

 Martin

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