Subject: [Capwap] need clarification on UDP ports

From: "Abhijit Choudhury" <[email-masked]>
Date: Tue, 17 Oct 2006 10:07:44 -0700

Pat, Mike, Dorothy:
 
I have a question based on v03 of the capwap spec.
In section 3.1, the spec mentions well-known UDP
ports for the CAPWAP control and data packets.
 
There are four kinds of CAPWAP packets:
1. DTLS protected control packets
2. Unprotected control packets
3. Unprotected data packets
4. (Optional) DTLS protected data packets
 
Will there be 4 well-known UDP port numbers ?
 
1, 2 and 3 will be present simultaneously in any
deployment. 3 and 4 may co-exist in a deployment
if some data channels are encrypted and some not.
There has to be a way to distinguish these four 
kinds of packets.  The draft is not clear about how 
this is done.
 
Thanks,
   Abhijit

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "NKA NKA" <[email-masked]>
Date: Wed, 18 Oct 2006 01:30:02 +0530

________________________________
From: Abhijit Choudhury [mailto:[email-masked]]
> Sent: Tue 10/17/2006 10:37 PM
> To: Dorothy Stanley; Pat Calhoun (pacalhou); Michael Montemurro
> Cc: [email-masked]
> Subject: [Capwap] need clarification on UDP ports
>
>
>
> Pat, Mike, Dorothy:
>

[NKA} As per my understanding, you don't need to have two seperate UDP ports
for handling DTLS and Non-DTLS control packets. Following is the logic which
I would use at AC:

  1. If AC receives a UDP packet on its control port, and if it CAN'T
find the session
  information corresponding to the sender WTP, then the arrived packet can
  be considered to be a discovery packet.

  In the above situation, for some reason, if WTP sent a DTLS packet, AC can
  continue to assume it to be a discovery packet. So it should feed the arrived
  DTLS packet to its discovery packet processing module. Ultimately the
  packet will get dropped by AC due to packet parsing error (chances of DTLS
  packet looking like a valid discovery packet is very very slim).
After a few trial,
  WTP will reboot and ultimately get in sync with AC's State machine.

  2. If AC receives a UDP packet on its control port, and if it CAN
find the session
  information corresponding to the sender, then the arrived packet can be
  considered as a DTLS packet. So AC should feed such packets to DTLS module
  directly.

  You may have a situation in which session information exists for a WTP at AC,
  but WTP is sending non-DTLS packet. Even in such situation, AC can feed such
  packets to DTLS module, which will ultimately reject the packet. AC can use
  this kind of notification to tear down the existing session, which
will bring AC's
  state machine in sync with that of WTP.

I have not given much thought about the data path issue. May be the
initial policy
(about dtls) exhcnage would help. Once both the party (AC as well as WTP) agree
whether DTLS will be used or not, the same information can be used for
programming the hardware. I know that issue # 221 is tracking data
path policy issue.

NKA

---

From: "Abhijit Choudhury" <[email-masked]>
Date: Wed, 18 Oct 2006 14:55:24 -0700

On 10/18/06, Abhijit Choudhury <[email-masked]> wrote:
>        I think for data channel security, it will have
>        to be a binary decision for an AC/WTP pair, i.e.
>        if data channel encryption is enabled, it is for all data.
>
>        For the control channel, I think to have a clean
>        solution (with deterministic behavior) we need either
>        a separate discovery port or a type header which allows
>        one to distinguish between discovery and dtls packets.
>
>        Scott
>
> In a clean solution, the packet itself should have enough information 
> to clearly classify it as one of the four types of packets. We should 
> not have to depend on configuration lookups to check whether the 
> packet is supposed to be DTLS encrypted or not.

[NKA] Good point. But remember that for this flag to be affective, it
needs to appear before the DTLS header. Currently Capwap transport
header comes after DTLS. If we take your suggestion, Capwap header will
be in two part. One part will appear before DTLS header and second one
will be after DTLS header. But didn't we recently decided to not go with
Mux header approach?

