Subject: Re: [NSIS] Incremental deployement story fordraft-ietf-nsis-nslp-natfw-20

From: "Martin Stiemerling" <[email-masked]>
Date: Mon, 11 Jan 2010 15:24:49 +0100

Hi Magnus, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Magnus Westerlund
> Sent: Friday, November 27, 2009 1:57 PM
> To: [email-masked]; NSIS
> Subject: [NSIS] Incremental deployement story fordraft-ietf-nsis-nslp-
> natfw-20
> 
> Hi,
> 
> I am reviewing the NAT/FW NSLP and have some high level questions about
> this work regarding incremental deployment.
> 
> When reading the document I get the impression that it starts out in
> world where the majority of the nodes have been upgraded and focus on
> mechanism in that world. It is not that it needs to work, but to me the
> main focus would be to ensure that the signaling protocol works well
> when deploying it only in one access network, or even subnet and then
> starts to grow the deployment.

I have to confess that the initial work started with the naïve view of deploying NSIS everywhere, but we backed off with the proxy mode.

> 
> I am missing this story and how to get good performance out of the NSLP
> in such settings. The proxy mode enables this to some degree but seems
> to lack some functionality to allow for incremental deployment. The
> main
> issue seems to be sender proxying that seems to lack a method to
> indicate: Please proxy this but also try end to end. That allows for
> quick setup of the egress to public path, and allows for opening all
> the
> way if the end-to-end actually works.
> 
> I would like to have a section that describes how one can start out
> with
> some end-hosts and edge-NAT/FW that support proxying. Then probe the
> path towards end-to-end to see if there are additional NATFW aware
> entities on the path allowing for a increase functionality scope.

I will draft text and send it. This sounds like an excellent idea.

> 
> I am also a bit worried about the assumption that edge devices must be
> correctly configured. Consider the case of an ISP that does NAT44, i.e.
> the customer - ISP edge has one NAT that may have been the edge
> initially, but then the ISP has run out of addresses and decides to
> deploy its own NAT. For the application running in an end-host the gain
> with the NATFW signalling is lost until the customer edge device is
> reconfigured to not any longer be the edge. I don't know if there is a
> simple solution to this problem. If not I would defer the inclusion but
> it should be noted as a short coming.

We discussed this back in time, but didn't come up with any good and workable solution. That is the reason with simply referred to "correctly configured", as only the ISP can (or should) know its network and the outermost NAT. This might not be the best solution, but seems to be the only workable as it stands right now.

  Martin

> 
> Comments?
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsis

---

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 19 Jan 2010 13:36:40 +0100

Hi Magnus,

Here is a text proposal for the incremental deployment, including path probing, and about the edge-devices that need to be properly configured. Let me know your comments.

  Martin

> Subject: [NSIS] Incremental deployement story fordraft-ietf-nsis-nslp-
[...]
> way if the end-to-end actually works.

**Added a new flag in the NSLP header:

**Added a new section describing the incremental deployment usage
3.7.6.3.  Incremental Deployment using the Proxy Mode

   The above sections described the the proxy mode for cases where the
   NATFW NSLP is solely deployed at the network edges.  However, the
   NATFW NSLP might be incrementally deployed first in some network
   edges, but later on also in other parts of the network.  Using the
   proxy mode only, would prevent the NI to determine whether the other
   parts of the network have also been upgraded to use the NATFW NSLP.
   One way of determining whether the path from the NI to the NR is
   NATFW NSLP capable is to use the regular CREATE message and to wait
   for a successful response or an error response.  This will lead to
   extra messages being sent, as a CREATE message in addition to the
   anyhow required CREATE-PROXY message is sent from the NI.

   The NATFW NSLP allows the usage of the proxy-mode and a further
   probing of the path by the edge-NAT or edge-firewall.  The NI can
   request proxy-mode handling as described, and can set the E flag (see
   Section Figure 20) to request the edge-NAT or edge-firewall to probe
   the further path for NATFW NSLP enabled NFs or NR.

   The edge-NAT or edge-firewall MUST continue to send the CREATE-PROXY
   or EXTERNAL-proxy towards the NR, if the received proxy-mode message
   has the E flag set, in addition to the regular proxy mode handling.
   The edge-NAT or edge-firewall relies on the NTLP measures to
   determine whether there is no other NATFW NSLP reachable towards NR.
   A failed attempt to forward the request message to the NR will be
   silently discarded.  A successful attempt of forwarding the request
   message to the NR will be acknowledged by the NR with a successful
   response message, which is subject to the regular behavior described
   in the proxy-mode sections.

> it should be noted as a short coming.

Added this section to address this:
3.7.6.4.  Deployment Considerations for Edge-Devices

   The proxy mode assumes that the edge-NAT or edge-firewall are
   properly configured by network operator, i.e., the edge-device is
   really the final NAT or firewall of that particular network.  There
   is currently no known way of letting the NATFW NSLP automatically
   detect which of the NAT or firewalls are the actual edge of a
   network.  Therefore, it is important for the network operator to
   configure the edge-NAT or edge-firewall and also to re-configure
   these devices if they are not at the edge anymore.  For instance, an
   edge-NAT is located within an ISP and the ISP chooses to place another
   NAT in front of this edge-NAT.  In this case, the ISP needs to
   reconfigure the old edge-NAT to be a regular NATFW NLSP NAT and to
   configure the newly installed NAT to be the edge-NAT.

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Jan 2010 17:14:02 +0100

This looks good.

Magnus

-- 

Magnus Westerlund