1 / 12

IEEE 802.1ae & Legacy Technologies

IEEE 802.1ae & Legacy Technologies. Ken Grewal. Agenda. Problem Statement Technologies Impacted Recommendations. Problem Statement. 802.1AE services Data Integrity – over entire frame Data Confidentiality – beyond MACsec headers Obscures VLAN, L3, L4, + headers + data

talasi
Télécharger la présentation

IEEE 802.1ae & Legacy Technologies

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. IEEE 802.1ae & Legacy Technologies Ken Grewal

  2. Agenda • Problem Statement • Technologies Impacted • Recommendations

  3. Problem Statement • 802.1AE services • Data Integrity – over entire frame • Data Confidentiality – beyond MACsec headers • Obscures VLAN, L3, L4, + headers + data • Impacts existing deployed platform technologies

  4. Layered model and existing industrial base • OSI Layered model presents abstract model where each layer operates independently • Existing industrial products process several layers. • All deployed communication products seek for processing power gain and energy power reduction. • Partial layers transparency may drive efficient products and cause system processing gain and over all power reduction. • Worldwide deployed industrial products access TCP/IP header above upper level applications in 802.3 frames.

  5. In-Line manipulation of L2+ data • Complex End node System & Comm. design calls for “in-line” manipulation of Layer 2+ Payload in hardware. • DMTF sanctioned Manageability (ASF, IPMI, others) commonly uses same MAC address as general traffic, but separate IP addresses. • Manageability packets must be directed to Out-of-band processing by hardware to guarantee persistence of management under any platform OS or functionality state. • Efficient use of DMA’s, Memory, Cache, Interrupts has driven Controller based manipulation of Payload for nearly a decade. • Packet classification per Layer 3,4,5 fields, or per some host based multithreading optimization algorithm • Tasking to Hardware Programmable engine should not be assumed. • Feasible & often used. • But unnecessarily grows power and cost, and presents scalability challenges.

  6. TCP/IP level access needs • Need to read the TCP/IP data without encapsulation protocols knowledge. • Accessing TCP/IP level directly is a wide industrial practice used for several applications • RSS – directing packet for the processing in the multiprocessor environment according to the TCP/IP header • TCP offload functionality • TCP Checksum offload • TCP/IP header/data splitter • Upper layer data support • iSCSI offload • Remote DMA (RDMA) • General packet management / redirection

  7. MPDU Format MPDU = MACsec protocol data unit

  8. Possible Options • Do not use AE on end stations supporting these legacy functions (client / server) • Unlikely, as industry trends push for more security • Use AE without data confidentiality • Impractical in all GEOs + confidentiality should be policy based and not product based • Provide HW assist for AE in all impacted technologies • This is the intent, but need a migration path. • Modify AE to accommodate visibility into upper layer protocols • ONLY needed as a migration path, for deployed technology base • Future technologies / products can factor in AE as needed

  9. Possible changes in AE • Flexible encryption offset • 1 bit to control presence / absence of offset field in frame • Future versions of protocol can deprecate this bit, as needed • Control channel negotiation of encryption offset field – 802.1AF yet undefined, so can easily accommodate this. • Fixed encryption offsets • A set of well defined encryption offsets • Negotiated via control channel • Current AE frame format not impacted – only control channel impacted

  10. Fixed encryption offset • Cannot accommodate all packet format / protocol permutations! • Two primitives considered • IPv4 + Upper layer protocols • Ether type = 2 Octets • IP Header (no options) = 20 Octets • Min (TCP / UDP / SCTP / etc, ports) = 8 Octets Total = 2 + 20 + 8 = 30 Octets With VLAN = 2 + 4 + 20 + 4 (Only ports for TCP/UDP/…) = 30 Octets • IPv6 + Upper layer protocols • Ether type = 2 Octets • IP Header (no options) = 40 Octets • Min (TCP / UDP / SCTP / etc, ports) = 8 Octets Total = 2 + 40 + 8 = 50 Octets With VLAN = 2 + 4 + 40 + 4 (Only ports for TCP/UDP/…) = 50 bytes • 30/50 Octet encryption offset (negotiated via control channel)

  11. Recommendations • Option 1 • Flexible offset not plausible at this stage of AE • Option 2 • Set of fixed encryption offsets (0/30/50) • Support L2/3/4 header exposure for IPv4/6 • No modifications to current AE frame format • Some textual changes reflect optional offsets • Control Channel (802.1AF) can negotiate offsets

  12. Questions?

More Related