[Abhijit] That is exactly why I did not suggest a shim header or type
field. Instead, I suggested separate UDP ports to indicate the type
af packet. That way we don't need a separate header between 
UDP and DTLS headers.
>
> We have used this principle already in designing the CAPWAP header.  
> The T bit clearly identifies the payload as 802.3 or native format. 
> This could have been identified based on a config lookup since an AC 
> would typically handle 802.3 payload or native but rarely both. But we

> chose to include this information the header itself to make the design

> clean.
>
> The same idea should be used for distinguishing between
> the four packet types.  Having four distinct UDP ports is one option. 
> I'm sure there are others.
>
> Regards,
> Abhijit
>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 18 Oct 2006 15:57:42 -0700 (GMT-07:00)

Hi Abhijit,

>af packet. That way we don't need a separate header between 

Yes, because we all know that putting anything between the UDP header and the DTLS header is *EVIL*, and anyone who would even *SUGGEST* such heresy should be crucified! And BURNED! And STABBED, SHOT, BEATEN, and RIDICULED, and then FEASTED UPON BY MAGGOTS!

But a little more seriously :-), one reason I still consider a type header worthy of consideration (despite the choice of separate ports for control/data): if we implement data channel crypto (and there seems to be stronger support for this now), we are either going to have to use exactly one QoS level for all data, or we'll need to be able to support multiple encrypted data channel streams per wtp (up to a maximum of 1 per QoS level, or 8).  Otherwise, the DTLS antireplay mechanism and QoS won't play well together.

