Subject: [Capwap] NAT traversal objective - take II

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Mon, 13 Jun 2005 14:04:39 -0400

I would like to propose adding below NAT traversal requirement following
the last thread on the subject.

Classification: Architecture
 
Description:
The CAPWAP protocol doesn't pose any restriction on the environment
where the AC and the WTP will be deployed and which devices facilitate
communication between the two. Therefore traversing NAT device cannot be
ruled out and the CAPWAP protocol should be robusted against such a
scenario.

Protocol Requirement:
CAPWAP protocol shall accommodate NAT traversal scenario and in
particular allow NAT device to manipulate layer 4 ports, take into
consideration symmetric NAT behavior (allowing access from the public
side only after session establish from the private side) and avoid peer
identification based on entity (e.g. WTP, AC) IP addresses.

Motivation and Protocol Benefits:
Independence of WTP and AC on intermediate devices and extending
deployment topologies and variance. A service provider connecting their
AC to their customer's WTP across a NAT device is an example of
potential deployment scenario.

Relation to Problem Statement:
This requirement is based on WG discussions that have determined to be
important for CAPWAP. 

Emek

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 13 Jun 2005 11:25:09 -0700 (PDT)

HI,

In this discussion, it seems like all are focusing on just
the AC to WTP communication and not the requirements and
consequences of such communication on the STAs that
associate with the WTPs.

In the below, and in previous messages, a motivation was
given as "A service provider connecting their
AC to their customer's WTP across a NAT device is an example of
potential deployment scenario." This seems like "technology
solution" in search of a real world need.

Would someone please describe what need and benefit is
provided by "A service provider..." and include the IP
address assignments, and a description of who the STAs
would be communicating with.

> This requirement is based on WG discussions that have determined to be
Regards,
/david t. perkins

---

From: "Pat Calhoun" <[email-masked]>
Date: Mon, 13 Jun 2005 14:28:29 -0700

I thought this picture that you had provided was correct.

  /------------\   209.128.82.1   10.1.1.1 /---------------\
 |             |           ----------     |                 |
 | Internet    |-----------|NAT box |-----|Private Network  |
 |             |---        ----------     |(say 10.1.1.0/16)|
  \-----------/    \                       \---------------/
       |            \                        |
       AC            \                      WTP     STA-IP=?
   209.128.82.62      \                  10.1.2.1
                       \                   /---------------\ 
                        \  ----------     |                 |
                         --|NAT box |-----|Private Network  |
                           ----------     |(say 10.1.1.0/16)|
                   209.128.82.2  10.1.1.1  \---------------/
                                             | 
                                            WTP    STA-IP=?
                                         10.1.2.1

                           More NAT boxes

Given you are quoting me, I had responded stating that I am not, and have no
plans to be, a service provider. Further, I had stated that to my knowledge
this type of deployment did not exist today, but that in certain
geographical areas outsourcing of LAN exists, so I don't necessarily see
WLAN as not being a possiblity.

If we really believe that we are chasing a solution with no problem, then we
don't have to. However, I really don't see a problem with requiring NAT in
the objectives.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David T. Perkins
> Sent: Monday, June 13, 2005 11:25 AM
> To: Sadot, Emek (Emek)
> Cc: [email-masked]
> Subject: Re: [Capwap] NAT traversal objective - take II
> 
> HI,
> 
> consequences of such communication on the STAs that associate 
> with the WTPs.
> 
> given as "A service provider connecting their AC to their 
> customer's WTP across a NAT device is an example of potential 
> deployment scenario." This seems like "technology solution" 
> in search of a real world need.
> 
> address assignments, and a description of who the STAs would 
> be communicating with.
> 
> 
> > I would like to propose adding below NAT traversal requirement 
> > following the last thread on the subject.
> > 
> > 
> > communication between the two. Therefore traversing NAT 
> device cannot 
> > be ruled out and the CAPWAP protocol should be robusted 
> against such a 
> > scenario.
> > 
> > Protocol Requirement:
> > side only after session establish from the private side) and avoid 
> > peer identification based on entity (e.g. WTP, AC) IP addresses.
> > 
> > deployment topologies and variance. A service provider connecting 
> > their AC to their customer's WTP across a NAT device is an 
> example of

---

From: "Pat Calhoun" <[email-masked]>
Date: Tue, 14 Jun 2005 06:21:34 -0700

Having thought about this some more, it appears that the requirements for
NAT conflict with the desire to split the control and the data path.

While I agree that a WTP can be behind a NAT, I don't believe that an AC
can. The reason being that in order to achieve the control/data path split
objective, where data goes to one device and control goes to another, it is
required that the protocol allows the AC to communicate the data path IP
address - and the inclusion of such an IP address in the protocol
implicitely breaks NAT traversal.

So I would disagree with requiring that an AC can be behind a NAT.

Pat Calhoun

> [mailto:[email-masked]] On Behalf Of Sadot, Emek (Emek)
> Sent: Monday, June 13, 2005 11:05 AM
> To: [email-masked]
> Subject: [Capwap] NAT traversal objective - take II
> 
> I would like to propose adding below NAT traversal 
> requirement following the last thread on the subject.
> 
> 
> The CAPWAP protocol doesn't pose any restriction on the 
> environment where the AC and the WTP will be deployed and 
> which devices facilitate communication between the two. 
> Therefore traversing NAT device cannot be ruled out and the 
> CAPWAP protocol should be robusted against such a scenario.
> 
> Protocol Requirement:
> CAPWAP protocol shall accommodate NAT traversal scenario and 
> in particular allow NAT device to manipulate layer 4 ports, 
> take into consideration symmetric NAT behavior (allowing 
> access from the public side only after session establish from 
> the private side) and avoid peer identification based on 
> entity (e.g. WTP, AC) IP addresses.
> 
> Independence of WTP and AC on intermediate devices and 
> extending deployment topologies and variance. A service 
> provider connecting their AC to their customer's WTP across a 
> NAT device is an example of potential deployment scenario.
> 
> This requirement is based on WG discussions that have 
> determined to be important for CAPWAP. 
> 
> 
> Emek
>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 14 Jun 2005 08:36:30 -0700

Pat,

> So I would disagree with requiring that an AC can be behind a NAT.

I think the only problem should be if the AC is behind a NAT and the WTPs
aren't or the WTPs are behind a different NAT. How about if the AC and WTPs
are behind the same NAT? I think that should work, right?

            jak

---

From: Dan Harkins <[email-masked]>
Date: Tue, 14 Jun 2005 08:39:02 -0700

James,

  If they're behind the same NAT then their packets to and from each
other won't be NAT'd, right? In that case as far as CAPWAP is concerned
it's just like there is no NAT. 

  Dan.

On Tue, 14 Jun 2005 08:36:30 PDT you wrote

---

From: Suresh Satapati <[email-masked]>
Date: Tue, 14 Jun 2005 12:04:15 -0700

Should work, as long as data path doesn't traverse NATs at all or doesn't
traverse different NATs. 

However, I see this being too restrictive a scenario. I see and hear a lot 
about WTPs talking to different ACs, and those ACs doesn't need to be 
behind the same NAT or the path between WTPs and ACs doesn't need to
traverse the same NAT device.

More I think about this, I feel it is better to leave this out, and 
simply make a call to traversal solutions out there.. 
I do feel that a wording like "CAPWAP protocol must be transparent to
NATs or must work with NAT traversal solutions", is important. 

-Suresh