1. Stein-67 Slide 1 PWsec draft-stein-pwe3-pwsec-00.txt PWE3 – 67 th IETF 7 November 2006 Yaakov (J) Stein

2. Stein-67 Slide 2 Reminder draft-stein-pwe3-sec-req identifies user and control plane security threats user plane problems derive from PW packets having no confidentiality integrity source authentication mechanisms here we will describe a method to supply such mechanisms

3. Stein-67 Slide 3 MACsec Recently IEEE 802.1ae proposed a security mechanism based on AES-128, but with a new mode - Galois Counter Mode SecTAG contains MACsec Ethertype (88E5) 4B Packet Number (sequence number) 8B Secure Channel Identifier … DASATypepayloadFCS DASAsecure dataFCS’SecTAG (incl. IV) ICV integrity optional confidentiality 12 B Initialization Vector

4. Stein-67 Slide 4 AES/GCM advantages encryption is provided by “state-of-the-art” AES (128/256 bit keys) mode of operation uses a counter to thwart replay attacks Integrity Check Value verifies the payload integrity encryption, integrity, and source authentication by a single algorithm authentication can be performed without encrypting data not in packet payload (e.g. source identifiers) can be authenticated too Initialization Vector nonce can be any length (but should not repeat for given key) algorithm can be efficiently implemented in software computation can be parallelized for high speed hardware implementations unencumbered by IPR claims adopted by IEEE 802.1ae for MACsec and RFCs 4106 and 4543 for IPsec

5. Stein-67 Slide 5 AES/GCM Input / Output Encryption Input plaintext to be encrypted (up to 2 36 -32 bytes) encryption key (128 or 256 bits) per-packet randomly generated IV (12 B recommended) additional data to be authenticated but not encrypted (0.. 2^61 B) Encryption Output ciphertext (length = length of plaintext) ICV (16 B) Decryption Input ciphertext encryption key IV used for encryption ICV generated by encryption Encryption Output Authentication pass/fail if pass - plaintext

6. Stein-67 Slide 6 PWsec format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Label | EXP |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW label | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Initialization Vector (IV) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encrypted Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Integrity Check Value (ICV) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7. Stein-67 Slide 7 Misc. considerations Use of PWsec must be –configured in both IWFs or –signaled via new TLV in PWE control protocol Initialization Vector –MACsec’s IV is 4B counter + 8B SCI –here IV should be chosen pseudo-randomly Source authentication as PW packet does not contain a source ID –can use source PE ID + AI –if LDP is authenticated, can use PW label + SN

8. Stein-67 Slide 8 dotting the i's PWE3 – 67 th IETF 7 November 2006 Yaakov (J) Stein

9. Stein-67 Slide 9 Pseudowire or pseudo-wire ? in the early days of the WG, different spellings were in use Pseudo Wire Pseudo-wire Pseudowire early RFCs use pseudo-wire, while later ones migrated to pseudowire http://www.ietf.org/html.charters/pwe3-charter.html now says: Pseudowire Emulation Edge to Edge (pwe3) from now on all drafts use the agreed term

10. Stein-67 Slide 10 RFC4385 and atm-encap problem RFC4385 (CW) states: If a PE negotiated not to use receive sequence number processing, and it received a non-zero sequence number, then it SHOULD send a PW status message indicating a receive fault, and disable the PW. the original text simply said If a PE does not support receive sequence number processing, then the sequence number field MAY be ignored. this new text first appeared in atm-encap draft version 08 it is not in RFCs 4448 (Ethernet), 4618 (HDLC), 4619 (frame relay) the problem is that RFC4447 (control protocol) negotiates the use of the control word (via the "C" bit) but provides no way of negotiating use of CW w/o using SN that is why SN=0 is a special case ! it enables NOT using the sequence number without signaling the fact !

11. Stein-67 Slide 11 Discussion sequencing should not start or stop in the middle of a PW so perhaps we could say If a PE was configured not to use receive sequence number processing but do we really need this ? the PWE philosophy has been not to check such things on a packet by packet basis Alternatively, perhaps we can consider the sending of SN=0 to be the negotiation but then RFC3985 says If the sequence number on the packet is zero, the sequence integrity of the packets cannot be determined. In this case, the received packet is considered to be in order.

12. Stein-67 Slide 12 FEC 128/129 problem FEC 128 (PWid) usually used for ATM or FR PWs, FEC 129 (generalized PWid) for VPLS or situations with autodiscovery mechanism there is no negotiation of FEC capabilities how does a PE decide to use 128 vs 129 ? how does it know what the other PE supports ? if an attempt at label mapping fails because of unsupported type how does the PE know why ? Proposal LDP FEC capability exchange

13. Stein-67 Slide 13 Definition of forwarder RFC 3985 (architecture) figures 4 and 5 show a single forwarder connected to multiple ACs … while in RFC 4447 we have the following text The protocol used to setup a pseudowire must allow the forwarder at one end of a pseudowire to identify the forwarder at the other end. We use the term "attachment identifier", or "AI", to refer to the field which the protocol uses to identify the forwarders. What does a forwarder do if connected to one AC ? forwarder ACs PW instance PWsACs forwarder PW instance PWs

14. Stein-67 Slide 14 To make things worse … the RFC 3985 explanation of forwarder further confuses things In some situations, the packet payload may be selected from the packets presented on the emulated wire on the basis of some sub- multiplexing technique. … This is a forwarder function, and this selection would therefore be made before the packet was presented to the PW Encapsulation Layer. this should be AC !

15. Stein-67 Slide 15 Proposals remove text from atm-encap draft (in RFC editor queue) before publication RFC 4385 erratum: remove text If a PE negotiated not to use receive sequence number processing, and it received a non-zero sequence number, then it SHOULD send a PW status message indicating a receive fault, and disable the PW. RFC 3985 erratum : AC instead of emulated wire RFC 4447 erratum : AC instead of forwarder

16. Stein-67 Slide 16 Y.1731 VCCV format draft-mohan-pwe3-vccv-eth-00.txt PWE3 – 67 th IETF 7 November 2006 Yaakov (J) Stein

17. Stein-67 Slide 17 Why ? PWs, especially TDM PWs need full-featured OAM connectivity verification fault reporting loopback control packet loss monitoring delay and PDV monitoring Many different OAM systems in use Most recent development is Y.1731 (802.1ag) State-of-the-art full-featured packet OAM Exploits experience of all previous OAM protocols Rapidly becoming gold standard for comparison

18. Stein-67 Slide 18 Y.1731 PDU LEVEL (3b) VER (5b) OPCODE (1B) FLAGS (1B) TLV offset (1B) TLV list end TLV (1B) LEVEL = 0.. 7 allows hierarchical layering of OAM VER = 0 OPCODE = CC (7 different rates allowed) LoopBack Link Trace AIS … FLAGS contain info such as RDI TLV offset enables fixed position parameters (e.g. timestamps) TLVs contain information

19. Stein-67 Slide 19 Y.1731 PDUs in VCCV To use Y.1731 PDU in VCCV PW label of PW being maintained use PWACH control word (need chType for Y.1731) insert unique endpoint identifiers –for Ethernet PW - may be MAC addresses –for other PW types, may be PE+AI PDU according to Y.1731 PW label CWsource and destination IDs Y.1731 PDU 0001 V=0 RES chType

20. Stein-67 Slide 20 Hierarchy may be useful for MS-PWs

21. Stein-67 Slide 21 Proposals make draft-mohan-pwe3-vccv-eth a WG draft allocate the required PWACH channel type