Capwap Mailing List: Re: need clarification on UDP ports

[Puneet Agarwal (pagarwal]

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:s.kelly [at] ix.netcom.com] 
Sent: Thursday, October 19, 2006 2:42 PM
To: Pat Calhoun (pacalhou); Abhijit Choudhury; Dorothy Stanley; Michael
Montemurro
Cc: capwap [at] frascone.com
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...>
>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.

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




>

>--------- 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:Abhijit [at] sinett.com] 
>       Sent: Tuesday, October 17, 2006 10:08 AM
>       To: Dorothy Stanley; Pat Calhoun (pacalhou); Michael Montemurro
>       Cc: capwap [at] frascone.com
>       Subject: need clarification on UDP ports
>       
>       
>       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

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

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