Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns

[Henning Peters <[e-mail]>]

Hi Martin,

see inline:

 >> 1) I might want to configure my local NAT (fitted with an NSIS ALG)
 >> manually, but do not have access to a hierarchical remote NAT (e.g.,
 >> located at ISP). Therefore, I want to have a mechanism that works
 >> seemlessly. Future application might support NSIS + NAT/FW NSLP
 >> out-of-the-box, without being able to "talk to the edge" creating a  NAT
 >> reservation at ISP level is impossible.
 >
 >
 > A question ahead: Why should NAT be equipped with an NSIS ALG but
 > not with an NATFW NSLP? When the NAT vendor is already providing
 > an NSIS ALG (I assume a GIST ALG) the way to the NATFW NSLP is
 > not that long anymore. This seems to be a very constructed case.

Sorry, surely a GIST ALG. I think it's just practical, i.e., one might
extend iptables with such a functionality without much trouble, but
iptables guys probably don't want to support a full NSIS stack. Iptables
has a very high coverage of deployed NATs, including non-PC devices. Of
course, this should not drive our thinking as it's focus is on a
short-term scale, but I think we should have an idea how reality looks
like beyond IETF documents. Thus, I think my scenario is very real and
far away from being constructed.

 > However, even the local NAT is configured manually to let GIST messages
 > traverse and the NAT bindings for the data flow are statically 
configured,
 > how is the correlation at the edge-NAT made between the  the inbound
 > external port and the port at the local NAT? This would require that the
 > NI sets the IP address and port information to the external 
parameters at
 > the local NAT? This isn't anymore the NATFW NSLP as it is right now.

I don't understand this paragraph, could you explain it to me again, please.

 >> Also, the local NAT can be later replaced transparently with real NSIS
 >> machine to cope more functionality (e.g. QoS NSLP). I see this as a
 >> deployment advantage. Otherwise we have to believe that within all
 >> domains
 >> deployment switches to NSIS at once - this would be nice (i.e.,
 >> IPv6), but
 >> hard to believe (i.e., IPv6)... ;)

 > The assumption is NOT that NSIS is deployed at once in all domains
 > (whatever
 > domains means here). The assumption is that at least one side of the
 > network
 > is NSIS-aware. The case you have mentioned could be already seen as
 > two domains (you and the operator ;-)

ok. But then GIST NAT traversal is bogus anyway...!? If you have
deployed GIST, adding NAT/FW NSLP is not the issue. Having support for
GIST is a much harder deployment constraint.

 >> 2) I don't care about semantics if it does not work in reality. My
 >> view is
 >> that NAT/Firewall NSLP should avoid any type of probing, otherwise  we
 >> are
 >> not much better off than BEHAVE folks doing hole-punching or 
praying for
 >> hairpin-translation.

 > Well, semantics are usually derived from real life.

Every derivation includes errors. If there would occur no errors in the
derivation process I would assume that semantics must perfectly match
reality. This does not seem always the case. I argue that the semantics
of LE-MRM look clean, but might not match "real life" as good as possible.

 > However, there are
 > cases where you need to obtain a public IP address even you do not
 > know from where your later data traffic is coming, e.g., SIP early 
media.

Sure, most prominently all symmetric NAT issues are concerned with that
problem. I don't see a reason why PC-MRM should not disallow DTInfo
object. Also, GIST MRI supports wildcarding in a similar way as DTInfo
supports it.

 > There is possibly not much probing. When you are NAT'ed, use the
 > LE-MRM; if not use the PC-MRM. Still you could argue about the NI
 > being unable to find out if it is NAT'ed our not. However, this could be
 > either a configuration or some other mechanisms.

NAT is not a problem (-> STUN), firewalls are: What about being NAT'ed
_and_ firewall'ed? How do you detect the firewalls? I only know
non-deterministic approaches to do that.

 >> Thus, an application (aka NI+) that wants to receive incoming traffic
 >> should not worry about the difficulties about this operation. This 
means
 >> that it should not need to probe anything. The decision whether to use
 >> PC-MRM or LE-MRM requires knowledge about the network structure: Is
 >> there
 >> a firewall in the administrative domain or not. Honestly, I would  not
 >> miss
 >> LE-MRM if we would drop it.

 > There is no knowledge about the network structure needed, i.e., you do
 > not care about topology and order of devices in the topology. You need
 > to know wether you are NAT'ed or not. This is indeed difficulty in some
 > environments but in many it is quite obvious.

see above.

 >> In case we stay with LE-MRM in the spec (whether it will be used
 >> might be
 >> a different question), I think that we should design it with maximum
 >> deployment support in mind - in this sense I believe that we should  not
 >> equip the semantical aspect with the highest priority,
 >>
 >> So let me pose the question the other way around: What is the use
 >> case for
 >> NAT-only operation (aka LE-MRM)? Aren't our networks already fitted
 >> with a
 >> multitude of both: NATs and firewalls?! Can we really be sure that the
 >> network does not change or that endpoints attach to new networks at  any
 >> time? Those changes should be handled transparently... and LE-MRM 
is not
 >> able to do this for firewalls, but only for NATs...

 > Right, the LE-MRM is "only" used for NAT'ed hosts that do not know  the
 > other
 > side, i.e., the data sender. In this case, the PC-MRM cannot be used.

You mean: NAT'ed _and_ not firewall'ed. How would you use wildcarding in
a NAT+firewall environment using PC-MRM. The same way it could be done
for NAT-only case with marginal effort and complexity (from both,
development and standardization perspective).

Henning

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis