Subject: Re: [Capwap] Proposed resolution to issue 137 - Proposal for arevised packet header

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 9 Oct 2006 10:42:12 -0700

I believe we need to wait until a resolution has been made before
proceeding with any proposed changes to the packet header.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Thursday, September 28, 2006 9:11 AM
	To: Michael Montemurro
	Cc: capwap
	Subject: Re: [Capwap] Proposed resolution to issue 137 -
Proposal for arevised packet header

	Hi Mike,
	 
	Use of a mux header, (regardless of 1 or 2 ports, not needed if
3 ports are used) is also one solution to the (recently opened
	Issue 224, regarding the) need to clearly distinguish Discovery
frames in the control channel:
	 
	"I have a basic question regarding the classification of packets
exchanged over
	control channel. It is stated in the draft that AC in Idle state
can receive
	Discovery as well as DTLS clientHello (+other dtls handshake)
packets. The 
	clientHello packets are delivered to the SSL layer and Discovery
packets are
	consumed by the CAPWAP. Question is how? The draft assumes some
magic
	way of doing it. Since both of the packets are in plain, and are
received on 
	a single udp port, which state/policy/field classifies such
packets from one
	another? Theoretically speaking, WTP can send a discovery packet
which is
	also a valid clientHello packet! Now AC would respond with a
discovery 
	response or a clientHello reponse?
	
	In thread
http://lists.frascone.com/pipermail/capwap/msg03035.html
<http://lists.frascone.com/pipermail/capwap/msg03035.html> , Pat talks
about
	the negotiated policy for the appropriate treatment of the
received packets. That may 
	mean, if the AC is in join onwards state, it can be assumed that
AC will only receive
	encrypted packets. Though this policy can work, but there would
be exceptions in
	which WTP dies and comes back with a discovery packet. AC still
being in join+ 
	state, the received packets will be delivered to the SSL layer.
Assumptions can be
	made here that SSL would discard non-dtls packets and with
timeouts in picture, WTP
	and AC would eventually reach a consensus. But is this ok to
assume? 
	
	In the same thread, Perkins suggested the mux header approach
for control channel,
	but it was not acknowledged? Is there some other hidden
mechanism for the
	classification? Or there is some basic point which I miss here?"

	This issue is noted in the issue 137 text (there is alot of
text), and
	is stated in terms of protected vs unprotected messages, though
the
	note comments that this is essentially the same as identifying
the Discover (unprotected
	contro)l message:
	 
	NOTE: A CAPWAP MUX header is needed whether or not the same or
	       different UDP ports are used for CAPWAP control and
	       data messages. This is because both CAPWAP data and
	       control messages can be unprotected or protected by 
	       DTLS, and the MUX header is needed to distinguish
	       protected from unprotected. Remember that CAPWAP
	       "discovery requests" and "discovery responses" are
	       unprotected, and that all other CAPWAP control 
	       message types are protected.
	 
	The current -02 draft in incomplete in its specification of how 
	Discovery frames are clearly identified. The header definition
proposed in issue 137, or a variant -
	one that differentiates between discovery, control and data
CAPWAP messages for example, provides a means to clearly identify
Discovery frames.
	 
	If an implementation has another means - the issue 224 commenter
used the term "magic",  to 
	disambiguate the frames, that implementation can chose to ignore
an added mux field; however
	the protocol should be explicit.

	Dorothy

	On 9/23/06, Michael Montemurro <[email-masked] >
wrote: 

		I don't see why a MUX header is required even if the
decision to go with separate control and data ports. I don't see how
this header definition is better than what is currently in draft -02. 
		 
		If there are specific edits to the header that are
required, I would like to know what they are; otherwise I propose
closing this issue.
		 
		Cheers,
		 
		Mike

_________________________________________________________________
		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