This is a well-documented problem that we ran into in IPsec, and it will also occur here in CAPWAP, and especially once 11n shows up.  See RFC 4301, halfway into section 4.1 (starting near the bottom of page 13):

   If different classes of traffic (distinguished by Differentiated
   Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on
   the same SA, and if the receiver is employing the optional
   anti-replay feature available in both AH and ESP, this could result
   in inappropriate discarding of lower priority packets due to the
   windowing mechanism used by this feature.  Therefore, a sender SHOULD
   put traffic of different classes, but with the same selector values,
   on different SAs to support Quality of Service (QoS) appropriately.
   To permit this, the IPsec implementation MUST permit establishment
   and maintenance of multiple SAs between a given sender and receiver,
   with the same selectors.  Distribution of traffic among these
   parallel SAs to support QoS is locally determined by the sender and
   is not negotiated by IKE.  The receiver MUST process the packets from
   the different SAs without prejudice.  These requirements apply to
   both transport and tunnel mode SAs.  In the case of tunnel mode SAs,
   the DSCP values in question appear in the inner IP header.  In
   transport mode, the DSCP value might change en route, but this should
   not cause problems with respect to IPsec processing since the value
   is not employed for SA selection and MUST NOT be checked as part of
   SA/packet validation.  However, if significant re-ordering of packets
   occurs in an SA, e.g., as a result of changes to DSCP values en
   route, this may trigger packet discarding by a receiver due to
   application of the anti-replay mechanism.
-----------------------

Antireplay is not optional in DTLS, so the same issues apply - you need per-QoS-level session identifiers to resolve this -- that is, if you want data channel QoS support. One option is to choose a separate port for each QoS level, but that would mean we'd potentially need to support 8 ports for data, and if we ever decide we need to differentiate QoS levels on the control channel for some reason, we'll need even more ports for that.

Even with 50K ports still available (or more, or less, don't know the exact number today),  it's possible that IANA and/or the IESG will object to us grabbing this many ports for one protocol. Especially when this could be easily solved by putting a few bytes between the udp header and the payload. This doesn't mean you don't use two ports, one for control, one for data - it simply means you have a stream id+type in the clear after the UDP header.

Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 19 Oct 2006 11:03:21 -0700

Abhijit, this issue was not addressed by the editors given that we were
waiting for the chairs to make a consensus determination, which occured
too close to the I-D deadline. That said, this would be a good time to
start the discussion.
 
My proposal would be as follows (this is conceptual, not actual draft
text). Note this proposal is optimized to utilize the fewest possible
ports, and assumes that IANA would not agree to a UDP port landgrab.
 
The AC maintains a DTLS SA table which consists of the WTP's IP address
and UDP port numbers. When the AC receives a Discovery Request on the
CAPWAP control port, it performs a lookup to determine whether the
IP/Port information matches the DTLS SA table. If the IP/Port does not
match an entry in the DTLS SA table, the AC responds with a Discovery
response and waits for a successful DTLS setup, which would create a new
DTLS SA. If there is a match, then the packet is a DTLS encrypted
payload, which is sent to the DTLS stack. The following is an example of
the packet exchange (note the ports used here are for illustration
purposes only):

WTP                                                       AC
(WTP Picks a pseudo-random source port)
----- CAPWAP Control/Discovery Request (662, 1233) ------> 
<---- CAPWAP Control/Discovery Response (1233, 662) ------

Using Scott's recommendation to look at the WBID, which when set to any
value other than 23 (which we will need to reserve), then we know this
packet is a discovery request, and process it accordingly. One
alternative to reserving a WBID would be to require that the Reserved
field in the CAPWAP header be set to '111', which would provide another
way to differentiate the packets.

--------- DTLS Session Setup/Control (662, 1233) -------->
<-------- DTLS Session Setup/Control (1233, 662) ---------

The WBID value of 23 will be an indication that the DTLS session is
being established (or the alternative proposed above)... at this point
all packets are from now on fed into the DTLS engine. Once the DTLS
session is established, all CAPWAP packets will be marked internally as
'Application Data', and once decrypted will be sent back into the CAPWAP
module for processing...

-------- CAPWAP Control/Join Request (662, 1233) ---------> (includes
support for DTLS/Data)
<------- CAPWAP Control/Join Response (1233, 662) --------- (Dictates
whether DTLS is to be used on data plane, and a random cookie)

When inactivity occurs over the control plane, the keepalive is sent to
keep the session alive (also useful for NAT traversal):

------- CAPWAP Control/Keepalive Request (662, 1233) ----->
<------ CAPWAP Control/Keepalive Response (1233, 662) -----

The following is optional, and occurs if DTLS needs to be used on the
data plane UDP port:

----------- DTLS Session Setup/Data (685, 1234) ---------->
<---------- DTLS Session Setup/Data (1234, 685) -----------

Again, the WBID of 23 is used to identify the DTLS packet. When used and
established, all CAPWAP data packets will be marked as 'Application
Data' within DTLS. So these packets would pop back out of the DTLS stack
for CAPWAP processing. Yes, this requires that the data plane remember
the configuration enforced by the AC, and therefore it does not mark
each packet as "with DTLS" or "without DTLS". We can do this, but
frankly it provides little value because ultimately, if DTLS was
required and a packet is sent in the clear, it will be dropped anyhow.
Furthermore, I trust an authenticated payload much more than a bit "in
the clear".

A specialized packet is then sent on the data plane to create the
correlation between the control and data plane sessions. A new bit in
the CAPWAP header, which I will call 'D' (for Data Management) is set so
this gets treated as a specialized packet on the data plane UDP port:

---------- CAPWAP Data/Announce Req (685, 1234) ----------> (Including
the cookie to bind to control channel)
<--------- CAPWAP Data/Announce resp (1234, 685) ----------

NOTE: Another alternative to this scheme is to include a session
identifier in the header, which provides the correlation between the
control and data channel. This would be much simpler to implement, and
not require special processing of the data plane. However, if folks
believe that keeping the NAT session fresh, then we need some mechanism
to keep the channel alive. If this is found to be desirable/required,
then a periodic exchange needs to occur to keep the NAT table entry
fresh (again, with the 'D' bit set):

------- CAPWAP Data/Keepalive Request (685, 1234) -------->
<------ CAPWAP Data/Keepalive Response (1234, 685) --------

Should the WTP fail, it would pick a new source UDP port for both the
control and data plane, and send a Discovery Request using the control
UDP port. It is important to note that the longevity of the uniqueness
characteristics of the UDP port is not very long (e.g., one day after
reboot). This is a new requirement on the WTP, but not unrealistic since
802.11 APs have to do this for the RADIUS protocol today (to maintain
unique session identifiers). The AC does not flush its current DTLS SA
until the DTLS exchange is complete (and successful).

WTP                                                       AC
(WTP picks a new pseudo-random source port)
----- CAPWAP Control/Discovery Request (772, 1233) ------> 
<---- CAPWAP Control/Discovery Response (1233, 772) ------

Using Scott's recommendation to look at the WBID, which when set to any
value other than 23 (which we will need to reserve), then we know this
packet is a discovery request, and process it accordingly.

--------- DTLS Session Setup/Control (772, 1233) -------->
<-------- DTLS Session Setup/Control (1233, 772) ---------

The WBID value of 23 will be an indication that the DTLS session is
being established... at this point all packets are from now on fed into
the DTLS engine.

If NAT is used, it is possible that the WTP's source IP address is used
for multiple WTPs. In this case, the AC can identify each WTP using the
DTLS credentials. The AC can then delete the old DTLS SAs (control and
optionally data), that are associated with the WTP's credentials.
Alternatively, the AC could simply wait for the sessions to expire.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

	From: Abhijit Choudhury [mailto:[email-masked]] 
	Sent: Tuesday, October 17, 2006 10:08 AM
	To: Dorothy Stanley; Pat Calhoun (pacalhou); Michael Montemurro
	Cc: [email-masked]
	Subject: need clarification on UDP ports

	Pat, Mike, Dorothy:

	 

	Thanks,
	   Abhijit

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 20 Oct 2006 11:48:39 -0700

I will need time to catch up to this thread, but want to quickly note
that I am not against using a separate port. The e-mail I sent out,
which I have yet to completely digest Scott's comments, was intended to
provide an approach where only two ports are used. If we wish to use
three, then that's ok with me too - as long as we can get them
allocated.

Pat Calhoun

> -----Original Message-----
> From: Puneet Agarwal [mailto:[email-masked]] 
> Sent: Thursday, October 19, 2006 7:24 PM
> To: Scott G. Kelly; Pat Calhoun (pacalhou); Abhijit 
> Choudhury; Dorothy Stanley; Michael Montemurro
> Cc: [email-masked]
> Subject: RE: [Capwap] need clarification on UDP ports
> 
> I agree with Scott - it is important that we come up with a 
> solution that is unambiguous and works even if packet formats 
> for dtls change. 
> 
> It seems that we (capwap) are one of the first folks trying 
> to use DTLS.
> It would be good to know how other folks (if any) have used 
> DTLS for their applications. If someone has already solved 
> the "discovery to dtls-secure" like problem before, then it 
> would be good to understand how they did it and maybe use a 
> similar approach (rather than re-invent the wheel). In that 
> regard, does anyone know of other groups using dtls to secure 
> their protocol?
> 
> Would having 3 UDP ports solve the problem:
> (a) capwap-open control port : All unencrypted capwap control 
> packets go on this channel
> (b) capwap-open data port : All unencrypted capwap data 
> packets go on this channel
> (b) capwap-secure port: All dtls encrypted capwap 
> data/control packets go on this channel. Demux for data vs 
> control happens after decryption.
> 
> We may need more ports if we need to support different QoS 
> levels (as pointed by Scott)- that to me is a bigger problem. 
> Wondering what the group thinks....
> 
> Thanks.
> 
> -Puneet
> 
> -----Original Message-----
> From: Scott G. Kelly [mailto:[email-masked]]
> Sent: Thursday, October 19, 2006 2:42 PM
> To: Pat Calhoun (pacalhou); Abhijit Choudhury; Dorothy 
> Stanley; Michael Montemurro
> Cc: [email-masked]
> Subject: Re: [Capwap] need clarification on UDP ports
> 
> You know, after seeing my post on this topic yesterday, I 
> thought maybe my sarcasm was a bit overdone, and I actually 
> regretted that post. But now, after seeing what sort of hoops 
> you're willing to jump through to avoid that much simpler 
> approach at apparently any cost... well, now I'm not so sure.
> 
> Sigh. Comments inline...
> 
> <extraneous text elided...>
> >response and waits for a successful DTLS setup, which would create a 
> >new DTLS SA. If there is a match, then the packet is a DTLS 
> encrypted 
> >payload, which is sent to the DTLS stack. The following is 
> an example 
> >of the packet exchange (note the ports used here are for 
> illustration 
> >purposes only):
> >
> >WTP                                                       AC
> Let's stop here, because this is where it starts getting 
> twisted. I didn't recommend this sort of hack. There are two 
> major flaws to this approach. The first is that you assume 
> that the DTLS header format will not change. That's probably 
> unwise, given that it is a new protocol.
> This early in the game, anything after the version field is 
> fair game, and hacking based on assumptions of immutability 
> is (in my opinion, at
> least) A Bad Thing (tm).
> 
> The second issue here is that you're not looking carefully at 
> the DTLS header alignment as it currently exists. Each 
> version change results in the first version byte being 
> decremented. It is currently FE, and the next will be FD, 
> then FC, and so on. Look at what this means for the WBID 
> field (which, by the way, could *also* be changed before 
> we've finished with capwap):
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |0 0 0 1|0 1 1 0 1|1 1 1 1 1|1 0 1 1 1|1 1 1 1 1 0 0 0 0 0 0 0 0|
>     |VERSION|   RID   | HLEN    |  WBID   |T|F|L|W|M|    FLAGS      |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
>     |    type       |     protocol version          |  epoch
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
> FEFF                |1 1 1 1 1 1 1 0|1 1 1 1 1 1 1 1|
>                     +---------------+---------------+
> FDFF                |1 1 1 1 1 1 0 1|1 1 1 1 1 1 1 1|
>                     +---------------+---------------+
> FCFF                |1 1 1 1 1 1 0 0|1 1 1 1 1 1 1 1|
>                     +---------------+---------------+
> FBFF                |1 1 1 1 1 0 1 1|1 1 1 1 1 1 1 1|
>                     +---------------+---------------+
> FAFF                |1 1 1 1 1 0 1 0|1 1 1 1 1 1 1 1|
>                     +---------------+---------------+
> 
> Since there are two WBID bits affected, your scheme requires 
> that there be at least 4 untouchable WBID values (assuming we 
> don't change the capwap header): 7, 15, 23, and 31. This is 
> starting to sound more than a little bit hacky, and certainly 
> not something you want to implement in hardware.
> 
> I won't go line by line on the stuff below, as this is more 
> than I can ask people to bear. I have only two points to make here: 
> 
> 1) regarding the comment below where you say "Furthermore, I 
> trust an authenticated payload much more than a bit 'in the 
> clear'",  I'm
> wondering: why are unauthenticated values in the UDP and IP 
> headers more trustworthy than values following them? Think about it.
> 
> 2) look at the signalling complexity you are adding! And all 
> this to avoid ...what, exactly?
> 
> 
> Scott
> 
> 
> 
> 
> >
> 
> >'Application Data', and once decrypted will be sent back into the 
> >CAPWAP module for processing...
> >
> >Again, the WBID of 23 is used to identify the DTLS packet. When used 
> >and established, all CAPWAP data packets will be marked as 
> 'Application
> 
> >Data' within DTLS. So these packets would pop back out of the DTLS 
> >stack for CAPWAP processing. Yes, this requires that the data plane 
> >remember the configuration enforced by the AC, and therefore it does 
> >not mark each packet as "with DTLS" or "without DTLS". We 
> can do this, 
> >but frankly it provides little value because ultimately, if DTLS was 
> >the CAPWAP header, which I will call 'D' (for Data 
> Management) is set 
> >so this gets treated as a specialized packet on the data plane UDP
> port:
> >

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 20 Oct 2006 12:04:41 -0700 (GMT-07:00)

> It would be good to know how other folks (if any) have used DTLS for
> their applications. If someone has already solved the "discovery to
> dtls-secure" like problem before, then it would be good to understand
> how they did it and maybe use a similar approach (rather than 
> re-invent
> the wheel). In that regard, does anyone know of other groups 
> using dtls
> to secure their protocol?

There are currently drafts active for using DTLS with syslog, SDP, and DCCP. Also, TLS has been used with many protocols, and we can certainly look there for inspiration. In general, there are two models. In the first, a given port is considered (D)TLS-only. In the other, the application somehow signals it's desire to convert the session to (D)TLS. For example, some applications support a "STARTTLS" directive, and for secure syslog a client might send the string "AUTH TLS CLIENT", to which the server will reply OK or ERROR. In general, once (D)TLS is on, no unprotected packets are allowed.

> (b) capwap-open data port : All unencrypted capwap data packets go on
> this channel
> (b) capwap-secure port: All dtls encrypted capwap data/control packets
> go on this channel. Demux for data vs control happens after 
> decryption.
> 
> We may need more ports if we need to support different QoS levels (as
> pointed by Scott)- that to me is a bigger problem. Wondering what the
> group thinks....

I've been re-thinking my position on this, given that the working group is committed to a multiport approach. Certainly there are multiple ways to solve this, and while I would prefer a solution that didn't involve adding yet more ports, we are where we are.

That said, I think adding a 3rd port which is only used for discovery operations solves part of the problem.  In that case, the control channel is always DTLS traffic, and we have an unambiguous solution which requires no protocol hacks.

As for the data channel, it's a little more complex. If hardware vendors must know a priori whether data is protected or not, the only options are either two data ports or a type header, and given the dramatic allergic reactions we've seen to protocol layering beyond the udp header here, distinct ports seem to be the only option on the table. However, if hardware vendors support tuple-plumbing, we can do this with one data port.

Tuple-plumbing solves the problem by letting the application tell the hardware when a session is protected or not, but you have to look at the source port too. This is part of the problem some of Pat's signalling is meant to solve. Once the AC knows what characteristics a given tuple should have, this can be plumbed into the hardare.

This still leaves two problems: associating a NAT'd data channel with the appropriate control channel, and the QoS problem for the data channel. The channel association can be solved by using the session ID, as has been noted numerous times in past threads. One way this could be extended to encompass multiple data channels would be to extend the session ID field, and treat the high-order portion as the session id, and the low-order portion as the channel id (control channel has channel id 0, data channel with no QoS has channel id 1, and so on). Just a thought.

Since there will be initial ambiguity when multiple WTPs are behind a NAT, there are two options:

1) don't worry about it; let the WTP establish a DTLS session without knowing which control channel it belongs to, and then get the session binding out of the first protected data packet (which may be an echo) to create the binding; if no packets come within some preset interval, tear down the DTLS session.

2) do some inline signalling, as Pat suggested. This could be via a capwap header with some special value, or it could be the text STARTDTLS along with the session/channel id - whatever.

