® 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 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 = = 30 Octets With VLAN = (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 = = 50 Octets With VLAN = (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