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

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 10 May 2006 09:59:39 +0100

hi all, 

i'm still trying to get my head round sections 3.8.2 and 3.8.7 of 
the spec (which i think is what most of the thread below is about). 

however, i do have a specific comment about the applicability of the 
LE-MRM and PC-MRM for various types of scenario. i'll say in advance 
that i'm not 100% certain that the LE-MRM definition is right; 
however, the discussion below is not persuading me that it is wrong. 
i'll try to explain why:

from a GIST perspective, the purpose of the LE-MRM is to allow an
NSLP at an end host to talk to the 'edge' of the network and to
get signalling messages back. from that point of view, no port numbers
are needed at the GIST level, because there are no port numbers
associated
with the concept 'edge of the network'. routing state can be quite
happily created at NATs along the path [how? see below] and GIST 
messages can be sent backwards and forwards as the NSLP requires.

it turns out that the NATFW NSLP may need a port number for NATFW
purposes; specifically, that the external address that gets allocated
may actually be a {address, port} pair, if the NAT is doing address
sharing [if i understand it right ...]. However, in this particular
case, it's vital that the {address, port} information is *not* carried
at the GIST level, since it's vital that these are *not* translated
on the way back to the end host - the end-host wants these unmodified
so it can advertise them in the public network. so {address, port} have
to be carried at the NSLP level (where other funny processing also
takes place on them).

the question then arises whether other NSLPs might want to use the
LE-MRM and might need to have port numbers translated for them if 
the signalling path went through a NAT. I can't assess that either 
way at the moment; however, I can say that the QoS-NSLP is not a 
valid example. if the QoS-NSLP wants to use some sort of proxy mode, 
then it should use the upstream PC-MRM, not the LE-MRM. this is 
because the QoS-NSLP talks about flows, not about network edges.
if the QoS-NSLP wanted to manage QoS for something which wasn't a 
flow but which was bound to a network edge for some reason, then the
LE-MRM might be appropriate - but then there would be no port numbers
involved anyway. and i think that the same line of reasoning would
be applied to other NSLPs also.

there remains the question of how GIST gets LE-MRM-routed traffic
through a NAT. i think there are two cases here:
*) if the NAT hosts the NSLP in question, it is a non-issue. the
signalling traffic is presented to GIST by the NSLP separately
on each interface, and the NSLP is responsible for choosing the
MRI/SID/NSLP to pick out the routing state towards the right peer.

*) if the NAT does not host the NSLP in question, GIST has to do
MRI/NLI/SCD re-writing to get the Query/Response messages backwards
and forwards correctly. no GIST routing state gets established, but
NAT bindings need to be established for the signalling traffic 
itself. but I don't see this requiring access to information that
might be carried in the NSLP; the NAT can use the SID or the UDP 
source port from the Query as keys for its binding table; the 
former we assume to be unique and the latter can be rewritten.

summary: at the moment, I think that the LE-MRM is ok. However, it's
a subtle subject and it's possible that I haven't understood all the
concerns. I'm also not certain at the moment that the way the NATFW
NSLP does things like proxy REA are correct - still thinking ...

cheers,

r.

> -----Original Message----- 
> From: Martin Stiemerling [mailto:[email-masked]] 
> Sent: 08 May 2006 16:01 
> To: Henning Peters 
> Cc: [email-masked] 
> Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns 
> 
> 
> Hi Henning, 
> 
> 
> Am 21.04.2006 um 22:06 schrieb Henning Peters: 
> 
> > Dear WG, dear NAT/Firewall NSLP authors, 
> > 
> > NAT/Firewall NSLP is a quite stable and usable protocol. There is  
> > running 
> > code already available that covers broad aspects of its 
> functionality. 
> > This proves at least that from an complexity and functional  
> > viewpoint it 
> 
> Good to hear that! 
> 
> > can be considered feasible. Still, I find that some parts of the  
> > spec can 
> > be improved. Here, I would like to present my concerns connected to 
> > LE-MRM/DTINFO that I developed during working on our implementation.

