Subject: L2VPN Requirements

From: "Serbest, Yetik" <[email-masked]>
Date: Thu, 8 Jan 2004 13:49:26 -0600

Russ Housley (L2VPN WG Security Adviser) sent his comments on L2VPN
requirements draft. Below please find his comments, which are categorized
into two sections as "comments for further discussion" and "comments with
proposed resolutions".

Thanks,

yetik

Comments for further discussion:

===============================

1------------

 4.5.2  Access control

   A L2VPN solution MAY also have the ability to activate the

   appropriate filtering capabilities upon request of a customer.

Russ: 

Where does the identity information to make the access control decision
function come from?  Is there a mechanism to ensure that the identity
information is authentic.

Editor:

Should we specify a mechanism? 

Comments with proposed resolutions:

==================================

1------------

 4.1 Scope of emulation

     - If sequencing is not turned on, BPDUs on a pseudowire may get

     out of order with respect to data packets and with respect to each

     other.

     - VPLS frames can get duplicated if the sequencing option isn't

     turned on. The data frames on the pseudowires are sent in IP

     datagrams, and under certain failure scenarios, IP networks can

     duplicate packets. If the pseudowire data transmission protocol

     does not ensure sequence of data packets, frames can be duplicated

     or received out of sequence. If the customer's BPDU frames are

     sent as data packets, then BPDU frames can be duplicated or mis-

     sequenced.

Russ: 

Is it a requirement that sequencing can be turned on? Also, can one turn it
on and another turn it off?  Or, is it a system-wide setting?

Resolution: 

Remove the first bullet point, as it is covered in the second one. Replace
"sequencing" by "PW sequencing".

2------------

 4.1 Scope of emulation

   L2VPN protocols SHOULD NOT interfere with existing Layer 2 protocols

   and standards of the Layer 2 network the customer is managing.  If

   they may impact customer Layer 2 protocols that are sent over the

   VPLS, then these impacts MUST be documented.

....

....

   The interaction between L2VPN and the customer equipment SHOULD

   comply with existing native protocols and specifications. In case, a

   L2VPN solution supports only a subset of these specifications, the

   exceptions MUST be documented.

Editor: 

Removed the second paragraph, as it is repetitive.

3------------

 4.2 Traffic Types

   It is desirable to support efficient replication of broadcast and
multicast traffic.

Russ:  

Is this sentence a SHOULD statement? 

Editor: 

I believe it was a "SHOULD", and I think it was changed based on the
L2VPN-DT discussions before.

Resolution: 

Replace the sentence with "Support efficient replication of broadcast and
multicast traffic is highly desirable."

4------------

 4.5 Security

....

    - Tampering with data forwarding

       o Incorrect MAC learning entry

       o Incorrect label

Russ: 

What kind of label? 

Resolution: 

"Incorrect PW label".

5------------

Russ: 

Confused by Section 4.10, CE-to-CE and CE-to-PE link requirements. The first
part discusses CE-to-PE links, and the second part discusses PE-to-PE links.
There is no discussion of CE-to-CE links.

Resolution: 

The title of Section 4.10 should read "CE-to-PE and PE-to-PE Link
Requirements" not "CE-to-CE and CE-to-PE Link Requirements". The only
possible CE-to-CE links in the service model is backdoor links and we
already have some requirements in place to handle those cases.

6------------

 5.5.3  Value added security services

   Security measures employed by a L2VPN service SHOULD NOT restrict

   implementation of customer based security add-ons.

Russ: 

At what layer?  L2 (like 802.10b) is above the MAC, but it could encrypt
VLAN tags. This makes other requirements impossible for other requirements
to be met.  I think L3, L4, and L7 need to be accommodated.  L1 and L2 can
cause problems. I think that it is appropriate to discuss the issue in this
section. Then, the concluding requirement is that the L2VPN service must not
interfere with security mechanisms employed at L3 or higher, but that the
L2VPN service may interfere security mechanisms in L1 and L2.

Resolution: 

Replace the text with the following.

"L2VPN services MUST NOT interfere with the security mechanisms employed at
Layer-3 and higher layers by customers. Layer-2 security mechanisms, such as
802.10b ([IEEE_802.10]), MAY NOT work with the L2VPN services, when the
service-delimiting VLAN-Ids are encrypted."

7------------

Russ: 

Personally, I find Figure 2 confusing. It will take more space, but a
separate Figure for each case may help by providing whitespace around them.
Plus, the discussion of each case can be with it. There is not currently
text to go with each case, which adds to my confusion.  Without a discussion
of each one, how can the reader tell the MUST from the SHOULD.

Resolution: 

Done as follows (Figures are not shown):

   L2VPN solutions

   SHOULD support at least the types of physical or link-layer

   connectivity arrangements shown in Figure 2-4 (in addition to the case

   shown in Figure 1). As in Figure 2, a CE can be dual homed to an SP or to
two

   different SPs via diverse access networks.

         Figure 2 Dual-Homed Access of CE Devices.

   Resiliency of the L2VPN service can be further

   enhanced as shown in Figure 3, where CE's, connected via a "back

   door" connection, connect to the same SP or to different SPs.

         Figure 3 Backdoor Links Between CE Devices.

   Arbitrary combinations of the above methods, with a few examples shown in

   Figure 4 SHOULD be supportable by any L2VPN solution.

         Figure 4 Combination of Dual-Homing and Backdoor Links for CE
Devices.

8------------

 6.7 Security

   The security requirements are stated in Section 4.5. The

   requirements provided in [PPVPN-REQTS] and in [L3REQTS] SHOULD be

   met as appropriate.

Russ: 

What does "as appropriate" mean?

Resolution: 

Replace the text as follows:

 6.7 Security

   The security requirements are stated in Section 4.5. The security 

   requirements provided in [PPVPN_REQTS] SHOULD be met. The security 

   requirements, except Layer-3 and higher layer dependent ones, 

   specified in [L3VPN_REQTS] SHOULD be met.

9------------

Russ: 

Missing references for Virtual LAN and IPLS in Section 3.4, for DSCP and
802.1p in Section 4.7.2, for 802.1s in Section 5.7.4, 

Resolution: 

Added [IEEE_802.1Q] for VLAN, [L2VPN_FR] for IPLS, [RFC2474] for DSCP,
[IEEE_802.1D] for 802.1p, and [IEEE_802.1s] for 802.1s, 

10------------

Non-ASCII characters, spelling errors, grammatical errors, inconsistent
spelling etc...