Subject: [NSIS] review of the "NAT/Firewall NSISSignaling Layer Protocol (NSLP) "

From: "Dan Wing" <[email-masked]>
Date: Thu, 15 Jun 2006 20:56:56 -0700

John,

I read through parts of draft-ietf-nsis-ntlp-09.txt to understand 
how NATs are handled in NTLP.  In that document's section 7.2,
"NAT Traversal", it says:

   5.  Add a NAT-Traversal payload, listing the objects which have been
       modified and including the unmodified MRI and any other data
       needed to interpret the response.  (If a NAT-Traversal object is
       already present, in the case of a sequence of NATs, the list of
       modified objects may be updated and further opaque data added,
       but the MRI contained in it is left unchanged.)

which sounds like you would be disclosing my 'private' IP address on the
public side of an NSIS-aware NAT.  I believe I'm misinterpreting that, as in
-ietf-nsis-nslp-natfw- I found text that alluded to avoiding such
information leakage by having the outer-most NAT or firewall configured to
know that it is the outer-most NAT (or firewall) and to terminate REA
processing.

Section 1.1 mentions STUN and TURN only being able to process two IP
addresses; have you looked at ICE and would it be useful.  I noticed the
reference to TURN should be updated to draft-ietf-behave-turn.

On to -nsis-nslp-natfw-11:

My first concern with this is Appendix A and section 3.8.2, which outlines
the fundamental problem of NAT traversal -- how to "leave" your network, on
the correct path, in order to get the NSLP messages to traverse the NATs
that are on-path between you and your intended peer.  This problem is
similar to STUN, am I correct?   Section 3.8.2 uses words that almost say
it, as well:

   o  It may be necessary to use a signaling destination address (SDA)
      as the actual target of the REA message (NR+) if the DR is located
      behind a NAT and the address of the DS is unknown.  The SDA is an
      arbitrary address in the outermost address realm on the other side
      of the NAT from the DR.  Typically this will be a suitable public
      IP address when the 'outside' realm is the public Internet.  This
      choice of address causes the REA message to be routed through the
      NATs towards the outermost realm and would force interception of
      the message by the outermost NAT in the network at the boundary
      between the private address and the public address realm (the
      edge-NAT).  It may also be intercepted by other NATs and firewalls
      on the path to the edge-NAT.

It seems that applications will need to collect several different routable
addresses and exchange those addressees with their intended peers in order
to optimize the network path.  This is what ICE does, and a generalization
of this technique is described in draft-ford-behave-app-02.txt section 2.3.

I'm also concerned by configuration information that is necessary, such as
this (in 3.8.2):

   The data receiver is
   challenged to determine whether it is solely located behind firewalls
   or NATs, for choosing the right message routing method.  This
   decision can depend on a local configuration parameter, possibly
   given through DHCP, or it could be discovered through other non-NSLP
   related testing of the network configuration.

and

   The end host cannot be assumed to know this [[the NAT device]] device -
   instead the NAT or firewall box itself is assumed to know that it is
   located at the outer perimeter of the network.  

For example, I am typing this message from my house, where I have two NATs
and a hardware VPN with split tunneling.  If both of my NATs were NSIS and
NSLP aware, I don't know how they would successfully send the appropriate
NSIS messages in this configuration; can you elaborate what my application
or my NSIS-aware OS stack would do in this situation?  From my experience,
my application would need to gather different IP addresses (one from my
'internal' network that I'm IPsec'd into, another from my local interface,
and another from my connection to the Internet).  Even if this _isn't_
necessary -- and I don't see how you'd have success otherwise, but I'm
interested in hearing -- I'm curious what information would be in this
as-yet-undefined DHCP option (I didn't notice any NSIS-related DHCP
document).

On page 7 is this sentence fragment:

  However, if the data receiver resides in a public 
  addressing realm. 

Figure 3 and its associated text would be clearer if the middleboxes were
numbered and the text referred to each middlebox explicitly.  Specifically,
the sentences:

   Note that this IP address is not the private
   IP address of the responder.  Instead a NAT binding (including a
   public IP address) has to be previously installed on the NAT that
   subsequently allows packets reaching the NAT to be forwarded to the
   receiver within the private address realm.

have too many "this" and "a NAT binding" and "the NAT" to be clearly
understood.  The other diagrams in surrounding figures 2 through 6 might
also benefit from similar changes.

Section 2.8, "Multihomed Network with NAT" promises that section 3.8.2 has
an extended discussion of such multihoming, but I didn't find anything in
that section related to multihomed NATs.

-d

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Tuesday, May 02, 2006 4:28 AM
> To: [email-masked]
> Subject: [Ietf-behave] Request for a review of the 
> "NAT/Firewall NSISSignaling Layer Protocol (NSLP) "
> 
> Hi all,
>
> Currently, the NSIS working group is finalizing the "NAT/Firewall
> NSIS Signaling Layer Protocol (NSLP)" for signaling middleboxes.
> The current document can be found here:
>
> Http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt
>
> NSIS is working on a path-coupled signaling protocol, to signal
> nodes along the data patch.  As both NAT and Firewalls are along the
> data path, NSIS signaling is developing a protocol for allow end
> nodes to signal these boxes.
>
> As both BEHAVE and MIDCOM have been working on related issues, I'd
> like to encourage people to read the document and send comments and
> questions to the mailing list - [email-masked].  As long as your
> subject lines are clearly marked, I'll enable posting rights so that
> you don't have to join the NSIS mailing list.
>
> Additionally, please try not to cross-post discussion on the other
> mailing lists; unless the BEHAVE & MIDCOM chairs feel that
> cross-posting would be beneficial.
>
> thanks,
> John 
> _______________________________________________
> Ietf-behave mailing list
> [email-masked]
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 

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

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 21 Jun 2006 15:24:45 +0200

[posting to the nsis list only]

Hi Dan, All,

Many thanks to Dan for reviewing the NATFW NSLP!

More inline.

> know that it is the outer-most NAT (or firewall) and to terminate REA

There some difference between the NAT behaviour in the NTLP spec
and the NATFW NSLP.  The NATFW NSLP follows the way of not
disclosing any private IP address. The way how the NTLP will do it
has been specified to some extend in the draft but is undergoing some
additional work and thoughts. I.e., the NTLP is probably disclosing
the private IP address to NTLP nodes outside the private IP address
realm. (as Andreas mentioned there is another draft discussing the
NAT traversal of the NTLP without a NATFW NSLP)

> reference to TURN should be updated to draft-ietf-behave-turn.

I believe this refers to the NTLP draft.

> similar to STUN, am I correct?   Section 3.8.2 uses words that  

Right, it is similar to STUN and ICE issues.

> of this technique is described in draft-ford-behave-app-02.txt  

Yes, indeed, an application can collect multiple addresses if needed. An
optimization would need to find out which of the obtained public contact
addresses is the best suited.

This section in the appendix is one of my open work items for the draft,
since it is crucial for operating the NATFW NSLP. Thanks for the pointer
to the BEHAVE draft. I will check it and then go back to the section.

> or my NSIS-aware OS stack would do in this situation?  From my  

I'm happy to clarify but I have to say I would need some information  
about the
ordering of the NATs and the VPN gateway in the topology. Are those
two NATs in sequence or in parallel? (I assume the latter?)

>   However, if the data receiver resides in a public

Will be removed, seems to be a left over from some old text.

> also benefit from similar changes.

Ok, thanks! That makes understanding easier.

> that section related to multihomed NATs.

Good catch! I need to write some text on this.

Many thanks and I will come back to the question on who the NATFW NSLP
will work in your home configuration as soon as I have the information
about the topology.

   Martin