Subject: [Capwap] Proposed resolution to issue 137 - Proposal for a revised packet header

From: "Michael Montemurro" <[email-masked]>
Date: Sat, 23 Sep 2006 14:58:34 -0400

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

---

From: "Dorothy Stanley" <[email-masked]>
Date: Thu, 28 Sep 2006 09:11:09 -0700

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:
> 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
>