Transcript PPT Version

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
1
Status Update
• IETF 67 - San Diego
– 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
2
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.
3
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.
4
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.
5
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.
6
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
7
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.
8
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.
9
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…