1 / 21

PWsec draft-stein-pwe3-pwsec-00.txt

PWsec draft-stein-pwe3-pwsec-00.txt. PWE3 – 67 th IETF 7 November 2006. Yaakov (J) Stein. 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

cgiles
Download Presentation

PWsec draft-stein-pwe3-pwsec-00.txt

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. PWsecdraft-stein-pwe3-pwsec-00.txt PWE3 – 67th IETF 7 November 2006 Yaakov (J) Stein

  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. 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 • … DA SA Type payload FCS DA SA SecTAG (incl. IV) secure data ICV FCS’ optional confidentiality integrity 12 B Initialization Vector

  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. AES/GCM Input / Output Encryption Input • plaintext to be encrypted (up to 236-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. 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. 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. dotting the i's PWE3 – 67th IETF 7 November 2006 Yaakov (J) Stein

  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. 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. 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. 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. forwarder PW instance ACs PWs PW instance PW instance forwarder PW instance ACs PWs forwarder PW instance forwarder PW instance 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 ?

  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. 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. Y.1731 VCCV formatdraft-mohan-pwe3-vccv-eth-00.txt PWE3 – 67th IETF 7 November 2006 Yaakov (J) Stein

  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. LEVEL (3b) VER (5b) OPCODE (1B) FLAGS (1B) TLV offset (1B) TLV list end TLV (1B) Y.1731 PDU 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. PW label CW source and destination IDs Y.1731 PDU 0001 V=0 RES chType 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

  20. Hierarchy may be usefulfor MS-PWs

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

More Related