> 
> Comments and suggestions are always welcome. 
> 
> > 
> > shortcut: the questions related to WG discussion are at 4). 
> > 
> > 1) Confusing directions 
> > 
> > Most notable, the directions are a bit confusing in this object.  
> > src port 
> > is data sender (DS) port, dst port is data receiver (DR) port. DR  
> > port is 
> > subject of rewrite, whereas DS port specifies the data 
> sender. I would 
> > appreciate avoiding the term source and destination in this  
> > context, this 
> > would also leverage the positioning issue (see later *** when  
> > discussing 
> > the message format that confusely destination port is positioned  
> > before 
> > source port). 
> 
> While the naming is technically correct, I have to admit that it is  
> confusing. 
> So, I would suggest to change the names directly to what you have 
> proposed: 'src port' -> 'DS port' and 'dst port' -> 'DR port'. This  
> is then 
> inline with the naming of 'data sender's IP address' in the 
> same object. 
> 
> > 
> > Anyway, I will refer to DS port and DR port in the following. 
> > 
> > 2) LE-MRM / DTINFO ports 
> > 
> > After introduction of LE-MRM (loose end message routing 
> method) to the 
> > spec last year it was found that NAT traversal in NAPTs is broken as

> > LE-MRM does not carry port information. Ports are 
> considered as not  
> > part 
> > of GIST routing and therefore omitted from MRI. 
> 
> There are two things to differentiate: NAPT support is not 
> broken in the 
> NATFW NSLP and whether NAPT traversal of GIST is broken when using 
> LE-MRM is a different story that depends on the view point. 
> 
> My concern here is about why we need a GIST/LE-MRM NAPT traversal 
> mechanism? When there is a NAT on your side of the network that is 
> not NATFW NSLP enabled you anyway need to fall back to all the 
> other workarounds, such as STUN, TURN, or other tricks. 
> 
> 
> > 
> > To compensate this DTINFO object was enhanced later with the port 
> > information that was previously accessable in PC-MRM 
> (signaling the  
> > wrong 
> > way) MRI. I believe that the current approach is not a good design 
> 
> There is non compensation needed, because GIST carries all information

> necessary for the message routing and the DTINFO object carries 
> information about the later expected data flow. That are basically two

> different things: The message routing information and the expected 
> data flow. 
> 
> > decision as GIST NAT traversal would be rendered broken. GIST NAT 
> > traversal is crucial as we cannot assume a domainwide deployment of 
> > NAT/Firewall NSLP instantly. I would appreciate a 
> deployable over a  
> > 100% 
> > clean solution as deployment will be very crucial to 
> NAT/Firewall NSLP 
> > success anyway. 
> 
> I do not see the applicability given for the GIST with LE-MRM and NAT 
> traversal. I probably need a good example why it is needed. 
> 
> > 
> > See Martin's and my discussion in the issue tracker: 
> > https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue50 
> > 
> > Actually, only the DR port and protocol field is needed for NAT  
> > traversal 
> > as REA/LE-MRM needs only a one-sided translation. 
> > 
> > 3) DTINFO message format 
> > 
> > The message format of the current solution is a bit confusing and  
> > lacks 
> > IPv6 support (DTINFOv6 object was removed in previous draft). Let  
> > me start 
> > with its figure: 
> 
> The DTINFO_IPV6 object has been removed since there is no IPv6 NAT 
> and the usage of NAT-PT seems to be deprecated. 
> 
> > 
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >      |I|P|S|    reserved             |   dest prefix |    
> protocol   | 
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > (***):      dst port number [DR]     |      src port number 
> [DS]     : 
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >      :                            IPsec SPI                 
>          : 
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >      |                  data sender's IPv4 address          
>          | 
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > 
> > The purpose of this object is two-fold: 
> > 
> > - specify data sender during REA (aka: the cone-ness of the NAT) 
> > 
> > - supply DR port/protocol for NAT traversal 
> > 
> > Unfortunately, the draft heavily mixes and overloads these two  
> > different 
> > semantical aspects in this object. Specifically, I see following  
> > issues: 
> > 
> > a) The P flag specifies whether port numbers are present or 
> not. This 
> > means that either both ports are present or none. Confusely, DR  
> > port and 
> > DS port cover different semantic aspects: 
> > 
> > DS port specifies the data sender, DR port is necessary for NAT  
> > traversal. 
> > A single flag to enable/disable two fields with different semantical

> > meaning can be problematic. 
> 
> I makes sense to either enable usage of ports or not. 
> However, if ports 
> are enabled you still can wildcard the DS port. This makes some sense 
> from the point of whether your policy rule to be installed in 
> the device 
> covers port numbers or not. 
> 
> > 
> > b) The I flag specifies whether the protocol field should be  
> > interpreted 
> > or not. The protocol defines the protocol used for above mentioned  
> > ports 
> > if the P flag is set aswell. Although the ports are of different 
> > semantical meaning, the protocol covers both equally. 
> > 
> > I am not sure whether this semantical overloading may introduce new 
> > problems, at least this limits flexibility compared to PC-MRM case  
> > where a 
> > protocol can be set in MRI and in DTINFO independently. 
> 
> DTINFO and PC-MRM cannot be used at the same time. *BUT* this is 
> not specified in the draft :-) 
> I will fix this. 
> 
> > 
> > c) DTINFO object might be used for firewall signaling scenarios. But

