Security Framework for MPLS and GMPLS Networks draft-fang-mpls-gmpls-security-framework-01.txt Luyuan Fang Michael Behringer Ross Callon Jean-Luis Le Roux Raymond Zhang Paul Knight Yaakov Stein Nabil Bitar Jerry Ash Monique Morrow Richard Graveman July 23, 2007 69 IETF, Chicago

Status Update IETF 67 - San Diego IETF 68 - Prague IETF 69 – Chicago Project first proposed at MPLS WG. Design team formed (members listed on front page). IETF 68 - Prague 00 draft posted in March 2007 before the meeting. 00 draft presented at MPLS WG and CCAMP WGs. Gathered feedback from the MPLS and CCAMP WGs, Security and Routing ADs IETF 69 – Chicago 01 draft posted in July 2007 before the meeting. 01 draft will be presented at MPLS and CCAMP WGs. Request to become working group document Looking for more feedbacks

Refresh: Motivations and Objectives Background on the motivation for this draft Security questions raised by Security ADs and reviewers on several recent drafts in MPLS and CCAMP WGs. A single document, MPLS/GMPLS Security Framework, to address MPLS/GMPLS general security issues would be useful. Other drafts in MPLS/GMPLS WGs may reference this framework document and must address the security considerations specific to the individual specs. Objectives: To cover general security implications, requirements, and guidelines for MPLS/GMPLS, especially Inter-provider MPLS/GMPLS. Quickly gather feedback from MPLS WG, GMPLS WG, Security ADs/Chairs, and anyone in IETF interested in the topic. Deliver subsequent revisions and work toward Informational RFC to meet the needs of MPLS and CCAMP WGs.

Comments received for 00 draft (1) Important work and a good start, encourage the WG to take it up as a work item. Scope: there may be cases in which insider threats are important The stance of not inventing security protocols or methods is entirely correct, but there are times when it may be important to say how certain security methods are used: what options to choose or otherwise. The design team may want to look at RFC 4230, RSVP Security Properties. The important security guidelines on DoS, which cannot be totally prevented, are to be able to filter at line speed and not to be an amplifier of attacks. The document says that encryption is expensive. This is generally not as true as it once was (1980s, e.g.), but sometimes it's not encryption but just cryptographic integrity that's needed, which is even less expensive. The key management is important, neglected, and harder. The document needs to spend more time on IKE than IPsec, instead of vice versa.

Comments received for 00 draft (2) OSPF (v2 and perhaps v3) and IS-IS (which is special because it doesn't run over IP) should also be considered in addition to BGP. Because SNMPv3 is mentioned, perhaps ISMS should be considered as well. Also, the section on reporting may wish to look at the new work in the Syslog WG, which is approaching or completing Last Calls, unless the DT has some other methods in mind. Define the trust domain scope - What are the boundaries? e.g. link ends, remote peers, areas, ASes How do you prove that you are in the domain? What are you allowed to do if you are in the domain? What are you allowed to do if you are outside the domain? If you are allowed to do something you are in *a* trust domain. So we need to define other trust domains such as inter-AS peering points. What can you assume everyone else in your domain does? The example here is that in an RSVP domain, you assume that the other members of the domain apply the same level of per-interface security as you do.

Changes in 01 draft (1) Add new design team member: Rich Graveman Modified draft with many suggestions by Rich, Sam, Adrian, and others since IETF 68. Indicate that the boundaries of trust domain should be carefully defined when analyzing the security property of each individual network, e.g., the boundaries can be at the link termination, remote peers, areas, or quite commonly, ASes. Encrypting for confidentiality must be accompanied with cryptographic integrity checks to prevent certain active attacks against the encrypted communications. Emphasis on the importance of key management, which may be more demanding in terms of both computational and administrative overhead. it is important to bind the authentication to the key management for the encryption. Otherwise the protocol is vulnerable to being hijacked between the authentication and key management.

Changes in 01 draft (2) Structure change: in defensive techniques, discussed Authentication before Cryptographic techniques. Refer to the recent work in ISMS WG (Integrated Security Model for SNMP WG) to define how to use SSH to secure SNMP (due to the limited deployment of SNMPv3) Handling DoS attacks has become increasingly important. Useful guidelines include the following: 1. Perform ingress filtering everywhere. Upstream prevention is better. 2. Be able to filter DoS attack packets at line speed. 3. Do not allow oneself to amplify attacks. 4. Continue processing legitimate traffic. Over-provide for heavy loads. Use diverse locations, technologies, etc. Editorial changes No changes in scope

Changes in 01 draft (3) New references added: [OIF-SMI-01.0] Renee Esposito, “Security for Management Interfaces to Network Elements”, Optical Internetworking Forum, Sept. 2003. [OIF-SMI-02.1] Renee Esposito, “Addendum to the Security for Management Interfaces to Network Elements”, Optical Internetworking Forum, March 2006. [RFC3562] M. Leech, “Key Management Considerations for the TCP MD5 Signature Option”, July 2003. [RFC3631] S. Bellovin, C. Kaufman, J. Schiller, "Security Mechanisms for the Internet," December 2003. [RFC4230] H. Tschofenig and R. Graveman, “RSVP Security Properties”, December 2005. [RFC4808] S. Bellovin, “Key Change Strategies for TCP-MD5”, March 2007.

Next Steps We are asking for this draft to be adapted as MPLS Working Group document. Looking for more feedbacks from MPLS and CCAMP WG meetings, mailing lists, etc. Design team to continue update the draft and progress it toward Informational RFC.

Open discussion Scope: Is the current scope OK? What need to be added or removed if not. Areas may need special security attention: e.g., RSVP. RSVP-TE, PCE, Optical Interworking, PW, SNMP, and Inter-AS connections – may be addressed in this draft or more detailed in each individual document. Specific protocols may need to address their security considerations in the new I-D, e.g., p2mp RSVP TE may have more specifics in addition to RSVP-TE; VPLS and 802.1ah inter-connection may bring more specific security considerations beyond VPLS…