Subject: [Capwap] <Interim>: Issue ???: QoS-DTLS interaction

From: "Mani, Mahalingam (Mani)" <[email-masked]>
Date: Sun, 4 Feb 2007 21:03:54 -0700

The following was discussed:

*          When data traffic is DTLS-protected between WTP & AC - the
different QoS-flows (11e-marked to-DS and Diffserv-marked from-DS) will
need to carry appropriate markings. This can lead to spurious replay as
the markings may cause reordering along the way - being carried over the
same DTLS session.

-         This is a concern for WTP-terminated 802.11i (as above).

-         Is there a need to differentiate control messages?

*          Are there any control messages requiring expedited delivery?

*          Proposed approach

-         Entertain per-DSCP DTLS sessions

-         Use DTLS-session resumption to create DTLS-session per-flow

*          Session-resumption preserves existing DTLS sessions - hence
allowing multiple DTLS sessions to exist between the same 5tuple
defining the transport endpoint-pair (AC & WTP).

*          Multiple DTLS sessions between the the same WTP-AC pair
(5-tuple)

*          Identify and map sessions by hosting DSCP values in the
preamble.

-         Nominal DoS concern (generic to all fields in the preamble)

*          WTP-initiated; need a control message to bind sessionID to
DSCP.

-         Issue

*          Does DTLS module implementation support multiple sessions for
same 5-tuple?

*          How do we let the DTLS module know which SA to pick?

*          Alternatives

-         Use different source addresses to distinguish DTLS sessions

-         Don't mark the encapsulation

Resolution:

This discussion was not closed due to lack of time. No issues have been
filed on the tracker yet.

The following is the proposed header addition (QoS Index) to the
preamble.
The QI is used to index into the database that maps the DTLS sessionID
corresponding to the
QoS value.
 
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

________________________________________________________________________

|  ver(4)  |  QI (3) |
|     |

|_______|______|______________________________________________________|_
__|

It has been argued that since WLAN entertains only 8 categories (802.1p
and 802.11e) that the 3-bit index is sufficient.

This mapping in the DTLS-protected datapath will require a control-plane
message exchange to map the (AC-WTP)

Address-protocol-port 5-tuple to the sessionid.

The proposal needs to be fully fleshed out with required text (including
corner cases when sessions are resumed for recovery purposes).

Thoughts?

Regards,

-mani

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 5 Feb 2007 08:17:28 -0800

Whatever proposed approach we agree on, I would highly recommend we make
it "optional", meaning that a single DTLS tunnel for the data plane
could be utilized if it was sufficient for a given deployment. The
question that remains is whether some negotiation is required, or simply
have each side use whatever logic/algorithm it chooses to determine how
many DTLS data tunnels, and which one to use on a per packet basis.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Mani, Mahalingam (Mani) [mailto:[email-masked]] 
	Sent: Sunday, February 04, 2007 8:04 PM
	To: capwap
	Subject: [Capwap] <Interim>: Issue ???: QoS-DTLS interaction
	Importance: High

	*          When data traffic is DTLS-protected between WTP & AC
- the different QoS-flows (11e-marked to-DS and Diffserv-marked from-DS)
will need to carry appropriate markings. This can lead to spurious
replay as the markings may cause reordering along the way - being
carried over the same DTLS session.

	-         This is a concern for WTP-terminated 802.11i (as
above).

	*          Are there any control messages requiring expedited
delivery?

	*          Proposed approach

	-         Use DTLS-session resumption to create DTLS-session
per-flow

	*          Session-resumption preserves existing DTLS sessions -
hence allowing multiple DTLS sessions to exist between the same 5tuple
defining the transport endpoint-pair (AC & WTP).

	*          Multiple DTLS sessions between the the same WTP-AC
pair (5-tuple)

	*          Identify and map sessions by hosting DSCP values in
the preamble.

	-         Nominal DoS concern (generic to all fields in the
preamble)

	*          WTP-initiated; need a control message to bind
sessionID to DSCP.

	-         Issue

	*          Does DTLS module implementation support multiple
sessions for same 5-tuple?

	*          Alternatives

	-         Use different source addresses to distinguish DTLS
sessions

	Resolution:

	This discussion was not closed due to lack of time. No issues
have been filed on the tracker yet.

	The following is the proposed header addition (QoS Index) to the
preamble.
	The QI is used to index into the database that maps the DTLS
sessionID corresponding to the
	QoS value.
	 
	0                   1                   2                   3

	|  ver(4)  |  QI (3) |
|     |

	It has been argued that since WLAN entertains only 8 categories
(802.1p and 802.11e) that the 3-bit index is sufficient.

	This mapping in the DTLS-protected datapath will require a
control-plane message exchange to map the (AC-WTP)

	The proposal needs to be fully fleshed out with required text
(including corner cases when sessions are resumed for recovery
purposes).

	Thoughts?

	Regards,

	-mani