Subject: DISCUSS: draft-ietf-l2vpn-requirements

From: "Serbest, Yetik" <[email-masked]>
Date: Tue, 9 May 2006 09:47:16 -0500

Hi Everybody,

Sam Hartman sent the following DISCUSS after reviewing
draft-ietf-l2vpn-requirements. Below please find the DISCUSS and our
proposed resolution. Please let us know if you have any comments or
suggestions.

Thanks,

Yetik

DISCUSS-1:

    The L2VPN requirements do not address section 4.5.1 of RFC 3809.

    According to section 4.5, PPVPN solutions should address user

    security.  Section 4.5.1 says that PPVPN solutions that include user

    security should support confidentiality and integrity using standard

    mechanism s.

    I would strongly prefer that L2VPN handle this issue the same as

    L3VPN.  In particular text similar to section 6.9.1 of RFC 4031
needs

    to be included.

PROPOSED RESOLUTION: Include the following text in Section 6.6 Security.

When a L2VPN solution operates over a part of the Internet, it should
support a configurable option to support one or more of the following
standard IPsec methods for securing a customer's VPN traffic:

    o  Confidentiality, so that only authorized devices can decrypt it

    o  Integrity, to ensure that the data has not been altered

    o  Authentication, to ensure that the sender is indeed who he or she
claims to be 

    o  Replay attack prevention.

 The above functions SHOULD be applicable to "data traffic" of the
customer, which includes the traffic exchanged between sites.  It
SHOULD also be possible to apply these functions to "control traffic",
such as routing or signaling protocol exchanges, that  are not
necessarily perceived by the customer but are  nevertheless essential to
maintain his or her VPN.

 Furthermore, such security methods MUST be configurable between
different end-points, such as PE-PE and PE-MTU, only in the case where
L2VPN data traffic is carried over IP [RFC4023].  Methods to secure data
flows at the native service layer (Layer-2), from CE-CE,

CE-

 MTU and CE-PE, are outside the scope of this document.  It is also
desirable to configure security on a per-VPN basis [VPNSEC].

 A VPN solution MAY support one or more encryption schemes, including
AES, and 3DES.  Encryption, decryption, and key management SHOULD be
included in profiles as part of the security management system.

   [RFC4023]     Worster, T., and et. al., "Encapsulating MPLS in IP or
                 Generic Routing Encapsulation", RFC 4023, March 2005.

   [VPNSEC]      De Clercq, J., et al., "Considerations about possible
                 security extensions to BGP/MPLS VPN", Work in Progress.

DISCUSS-2:

    Also, please confirm that nothing from RFC 4031 6.10.4 applies to

    L2VPN.  I believe that nothing does because I believe you are not

    currently handling the multi-provider case.

PROPOSED RESOLUTION: Include the following text in Section 9 Security
Considerations.

    In the case where a L2VPN service is carried over IP [RFC4023],

    traverses multiple SP networks and passes through an

    unsecured SP, POP, NAP, or IX, then security mechanisms MUST be

    employed.  These security mechanisms include encryption,

    authentication, and resource protection, as described in section
4.5.

    For example, a provider should consider using both authentication

    and encryption for a tunnel used as part of an L2VPN that traverses

    another service provider's network.