draft-ietf-forces-framework-11.txt   draft-ietf-forces-framework-12.txt 
Internet Draft L. Yang Internet Draft L. Yang
Expiration: June 2004 Intel Corp. Expiration: June 2004 Intel Corp.
File: draft-ietf-forces-framework-11.txt R. Dantu File: draft-ietf-forces-framework-12.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
December 2003 December 2003
Forwarding and Control Element Separation (ForCES) Framework Forwarding and Control Element Separation (ForCES) Framework
draft-ietf-forces-framework-11.txt draft-ietf-forces-framework-12.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 5, line 38 skipping to change at page 5, line 38
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
NE are interconnected. Sometimes it is called inter-FE topology, are interconnected. Sometimes it is called inter-FE topology, to
to be distinguished from intra-FE topology used by the FE model. 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)
An IP network element (NE) appears to external entities as a An IP network element (NE) appears to external entities as a
monolithic piece of network equipment, e.g., a router, NAT, monolithic piece of network equipment, e.g., a router, NAT,
firewall, or load balancer. Internally, however, an IP network firewall, or load balancer. Internally, however, an IP network
element (NE) (such as a router) is composed of numerous logically element (NE) (such as a router) is composed of numerous logically
separated entities that cooperate to provide a given functionality separated entities that cooperate to provide a given functionality
skipping to change at page 34, line 8 skipping to change at page 34, line 8
(IP Security) [14] or TLS (Transport Layer Security) [13]. TLS (IP Security) [14] or TLS (Transport Layer Security) [13]. TLS
works with reliable transports such as TCP or SCTP for unicast, works with reliable transports such as TCP or SCTP for unicast,
while IPsec can be used with any transport (UDP, TCP, SCTP) and while IPsec can be used with any transport (UDP, TCP, SCTP) and
supports both unicast and multicast. Both TLS and IPsec can be supports both unicast and multicast. Both TLS and IPsec can be
used potentially to satisfy all of the security requirements for used potentially to satisfy all of the security requirements for
ForCES protocol. In addition, other approaches may be used as well ForCES protocol. In addition, other approaches may be used as well
but are not documented here, including using L2 security mechanisms but are not documented here, including using L2 security mechanisms
for a given L2 interconnect technology, as long as the requirements for a given L2 interconnect technology, as long as the requirements
can be satisfied. can be satisfied.
When ForCES is deployed between CEs and FEs inside a box, When ForCES is deployed between CEs and FEs inside a box or a
authentication, confidentiality and integrity may be provided by physically secured room, authentication, confidentiality and
the physical security of the box and so the security mechanisms may integrity may be provided by the physical security of the box and
be turned off, depending on the networking topology and its so the security mechanisms may be turned off, depending on the
administration policy. However, it is important to realize that networking topology and its administration policy. However, it is
even if the NE is in a single-box, the DoS attacks as described in important to realize that even if the NE is in a single-box, the
Section 8.1.8 can still be launched through Fi/f interfaces. DoS attacks as described in Section 8.1.8 can still be launched
Therefore, it is important to have the corresponding counter- through Fi/f interfaces. Therefore, it is important to have the
measurement in place even for single-box deployment. corresponding counter-measurement in place even for single-box
deployment.
8.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
skipping to change at page 35, line 46 skipping to change at page 35, line 47
during the fail-over. during the fail-over.
8.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. At the time IPsec can support both unicast and multicast transport. At the time
this document was published, MSEC working group is actively working this document was published, MSEC working group is actively working
on standardizing protocols to provide multicast security [17]. on standardizing protocols to provide multicast security [17].
 End of changes. 

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