Stein-67 Slide 1

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
secure data
FCS
SecTAG (incl. IV)
ICV
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 .. 261 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
• MACsecs 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.htm
  l 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 SN0 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 SN0 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
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.tx
t

• 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
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
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 PEAI
• 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