Stein-67 Slide 1

PWsecPWsecdraft-stein-pwe3-pwsec-00.txtdraft-stein-pwe3-pwsec-00.txt

PWE3 – 67th IETF

7 November 2006

Yaakov (J) Stein

Stein-67 Slide 2

ReminderReminder

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

Stein-67 Slide 3

MACsecMACsec

Recently IEEE 802.1ae proposed a security mechanismbased 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

integrity

optionalconfidentiality

12 B Initialization Vector

Stein-67 Slide 4

AES/GCM advantagesAES/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

Stein-67 Slide 5

AES/GCM Input / OutputAES/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

Stein-67 Slide 6

PWsec formatPWsec 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) |

| |

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Stein-67 Slide 7

Misc. considerationsMisc. 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 authenticationas PW packet does not contain a source ID – can use source PE ID + AI– if LDP is authenticated, can use PW label + SN

Stein-67 Slide 8

dotting the dotting the i'si's

PWE3 – 67th IETF

7 November 2006

Yaakov (J) Stein

Stein-67 Slide 9

Pseudowire or pseudo-wire ?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

Stein-67 Slide 10

RFC4385 and atm-encap RFC4385 and atm-encap problemproblem

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 08it 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 !

Stein-67 Slide 11

DiscussionDiscussion

sequencing should not start or stop in the middle of a PWso 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 negotiationbut 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.

Stein-67 Slide 12

FEC 128/129 problemFEC 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 typehow does the PE know why ?

Proposal LDP FEC capability exchange

Stein-67 Slide 13

Definition of forwarderDefinition of forwarderRFC 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 ?

forwarderACsPW instance

PW instance

PW instance PWs

ACsforwarder PW instance

forwarder PW instance

forwarder PW instance PWs

Stein-67 Slide 14

To make things worse …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 !

Stein-67 Slide 15

ProposalsProposals

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

Stein-67 Slide 16

Y.1731 VCCV Y.1731 VCCV formatformat

draft-mohan-pwe3-vccv-eth-draft-mohan-pwe3-vccv-eth-00.txt00.txt

PWE3 – 67th IETF

7 November 2006

Yaakov (J) Stein

Stein-67 Slide 17

Why ?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

Stein-67 Slide 18

Y.1731 PDUY.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

Stein-67 Slide 19

Y.1731 PDUs in VCCVY.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

CW source and

destination IDsY.1731 PDU

0001 V=0 RES chType

Stein-67 Slide 20

Hierarchy may be usefulHierarchy may be usefulfor MS-PWsfor MS-PWs

Stein-67 Slide 21

ProposalsProposals

make draft-mohan-pwe3-vccv-eth a WG draft

allocate the required PWACH channel type