draft-ietf-forces-framework-08.txt   draft-ietf-forces-framework-09.txt 
Internet Draft L. Yang Internet Draft L. Yang
Expiration: February 2004 Intel Corp. Expiration: March 2004 Intel Corp.
File: draft-ietf-forces-framework-08.txt R. Dantu File: draft-ietf-forces-framework-09.txt R. Dantu
Working Group: ForCES Univ. of North Texas Working Group: ForCES Univ. of North Texas
T. Anderson T. Anderson
Intel Corp. Intel Corp.
R. Gopal R. Gopal
Nokia Nokia
August 2003
September 2003
Forwarding and Control Element Separation (ForCES) Framework Forwarding and Control Element Separation (ForCES) Framework
draft-ietf-forces-framework-08.txt draft-ietf-forces-framework-09.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 2, line ? skipping to change at page 2, line ?
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document defines the architectural framework for the ForCES This document defines the architectural framework for the ForCES
(Forwarding and Control Element Separation) network elements, and (Forwarding and Control Element Separation) network elements, and
identifies the associated entities and the interaction among them. identifies the associated entities and the interactions among them.
Table of Contents Table of Contents
1. Definitions...................................................3 1. Definitions...................................................3
2. Introduction to Forwarding and Control Element Separation 2. Introduction to Forwarding and Control Element Separation
(ForCES).........................................................5 (ForCES).........................................................5
3. Architecture..................................................9 3. Architecture..................................................9
3.1. Control Elements and Fr Reference Point.................10 3.1. Control Elements and Fr Reference Point.................10
3.2. Forwarding Elements and Fi reference point..............11 3.2. Forwarding Elements and Fi reference point..............11
3.3. CE Managers.............................................14 3.3. CE Managers.............................................14
3.4. FE Managers.............................................14 3.4. FE Managers.............................................14
skipping to change at page 2, line ? skipping to change at page 2, line ?
4.1.1. Fl Reference Point.................................15 4.1.1. Fl Reference Point.................................15
4.1.2. Ff Reference Point.................................16 4.1.2. Ff Reference Point.................................16
4.1.3. Fc Reference Point.................................17 4.1.3. Fc Reference Point.................................17
4.2. Post-association Phase and Fp reference point...........17 4.2. Post-association Phase and Fp reference point...........17
4.2.1. Proximity and Interconnect between CEs and FEs.....17 4.2.1. Proximity and Interconnect between CEs and FEs.....17
4.2.2. Association Establishment..........................18 4.2.2. Association Establishment..........................18
4.2.3. Steady-state Communication.........................19 4.2.3. Steady-state Communication.........................19
4.2.4. Data Packets across Fp reference point.............20 4.2.4. Data Packets across Fp reference point.............20
4.2.5. Proxy FE...........................................21 4.2.5. Proxy FE...........................................21
4.3. Association Re-establishment............................21 4.3. Association Re-establishment............................21
4.3.1. CE graceful restart................................21 4.3.1. CE graceful restart................................22
4.3.2. FE restart.........................................23 4.3.2. FE restart.........................................23
5. Applicability to RFC1812.....................................24 5. Applicability to RFC1812.....................................24
5.1. General Router Requirements.............................24 5.1. General Router Requirements.............................24
5.2. Link Layer..............................................25 5.2. Link Layer..............................................26
5.3. Internet Layer Protocols................................26 5.3. Internet Layer Protocols................................26
5.4. Internet Layer Forwarding...............................26 5.4. Internet Layer Forwarding...............................27
5.5. Transport Layer.........................................27 5.5. Transport Layer.........................................28
5.6. Application Layer -- Routing Protocols..................28 5.6. Application Layer -- Routing Protocols..................28
5.7. Application Layer -- Network Management Protocol........28 5.7. Application Layer -- Network Management Protocol........28
6. Summary......................................................29 6. Summary......................................................29
7. Security Considerations......................................29 7. Acknowledgements.............................................29
7.1. Analysis of Potential Threats Introduced by ForCES......29 8. Security Considerations......................................29
7.1.1. "Join" or "Remove" Message Flooding on CEs.........29 8.1. Analysis of Potential Threats Introduced by ForCES......30
7.1.2. Impersonation Attack...............................30 8.1.1. "Join" or "Remove" Message Flooding on CEs.........30
7.1.3. Replay Attack......................................30 8.1.2. Impersonation Attack...............................30
7.1.4. Attack during Fail Over............................30 8.1.3. Replay Attack......................................30
7.1.5. Data Integrity.....................................31 8.1.4. Attack during Fail Over............................31
7.1.6. Data Confidentiality...............................31 8.1.5. Data Integrity.....................................31
7.1.7. Sharing security parameters........................31 8.1.6. Data Confidentiality...............................31
7.1.8. Denial of Service Attack via External Interface....32 8.1.7. Sharing security parameters........................32
7.2. Security Recommendations for ForCES.....................32 8.1.8. Denial of Service Attack via External Interface....32
7.2.1. Security Configuration.............................33 8.2. Security Recommendations for ForCES.....................32
7.2.2. Using TLS with ForCES..............................33 8.2.1. Security Configuration.............................33
7.2.3. Using IPsec with ForCES............................34 8.2.2. Using TLS with ForCES..............................33
8. Normative References.........................................36 8.2.3. Using IPsec with ForCES............................34
9. Informative References.......................................36 9. Normative References.........................................36
10. Acknowledgements............................................37 10. Informative References......................................36
11. Authors' Addresses..........................................37 11. Authors' Addresses..........................................37
12. Intellectual Property Right.................................38 12. Intellectual Property Right.................................38
13. Full Copyright Statement....................................38 13. Full Copyright Statement....................................38
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119]. this document are to be interpreted as described in RFC 2119.
1. Definitions 1. Definitions
A set of terminology associated with the ForCES requirements is A set of terminology associated with the ForCES requirements is
defined in [3] and we only include the definitions that are most defined in [3] and we only include the definitions that are most
relevant to this document here. relevant to this document here.
Addressable Entity (AE) - An entity that is directly addressable Addressable Entity (AE) - An entity that is directly addressable
given some interconnect technology. For example, on IP networks, given some interconnect technology. For example, on IP networks,
it is a device to which we can communicate using an IP address; on it is a device to which we can communicate using an IP address; on
a switch fabric, it is a device to which we can communicate using a a switch fabric, it is a device to which we can communicate using a
switch fabric port number. switch fabric port number.
Physical Forwarding Element (PFE) - An AE that includes hardware Physical Forwarding Element (PFE) - An AE that includes hardware
used to provide per-packet processing and handling. This hardware used to provide per-packet processing and handling. This hardware
may consist of (but is not limited to) network processors, ASICs may consist of (but is not limited to) network processors, ASICs
(Application-Specific Integrated Circuits), or general processors, (Application-Specific Integrated Circuits), or general purpose
installed on line cards, daughter boards, mezzanine cards, or in processors, installed on line cards, daughter boards, mezzanine
stand-alone boxes. cards, or in stand-alone boxes.
PFE Partition - A logical partition of a PFE consisting of some PFE Partition - A logical partition of a PFE consisting of some
subset of each of the resources (e.g., ports, memory, forwarding subset of each of the resources (e.g., ports, memory, forwarding
table entries) available on the PFE. This concept is analogous to table entries) available on the PFE. This concept is analogous to
that of the resources assigned to a virtual switching element as that of the resources assigned to a virtual switching element as
described in [8]. described in [8].
Physical Control Element (PCE) - An AE that includes hardware used Physical Control Element (PCE) - An AE that includes hardware used
to provide control functionality. This hardware typically includes to provide control functionality. This hardware typically includes
a general-purpose processor. a general purpose processor.
PCE Partition - A logical partition of a PCE consisting of some PCE Partition - A logical partition of a PCE consisting of some
subset of each of the resources available on the PCE. subset of each of the resources available on the PCE.
Forwarding Element (FE) - A logical entity that implements the Forwarding Element (FE) - A logical entity that implements the
ForCES protocol. FEs use the underlying hardware to provide per- ForCES protocol. FEs use the underlying hardware to provide per-
packet processing and handling as directed by a CE via the ForCES packet processing and handling as directed by a CE via the ForCES
protocol. FEs may happen to be a single blade (or PFE), a protocol. FEs may happen to be a single blade (or PFE), a
partition of a PFE or multiple PFEs. partition of a PFE or multiple PFEs.
skipping to change at page 4, line 40 skipping to change at page 4, line 40
ForCES Post-Association Phase Protocol - The protocol used for ForCES Post-Association Phase Protocol - The protocol used for
post-association phase communication between CEs and FEs. This post-association phase communication between CEs and FEs. This
protocol does not apply to CE-to-CE communication, FE-to-FE protocol does not apply to CE-to-CE communication, FE-to-FE
communication, nor to communication between FE and CE managers. communication, nor to communication between FE and CE managers.
The ForCES protocol is a master-slave protocol in which FEs are The ForCES protocol is a master-slave protocol in which FEs are
slaves and CEs are masters. This protocol includes both the slaves and CEs are masters. This protocol includes both the
management of the communication channel (e.g., connection management of the communication channel (e.g., connection
establishment, heartbeats) and the control messages themselves. establishment, heartbeats) and the control messages themselves.
This protocol could be a single protocol or could consist of This protocol could be a single protocol or could consist of
multiple protocols working together. multiple protocols working together, and may be unicast based or
multicast based. A separate protocol document will specify this
information.
FE Manager - A logical entity that operates in the pre-association FE Manager - A logical entity that operates in the pre-association
phase and is responsible for determining to which CE(s) an FE phase and is responsible for determining to which CE(s) an FE
should communicate. This process is called CE discovery and may should communicate. This process is called CE discovery and may
involve the FE manager learning the capabilities of available CEs. involve the FE manager learning the capabilities of available CEs.
A FE manager may use anything from a static configuration to a pre- An FE manager may use anything from a static configuration to a
association phase protocol (see below) to determine which CE(s) to pre-association phase protocol (see below) to determine which CE(s)
use, however this is currently out of scope. Being a logical to use; however, this is currently out of scope. Being a logical
entity, an FE manager might be physically combined with any of the entity, an FE manager might be physically combined with any of the
other logical entities mentioned in this section. other logical entities mentioned in this section.
CE Manager - A logical entity that operates in the pre-association CE Manager - A logical entity that operates in the pre-association
phase and is responsible for determining to which FE(s) a CE should phase and is responsible for determining to which FE(s) a CE should
communicate. This process is called FE discovery and may involve communicate. This process is called FE discovery and may involve
the CE manager learning the capabilities of available FEs. A CE the CE manager learning the capabilities of available FEs. A CE
manager may use anything from a static configuration to a pre- manager may use anything from a static configuration to a pre-
association phase protocol (see below) to determine which FE to association phase protocol (see below) to determine which FE to
use, however this is currently out of scope. Being a logical use, however this is currently out of scope. Being a logical
skipping to change at page 5, line 28 skipping to change at page 5, line 30
capability discovery mechanism. Note that this capability capability discovery mechanism. Note that this capability
discovery process is wholly separate from (and does not replace) discovery process is wholly separate from (and does not replace)
that used within the ForCES protocol. However, the two capability that used within the ForCES protocol. However, the two capability
discovery mechanisms may utilize the same FE model. discovery mechanisms may utilize the same FE model.
FE Model - A model that describes the logical processing functions FE Model - A model that describes the logical processing functions
of an FE. of an FE.
ForCES Protocol Element - An FE or CE. ForCES Protocol Element - An FE or CE.
Intra-FE topology - Representation of how a single FE is realized Intra-FE topology - - Representation of how a single FE is realized
by combining possibly multiple logical functional blocks along by combining possibly multiple logical functional blocks along
multiple data path. This is defined by the FE model. multiple data path. This is defined by the FE model.
FE Topology -- Representation of how the multiple FEs in a single FE Topology -- Representation of how the multiple FEs in a single
NE are interconnected. Sometimes it is called inter-FE topology, NE are interconnected. Sometimes it is called inter-FE topology,
to be distinguished from intra-FE topology used by the FE model. to be distinguished from intra-FE topology used by the FE model.
Inter-FE topology - see FE Topology. Inter-FE topology - see FE Topology.
2. Introduction to Forwarding and Control Element Separation (ForCES) 2. Introduction to Forwarding and Control Element Separation (ForCES)
skipping to change at page 6, line 16 skipping to change at page 6, line 18
standardize information exchange between the control and forwarding standardize information exchange between the control and forwarding
plane. Having standard mechanisms allows CEs and FEs to become plane. Having standard mechanisms allows CEs and FEs to become
physically separated standard components. This physical separation physically separated standard components. This physical separation
accrues several benefits to the ForCES architecture. Separate accrues several benefits to the ForCES architecture. Separate
components would allow component vendors to specialize in one components would allow component vendors to specialize in one
component without having to become experts in all components. component without having to become experts in all components.
Standard protocol also allows the CEs and FEs from different Standard protocol also allows the CEs and FEs from different
component vendors to interoperate with each other and hence it component vendors to interoperate with each other and hence it
becomes possible for system vendors to integrate together the CEs becomes possible for system vendors to integrate together the CEs
and FEs from different component suppliers. This interoperability and FEs from different component suppliers. This interoperability
translates into a lot more design choices and flexibility for the translates into more design choices and flexibility for the system
system vendors. Overall, ForCES will enable rapid innovation in vendors. Overall, ForCES will enable rapid innovation in both the
both the control and forwarding planes while maintaining control and forwarding planes while maintaining interoperability.
interoperability. Scalability is also easily provided by this Scalability is also easily provided by this architecture in that
architecture in that additional forwarding or control capacity can additional forwarding or control capacity can be added to existing
be added to existing network elements without the need for forklift network elements without the need for forklift upgrades.
upgrades.
------------------------- ------------------------- ------------------------- -------------------------
| Control Blade A | | Control Blade B | | Control Blade A | | Control Blade B |
| (CE) | | (CE) | | (CE) | | (CE) |
------------------------- ------------------------- ------------------------- -------------------------
^ | ^ | ^ | ^ |
| | | | | | | |
| V | V | V | V
--------------------------------------------------------- ---------------------------------------------------------
| Switch Fabric Backplane | | Switch Fabric Backplane |
skipping to change at page 6, line 50 skipping to change at page 7, line 4
| (FE) | | (FE) | | (FE) | | (FE) | | (FE) | | (FE) |
------------ ------------ ------------ ------------ ------------ ------------
^ | ^ | ^ | ^ | ^ | ^ |
| | | | . . . | | | | | | . . . | |
| V | V | V | V | V | V
Figure 1. A router configuration example with separate blades. Figure 1. A router configuration example with separate blades.
One example of such physical separation is at the blade level. One example of such physical separation is at the blade level.
Figure 1 shows such an example configuration of a router, with two Figure 1 shows such an example configuration of a router, with two
control blades and multiple router (forwarding) blades, all control blades and multiple forwarding blades, all interconnected
interconnected into a switch fabric backplane. In such a chassis into a switch fabric backplane. In such a chassis configuration,
configuration, the control blades are the CEs while the router the control blades are the CEs while the router blades are FEs, and
blades are FEs, and the switch fabric backplane provides the the switch fabric backplane provides the physical interconnect for
physical interconnect for all the blades. Control blade A may be all the blades. Control blade A may be the primary CE while
the primary CE while control blade B may be the backup CE providing control blade B may be the backup CE providing redundancy. It is
redundancy. It is also possible to have a redundant switch fabric also possible to have a redundant switch fabric for high
for high availability support. Routers today with this kind of availability support. Routers today with this kind of
configuration use proprietary interfaces for messaging between CEs configuration use proprietary interfaces for messaging between CEs
and FEs. The goal of ForCES is to replace such proprietary and FEs. The goal of ForCES is to replace such proprietary
interfaces with a standard protocol. With a standard protocol like interfaces with a standard protocol. With a standard protocol like
ForCES implemented on all blades, it becomes possible for control ForCES implemented on all blades, it becomes possible for control
blades from vendor X and routing blades from vendor Y to work blades from vendor X and forwarding blades from vendor Y to work
seamlessly together in one chassis. seamlessly together in one chassis.
------- ------- ------- -------
| CE1 | | CE2 | | CE1 | | CE2 |
------- ------- ------- -------
^ ^ ^ ^
| | | |
V V V V
============================================ Ethernet ============================================ Ethernet
^ ^ . . . ^ ^ ^ . . . ^
skipping to change at page 9, line 48 skipping to change at page 9, line 49
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Fi/f Fi/f Fi/f Fi/f
Figure 4. ForCES Architectural Diagram Figure 4. ForCES Architectural Diagram
The diagram in Figure 4 shows the logical components of the ForCES The diagram in Figure 4 shows the logical components of the ForCES
architecture and their relationships. There are two kinds of architecture and their relationships. There are two kinds of
components inside a ForCES network element: control element (CE) components inside a ForCES network element: control element (CE)
and forwarding element (FE). The framework allows multiple and forwarding element (FE). The framework allows multiple
instances of CE and FE inside one NE. Each FE contains one or instances of CE and FE inside one NE. Each FE contains one or more
more physical media interfaces for receiving and transmitting physical media interfaces for receiving and transmitting packets
packets from/to the external world. The aggregation of these FE from/to the external world. The aggregation of these FE interfaces
interfaces becomes the NE's external interfaces. In addition to becomes the NE's external interfaces. In addition to the external
the external interfaces, there must also exist some kind of interfaces, there must also exist some kind of interconnect within
interconnect within the NE so that the CE and FE can communicate the NE so that the CE and FE can communicate with each other, and
with each other, and one FE can forward packets to another FE. one FE can forward packets to another FE. The diagram also shows
The diagram also shows two entities outside of the ForCES NE: CE two entities outside of the ForCES NE: CE Manager and FE Manager.
Manager and FE Manager. These two entities provide configuration These two entities provide configuration to the corresponding CE or
to the corresponding CE or FE in the pre-association phase (see FE in the pre-association phase (see Section 4.1). There is no
Section 5.1). There is no defined role for FE Manager and CE defined role for FE Manager and CE Manager in post-association
Manager in post-association phase, thus these logical components phase, thus these logical components are not considered part of the
are not considered part of the ForCES NE. ForCES NE.
For convenience, the logical interactions between these components For convenience, the logical interactions between these components
are labeled by reference points Fp, Fc, Ff, Fr, Fl, and Fi, as are labeled by reference points Fp, Fc, Ff, Fr, Fl, and Fi, as
shown in Figure 4. The FE external interfaces are labeled as Fi/f. shown in Figure 4. The FE external interfaces are labeled as Fi/f.
More detail is provided in Section 4 and 5 for each of these More detail is provided in Section 3 and 4 for each of these
reference points. All these reference points are important in reference points. All these reference points are important in
understanding the ForCES architecture, however, the ForCES protocol understanding the ForCES architecture, however, the ForCES protocol
is only defined over one reference point -- Fp. is only defined over one reference point -- Fp.
The interface between two ForCES NEs is identical to the interface The interface between two ForCES NEs is identical to the interface
between two conventional routers and these two NEs exchange the between two conventional routers and these two NEs exchange the
protocol packets through the external interfaces at Fi/f. ForCES protocol packets through the external interfaces at Fi/f. ForCES
NEs connect to existing routers transparently. NEs connect to existing routers transparently.
3.1. Control Elements and Fr Reference Point 3.1. Control Elements and Fr Reference Point
skipping to change at page 11, line 28 skipping to change at page 11, line 28
An FE is a logical entity that implements the ForCES protocol and An FE is a logical entity that implements the ForCES protocol and
uses the underlying hardware to provide per-packet processing and uses the underlying hardware to provide per-packet processing and
handling as directed by a CE. It is possible to partition one handling as directed by a CE. It is possible to partition one
physical FE into multiple logical FEs. It is also possible for one physical FE into multiple logical FEs. It is also possible for one
FE to use multiple physical FEs. The mapping between physical FE to use multiple physical FEs. The mapping between physical
FE(s) and the logical FE(s) is beyond the scope of ForCES. For FE(s) and the logical FE(s) is beyond the scope of ForCES. For
example, a logical partition of a physical FE can be created by example, a logical partition of a physical FE can be created by
assigning some portion of each of the resources (e.g., ports, assigning some portion of each of the resources (e.g., ports,
memory, forwarding table entries) available on the physical FE to memory, forwarding table entries) available on the physical FE to
each of the logical FEs. Such concept of FE virtualization is each of the logical FEs. Such concept of FE virtualization is
analogous to a virtual switching element as described in [8]. FE analogous to a virtual switching element as described in [8]. If
virtualization should occur only in the pre-association phase and FE virtualization occurs only in the pre-association phase, it has
hence has no impact on ForCES. no impact on ForCES. However, if FE virtualization results in
dynamic resource change on FE during post-associaiton phase, the FE
model needs to be able to report such capability and the ForCES
protocol needs to be able to inform the CE of such change via
asynchronous messages (see [3], Section 5, requirement #6).
FEs perform all packet processing functions as directed by CEs. FEs perform all packet processing functions as directed by CEs.
FEs have no initiative of their own. Instead, FEs are slaves and FEs have no initiative of their own. Instead, FEs are slaves and
only do as they are told. FEs may communicate with one or more CEs only do as they are told. FEs may communicate with one or more CEs
concurrently across reference point Fp. FEs have no notion of CE concurrently across reference point Fp. FEs have no notion of CE
redundancy, load sharing, or distributed control. Instead, FEs redundancy, load sharing, or distributed control. Instead, FEs
accept commands from any CE authorized to control them, and it is accept commands from any CE authorized to control them, and it is
up to the CEs to coordinate among themselves to achieve redundancy, up to the CEs to coordinate among themselves to achieve redundancy,
load sharing or distributed control. The idea is to keep FEs as load sharing or distributed control. The idea is to keep FEs as
simple and dumb as possible so that FEs can focus their resource on simple and dumb as possible so that FEs can focus their resource on
skipping to change at page 13, line 5 skipping to change at page 13, line 10
could be used by FEs to discovery their (inter-FE) topology, could be used by FEs to discovery their (inter-FE) topology,
perhaps during pre-association phase. The Fi reference point is a perhaps during pre-association phase. The Fi reference point is a
separate protocol from the Fp reference point and is not currently separate protocol from the Fp reference point and is not currently
defined by the ForCES architecture. defined by the ForCES architecture.
FEs could be connected in different kinds of topologies and packet FEs could be connected in different kinds of topologies and packet
processing may spread across several FEs in the topology. Hence, processing may spread across several FEs in the topology. Hence,
logical packet flow may be different from physical FE topology. logical packet flow may be different from physical FE topology.
Figure 6 provides some topology examples. When it is necessary to Figure 6 provides some topology examples. When it is necessary to
forward packets between FEs, the CE needs to understand the FE forward packets between FEs, the CE needs to understand the FE
topology. The FE topology can be queried from the FEs by CEs. topology. The FE topology may be queried from the FEs by the CEs
via ForCES protocol, but the FEs are not required to provide that
information to the CEs. So, the FE topology information may also be
gathered by other means outside of the ForCES protocol (like inter-
FE topology discovery protocol).
----------------- -----------------
| CE | | CE |
----------------- -----------------
^ ^ ^ ^ ^ ^
/ | \ / | \
/ v \ / v \
/ ------- \ / ------- \
/ +->| FE3 |<-+ \ / +->| FE3 |<-+ \
/ | | | | \ / | | | | \
skipping to change at page 16, line 37 skipping to change at page 16, line 44
disconnect from an existing NE. The FE Manager could also assign disconnect from an existing NE. The FE Manager could also assign
unique FE identifiers to the FEs using this reference point. The unique FE identifiers to the FEs using this reference point. The
FE identifiers are useful in post association phase to express FE FE identifiers are useful in post association phase to express FE
topology. Figure 8 shows example of message exchange over Ff topology. Figure 8 shows example of message exchange over Ff
reference point. reference point.
FE Manager FE CE Manager CE FE Manager FE CE Manager CE
| | | | | | | |
| | | | | | | |
|(security exchange) |(security exchange) |(security exchange) |(security exchange)
1|<------------>|authentication 1|<----------- 1|<------------>|authentication 1|<----------->|authentication
>|authentication | | | | | | |
|
|(FE ID, attributes) |(CE ID, attributes) |(FE ID, attributes) |(CE ID, attributes)
2|<-------------|request 2|<------------|request 2|<-------------|request 2|<----------->|request
| | | | | | | |
3|------------->|response 3|------------>|response 3|------------->|response 3|------------>|response
|(corresponding CE ID) |(corresponding FE ID) |(corresponding CE ID) |(corresponding FE ID)
| | | | | | | |
| | | | | | | |
|<-----Ff----->| |<-----Fc---->| |<-----Ff----->| |<-----Fc---->|
Figure 8. Examples of message exchange Figure 8. Examples of message exchange
over Ff and Fc reference points. over Ff and Fc reference points.
skipping to change at page 17, line 39 skipping to change at page 17, line 45
CE have been configured with information necessary to contact each CE have been configured with information necessary to contact each
other and includes both association establishment and steady-state other and includes both association establishment and steady-state
communication. The communication between CE and FE is performed communication. The communication between CE and FE is performed
across the Fp ("p" meaning protocol) reference point. ForCES across the Fp ("p" meaning protocol) reference point. ForCES
protocol is exclusively used for all communication across the Fp protocol is exclusively used for all communication across the Fp
reference point. reference point.
4.2.1. Proximity and Interconnect between CEs and FEs 4.2.1. Proximity and Interconnect between CEs and FEs
The ForCES Working Group has made a conscious decision that the The ForCES Working Group has made a conscious decision that the
first version of ForCES will not be designed to support first version of ForCES will be focused on "very close" CE/FE
configurations where the CE and FE are located arbitrarily in the localities in IP networks. Very Close localities consist of control
network. In particular, ForCES is intended for "very close" CE/FE and forwarding elements that either are components in the same
localities in IP networks, as defined by ForCES Applicability physical box, or are separated at most by one local network hop
Statement ([7]). Very Close localities consist of control and ([7]). CEs and FEs can be connected by a variety of interconnect
forwarding elements that either are components in the same physical technologies, including Ethernet connections, backplanes, ATM
box, or are separated at most by one local network hop. CEs and (cell) fabrics, etc. ForCES should be able to support each of
FEs can be connected by a variety of interconnect technologies, these interconnects (see [3] Section 5, requirement #1). When the
including Ethernet connections, backplanes, ATM (cell) fabrics, CEs and FEs are separated beyond a single L3 routing hop, the
etc. ForCES should be able to support each of these interconnects ForCES protocol will make use of an existing RFC2914 compliant L4
(see [3] Section 5, requirement #1). When the CEs and FEs are protocol with adequate reliability, security and congestion control
separated beyond a single L3 routing hop, the ForCES protocol will (e.g. TCP, SCTP) for transport purposes.
make use of an existing RFC2914 compliant L4 protocol with adequate
reliability, security and congestion control (e.g. TCP, SCTP) for
transport purposes.
4.2.2. Association Establishment 4.2.2. Association Establishment
FE CE FE CE
| | | |
|(Security exchange.) | |(Security exchange.) |
1|<--------------------->| 1|<--------------------->|
| | | |
|(Let me join the NE please.) |(Let me join the NE please.)
2|---------------------->| 2|---------------------->|
skipping to change at page 19, line 5 skipping to change at page 19, line 8
Figure 9. Example of message exchange between CE and FE Figure 9. Example of message exchange between CE and FE
over Fp to establish NE association over Fp to establish NE association
As an example, figure 9 shows some of the message exchange that may As an example, figure 9 shows some of the message exchange that may
happen before the association between the CE and FE is fully happen before the association between the CE and FE is fully
established. Either the CE or FE can initiate the connection. established. Either the CE or FE can initiate the connection.
Security handshake is necessary to authenticate the two Security handshake is necessary to authenticate the two
communication endpoints to each other before any further message communication endpoints to each other before any further message
exchange can happen. The exact details of the security handshake exchange can happen. The exact details of the security handshake
depend on the security solution chosen by ForCES protocol. It is depend on the security solution chosen by ForCES protocol. Section
most likely that either IPSec or TLS will be used. Section 9 8 provides more details on the security considerations for ForCES.
provides more details on the security considerations for ForCES.
After the successful security handshake, the FE needs to inform the After the successful security handshake, the FE needs to inform the
CE of its own capability and its topology in relation to other FEs. CE of its own capability and its topology in relation to other FEs.
The capability of the FE is represented by the FE model, described The capability of the FE is represented by the FE model, described
in a separate document. The model would allow an FE to describe in a separate document. The model would allow an FE to describe
what kind of packet processing functions it contains, in what order what kind of packet processing functions it contains, in what order
the processing happens, what kinds of configurable parameters it the processing happens, what kinds of configurable parameters it
allows, what statistics it collects and what events it might throw, allows, what statistics it collects and what events it might throw,
etc. Once such information is available to the CE, the CE may etc. Once such information is available to the CE, the CE may
choose to send some initial or default configuration to the FE so choose to send some initial or default configuration to the FE so
that the FE can start receiving and processing packets correctly. that the FE can start receiving and processing packets correctly.
skipping to change at page 21, line 49 skipping to change at page 22, line 5
between these two phases, but the ForCES protocol is only between these two phases, but the ForCES protocol is only
applicable for the post-association phase. However, the protocol applicable for the post-association phase. However, the protocol
should provide mechanisms to support association re-establishment. should provide mechanisms to support association re-establishment.
This includes the ability for CEs and FEs to determine when there This includes the ability for CEs and FEs to determine when there
is a loss of association between them, ability to restore is a loss of association between them, ability to restore
association and efficient state (re)synchronization mechanisms (see association and efficient state (re)synchronization mechanisms (see
[3] Section 5, requirement #7). Note that security association and [3] Section 5, requirement #7). Note that security association and
state must be also re-established to guarantee the same level of state must be also re-established to guarantee the same level of
security exists before and after the association re-establishment. security exists before and after the association re-establishment.
When an FE leaves or joins an existing NE that is already in post-
association phase, the CE needs to be aware of the impact on FE
topology and deals with the change accordingly.
4.3.1. CE graceful restart 4.3.1. CE graceful restart
The failure and restart of the CE in a router can potentially cause The failure and restart of the CE in a router can potentially cause
much stress and disruption on the control plane throughout a much stress and disruption on the control plane throughout a
network. Because when a CE has to restart for any reason, the network. Because when a CE has to restart for any reason, the
router loses routing adjacencies or sessions with its routing router loses routing adjacencies or sessions with its routing
neighbors. Neighbors who detect the lost adjacency normally re- neighbors. Neighbors who detect the lost adjacency normally re-
compute new routes and then send routing updates to their own compute new routes and then send routing updates to their own
neighbors to communicate the lost adjacency. Their neighbors do neighbors to communicate the lost adjacency. Their neighbors do
the same thing to propagate throughout the network. In the the same thing to propagate throughout the network. In the
meantime, the restarting router cannot receive traffic from other meantime, the restarting router cannot receive traffic from other
routers because the neighbors have stopped using the router's routers because the neighbors have stopped using the router's
skipping to change at page 29, line 26 skipping to change at page 29, line 34
reference points. It is important to point out that, among all the reference points. It is important to point out that, among all the
reference points, only the Fp interface between CEs and FEs is reference points, only the Fp interface between CEs and FEs is
within the scope of ForCES. ForCES alone may not be enough to within the scope of ForCES. ForCES alone may not be enough to
support all desirable NE configurations. However, we believe that support all desirable NE configurations. However, we believe that
ForCES over Fp interface is the most important element in realizing ForCES over Fp interface is the most important element in realizing
physical separation and interoperability of CEs and FEs, and hence physical separation and interoperability of CEs and FEs, and hence
the first interface that ought to be standardized. Simple and the first interface that ought to be standardized. Simple and
useful configurations can still be implemented with only CE-FE useful configurations can still be implemented with only CE-FE
interface being standardized, e.g., single CE with full-meshed FEs. interface being standardized, e.g., single CE with full-meshed FEs.
7. Security Considerations 7. Acknowledgements
Joel M. Halpern gave us many insightful comments and suggestions
and pointed out several major issues. T. Sridhar suggested that
the AgentX protocol could be used with SNMP to manage the ForCES
network elements. Many of our colleagues and people in the ForCES
mailing list also provided valuable feedback.
8. Security Considerations
In general, the physical separation of two entities usually results In general, the physical separation of two entities usually results
in a potentially insecure link between the two entities and hence in a potentially insecure link between the two entities and hence
much stricter security measurements are required. For example, we much stricter security measurements are required. For example, we
pointed out in Section 4.1 that authentication becomes necessary pointed out in Section 4.1 that authentication becomes necessary
between CE manager and FE manager, between CE and CE manager, between CE manager and FE manager, between CE and CE manager,
between FE and FE manager in some configurations. The physical between FE and FE manager in some configurations. The physical
separation of CE and FE also imposes serious security requirement separation of CE and FE also imposes serious security requirement
for ForCES protocol over Fp interface. This section first attempts for ForCES protocol over Fp interface. This section first attempts
to describe the security threats that may be introduced by the to describe the security threats that may be introduced by the
physical separation of the FEs and the CEs, and then it provides physical separation of the FEs and the CEs, and then it provides
recommendation and guidelines for secure operation and management recommendation and guidelines for secure operation and management
of ForCES protocol over Fp interface based on existing standard of ForCES protocol over Fp interface based on existing standard
security solutions. security solutions.
7.1. Analysis of Potential Threats Introduced by ForCES 8.1. Analysis of Potential Threats Introduced by ForCES
This section provides the threat analysis for ForCES, with a focus This section provides the threat analysis for ForCES, with a focus
on Fp interface. Each threat is described in details with the on Fp interface. Each threat is described in details with the
effects on the ForCES protocol entities or/and the NE as a whole, effects on the ForCES protocol entities or/and the NE as a whole,
and the required functionalities that need to be in place to defend and the required functionalities that need to be in place to defend
the threat. the threat.
7.1.1. "Join" or "Remove" Message Flooding on CEs 8.1.1. "Join" or "Remove" Message Flooding on CEs
Threats: A malicious node could send a stream of false "join NE" Threats: A malicious node could send a stream of false "join NE"
or "remove from NE" requests on behalf of non-existent or or "remove from NE" requests on behalf of non-existent or
unauthorized FE to legitimate CEs at a very rapid rate and thereby unauthorized FE to legitimate CEs at a very rapid rate and thereby
create unnecessary state in the CEs. create unnecessary state in the CEs.
Effects: If by maintaining state for non-existent or unauthorized Effects: If by maintaining state for non-existent or unauthorized
FEs, a CE may become unavailable for other processing and hence FEs, a CE may become unavailable for other processing and hence
suffer from denial of service (DoS) attack similar to the TCP SYN suffer from denial of service (DoS) attack similar to the TCP SYN
DoS. If multiple CEs are used, the unnecessary state information DoS. If multiple CEs are used, the unnecessary state information
may also be conveyed to multiple CEs via Fr interface (e.g., from may also be conveyed to multiple CEs via Fr interface (e.g., from
the active CE to the stand-by CE) and hence subject multiple CEs to the active CE to the stand-by CE) and hence subject multiple CEs to
DoS attack. DoS attack.
Requirement: A CE that receives a "join" or "remove" request Requirement: A CE that receives a "join" or "remove" request
should not create any state information until it has authenticated should not create any state information until it has authenticated
the FE endpoint. the FE endpoint.
7.1.2. Impersonation Attack 8.1.2. Impersonation Attack
Threats: A malicious node can impersonate a CE or FE and send out Threats: A malicious node can impersonate a CE or FE and send out
false messages. false messages.
Effects: The whole NE could be compromised. Effects: The whole NE could be compromised.
Requirement: The CE or FE must authenticate the message before Requirement: The CE or FE must authenticate the message before
accepting and processing it. accepting and processing it.
7.1.3. Replay Attack 8.1.3. Replay Attack
Threat: A malicious node could replay the entire message previously Threat: A malicious node could replay the entire message previously
sent by an FE or CE entity to get around authentication. sent by an FE or CE entity to get around authentication.
Effect: The NE could be compromised. Effect: The NE could be compromised.
Requirement: Replay protection mechanism needs to be part of the Requirement: Replay protection mechanism needs to be part of the
security protocol to defend this attack. security solution to defend against this attack.
7.1.4. Attack during Fail Over 8.1.4. Attack during Fail Over
Threat: A malicious node may exploit the CE fail-over mechanism to Threat: A malicious node may exploit the CE fail-over mechanism to
take over the control of NE. For example, suppose two CEs, say CE-A take over the control of NE. For example, suppose two CEs, say CE-A
and CE-B, are controlling several FEs. CE-A is active and CE-B is and CE-B, are controlling several FEs. CE-A is active and CE-B is
stand-by. When CE-A fails, CE-B is taking over the active CE stand-by. When CE-A fails, CE-B is taking over the active CE
position. The FEs already had a trusted relationship with CE-A, position. The FEs already had a trusted relationship with CE-A,
but the FEs may not have the same trusted relationship established but the FEs may not have the same trusted relationship established
with CE-B prior to the fail-over. A malicious node can take over with CE-B prior to the fail-over. A malicious node can take over
as CE-B if such trusted relationship is not established during the as CE-B if such trusted relationship is not established during the
fail-over. fail-over.
Effect: The NE may be compromised after such insecure fail-over. Effect: The NE may be compromised after such insecure fail-over.
Requirement: The level of trust relationship between the stand-by Requirement: The level of trust relationship between the stand-by
CE and the FEs must be as strong as the one between the active CE CE and the FEs must be as strong as the one between the active CE
and the FEs. The security association between the FEs and the and the FEs. The security association between the FEs and the
stand-by CE may be established prior to fail-over. If not already stand-by CE may be established prior to fail-over. If not already
in place, such security association must be re-established before in place, such security association must be re-established before
the stand-by CE takes over. the stand-by CE takes over.
7.1.5. Data Integrity 8.1.5. Data Integrity
Threats: A malicious node may inject false messages to legitimate Threats: A malicious node may inject false messages to legitimate
CE or FE. CE or FE.
Effect: An FE or CE receives the fabricated packet and performs Effect: An FE or CE receives the fabricated packet and performs
incorrect or catastrophic operation. incorrect or catastrophic operation.
Requirement: Protocol messages require integrity protection. Requirement: Protocol messages require integrity protection.
7.1.6. Data Confidentiality 8.1.6. Data Confidentiality
Threat: When FE and CE are physically separated, a malicious node Threat: When FE and CE are physically separated, a malicious node
may eavesdrop the messages in transit. Some of the messages are may eavesdrop the messages in transit. Some of the messages are
critical to the functioning of the whole network, while others may critical to the functioning of the whole network, while others may
contain confidential business data. Leaking of such information contain confidential business data. Leaking of such information
may result in compromise even beyond the immediate CE or FE. may result in compromise even beyond the immediate CE or FE.
Effect: Sensitive information might be exposed between CE and FE. Effect: Sensitive information might be exposed between CE and FE.
Requirement: Data confidentiality between FE and CE must be Requirement: Data confidentiality between FE and CE must be
available for sensitive information. available for sensitive information.
7.1.7. Sharing security parameters 8.1.7. Sharing security parameters
Threat: Consider a scenario where several FEs communicating to the Threat: Consider a scenario where several FEs communicating to the
same CE share the same authentication keys for the Fp interface. same CE share the same authentication keys for the Fp interface.
If any FE or the CE is compromised, all other entities are If any FE or the CE is compromised, all other entities are
compromised. compromised.
Effect: The whole NE is compromised. Effect: The whole NE is compromised.
Requirement: To avoid this side effect, it is better to configure Recommendation: To avoid this side effect, it's better to configure
different security parameters for each FE-CE communication over Fp different security parameters for each FE-CE communication over Fp
interface. interface.
7.1.8. Denial of Service Attack via External Interface 8.1.8. Denial of Service Attack via External Interface
Threat: When an FE receives a packet that is destined for its CE, Threat: When an FE receives a packet that is destined for its CE,
the FE forwards the packet over the Fp interface. Malicious node the FE forwards the packet over the Fp interface. Malicious node
can generate huge message storm like routing protocol packets etc. can generate huge message storm like routing protocol packets etc.
through the external Fi/f interface so that the FE has to process through the external Fi/f interface so that the FE has to process
and forward all packets to CE through Fp interface. and forward all packets to CE through Fp interface.
Effect: CE encounters resource exhaustion and bandwidth starvation Effect: CE encounters resource exhaustion and bandwidth starvation
on Fp interface due to an overwhelming number of packets from FEs. on Fp interface due to an overwhelming number of packets from FEs.
Requirement: Rate limiting mechanism needs to be in place at both Requirement: Some sort of rate limiting mechanism MUST to be in
FE and CE. Rate Limiter can be configured at FE for each message place at both FE and CE. Examples of such mechanisms include
type that are being received through Fi/F interface. explicit rate limiters or congestion control algorithms. Rate
Limiter SHOULD be configured at FE for each message type that are
being received through Fi/F interface.
7.2. Security Recommendations for ForCES 8.2. Security Recommendations for ForCES
The requirements document [3] suggested that ForCES protocol should The requirements document [3] suggested that ForCES protocol should
support reliability over Fp interface, but no particular transport support reliability over Fp interface, but no particular transport
protocol is yet specified for ForCES. This framework document does protocol is yet specified for ForCES. This framework document does
not intend to specify the particular transport either, and so we not intend to specify the particular transport either, and so we
only provide recommendations and guidelines based on the existing only provide recommendations and guidelines based on the existing
standard security protocols that can work with the common transport standard security protocols that can work with the common transport
candidates suitable for ForCES. candidates suitable for ForCES.
We review two existing security protocol solutions, namely IPsec We review two existing security protocol solutions, namely IPsec
skipping to change at page 32, line 49 skipping to change at page 33, line 20
used potentially to satisfy all of the security requirements for used potentially to satisfy all of the security requirements for
ForCES protocol. Other approaches may be used as well but are not ForCES protocol. Other approaches may be used as well but are not
documented here. documented here.
When ForCES is deployed between CEs and FEs inside a box, When ForCES is deployed between CEs and FEs inside a box,
authentication, confidentiality and integrity may be provided by authentication, confidentiality and integrity may be provided by
the physical security of the box and so the security mechanisms may the physical security of the box and so the security mechanisms may
be turned off, depending on the networking topology and its be turned off, depending on the networking topology and its
administration policy. However, it is important to realize that administration policy. However, it is important to realize that
even if the NE is in a single-box, the DoS attacks as described in even if the NE is in a single-box, the DoS attacks as described in
Section 7.1.8 can still be launched through Fi/f interfaces. Section 8.1.8 can still be launched through Fi/f interfaces.
Therefore, it is important to have the corresponding counter- Therefore, it is important to have the corresponding counter-
measurement in place even for single-box deployment. measurement in place even for single-box deployment.
7.2.1. Security Configuration 8.2.1. Security Configuration
The NE administrator has the freedom to determine the exact The NE administrator has the freedom to determine the exact
security configuration that is needed for the specific deployment. security configuration that is needed for the specific deployment.
For example, ForCES may be deployed between CEs and FEs connected For example, ForCES may be deployed between CEs and FEs connected
to each other inside a box over a backplane. In such scenario, to each other inside a box over a backplane. In such scenario,
physical security of the box ensures that most of the attacks such physical security of the box ensures that most of the attacks such
as man-in-the-middle, snooping, and impersonation are not possible, as man-in-the-middle, snooping, and impersonation are not possible,
and hence ForCES architecture may rely on the physical security of and hence ForCES architecture may rely on the physical security of
the box to defend against these attacks and protocol mechanisms may the box to defend against these attacks and protocol mechanisms may
be turned off. However, it is also shown that denial of service be turned off. However, it is also shown that denial of service
attack via external interface as described in Section 7.1.8 is attack via external interface as described in Section 8.1.8 is
still a potential threat even for such "all-in-one-box" deployment still a potential threat even for such "all-in-one-box" deployment
scenario and hence the rate limiting mechanism is still necessary. scenario and hence the rate limiting mechanism is still necessary.
This is just one example to show that it is important to assess the This is just one example to show that it is important to assess the
security needs of the ForCES-enabled network elements under security needs of the ForCES-enabled network elements under
different deployment scenarios. It should be possible for the different deployment scenarios. It should be possible for the
administrator to configure the level of security needed for the administrator to configure the level of security needed for the
ForCES protocol. ForCES protocol.
7.2.2. Using TLS with ForCES 8.2.2. Using TLS with ForCES
TLS [13] can be used if a reliable unicast transport such as TCP or TLS [13] can be used if a reliable unicast transport such as TCP or
SCTP is used for ForCES over the Fp interface. The TLS handshake SCTP is used for ForCES over the Fp interface. The TLS handshake
protocol is used during association establishment or re- protocol is used during association establishment or re-
establishment phase to negotiate a TLS session between the CE and establishment phase to negotiate a TLS session between the CE and
FE. Once the session is in place, the TLS record protocol is used FE. Once the session is in place, the TLS record protocol is used
to secure ForCES communication messages between the CE and FE. to secure ForCES communication messages between the CE and FE.
A basic outline of how TLS can be used with ForCES is described A basic outline of how TLS can be used with ForCES is described
below. Steps 1) till 7) complete the security handshake as below. Steps 1) till 7) complete the security handshake as
skipping to change at page 34, line 27 skipping to change at page 34, line 43
configured directly a list of valid certificates in the pre- configured directly a list of valid certificates in the pre-
association phase. association phase.
In the case of fail-over, it is the responsibility of the active CE In the case of fail-over, it is the responsibility of the active CE
and the standby CE to synchronize ForCES states including the TLS and the standby CE to synchronize ForCES states including the TLS
states to minimize the state reestablishment during fail-over. states to minimize the state reestablishment during fail-over.
Care must be taken to ensure that the standby CE is also Care must be taken to ensure that the standby CE is also
authenticated in the same way as the active CE, either before or authenticated in the same way as the active CE, either before or
during the fail-over. during the fail-over.
7.2.3. Using IPsec with ForCES 8.2.3. Using IPsec with ForCES
IPsec [14] can be used with any transport protocol, such as UDP, IPsec [14] can be used with any transport protocol, such as UDP,
SCTP and TCP over Fp interface for ForCES. When using IPsec, we SCTP and TCP over Fp interface for ForCES. When using IPsec, we
recommend using ESP in transport mode for ForCES because message recommend using ESP in transport mode for ForCES because message
confidentiality is required for ForCES. confidentiality is required for ForCES.
IPsec can be used with both manual and automated SA and IPsec can be used with both manual and automated SA and
cryptographic key management. But Ipsec's replay protection cryptographic key management. But Ipsec's replay protection
mechanisms are not available if manual key management is used. mechanisms are not available if manual key management is used.
Hence, automatic key management is recommended if replay protection Hence, automatic key management is recommended if replay protection
is deemed important. Otherwise, manual key management might be is deemed important. Otherwise, manual key management might be
sufficient for some deployment scenarios, esp. when the number of sufficient for some deployment scenarios, esp. when the number of
CEs and FEs is relatively small. It is recommended that the keys CEs and FEs is relatively small. It is recommended that the keys
be changed periodically even for manual key management. be changed periodically even for manual key management.
IPsec can support both unicast and multicast transport. When IPsec can support both unicast and multicast transport. At the time
multicast is used, IPsec can be used with manual keying with no this document was published, MSEC working group is actively working
replay protection and no automatic rekeying. This meets the on standardizing protocols to provide multicast security [17].
confidentiality and integrity requirements. Multicast-based Multicast-based solutions relying on IPsec should specify how to
solutions relying on IPsec should specify how rekeying and replay meet the security requirements in [3].
protection are provided.
Unlike TLS, IPsec provides security services between the CE and FE Unlike TLS, IPsec provides security services between the CE and FE
at IP level, and so the security handshake as illustrated in Figure at IP level, and so the security handshake as illustrated in Figure
9 amounts to a "no-op" when manual key management is used. The 9 amounts to a "no-op" when manual key management is used. The
following outline the steps taken for ForCES in such a case. following outline the steps taken for ForCES in such a case.
1) During Pre-association phase all FEs are configured with 1) During Pre-association phase all FEs are configured with
the CEs (including active CE and standby CE) and SA parameters the CEs (including active CE and standby CE) and SA parameters
manually. manually.
2) The FE sends a "join NE" message to the CE. This message 2) The FE sends a "join NE" message to the CE. This message
skipping to change at page 36, line 15 skipping to change at page 36, line 32
authentication that administrator wants to configure. authentication that administrator wants to configure.
In the case of fail-over, it is the responsibility of active CE and In the case of fail-over, it is the responsibility of active CE and
standby CE to synchronize ForCES states and IPsec states to standby CE to synchronize ForCES states and IPsec states to
minimize the state reestablishment during fail-over. minimize the state reestablishment during fail-over.
Alternatively, the FE needs to establish different IPsec SA during Alternatively, the FE needs to establish different IPsec SA during
the startup operation itself with each CE. This will minimize the the startup operation itself with each CE. This will minimize the
periodic state transfer across IPsec layer though Fr (CE-CE) periodic state transfer across IPsec layer though Fr (CE-CE)
Interface. Interface.
8. Normative References 9. Normative References
[1] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, [1] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995. June 1995.
[2] Floyd, S., "Congestion Control Principles", RFC 2914, September [2] Floyd, S., "Congestion Control Principles", RFC 2914, September
2000. 2000.
[3] Khosravi, H. et al., "Requirements for Separation of IP Control [3] Khosravi, H. et al., "Requirements for Separation of IP Control
and Forwarding", work in progress, May 2003, <draft-ietf-forces- and Forwarding", work in progress, May 2003, <draft-ietf-forces-
requirements-09.txt>. requirements-09.txt>.
9. Informative References 10. Informative References
[4] Case, J., et al., "A Simple Network Management Protocol [4] Case, J., et al., "A Simple Network Management Protocol
(SNMP)", RFC 1157, May 1990. (SNMP)", RFC 1157, May 1990.
[5] Daniele, M. et al., "Agent Extensibility (AgentX) Protocol [5] Daniele, M. et al., "Agent Extensibility (AgentX) Protocol
Version 1", RFC 2741, January 2000. Version 1", RFC 2741, January 2000.
[6] Chan, K. et al., "COPS Usage for Policy Provisioning (COPS- [6] Chan, K. et al., "COPS Usage for Policy Provisioning (COPS-
PR)", RFC 3084, March 2001. PR)", RFC 3084, March 2001.
skipping to change at page 37, line 23 skipping to change at page 37, line 38
[14] Kent, S. and R. Atkinson, "Security Architecture for the [14] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE) ", [15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE) ",
RFC 2409, November 1998. RFC 2409, November 1998.
[16] Bellovin, S., "Guidelines for Mandating the Use of Ipsec", [16] Bellovin, S., "Guidelines for Mandating the Use of Ipsec",
work in progress, October 2002, <draft-bellovin-useipsec-00.txt>. work in progress, October 2002, <draft-bellovin-useipsec-00.txt>.
10. Acknowledgements [17] Hardjono, T. and Weis, B. "The Multicast Security
Architecture", work in progress, August 2003, <draft-ietf-msec-
Joel M. Halpern gave us many insightful comments and suggestions arch-03.txt>.
and pointed out several major issues. T. Sridhar suggested that
the AgentX protocol could be used with SNMP to manage the ForCES
network elements. Many of our colleagues and people in the ForCES
mailing list also provided valuable feedback.
11. Authors' Addresses 11. Authors' Addresses
Lily L. Yang L. Lily Yang
Intel Corp., MS JF3-206, Intel Corp., MS JF3-206,
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124, USA Hillsboro, OR 97124, USA
Phone: +1 503 264 8813 Phone: +1 503 264 8813
Email: lily.l.yang@intel.com Email: lily.l.yang@intel.com
Ram Dantu Ram Dantu
Department of Computer Science, Department of Computer Science,
University of North Texas, University of North Texas,
Denton, TX 76203, USA Denton, TX 76203, USA
Phone: +1 940 565 2822 Phone: +1 940 565 2822
Email: rdantu@unt.edu Email: rdantu@unt.edu
Todd A. Anderson Todd A. Anderson
Intel Corp. Intel Corp.
2111 NE 25th Avenue 2111 NE 25th Avenue
skipping to change at page 38, line 14 skipping to change at page 38, line 26
Email: todd.a.anderson@intel.com Email: todd.a.anderson@intel.com
Ram Gopal Ram Gopal
Nokia Research Center Nokia Research Center
5, Wayside Road, 5, Wayside Road,
Burlington, MA 01803, USA Burlington, MA 01803, USA
Phone: +1 781 993 3685 Phone: +1 781 993 3685
Email: ram.gopal@nokia.com Email: ram.gopal@nokia.com
12. Intellectual Property Right 12. Intellectual Property Right
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in RFC 2026. Copies standards-related documentation can be found in RFC 2026. Copies
of of claims of rights made available for publication and any
claims of rights made available for publication and any assurances assurances of licenses to be made available, or the result of an
of licenses to be made available, or the result of an attempt made attempt made to obtain a general license or permission for the use
to obtain a general license or permission for the use of such of such proprietary rights by implementors or users of this
proprietary rights by implementors or users of this specification specification can be obtained from the IETF Secretariat.
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF this standard. Please address the information to the IETF
Executive Director. Executive Director.
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/