> > LE-MRM can only cover NAT-only scenarios. That means that the NR  
> > has to 
> > know the scenario in advance to choose between PC-MRM and LE-MRM 
> > signaling. The more intelligence is put into NR the more it 
> evolves  
> > to a 
> > probing NR. 
> 
> Right, NR needs to choose carefully in what scenario it is. But the  
> DTINFO object 
> is not useful in firewall only scenarios, since those messages are  
> anyway 
> carried using the PC-MRM. 
> 
> > 
> > A probing NR sounds to me a bit like the situations BEHAVE working  
> > group 
> > deal with; this is not the situation I would like to see NAT/ 
> > Firewall NSLP 
> > in. I think that our network states can be used more flexibly to  
> > assist 
> > the NR better. The NR should not care about the network, but only  
> > give the 
> > definitions that the network should adapt to. 
> 
> I would prefer a different way of deciding whether the NR is NATed or 
> firewalled only. However, until now there has been now good proposal 
> how to avoid this. Suggestions are welcome. 
> 
> > 
> > Surely, this is a design decision that needs WG consensus. 
> > 
> > d) DTINFO object MUST be included when using LE-MRM as NAT  
> > traversal is 
> > not possible as long as DR port is not available. 
> Therefore, following 
> > paragraphs might need correction: 
> > 
> >> The NI+ MAY include a NATFW_DTINFO_IPv4 object in the REA message 
> >> when using the LE-MRM.  The LE-MRM does not include enough 
> > 
> > also: 
> > 
> >> When the data sender's address information is known in 
> advance the  
> >> NI+ 
> >> MAY include a NATFW_DTINFO_IPv4 object in the REA message (as  
> >> described 
> >> above). 
> 
> Already noted this. 
> 
> > 
> > 4) I hope I pointed out that a discussion of following points in  
> > the WG is 
> > necessary: 
> > 
> > - How much intelligence should have the NR -> shall the network  
> > handle the 
> > deployment sceario or should the NR know/probe the network scenario?

> 
> As said, I'm open for suggestions! 
> 
> > 
> > - Is a broken GIST NAT traversal worth giving up a 100% clean MRM  
> > design? 
> 
> I still lack the real usage scenario for GIST with LE-MRM NAT 
> traversal. 
> 
> > 
> > The message format issues heavily depend on these discussions,  
> > therefore I 
> > would rather like to delay the message format design until both  
> > questions 
> > gained consensus. 
> > 
> > I also appreciate any feedback on our NAT/Firewall NSLP 
> implementation 
> > available at: 
> > 
> > http://user.informatik.uni-goettingen.de/~nsis/ 
> 
> I hope to get some time for checking this out. 
> 
> > 
> > Thank you for your attention, 
> 
> Thanks a lot for the comments! 
> 
> > Henning Peters 
> > 
> > 
> > _______________________________________________ 
> > nsis mailing list 
> > [email-masked] 
> > https://www1.ietf.org/mailman/listinfo/nsis 
> 
> 
> _______________________________________________ 
> nsis mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/nsis 
> 

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

---

From: "Henning Peters" <[email-masked]>
Date: Wed, 10 May 2006 14:32:37 -0400 (EDT)

Hi Robert,

good summary. Though, I am missing one point:

In a hierarchical NAT scenario, is it sufficient only talk to the edge to
make a reservation? An example:

   A:NI --[ B:NF(NAT) --[ C:NF(NAT) --- D:NR
1)             <=========================REA
2)             RESPONSE====================>
3)    CREATE====> ============> X =========>  X...marks the problem loc.
4)    <========== <============= <==RESPONSE

Assumption: In this scenario I assume that a REA(1) message with LE-MRM
does only talk to the edge and traverses C seemlessly. C may trigger a
reservation, read the flow, but will not change any data of the message
exchange between B and D.

For an upcoming CREATE(3) message from A it seems to be necessary for B to
previously store the IP address of the C during REA(1) operation, because
B has to map between different session IDs based upon the external port
reservations. It also has to know the external port reservation of C.

