[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [NSIS] 3.2.2 in draft-ieft-nsis-nslp-natfw-02.txt
hi robert,
as part of our action item assignment cedric aggreed to take a look at this
issue. have you seen his posting at:
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-natfw-issues/issue7
btw, i have added your text there as well.
ciao
hannes
> -----Original Message-----
> From: Hancock, Robert [mailto:robert.hancock at roke.co.uk]
> Sent: Tuesday, May 25, 2004 12:35 AM
> To: 'nsis at ietf.org '
> Subject: [NSIS] 3.2.2 in draft-ieft-nsis-nslp-natfw-02.txt
>
>
> dear all,
>
> I have been reading the NATFW draft more from a GIMPS
> perspective, and I have one specific comment. (I won't
> say there won't be more...)
>
> 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 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.)
>
> 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.)
>
> (The second point is the partial motivation for the
> restructuring of GIMPS D mode which I will describe in
> a separate email.)
>
> robert h.
>
> _______________________________________________
> 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