I think, based on the above, that a 3-port solution exists - but this depends on what is workable for the hardware vendors.

Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 23 Oct 2006 07:28:37 -0700

To start with, we have to answer few questions:
	1. How capwap is protected against discovery packet attacks?
Even if there
	is a port-based or mux-based soltuion for reliably identifying
discovery and
	DTLS packets, an attacker can send a discovery packet to the AC,
which may
	result in the tear down of the WTP session. This is because
discovery packets
	are un-authenticated packets, and are sent in plain. AC needs to
blindly
	believe on the discovery packets.
	
	2. If an AC employs actions again discovery packet attacks by
discarding
	discovery packets if WTP session did not timeout, then an
attacker may
	prevent the WTP joining back to the AC after a WTP crash.
Attacker can detect
	a sudden absence of echo request messages from WTP, and start
replaying the
	WTP echo request messages which causes AC not to teardown the
WTP session.
	And thus genuine discovery packets might be discarded by AC. May
be I am wrong
	here if DTLS can detect duplicate packets and discard them
automatically.

	To resolve the above issues, we can impose following rules on
AC.
	
	For issue (1) above:
	RULE 1:
	  (a) AC discards all discovery packets if an active WTP session
exists for the
	  WTP.
	  (b) A discovery packet from WTP can be accepted by AC only
