Security Framework for MPLS and GMPLS Networks draft-fang-mpls-gmpls-security-framework-01.txt

1
Security Framework for MPLS and GMPLS
Networksdraft-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

2
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

3
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.

4
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.

5
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.

6
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.

7
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

8
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.

9
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.

10
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