1 / 4

Packet Format Issues

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.

shilah
Download Presentation

Packet Format Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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.

  2. 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?

  3. 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.

  4. 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

More Related