when there does
	  not exist any active session for that WTP. Whereas, if a
discovery packet is
	  received if an active WTP session exists at AC, then all such
discovery
	  packets are discarded without change or update of any of the
AC states.
<PRC> I disagree with this approach, and disagree with any mechanisms
that will create
delays before a WTP can reconnect to its AC. The couple of previous
posts included a
method to quickly detect the WTP had failed - in a secure fashion.

	To resolve the second issue (if at all it exists):
	RULE 2:
	  AC should discard all duplicate DTLS and CAPWAP packets
without change or
	  update of any of its states.
<PRC> Sort of a bogus attack, but one that I suppose is possible. I
would once more 
resort to my proposal that if the WTP can re-establish a successful DTLS
(using a new
UDP source port), then the old control and data channels are deleted.	

Pat Calhoun

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 23 Oct 2006 07:28:34 -0700

> packets go on this channel

There is really only two CAPWAP packets that are in the clear - the
Discovery packets. One alternative is to simply use the DTLS packet
header, filled with zeroes. Yes, there is still some risk here because
the DTLS header can change format, as stated by Scott. However, even so,
we could agree on today's DTLS version for the unencrypted frames. A
series of zeroes would imply an empty DTLS header, followed by the
unencrypted CAPWAP control frame.

> control happens after decryption.