Thus, in respect to NAT behavior, B has to translate the IP and TCP/UDP
layer and update MRI accordingly to match the new destination
address/port. But: how does B know about a valid destination port at C?

In my view all NAT have to do a mapping unrelated to session ID, but on IP
address and port, because REA and CREATE messages are different sessions.
Thus, they need a mechanism to signal their external port reservation to
the upstream NAT, this is not possible without modifying the exchange
between B and D. Thus my previously made assumption is wrong.

Hence, I asked Martin to give me a port field, it was introduced in last
fall. The whole issue is complicated, so I am not 100% sure whether I
might not miss a point. If I might be right, then I have following
concern:

LE-MRM is not only about "talking to the edge". Therefore, I find it
sensible to put the port into LE-MRM. Please keep in mind that I might be
biased, because I want to keep my codebase small ;).

Currently the port resides in DTINFO object. So, if signaled with LE-MRM
one has to use this field, when using PC-MRM one has to use MRI port
although the port is here needed for the same purpose: giving the upstream
NAT information about the local NATs port reservation. Sure, in PC-MRM
this information is overloaded the same way as NAT is already overloading
identifiers.

Henning

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 11 May 2006 15:30:41 +0200

Hi Robert and All,

> be applied to other NSLPs also.

Nothing to say other that I fully agree. Good that we've had the sushi
in San Diego ;-)

> former we assume to be unique and the latter can be rewritten.

 From the NTLP point that is all right. However, semantically the
purpose of LE-MRM NAT traversal support at the NTLP is
questionable (therefore I have asked Henning about use
cases). A message with LE-MRM is used to locate a network
edge with a NAT to enable inbound traffic. A REA message would
be used in conjunction with the LE-MRM. If this type of message
is transparently pushed through a NAT (let's call it N1) and intercepted
by yet another edge-NAT (N2) beyond this, we get some non-issue
as well. N2 can enable locally the NAT bindings for inbound data  
traffic,
but how is this done at N1? The NATFW NSLP signaling messages
can be exchanged between the hop before N1 and N2, but
there is no way out of the NATFW NSLP to configure N1 for the
expected inbound traffic. The NI would anyway need to use some
other sort of NAT traversal technique.

> NSLP does things like proxy REA are correct - still thinking ...

I also see no issue with LE-MRM in the current NATFW NSLP usage.
However, no guarantee for other NSLPs.

There is no doubt from my side about proxy REA and LE-MRM.
The semantics of REA on the NTLP level itself is not changed for
proxy REA. Proxy REA just needs to carry additional information
for generating the latter CREATE. The CREATE is independent
of the signaling state created by REA. The proxy REA is, in the
first place, doing exactly the same job as REA: Finding the network
edge with an edge-NAT.

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 11 May 2006 15:37:55 +0200

Hi Henning,

> exchange between B and D.

Does this imply C:NF(NAT) being NATFW NSLP unaware or do you say
C:NF(NAT) is NATFW NSLP aware but does not care about the message?

The picture does not show the NATFW NSLP operation
if C:NF(NAT) is NATFW NSLP aware.

Can you clarify this? Otherwise the answer to this email is going  
full of ifs.

Thanks,

   Martin

---

From: "Henning Peters" <[email-masked]>
Date: Thu, 11 May 2006 13:56:24 -0400 (EDT)

Hi Martin, hi Robert,

Martin said:
> ... semantically the
> cases).

Sure:

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.

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

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.

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.

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

Henning

---

From: "Henning Peters" <[email-masked]>
Date: Thu, 11 May 2006 13:59:00 -0400 (EDT)

Hi Martin,

> if C:NF(NAT) is NATFW NSLP aware.

C is a NATFW NSLP aware hop with the artificial restriction that it does
not add port information. By this negative conjecture I wanted to show
that the port  indeed is necessary for upstream NAPTs, not only the edge.
My point was that LE-MRM does not only talk to the edge (as Robert said
previously), but also to all intermediate NAPTs.

Henning

---

From: Henning Peters <[email-masked]>
Date: Thu, 18 May 2006 11:06:08 -0400

Hi Martin,

see inline:

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

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

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

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

 > 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

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 18 May 2006 15:45:23 +0200

> not much better off than BEHAVE folks doing hole-punching or  

Well, semantics are usually derived from real life. 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.

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

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 22 May 2006 16:05:46 +0200

Hi Henning,

> previously), but also to all intermediate NAPTs.

