Addendum to the Security Extension for
UNI and NNI
IA # OIF-SEP-02.1
March 31, 2006
Implementation Agreement created and approved
by the Optical Internetworking Forum
www.oiforum.com
The OIF is an international non profit organization with over 100 member companies,
including the world’s leading carriers and vendors. Being an industry group uniting
representatives of the data and optical worlds, OIF’s purpose is to accelerate the deployment
of interoperable, cost-effective and robust optical internetworks and their associated
technologies. Optical internetworks are data networks composed of routers and data switches
interconnected by optical networking elements.
With the goal of promoting worldwide compatibility of optical internetworking products, the
OIF actively supports and extends the work of national and international standards bodies.
Formal liaisons have been established with The ATM Forum, IEEE 802.3, IETF, ITU-T Study
Group 13, ITU-T Study Group 15, MEF, NPF, T1M1, T1X1, TMF, UXPi and the XFP MSA
Group.
For additional information contact:
The Optical Internetworking Forum, 39355 California Street,
Suite 307, Fremont, CA 94538
510-608-5928 Φ [email protected]
www.oiforum.com
Notice: This Technical Document has been created by the Optical Internetworking Forum (OIF).
This document is
offered to the OIF Membership solely as a basis for agreement and is not a binding proposal on the companies listed as
resources above. The OIF reserves the rights to at any time to add, amend, or withdraw statements contained herein.
Nothing in this document is in any way binding on the OIF or any of its members.
The user's attention is called to the possibility that implementation of the OIF implementation agreement contained herein
may require the use of inventions covered by the patent rights held by third parties. By publication of this OIF
implementation agreement, the OIF makes no representation or warranty whatsoever, whether expressed or implied, that
implementation of the specification will not infringe any third party rights, nor does the OIF make any representation or
warranty whatsoever, whether expressed or implied, with respect to any claim that has been or may be asserted by any
third party, the validity of any patent rights related to any such claim, or the extent to which a license to use any such
rights may or may not be available or the terms hereof.
© 2001 Optical Internetworking Forum
This document and translations of it may be copied and furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in
part, without restriction other than the following, (1) the above copyright notice and this paragraph must be included on
all such copies and derivative works, and (2) this document itself may not be modified in any way, such as by removing
the copyright notice or references to the OIF, except as needed for the purpose of developing OIF Implementation
Agreements.
By downloading, copying, or using this document in any manner, the user consents to the terms and conditions of this
notice. Unless the terms and conditions of this notice are breached by the user, the limited permissions granted above are
perpetual and will not be revoked by the OIF or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and THE OIF DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, TITLE OR FITNESS FOR A PARTICULAR PURPOSE.
www.oiforum.com
2
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
1
Table of Contents
Cover Sheet ........................................................................................................... 1
1
Table of Contents ................................................................................................. 3
2
List of Figures ....................................................................................................... 4
3
List of Tables ......................................................................................................... 4
4
Document Revision History ............................................................................... 5
5
Document Summary............................................................................................ 6
5.1 Problem Statement............................................................................................... 6
5.2 Scope ...................................................................................................................... 6
5.3 Relationship to Other Standards Bodies........................................................... 7
5.4 Acknowledgements ............................................................................................. 7
6 Introduction .......................................................................................................... 7
6.1 Outline of the Implementation Agreement...................................................... 7
6.2 How to Use this Implementation Agreement.................................................. 8
7
Terminology and Acronyms .............................................................................. 8
7.1 Terminology.......................................................................................................... 8
7.2 Keywords .............................................................................................................. 8
7.3 Acronyms .............................................................................................................. 9
8
Applicability of Updates to IPsec .................................................................... 10
8.1 IKEv1 and IKEv2................................................................................................ 10
8.2 Revisions to ESP, AH, and RFC 2401 .............................................................. 11
8.3 Transforms .......................................................................................................... 13
8.4 IPv6 Considerations........................................................................................... 15
9 Security for Link State Routing in the NNI.................................................... 15
9.1 Implementations not Using the Security Extension...................................... 17
9.2 Securing OSPF with the Security Extension................................................... 17
9.3 Securing IS-IS with the Security Extension .................................................... 18
9.4 Additional Issues ............................................................................................... 18
10 Security for Discovery Protocols...................................................................... 19
10.1 Use of the Security Extension with LMP ........................................................ 19
11 Clarifications and Updates to the Security Extension .................................. 19
12 References ........................................................................................................... 20
12.1 Normative references ........................................................................................ 21
12.2 Informative references....................................................................................... 24
13 Appendix A: Open Issues / current work items........................................... 25
14 Appendix B: List of companies belonging to OIF when document was
approved ......................................................................................................... 26
www.oiforum.com
3
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
2
List of Figures
None.
3
List of Tables
None.
www.oiforum.com
4
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
4
Document Revision History
Working Group: OAM&P
SOURCE:
Editors
Renée Esposito
Department of Defense
[email protected]
Working Group Chair
Doug Zuckerman
Telcordia Technologies
[email protected]
Richard Graveman
Department of Defense
[email protected]
DATE: OIF-SEP-02.0: October 3, 2005
OIF-SEP-02.1: March 31, 2006
5
www.oiforum.com
5
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
Document Summary
This addendum brings the Security Extension for UNI and NNI [SecExt] up to date
with (1) new work in the OIF on NNI, routing, and discovery; (2) new work in
the IETF on IPsec and IKE; and (3) feedback gained from implementation
experience and other comments on [SecExt].
5.1
Problem Statement
The Security Extension for UNI and NNI [SecExt] defines an optional-toimplement profile of IPsec for securing the OIF’s control plane protocols. Its
first goal is to define a complete, high-quality, interoperable security system
for all control plane traffic between two network elements consisting of a
single pair of Tunnel Mode Security Associations running the mandatory-toimplement IPsec transforms. Secondly, it defines additional security services
and mechanisms that implementations of [SecExt] can include for finegrained control of security.
Since the publication of [SecExt], (1) the OIF has started new work on the UNI
and NNI and released Implementation Agreements for UNI 1.0r2 and E-NNI;
(2) the IETF has continued to revise IPsec, IKE, and the list of associated
transforms; and (3) suggestions to clarify certain aspects of [SecExt] have been
received. This IA keeps [SecExt] up to date and aligned with current practice
by addressing these three items.
5.2
Scope
This IA modifies the optional security extension to UNI and NNI in [SecExt].
It addresses protocol security for the OIF’s control plane signaling, routing,
and discovery protocols specified in [UNI1.0], [UNI1.0r2], [UNI1.0r2r],
[UNI2.0], [UNI2.0r], [UNI2.0c], [E-NNI], [NNI-OSPF], and [NNI-IS-IS].
Security for management plane interfaces to network elements is addressed
separately in [SecMang] and [SecManA].
[SecExt] defines an optional extension to the OIF’s control plane protocols
listed in Section 1.3. This addendum contains both REQUIRED and
OPTIONAL requirements for compliance with [SecExt] as well as
informational material to clarify items in [SecExt] and promote the
development of interoperable implementations.
www.oiforum.com
6
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
This IA extends the value of [SecExt] to new OIF control plane protocols,
keeps [SecExt] up to date with current work in the IETF, and clarifies aspects
of the use of [SecExt].
5.3
Relationship to Other Standards Bodies
This IA uses the RFCs written by the IETF as normative references to almost
all of the work described herein.
This document defines no new protocols. It consolidates, profiles, and applies
many aspects of work done at other standards bodies, particularly the IETF.
It updates and modifies the optional security services in [SecExt].
5.4
Acknowledgements
Hannes Tschofenig (Siemens) raised a number of questions about the use of IPsec
to protect RSVP. Scott McNown (DoD), Sheila Frankel (NIST), and Don Choi
(DoD) cooperated on implementing [SecExt] and provided feedback from their
experiences. Jonathan Sadler (Tellabs) advised the editors on the directions the
OIF is likely to take with respect to routing protocols, the use of GRE to
encapsulate IS-IS, and the potential, unintended interactions between IPsec
tunnel mode and DCN routing protocols. Jim Jones, Monica Lazer, Walter
Rothkegel, and Stephen Trowbridge provided helpful inputs during balloting.
6
Introduction
The goal of [SecExt] is to specify how to apply security to the control plane
(signaling, routing, and discovery) protocols used in the OIF’s UNI and NNI.
This IA brings [SecExt] up to date with changes in the UNI, specification of
the E-NNI, IETF work on IPsec, and implementors’ experiences with [SecExt].
6.1
Outline of the Implementation Agreement
This document is organized as follows:
•
Section 5 provides a summary of this addendum.
•
Section 6 describes the organization of this document.
•
Section 7 defines the terminology, keywords, and acronyms used.
•
Section 8 brings [SecExt] up to date with work in the IETF.
•
Section 9 covers security for the OIF’s link state routing in the NNI based
on OSPF and IS-IS.
www.oiforum.com
7
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
•
Section 10 defines the use of [SecExt] for the OIF’s discovery protocols
based on LMP.
•
Section 11 contains clarifications and implementation guidelines for
[SecExt].
•
Section 12 contains normative and informative references.
6.2
How to Use this Implementation Agreement
This IA is an addendum to [SecExt]. To apply it, it must be used together with
[SecExt]. It is not a self-contained replacement for [SecExt]. Applying this IA
also depends on using the normative references from the IETF and OIF listed
in Section 8.1.
7
Terminology and Acronyms
7.1
Terminology
Clarification: In [SecExt], the term “ONE” or “Optical Network Element” is
used to refer to either a UNI-C client or a Transport Network Element (TNE),
as defined in [UNI1.0], [UNI1.0r2], and [UNI2.0]. When applied to the OIF
UNI, the term “ONE” should be replaced with “UNI-C” or “TNE,” as
appropriate.
7.2
Keywords
When written in ALL CAPITALS, the key words “MUST”, “MUST NOT,”
“REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,”
“RECOMMENDED,” “MAY,” and “OPTIONAL” in this document are to be
interpreted as described in IETF RFC 2119 [Bra97].
In addition, as defined in [Sch05], the following terms and their respective
interpretations are used:
SHOULD+
SHOULD–
www.oiforum.com
This term means the same as SHOULD. However it is likely
that a requirement marked as SHOULD+ will be promoted at
some future time to be a MUST.
This term means the same as SHOULD. However a
requirement marked as SHOULD– may be deprecated to a
MAY in a future version of this IA.
8
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
MUST–
This term means the same as MUST. However it is expected
that at some point this requirement will no longer be a MUST
in a future version of this IA.
7.3
Acronyms
The following acronyms or abbreviations are used in this implementation
agreement:
ABR
AES
AH
CA
CBC
CCM
CRC
CTR
DAD
DCN
DES
DH
E-NNI
ESP
GRE
ESP
HMAC
ICMP
IESG
IETF
IKE
IP
IPsec
IS-IS
LMP
LSA
MAC
MIB
MTU
Area Border Router
Advanced Encryption Standard
Authentication Header
Certification Authority
Cipher Block Chaining (Mode)
Counter with CBC-MAC (Mode)
Cyclic Redundancy Check
Counter (Mode)
Duplicate Address Detection
Data Communications Network
Data Encryption Standard
Diffie-Hellman
Exterior Network Node Interface
Encapsulating Security Payload
Generic Routing Encapsulation
Encapsulating Security Payload
Hashed Message Authentication Code
Internet Control Message Protocol
Internet Engineering Steering Group
Internet Engineering Task Force
Internet Key Exchange
Internet Protocol
IP Security
Intermediate System—Intermediate System
Link Management Protocol
Link State Advertisement
Message Authentication Code
Management Information Base
Maximum Transmission Unit
www.oiforum.com
9
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
NA
NAT
NE
NNI
OSPF
PAD
PS
RFC
RSA
RSVP
RFC
SA
SAD
SHA
SIP
SNMP
SPD
TCP
TNE
UDP
UNI
UNI-C
VPN
XML
8
Network Administrator
Network Address Translation
Network Element
Network Node Interface
Open Shortest Path First
Peer Authentication Database
Proposed Standard
Request for Comments
Rivest, Shamir, and Adleman
Resource Reservation Protocol
Request for Comments
Security Association
Security Association Database
Secure Hash Algorithm
Session Initialization Protocol
Simple Network Management Protocol
Security Policy Database
Transmission Control Protocol
Transport Network Element
User Datagram Protocol
User-Network Interface
UNI Client
Virtual Private Network
Extensible Markup Language
Applicability of Updates to IPsec
See [Abo04] (Informational) for the use of IPsec in IP Storage, which was used
as a guide to specifying the profile of IPsec in [SecExt].
8.1
IKEv1 and IKEv2
The current IKE version 1, as described in [SecExt] and modified by [Hof05a],
MUST– be included with implementations of [SecExt]. However, the reasons
for replacing IKEv1 with IKEv2 as quickly as practical are that IKEv2 is
simpler to implement, has clearer documentation, is more efficient, has fewer
options, and fixes some of the shortcomings in IKEv1. IKEv2 [Kau05]
SHOULD+ be implemented. (The current IKEv2 draft has been approved as
www.oiforum.com
10
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
PS by the IESG and is awaiting an RFC number to be assigned. It is expected
that after the IKEv2 RFC is issued, it will become the REQUIRED key
management system.)
For additional information about IKEv2, see [EH06], [Per03] (expired), and
[Kra03].
For implementations of IKEv1 or IKEv2 that allow use of public key
authentication (e.g., digital signatures), [Kor05] SHOULD+ be implemented.
For implementations of IKEv2 that allow use of a legacy authentication
system, [Tsc06] SHOULD be implemented.
Implementations of IKEv2 SHOULD measure resource consumption and use
the initial exchange with cookies whenever they determine that a denial of
service attack may be occurring.
8.2
Revisions to ESP, AH, and RFC 2401
The new version of ESP [Ken05a] and [Ken05b] and revision to the IPsec
Security Architecture in RFC2401bis [KS05] provide:
•
Extended (64-bit, implicit) sequence numbers
•
Better traffic flow protection (padding and dummy packets)
•
More flexible naming of security associations
•
Better support for multicast
•
Support for new algorithms and modes (AES, counter mode, and
combined confidentiality and integrity mode algorithms)
•
A Peer Authorization Database (PAD)
•
A new processing model with better support for VPNs and combined
mode algorithms (The concept of “SA bundles” has been dropped.)
Therefore, the new version of ESP [Ken05a] and [Ken05b] and RFC2401bis
[KS05] SHOULD+ be implemented, and the current versions [KA98a] and
[KA98c] MUST– be implemented.
Implementations that provide NAT traversal MUST follow [Hut05]. See also
[AD03] (Informational) for a discussion of NAT traversal requirements.
For dead peer detection, implementations MAY generate and MUST accept
the messages defined in [HBR04].
www.oiforum.com
11
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
Both versions of AH ([KA98b] and [Ken05c]) MAY be implemented, but use
of ESP is preferred over AH in all cases.
www.oiforum.com
12
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
8.3
Transforms
It is expected that AES will replace DES and Triple DES as the REQUIRED
confidentiality algorithm for ESP and IKE, partially because it is more
efficient, and partially because it is presumed to offer better security. This
change has additional consequences. First, AES can also be used as the ESP
(and IKE) integrity algorithm, which reduces the total number of algorithms
in and code size of implementations. Second, AES is defined with new, more
efficient modes of operation (counter mode [Hou04] and combined
confidentiality and integrity mode [Hou05, VM05, MV05]). Third, it is
recommended that the security of IKE key exchanges be increased to match
the increased level of security that comes with using AES.
Implementors of these transforms, who often need pseudorandom,
unpredictable numbers or bit strings for keying material, initialization
vectors, padding, or other uses, are also referred to [ESC05].
8.3.1
IPsec Transforms
The RECOMMENDED and REQUIRED to implement suites for IPsec and
IKEv1 are defined in [Hof05b]. Suite A is MUST– and Suite B is SHOULD+.
All other IPsec transforms, including user-defined algorithms, MAY be
implemented.
8.3.2
IKEv2 Transforms
The RECOMMENDED and REQUIRED IKEv2 transforms below are adopted
and augmented from those in [Sch05] to meet the requirements in [SecExt].
All other IKEv2 transforms, including the elliptic curve groups defined in
[FS05] and user-defined algorithms, MAY be implemented.
•
The IKEv2 encrypted payload requires an encryption algorithm and an
integrity algorithm. For the encryption algorithm, 3DES-CBC [PA98]
MUST– be implemented and AES-128-CBC [FGK03] SHOULD+ be
implemented.
•
For the integrity algorithm, SHA-1 [MG98] MUST be implemented and
AES-XCBC-MAC-96 [FH03] SHOULD+ be implemented.
•
IKEv2 requires a Diffie-Hellman group. As in [Sch05], Group 2 (1024
bits) [HC98] MUST– be implemented and Group 14 (2048 bits) [KK03]
SHOULD+ be implemented. In addition, Group 5 (1536 bits) [KK03]
SHOULD be implemented.
www.oiforum.com
13
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
IKEv2 [Kau05] provides for negotiation of confidentiality algorithms (Type
11) for use in IKE and ESP, pseudo-random functions (Type 2) for use in IKE,
and integrity algorithms (Type 3) for use in IKE, AH, and ESP.
•
•
For confidentiality algorithms (Type 1), see the table below:
Algorith
m
Number
Algorithm
Name
Reference
Status
0
n/a
n/a
RESERVED
3
ENCR_3DES
[PA98]
MUST–
11
ENCR_NULL
[GK98]
MUST
12
ENCR_AES_CBC
[FGK03]
SHOULD+
13
ENCR_AES_CTR
[Hou04]
SHOULD
18, 19, 20
AES-GCM-ESP
[VM05]
SHOULD
For pseudo-random functions (Type 2), see the table below:
Algorith
m
Number
Algorithm
Name
Reference
Status
0
n/a
n/a
RESERVED
2
PRF_HMAC_SHA1
[KBC97]
MUST–
4
PRF_AES128_CBC
[Hof04],
[Hof06]
SHOULD+
These designations, “Type 1” for confidentiality (encryption) algorithms and
“Type 3” for integrity algorithms, apply only in the context of IKEv2 for
algorithm robustness and have nothing to do with the use of “Type numbers” to
describe algorithms in other contexts.
1
www.oiforum.com
14
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
•
For integrity algorithms (Type 3), see the table below:
Algorithm
Number
Algorithm
Name
Reference
Status
2
HMAC_SHA1_96]
[MG98
MUST–
5
AUTH_AES_XCBC_
96
[FH03]
SHOULD+
11
ENCR_NULL
[GK98]
MUST
18
AES-GCM-ESP
[VM05]
MAY
19
AES-GCM-ESP
[VM05]
MAY
20
AES-GCM-ESP
[VM05]
SHOULD
8.4
IPv6 Considerations
This specification of ESP and IKE works with both IPv4 and IPv6.
The following options MUST NOT be used with IPv6: link-local and site-local
addresses, NAT traversal, and Mobile IP.
Note that IPv6 (as well as IPv4) implementations of IKEv2 MUST support the
larger minimum MTU of 1280 and SHOULD support an MTU of 3000 as
specified in [Kau05].
Note that IPv6 subnet renumbering MAY break existing IPsec SAs, which
then need to be re-established. Unique local addresses (ULAs) MAY be used.
When using ESP or IKE with IPv6, ICMPv6 MUST be handled as specified in
[KS05].
Either IPv6 Autoconfiguration with DAD or DHCPv6 MAY be used with
IPv6.
IPv6 packets using IKE or ESP as specified herein MUST be allowed to traverse
firewalls and MAY be transported through IPv4 transition tunnels. Note also that
IPv6 packets to be protected with ESP Tunnel Mode MAY be encapsulated with
an IPv4 outer header.
9
www.oiforum.com
15
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
Security for Link State Routing in the NNI
The OIF has specified signaling for the UNI ([UNI1.0], [UNI1.0r2], [UNI1.0r2r],
and [UNI2.0]) and NNI ([E-NNI]) and now is developing routing solutions for
the NNI ([NNI-OSPF] and [NNI-IS-IS]).
The security requirements for NNI signaling are summarized in [SecExt]. The
IETF, in [BMY03], has enumerated the sources, actions, and consequences
inherent in security threats to routing protocols. The consequences of such
attacks (see [BMY03]) can include disclosure of network configuration data,
deception, disruption, and loss of control of network functionality. The resulting
damage can include congestion, black-holing, looping, partitioning, churning,
instability, overload, starvation, eavesdropping, or delay.
Attacks against routing protocols can disrupt the establishment of peering
relationships; interfere with protocol elements such as election of a designated
router; forge or modify routing information; eavesdrop on the content or traffic
patterns of routing information; corrupt the internal state of routing databases; or
replace an authorized router with an imposter.
This IA addresses the protocol issues involved in securing OSPF and IS-IS as
used in the OIF’s NNI. It does not address (1) system security for routers; (2)
problems that result from faulty implementations; (3) physical, personnel, and
environmental security issues; (4) firewalls; (5) security for IPv6 Router
Advertisements; or (6) denial of service attacks that result, for example, from
flooding routers.
Implementations of the OIF’s Security Extension for UNI and NNI MUST provide
the same security services for the routing protocol messages that determine
forwarding of signaling messages as for the signaling protocol messages
themselves. If routing controllers communicate along the same path for which
IPsec SAs to secure signaling are specified in the Security Policy Database (SPD),
the SPD SHOULD specify use of these same SAs for routing protocol messages,
but see the cautionary note in Section 7, below. In addition, these security
services MAY be applied to routing protocol messages that determine packet
forwarding in the data plane or management plane.
Securing link state routing protocol messages with the OIF’s Security
Extension for UNI and NNI prevents modification, address spoofing, forgery,
replay, and “cut-and-paste” attacks against these protocols. It also can
provide confidentiality, hide the names of the endpoints, and disguise the
actual amount of traffic transmitted, which inhibit network mapping attacks.
Link state routing protocols, however, rely on distributing accurate topology
and configuration information across a network. To accomplish this, the
www.oiforum.com
16
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
switches trust each other to act properly. Because of this, a compromised or
mis-configured switch can do a lot of hard-to-detect damage. Protocol
security between adjacent switches cannot solve this problem.
To provide end-to-end routing protocol security, digital signatures on the
messages can be used. Such an approach has been proposed not only for
routing protocols [Per88, Ste93, Mur97] but also for secure email, XML, and
SIP. New methods exist to provide adequate security with signatures only 20
to 25 bytes long [BLS01] and to combine multiple signatures into a single,
aggregated signature [Bon03], which eliminate potential objections due to
extensive message overhead. Methods such as these may be proposed for
future OIF Control Plane protocols.
In the meantime, the OIF is working on a different approach, which may be
useful in its own right. The idea is to specify a flexible, dynamically
configurable logging and auditing capability, which, among other uses, can
be turned on to generate a trace of a Control Plane protocol whenever
needed. This capability is based on the Syslog protocol, which is currently
being revised by the IETF. For the most recent references to the underlying
Syslog mechanisms, see [SysL]. Although the Syslog transport mechanism
(unidirectional, unfragmented UDP packets) is chosen to minimize overhead,
logging may add to network congestion or overload conditions. Operators
may choose to turn logging off in such situations, manually or automatically.
9.1
Implementations not Using the Security Extension
OSPF implementations not using the OIF’s Security Extension for UNI and NNI
SHOULD use OSPFv2 with the option for cryptographic authentication
specified in Sections D.3, D.4.3, and D.5.3 of RFC 2328. IS-IS implementations
not using the OIF’s Security Extension for UNI and NNI SHOULD incorporate
the authentication mechanism specified in RFC 3567 (Informational).
Note, however, that these mechanisms do not include automated key
management.
[GHM04], the so-called hop-count-255 trick, MAY be used to verify that
untampered messages are delivered directly, router to router. Note, however,
that this mechanism does not provide cryptographic protection against
tampering or forgery.
9.2
www.oiforum.com
Securing OSPF with the Security Extension
17
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
Implementations of [NNI-OSPF] that also provide [SecExt] MUST allow for
IPsec protection of OSPF messages. Wherever practical, they SHOULD do
this with the same IPsec SAs used for signaling. (Note that this is consistent
with the security in [GM05]2.) To aid in the diagnosis of multiple-hop or endto-end security problems, such implementations SHOULD also implement
[LogAud]. As an alternative to deploying logging at all routers in an Area,
implementations MAY log only at ABRs and MAY use digital signatures on
LSAs (link state advertisements) within an Area (i.e., they MAY implement
[Mur97] in addition to [SecExt]). Note, however, that aggregation of routing
information (LSAs) does not preserve signatures.
9.3
Securing IS-IS with the Security Extension
Implementations of [NNI-IS-IS] that also provide [SecExt] MUST allow for
IPsec protection of IS-IS messages. Because IS-IS runs directly over a link
layer protocol, not over IP, GRE [Far00] SHOULD be run between the IS-IS
peers. The protocol stack IS-IS/GRE/ESP/IP/<Layer 2> SHOULD be used.
The IPv4 or IPv6 next header is 50 for ESP. When using this option,
implementations MUST– use [KA98c] and SHOULD+ use [Ken05a] for ESP.
The ESP next header is 47 for GRE. The version and Reserved0 fields in the
GRE header MUST be set to 0. Because ESP secures GRE and IS-IS, [Dom00]
or [LA03] SHOULD NOT be used. Wherever practical, implementations
SHOULD protect IS-IS over GRE with the same IPsec SAs used to protect the
signaling traffic between the same two points. To aid in the diagnosis of
multiple-hop or end-to-end security problems, such implementations
SHOULD also implement [LogAud].
Note: No description of a signature option for IS-IS, which would correspond
to [Mur97] exists. Such capability is for future study.
9.4
Additional Issues
Management interfaces to routers implementing the OIF’s NNI routing
protocols, in particular implementations of MIBs for OSPF and IS-IS,
SHOULD secure these management interfaces with the methods specified in
[SecMang] and [SecManA].
The most general security solution for protocols like OSPF and IS-IS allows
the link state protocol to work correctly as long as one uncorrupted path
2
This standard recommends protecting OSPF messages with IPsec ESP, which adds confidentiality,
although it does not provide end-to-end security against the case of a misbehaving router.
www.oiforum.com
18
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
between any two points exists. There may be multiple failures, and the
corrupted routers may in fact be cooperating to carry out an attack. Perlman
(in [Per88] and [Per00]) has shown how to how achieve security in such cases,
which are called “Byzantine failures.” Addressing such threats, in whole or in
part, is for future study.
10
Security for Discovery Protocols
Discovery protocols for UNI 2.0 have not been fully defined. As this work
progresses, security requirements and specifications for discovery ought to be
reconsidered.
10.1
Use of the Security Extension with LMP
The Link Management Protocol (LMP) draft [Lan05] proposes the use of IPsec
to secure LMP, which is, in principle, consistent with this IA. However, the
following notes are added to the specification of IPsec in [Lan05]:
1. As specified in this document and in [SecExt], the confidentiality
service with ESP MUST be implemented and SHOULD be used
wherever required.
2. The specification of IPsec in [Lan05] is updated with the newer
transforms and protocols for IKEv2 and ESP, as specified above.
3. Use of IKE or IKEv2 with pre-shared keys is preferable to manual
keying.
As for routing protocols, wherever practical, LMP MAY share SAs with other
protocols protected by [SecExt] and the methods in this IA. That is, when
LMP messages are sent along a path that uses the Security Extension, the SPD
SHOULD be configured so that all LMP messages are protected with the
same IPsec SAs as other traffic secured with the Security Extension. Note that
this applies only to unicast messages; the Security Extension does not define
security for broadcast or multicast messages.
Management interfaces to systems implementing discovery protocols
SHOULD be secured with the methods specified in [SecMang] and
[SecManA].
11
Clarifications and Updates to the Security Extension
The following notes are added as clarifications to [SecExt]:
www.oiforum.com
19
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
1. The IPsec selectors for ESP Tunnel Mode MAY be set up to secure all
IP traffic between the two points.
2. The RSVP messages used in the OIF’s signaling protocols do not use
the Router Alert bit, which would interfere with the use of the
confidentiality service of IPsec.
3. ESP in tunnel mode SHOULD be used between each pair of RSVPaware routers.
Caution: If IPsec Tunnel Mode is used and the implementation treats
these IPsec tunnels as virtual interfaces, these virtual interfaces may be
assigned DCN routing protocol costs that, if advertised by the DCN
routing protocol, cause traffic between other systems to be routed
inappropriately. For IPsec implementations that have this side effect,
inappropriate DCN routing protocol costs due to such virtual
interfaces should not be advertised across the DCN routing protocol.
Note, in addition, that [KS05] allows IPsec Transport Mode to be used
with certain restrictions.
4. Transport mode IPsec SAs SHOULD be avoided.
5. The RSVP authorization object may be used for user identification in
addition to the security methods specified in this IA and in [SecExt].
12
www.oiforum.com
20
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
References
12.1
Normative references
The following references contain provisions that, through reference in this
text, constitute provisions of this specification. At the time of publication, the
versions listed were valid. Many references are subject to revision, and parties
to agreements based on this implementation agreement are encouraged to
investigate the possibility of applying the most recent editions of the
references indicated below.
[Bra97]
[DH98]
[E-NNI]
[Far00]
[FGK03]
[FH03]
[FS05]
[GHM04]
[GK98]
[HBR04]
[HC98]
[HFPS99]
www.oiforum.com
Bradner, S., “Key words for use in RFCs to Indicate
Requirement Levels,” IETF RFC 2119, March 1997.
Deering, S., and R. Hinden, “Internet Protocol, Version 6 (IPv6)
Specification,” IETF RFC 2460, December, 1998.
Optical Internetworking Forum Implementation Agreement,
“Intra-Carrier E-NNI Signaling Specification,” OIF-E-NNI-Sig01.0, February 27, 2004.
Farinacci, D., et al., “Generic Routing Encapsulation (GRE),”
IETF RFC 2784, March 2000.
Frankel, S., R. Glenn, and S. Kelly, “The AES-CBC Cipher
Algorithm and Its Use with IPsec,” IETF RFC 3602, September
2003.
Frankel, S., and H. Herbert, “The AES-XCBC-MAC-96
Algorithm and Its Use With IPsec,” IETF RFC 3566, September
2003.
Fu, D., and J. Solinas, “ECP Groups for IKE and IKEv2,” IETF
Work in Progress, draft-ietf-ipsec-ikev2-ecp-groups-02,
September 2005.
Gill, V., J. Heasley, and D. Meyer, “The Generalized TTL
Security Mechanism (GTSM),” IETF RFC 3682, February 2004.
Glenn, R., and S. Kent, “The NULL Encryption Algorithm and
Its Use With IPsec,” RFC 2410, November 1998.
Huang, G., S. Beaulieu, and D. Rochefort, “A Traffic-Based
Method of Detecting Dead IKE Peers,” IETF RFC 3706, February
2004.
Harkins, D., and D. Carrel, “The Internet Key Exchange (IKE),”
IETF RFC 2409, November 1998.
Housley, R., W. Ford, W. Polk, and D. Solo, “Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile,” IETF RFC 3280, April 2002.
21
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
[Hof04]
[Hof05a]
[Hof05b]
[Hof06]
[Hou04]
[Hou05]
[Hut05]
[KA98a]
[KA98b]
[KA98c]
[Kau05]
[KBC97]
[Ken05a]
[Ken05b]
[Ken05c]
[KK03]
[Kor05]
www.oiforum.com
Hoffman, P., “The AES-XCBC-PRF-128 algorithm for IKE,” IETF
RFC 3664, January 2004.
Hoffman, P., “Algorithms for Internet Key Exchange version 1
(IKEv1),” IETF RFC 4109, May 2005.
Hoffman, P., “Cryptographic Suites for IPsec,” IETF RFC 4308,
December 2005.
Hoffman, P., “The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE),” IETF RFC 4434,
February 2006.
Housley, R., “Using AES Counter Mode With IPsec ESP,” IETF
RFC 3686, January 2004.
Housley, R., “Using Advanced Encryption Standard (AES)
CCM Mode with IPsec Encapsulating Security Payload (ESP),”
IETF RFC 4309, DECember 2005.
Huttunen, A., et al., “UDP Encapsulation of IPsec Packets,”
IETF RFC 3948, January 2005.
Kent, S., and R. Atkinson, “Security Architecture for the Internet
Protocol,” IETF RFC 2401, November 1998.
Kent, S., and R. Atkinson, “IP Authentication Header,” IETF
RFC 2402, November 1998.
Kent, S., and R. Atkinson, “IP Encapsulating Security Payload
(ESP),” IETF RFC 2406, November 1998.
Kaufman, C., ed., “Internet Key Exchange (IKEv2) Protocol,”
IETF RFC 4306, December 2005.
Krawczyk, H., M. Bellare, and R. Canetti, “HMAC: KeyedHashing for Message Authentication,” IETF RFC 2104, February
1997.
Kent, S., “IP Encapsulating Security Payload (ESP),” IETF RFC
4303, December 2005.
Kent, S., “Extended Sequence Number (ESN) Addendum to
IPsec Domain of Interpretation (DOI) for Internet Security
Association and Key Management Protocol (ISAKMP),” IETF
RFC 4304, December 2005.
Kent, S., “IP Authentication Header,” IETF RFC 4302, December
2005.
Kivenen, T., and M. Kojo, “More Modular Exponential (MODP)
Diffie-Hellman Groups for Internet Key Exchange (IKE),” IETF
RFC 3526, May 2003.
Korver, B., “The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX,” IETF Work in Progress,
draft-ietf-pki4ipsec-ikecert-profile-06, November 2005.
22
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
[KS05]
Kent, S., and K. Seo, “Security Architecture for the Internet
Protocol,” IETF RFC 4301, December 2005.
[LA03]
Li, T., and R. Atkinson, “Intermediate System to Intermediate
System (IS-IS) Cryptographic Authentication,” IETF RFC 3567,
July 2003 (Informational).
[Lan05]
J. Lang, Ed., “Link Management Protocol (LMP),” IETF RFC
4204, October 2005.
[LogAud]
Optical Internetworking Forum Work in Progress, “OIF Control
Plane Logging and Auditing with Syslog,” OIF Work in
Progress, July 2005.
[MG98]
Madson, C., and R. Glenn, “The Use of HMAC-SHA-1-96 within
ESP and AH,” IETF RFC 2404, November 1998.
[MSST98]
Maughan, D., M. Schertler, M. Schneider, and J. Turner,
“Internet Security Association and Key Management Protocol
(ISAKMP),” IETF RFC 2408, November 1998.
[Mur97]
Murphy, S., et al., “OSPF with Digital Signatures,” RFC 2154,
June 1997.
[MV05]
McGrew, D., and J. Viega, “The Galois/Counter Mode of
Operation (GCM),”
http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/
gcm/gcm-revised-spec.pdf, May 2005.
[NNI-OSPF] Optical Internetworking Forum Work in Progress, NNI Routing
with OSPF.
[NNI-IS-IS] Optical Internetworking Forum Work in Progress, NNI Routing
with IS-IS.
[PA98]
Pereira, R., and R. Adams, “The ESP CBC-Mode Cipher
Algorithms,” IETF RFC 2451, November 1998.
[Pip98]
Piper, D., “The Internet IP Security Domain of Interpretation for
ISAKMP,” IETF RFC 2407, November 1998.
[Sch05]
Schiller, J., “Cryptographic Algorithms for Use in the Internet
Key Exchange Version 2 (IKEv2), IETF RFC 4307,
December 2005.
[SecExt]
Optical Internetworking Forum Implementation Agreement,
“Security Extension for UNI and NNI,” OIF-SEP-01.1, May 8,
2003.
[SecMang] Optical Internetworking Forum Implementation Agreement,
“Security for Management Interfaces to Network Elements,”
OIF-SMI-01.0, September 4, 2003.
[SecManA] Optical Internetworking Forum Implementation Agreement,
“Addendum to the Security for Management Interfaces to
Network Elements,” OIF-SMI-02.1, March 31, 2006.
www.oiforum.com
23
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
[Tsc06]
Tschofenig, H., et al., “EAP IKEv2 Method,” IETF Work in
Progress, draft-tschofenig-eap-ikev2-08, January 2006.
[UNI1.0]
Optical Internetworking Forum Implementation Agreement,
“User Network Interface (UNI) 1.0 Signaling Specification,”
OIF-UNI-01.1, October 1, 2001.
[UNI1.0r2] OIF Implementation Agreement, “OIF-UNI-01.0-R2-Common User Network Interface (UNI) 1.0 Signaling Specification,
Release 2: Common Part,” OIF-UNI-01.0-R2-Common, February
27, 2004.
[UNI1.0r2r] OIF Implementation Agreement, “OIF-UNI-01.0-R2-RSVP RSVP Extensions for User Network Interface (UNI) 1.0
Signaling, Release 2,” OIF-UNI-01.0-R2-RSVP, February 27,
2004.
[UNI2.0]
Optical Internetworking Forum Work in Progress, User
Network Interface (UNI ) 2.0 Signaling Specification.
[UNI2.0c]
Optical Internetworking Forum Work in Progress, UNI 2.0
Signaling with LDP.
[UNI2.0r]
Optical Internetworking Forum Work in Progress, UNI 2.0
Signaling with RSVP.
[VM05]
Viega, J., and D. McGrew, “The Use of Galois/Counter Mode
(GCM) in IPsec ESP,” IETF RFC 4106, June 2005.
12.2
Informative references
[Abo04]
[AD03]
[BLS01]
[BMY04]
[Bon03]
[Dom00]
[EH06]
www.oiforum.com
Aboba, B., et al., “Securing Block Storage Protocols over IP,”
IETF RFC 3723, April 2004.
Aboba, B., and W. Dixon, “IPsec-NAT Compatibility
Requirements,” IETF RFC 3715, March 2004. (Informational)
Boneh, D., B. Lynn, and H. Shacham, “Short Signatures from the
Weil Pairing,” Advances in Cryptology—Asiacrypt 2001, LNCS
Vol. 2248, Springer-Verlag, 2001.
Barbir, A., S. Murphy, and Y. Yang, “Generic Threats to Routing
Protocols, IETF Work in Progress, draft-ietf-rpsec-routingthreats-07, October 2004. [In RFC Editor’s queue]
Boneh, D., et al., “Aggregate and Verifiably Encrypted
Signatures from Bilinear Maps,” Advances in Cryptology—
Eurocrypt 2003, Springer-Verlag, 2003.
Dommety, G., “Key and Sequence Number Extensions to GRE,”
IETF RFC 2890, September 2000.
Eronen, P., and P. Hoffman, “IKEv2 Clarifications and
Implementation Guidelines,” IETF Work in Progress, drafteronen-ipsec-ikev2-clarifications-08, February 2006.
24
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
[ESC05]
[GM06]
[Gut98]
[Kra03]
[KSF99]
[Moy98]
[Mur97]
[Per88]
[Per00]
[Per03]
[Ste93]
[SysL]
Donald E. Eastlake, D., J. Schiller, and S. Crocker, “Randomness
Requirements for Security,” IETF RFC 4086, June 2005.
Gupta, M., and N. Melam, “Authentication/Confidentiality for
OSPFv3,” IETF Work in Progress, draft-ietf-ospf-ospfv3-auth-08,
February 2006.
Gutmann, P., “Software Generation of Practically Strong
Random Numbers,” Seventh USENIX Security Symposium
Proceedings, The USENIX Association, 1998, pp. 243–257.
Krawczyk, H., “SIGMA: The SIGn-and-MAc approach to
Authenticated Diffie-Hellman and Its Use in the IKE Protocols,”
Advances in Cryptology—Crypto 2003, Springer-Verlag LNCS Vol.
2729, pp. 400–425. See also
http://www.ee.technion.ac.il/~hugo/sigma.html.
Kelsey, J., B. Schneier, and N. Ferguson, “Notes on the Design
and Analysis of the Yarrow Cryptographic Pseudorandom
Number Generator,” Sixth Annual Workshop on Selected Areas in
Cryptography, Springer-Verlag, 1999.
Moy, J., “OSPF Version 2,” IETF RFC 2328, April 1998.
Murphy, S. et al., “OSPF with Digital Signatures,” IETF RFC
2154, June 1997. (Experimental)
Perlman, R., Network Layer Protocols with Byzantine Robustness,
Ph.D. Thesis, Department of Electrical Engineering and
Computer Science, MIT, August 1988.
Perlman, R., Interconnections, Second Edition, Addison-Wesley,
Reading, MA, 2000.
Perlman, R., “Understanding IKEv2: Tutorial, and rationale for
decisions,” IETF Work in Progress, draft-ietf-ipsec-ikev2tutorial-02, November 2003. (expired)
Steenstrup, M., “Inter-Domain Policy Routing Protocol
Specification: Version 1,” IETF RFC 1479, July 1993.
IETF Syslog Working Group,
http://www.ietf.org/html.charters/syslog-charter.html.
13
www.oiforum.com
25
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
Appendix A: Open Issues / current work items
•
Work continues in the IETF on IKEv2 clarifications and use of elliptic
curves with IKEv2.
Appendix B: List of companies belonging to OIF when document
was approved
ADVA Optical Networking
Aevix Systems
Agere Systems
Agilent Technologies
Alcatel
Altera
AMCC
Analog Devices
Anritsu
Apogee Photonics, Inc.
AT&T
Avici Systems
Azna
Big Bear Networks
Bookham
Booz-Allen & Hamilton
Broadcom
China Telecom
Ciena Corporation
Cisco Systems
CoreOptics
Cortina Systems
Cypress Semiconductor
Data Connection
Department of Defense
Deutsche Telekom
Elisa Communications
Essex Corporation
Finisar Corporation
Flextronics
Force 10 Networks
Foxconn
France Telecom
www.oiforum.com
26
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
Freescale Semiconductor
Fujitsu
Furukawa America
Harris Corporation
Hi/fn
Huawei Technologies
IBM Corporation
IDT
Infinera
Intel
JDS Uniphase
KDDI R&D Laboratories
Kodeos Communications
KT Corporation
Lambda Optical Systems
Lattice Semiconductor
LSI Logic
Lucent
Marconi Communications
MCI
MergeOptics GmbH
Mindspeed
MITRE Corporation
Mitsubishi Electric Corporation
Molex
NEC
Nortel Networks
Northrop Grumman
NTT Corporation
Opnext
Optovia
OpVista Inc
PMC Sierra
Quake Technologies
RedC Optical Networks Ltd.
Redfern Integrated Optics, Inc.
Sandia National Laboratories
Santur
SBC
Scintera Networks
Siemens
Silicon Laboratories
www.oiforum.com
27
OIF-SEP-02.1
Addendum to the Security Extension for UNI and NNI
Silicon Logic Engineering
StrataLight Communications
Sycamore Networks
Syntune
Tektronix
Telcordia Technologies
Telecom Italia Lab
Tellabs
TeraSea
Texas Instruments
Time Warner Cable
Toshiba Corporation
Tyco Electronics
Verizon
Vitesse Semiconductor
Xilinx
www.oiforum.com
28