It's not completely obvious to me why the data plane packet format is
not known apriori. The control channel will negotiate the use of crypto
on the data channel, and all data plane packets received MUST be in the
format negotiated.

Assume for the moment a device negotiates crypto, but opts to send a
plain text packet. Let's also assume that the packet had a way to signal
it was in the clear (either through a bit, ot via a separate UDP port).
Further, if the packet was supposed to be encrypted, as the bit or port
indicates, but the packet is in the clear, then a CAPWAP device would
have to attempt to decrypt the packet, which would fail and be dropped.

So it seems to me like it is completely valid to simply have the
endpoints (WTP, AC) remember the negotiated value (hell, you need to in
order to transmit packets anyhow), and simply enforce the policy based
on packets received.

So it does seem to me like a dual port approach is completely possible.
If there is concern about the empty DTLS header, then the three UDP port
number is still an option.

Pat Calhoun

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 23 Oct 2006 07:28:36 -0700

> [NKA] My point is that seperate discovery packet processing 
> via a special port is a bad idea. And it doesn't bring any 
> additional value than what can be achieved without special 
> port approach. Scott's additional reasoning that two port 
> approach would open up scope for DOS atack. I totally 
> disagree with the argument. I claim that the same risk exists 
> even with 3-port approach also.

In my previous post, I suggested the use of the source UDP port 
number in the DTLS SA table. This is required to support both the
control and data plane being encrypted. However, it can also be used
to detect a failed/reset WTP, but ensuring that the Discovery Request
is sent from a new source UDP port. This does impose a requirement for
random UDP ports on the WTP, but this is not out of the question since
the RADIUS protocol imposes this on "fat" APs.