I see us on the same side. The intermediate NAPTs need the port  
information
as well. However, Robert's comment on "need for talking to the edge" is
valid, since the host behind a NAT is basically interested in the  
external
IP address and port and does not care about what is happening in
between.

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 23 May 2006 14:51:17 +0200

Hi Henning,

> iptables guys probably don't want to support a full NSIS stack.  

Here I see a strong disagreement and some issues on predicting future.
I believe that the iptables folks wouldn't care about a GIST ALG but  
rely
on somebody else to program the NSIS stack. However, that's trying to
tell the future.

> I don't understand this paragraph, could you explain it to me  

Sorry for being so fuzzy; I assume it would need paper to sketch it  
in a good
way. Anyway, since we some miles apart, I will try to write it down.

Two cases to distinguish a) GIST unaware NAT traversal and b) GIST
aware NAT traversal, i.e., the NAT has a GIST ALG. The topology is
given as

   NI+ ~~~~~  home-NAT ~~~~~ edge-NAT ~~~~~ the Internet

NATFW sig. ========|=========>|

data direction <----------<-----------------<---------------

The home-NAT is either case a) or b)

For a): The NATFW signalling (on top of GIST) may pass through the
home NAT, even though this can be tricky. [Try sending IP datagrams
with IP option set to router alert through your home-NAT. Typically,
the home-NAT will not forward these packets.]
(Here it is assumed to run with PC-MRM, i.e. ports are included)
The NATFW signalling will reach the edge-NAT and the NI+ can
exchange signalling messages with the edge-NAT, either via
D-MODE or C-MODE, latter would be preferable, because of the NAT.
The data flow information stored in the MRI is not usable by the
edge-NAT, since the data flow receiver's IP address is set to a
private IP address the respective private port number (if applicable).
The edge-NAT could obtain an external IP address and port number,
but it cannot make the mapping between external IP address/port
and the inbound IP address/port at the home-NAT. The NI+ would
be required to foresee this situation and to obtain the IP/port at the
home-NAT in advance, add this in the MRI as destination address
and send the message. However, this looks rather odd.

For b) Here, the home-NAT would intercept the signalling
and modify the MRI according to the NAT traversal needs
(i.e. port translation, etc). This would work, since the GIST-ALG
can modify the MRI and set the mapping entries in the NAT
accordingly. (see also the question later!) The edge-NAT would get
an MRI with destination address set to the external IP/port at the
home-NAT. It works fine for the assumption PC-MRM, with
LE-MRM it would not work. PC-MRM is anyway used when
the data sender is known in advanced, but there are many
cases where the data sender is not known. For instance,
but not limiting to, SIP early media and a server behind a
NAT.

Question: Would the GIST-ALG just intercept the messages
and modify them on the fly or would it act as a peering GIST
node, i.e., your messaging association is done between
NI+ and the home-NAT?

Coming to a conclusion: As you have said, having ports
included in the LE-MRM MRI would allow case b),
semantically, they do not belong there, because they
are not needed to route the message.
This leads more to a global question: How is the
NAT traversal of NSIS seen? I do not see
consensus about this issue in the WG, i.e., how
to deal with GIST-enabled NATs that do not have
the NSLP installed.

> GIST is a much harder deployment constraint.

I wouldn't say that GIST NAT traversal is bogus anyway, but I there some
constraints that need to be considered first. There is a draft on GIST
NAT traversal which can be a good start. (see also my thoughts above
on whether this type of NAT traversal is accepted within the WG.

> >> that NAT/Firewall NSLP should avoid any type of probing,  
> otherwise  we
> >> are
> > know from where your later data traffic is coming, e.g., SIP  
> early media.
>

With NATFW enabled firewalls you are on the right side. All others will
require heavy probing.

> >> a firewall in the administrative domain or not. Honestly, I  
> would  not
> >> miss

No, I mean whatever combination of NAT'ed and firewalled (or not).  
There is
a semantically difference between sender address wildcarded PC-MRM and
the LE-MRM. Using a wildcarded PC-MRM will lead you nowhere when you
are in a network with multiple inbound NATs. GIST cannot know to  
which point
it should forward the signalling message and the forwarding is very  
likely
to be stopped half-way without reaching the edge. With LE-MRM, GIST can
always forward the signalling message to some edge-NAT. For inbound
data flows is does not matter (only to some degree of course) which  
NAT you
hit, since the data flow is anchored at the external IP address at  
the NAT.
However, by choosing a good signalling destination address (SDA), you
can get the better edge-NAT, e.g., the one topology-wise closest to the
possible data sender.

   Martin