Packet Format Issues #227: Need Shim Header to indicate Crypto Property of packet

Packet Format Issues

• #227: Need Shim Header to indicate Crypto Property of packet

• Do we need to add pre-amble header to indicate if data is encrypted or not. Leads up to comments for #146 (in some 224/89 list comments)

• Comments: Need to determine if data is plain text or DTLS.

• WG List proposed text for new 32 bit pre-amble header, with 1 bit reserved for DTLS payload identification.
• No Consensus yet

• Do we put the pre-amble/mux on the capwap data channel. (from #146 comments on list)

• CON: Wastes 31 bits, since 1 bit is to used to tell if encrypted or not.

• CON: Since we set up a UDP tunnel in the first place it’s a property of that channel if the data is encrypted or not.

• FOR: the Lookup to check if the data is encrypted or not, is slower than just looking at 1 bit in header.

• FOR: an AC will have to handle non-encrypted traffic and MAY have to handle encrypted traffic (optional). So will have to do a table look up to check for data encryption for each packet. Less processing to know encrypted in packet.

• Alternate proposal, put bit in the capwap header and move the capwap header out of the data portion.

• Can’t capwap hdr comes after dtls header.
• WG decided to protect the entire capwap header.

Packet Format Issues

• #146: Updated Proposal for packet formats

• Separate fragmentation header from control header and if PDU is fragmented, put the control header only in first fragment

• FOR: Reduction of packet size?

• FOR: frag/re-assembly not really function of capwap?

• CON: Bits proposed are already specified in F and L bits. Introduces complexity in packet handling logic since packets have separate header sizes

• Tracker recommendation to reject request.

• Changing control and data formats so fields are tailored to the header type (data or control)

• CON: small amount of redundant data doesn’t justify different header formats

• Tracker recommendation to reject request.

• Add a Retry Number field

• CON: Doesn’t matter what the retry number is. Seq Num field is used to detect duplicate packets (retransmissions)

• Tracker recommendation to reject request

• Req and Resp to share the same message type vs explicit request and response message types

• CON: Easier to read with explicit message types.

• Tracker recommendation to reject request

• Increase the message type from 16 to 32 bits.

• COMMENT: WG List agreement that 16 bits is sufficient. Was originally increased from 8 bits.

• Tracker recommendation to reject request

• New comments (not considered in 146) on WG list on 1/23/07:

• Message drop recovery?

• Message syntax version?

• Message source/target specification?

Packet Format Issues

• #127: Usage of the Session ID field

• Do we need a Session ID Field?

• FOR: Used to bind control & data channels together with a dual port architecture.

• FOR: Easier for NAT traversal and load balancing (source/destination ip address changes)

• Comment: Is this only needed for DTLS control messages?

• Reply on list: This is independent of DTLS session.

• Change Session ID from 32 bits to 64 bit field

• FOR: harder to spoof the ID.

• Use keep alive packet as Session ID

• FOR: Put session ID in the payload of keep-alive message to manage NAT State.

• FOR: Use the keep alive function to bind control and data

• COMMENT: Do keep alive packets need to be sent if NAT is not detected?

• Reply on List: Yes, needed on DC so that we don’t lose DC (black-hole) and can detect errors on DC.
• WG List: Proposed Text submitted for keep alive packet. No consensus yet.

Packet Format Issues

• #223: Description of the RID Field is unclear

• Clarify the case why we need RID field to support multiple radios that share the same MAC address.

• Comment: Explain the BSSID is not sufficient since there can be BSSID re-use across a/b/g WTP vendors.

• Comment: Accepted in tracker, no further comments on list.

• Propose to List for General Consensus

• #230: Crypto Algorithms for DTLS

• Add AES-GCM with GMAC as mandatory mode

• FOR: Supported in IPSec (RFC 4106) and 802.1ae

• FOR: Significant performance improvements with AES-GCM to prepare for high throughput with upcoming 802.11n.

• Comment: This would require changes to TLS, but is a work in progress. Requires ECC instead or RSA, ECC is not mandatory now.

• Propose to List for WG Consensus