That said, it is important to note that the "old" DTLS SA MUST not be
torn down, or dismissed in any way until a new DTLS SA can be
established
using the new UDP source port.

Pat Calhoun

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 24 Oct 2006 13:26:12 -0400 (EDT)

-----Original Message-----
>From: Hasan Raza <[email-masked]>
>Sent: Oct 24, 2006 1:18 PM
>To: "Pat Calhoun (pacalhou)" <[email-masked]>, "Scott G. Kelly" <[email-masked]>, [email-masked]
>Cc: capwap <[email-masked]>
>Pat Calhoun (pacalhou) wrote:
> 
>> While it is impossible to disagree, it is worth noting that version
>> fields are typically fixed in location (for future compatibility),
>> and generally increase monotonically.
>My mistake that I was not clear. I agree that version field is at
>fixed location, and increase monotonically. But header size might
>be version dependent as well. Now since DTLS header is made zero,
>the version information, and in turn header size info., is lost.

Right. And the previous email suggested 

> For that matter any unique pattern of fixed amount of bytes in front
> of udp header can work for discovery packets. Why should it 
> be zero filled
> DTLS header only? The only restriction on the pattern should be
> that it is uniquely different from first fixed bytes of the 
> DTLS header.

This sounds an awful lot like the type header suggestion - a fixed number of bytes after the UDP header that indicate *precisely* what follows. No hacking, no ambiguity - seems like a no-brainer.

Scott

---

From: "Rohit Suri (rsuri)" <[email-masked]>
Date: Tue, 24 Oct 2006 22:58:02 +0530

I think setting the DTLS header to zero would make the version ID in
dtls header also zero, making the header length deterministic.
 
Regards
Rohit

From: Hasan Raza [mailto:[email-masked]] 
Sent: Tuesday, October 24, 2006 10:19 AM
To: Pat Calhoun (pacalhou); Scott G. Kelly; [email-masked]
Cc: capwap
Subject: Re: [Capwap] need clarification on UDP ports

Hasan

 -----Original Message-----
From:   Hasan Raza [mailto:[email-masked]]
Sent:   Tuesday, October 24, 2006 09:35 AM Pacific Standard Time
To:     Pat Calhoun (pacalhou); Scott G. Kelly; [email-masked]
Cc:     capwap
Subject:        Re: [Capwap] need clarification on UDP ports

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
Sent: Mon 10/23/2006 7:28 AM
To: Scott G. Kelly; [email-masked]
Cc: capwap
Subject: Re: [Capwap] need clarification on UDP ports

> True, and if we decide that hacks are not acceptable, then a third
port
> is really the only way to solve this one. However, I'd like people to
> consider the zero filled DTLS header. Yes, it is "hack-ish", but
> I believe it to be completely workable.
For that matter any unique pattern of fixed amount of bytes in front
of udp header can work for discovery packets. Why should it be zero
filled
DTLS header only? The only restriction on the pattern should be
that it is uniquely different from first fixed bytes of the DTLS header.
All zeros is a good pattern, though. I think zero filled DTLS header
would impose variable header size problems (in future), because version
field would also become zero.

Hasan

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 24 Oct 2006 12:56:31 -0700

Except we can document that any CAPWAP implementation receiving a packet with 'n' zeroes uses DTLS header format foo, which is of lengh 'y'.

PatC

 -----Original Message-----
From: 	Hasan Raza [mailto:[email-masked]]
Sent:	Tuesday, October 24, 2006 10:18 AM Pacific Standard Time
To:	Pat Calhoun (pacalhou); Scott G. Kelly; [email-masked]
Cc:	capwap
Subject:	RE: [Capwap] need clarification on UDP ports

Hasan

 -----Original Message-----
From: 	Hasan Raza [mailto:[email-masked]]
Sent:	Tuesday, October 24, 2006 09:35 AM Pacific Standard Time
To:	Pat Calhoun (pacalhou); Scott G. Kelly; [email-masked]
Cc:	capwap
Subject:	Re: [Capwap] need clarification on UDP ports

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
Sent: Mon 10/23/2006 7:28 AM
To: Scott G. Kelly; [email-masked]
Cc: capwap
Subject: Re: [Capwap] need clarification on UDP ports

> True, and if we decide that hacks are not acceptable, then a third port
of udp header can work for discovery packets. Why should it be zero filled

Hasan

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 24 Oct 2006 13:23:52 -0700 (GMT-07:00)

"Pat Calhoun (pacalhou)" wrote:

>Except we can document that any CAPWAP implementation receiving a packet with
> 'n' zeroes uses DTLS header format foo, which is of lengh 'y'.

...except that it is decidedly *not* a DTLS header, right? I'm having a really hard time understanding why you're pushing for a hack at any/all costs to solve this problem. We are at the design stage - if there were ever a time to do it right, that time is now. Exactly what will break if we don't adopt this hack?

Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 24 Oct 2006 12:56:35 -0700

No. There is a distinct difference as it is sent on the control port. 

PatC

 -----Original Message-----
From: 	Scott G. Kelly [mailto:[email-masked]]
Sent:	Tuesday, October 24, 2006 10:27 AM Pacific Standard Time
To:	Hasan Raza; Pat Calhoun (pacalhou); [email-masked]
Cc:	capwap
Subject:	Re: [Capwap] need clarification on UDP ports

-----Original Message-----

Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 26 Oct 2006 10:07:04 -0700

Issue 227 created.

Pat Calhoun

> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Thursday, October 26, 2006 9:49 AM
> To: Scott G Kelly
> Cc: capwap
> Hi Scott,
> On Oct 26, 2006, at 10:50 AM, Scott G Kelly wrote:
> > But I think the assumption that encryption on the data port 
> is binary 
> > on/off is a little premature. I think that for any given 
> WTP, it will 
> > be binary, but that for a given deployment, some WTPs could require 
> > data channel encryption while others do not.
> 
> Good point.  I'm now convinced (by this note and Pat's) that 
> it would be best to include a short header on both the data 
> and control channels to indicate whether the packet is a DTLS 
> packet or an unencrypted packet.
> 
> Margaret
>