draft-ietf-forces-framework-10.txt   draft-ietf-forces-framework-11.txt 
Internet Draft L. Yang Internet Draft L. Yang
Expiration: April 2004 Intel Corp. Expiration: June 2004 Intel Corp.
File: draft-ietf-forces-framework-10.txt R. Dantu File: draft-ietf-forces-framework-11.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
October 2003 December 2003
Forwarding and Control Element Separation (ForCES) Framework Forwarding and Control Element Separation (ForCES) Framework
draft-ietf-forces-framework-10.txt draft-ietf-forces-framework-11.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 ?
3.3. CE Managers.............................................14 3.3. CE Managers.............................................14
3.4. FE Managers.............................................15 3.4. FE Managers.............................................15
4. Operational Phases...........................................15 4. Operational Phases...........................................15
4.1. Pre-association Phase...................................15 4.1. Pre-association Phase...................................15
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.........................20
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............................22
4.3.1. CE graceful restart................................22 4.3.1. CE graceful restart................................22
4.3.2. FE restart.........................................23 4.3.2. FE restart.........................................24
5. Applicability to RFC1812.....................................24 5. Applicability to RFC1812.....................................25
5.1. General Router Requirements.............................25 5.1. General Router Requirements.............................25
5.2. Link Layer..............................................26 5.2. Link Layer..............................................26
5.3. Internet Layer Protocols................................26 5.3. Internet Layer Protocols................................27
5.4. Internet Layer Forwarding...............................27 5.4. Internet Layer Forwarding...............................27
5.5. Transport Layer.........................................28 5.5. Transport Layer.........................................28
5.6. Application Layer -- Routing Protocols..................28 5.6. Application Layer -- Routing Protocols..................29
5.7. Application Layer -- Network Management Protocol........29 5.7. Application Layer -- Network Management Protocol........29
6. Summary......................................................29 6. Summary......................................................30
7. Acknowledgements.............................................29 7. Acknowledgements.............................................30
8. Security Considerations......................................29 8. Security Considerations......................................30
8.1. Analysis of Potential Threats Introduced by ForCES......30 8.1. Analysis of Potential Threats Introduced by ForCES......30
8.1.1. "Join" or "Remove" Message Flooding on CEs.........30 8.1.1. "Join" or "Remove" Message Flooding on CEs.........31
8.1.2. Impersonation Attack...............................30 8.1.2. Impersonation Attack...............................31
8.1.3. Replay Attack......................................31 8.1.3. Replay Attack......................................31
8.1.4. Attack during Fail Over............................31 8.1.4. Attack during Fail Over............................32
8.1.5. Data Integrity.....................................31 8.1.5. Data Integrity.....................................32
8.1.6. Data Confidentiality...............................32 8.1.6. Data Confidentiality...............................32
8.1.7. Sharing security parameters........................32 8.1.7. Sharing security parameters........................33
8.1.8. Denial of Service Attack via External Interface....32 8.1.8. Denial of Service Attack via External Interface....33
8.2. Security Recommendations for ForCES.....................32 8.2. Security Recommendations for ForCES.....................33
8.2.1. Security Configuration.............................33 8.2.1. Security Configuration.............................34
8.2.2. Using TLS with ForCES..............................34 8.2.2. Using TLS with ForCES..............................34
8.2.3. Using IPsec with ForCES............................35 8.2.3. Using IPsec with ForCES............................35
9. Normative References.........................................36 9. Normative References.........................................37
10. Informative References......................................37 10. Informative References......................................37
11. Authors' Addresses..........................................37 11. Authors' Addresses..........................................38
12. Intellectual Property Right.................................38 12. Intellectual Property Right.................................39
13. Full Copyright Statement....................................39 13. Full Copyright Statement....................................39
1. Definitions 1. Definitions
1.1. Conventions used in this document 1.1. 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.
skipping to change at page 19, line 12 skipping to change at page 19, line 12
|(Go ahead!) | |(Go ahead!) |
9|<----------------------| 9|<----------------------|
| | | |
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 security handshake should include mutual
depend on the security solution chosen by ForCES protocol. Section authentication and authorization between the CE and FE, but the
8 provides more details on the security considerations for ForCES. exact details depend on the security solution chosen by ForCES
protocol. Authorization can be as simple as checking against the
list of authorized end points provided by the FE or CE manager
during the pre-association phase. Both authentication and
authorization must be successful before the association can be
established. If either authentication or authorization fails, the
end point must not be allowed to join the NE. After the successful
security handshake, message authentication and confidentiality are
still necessary for the on-going information exchange between the
CE and FE, unless some form of physical security exists. Whenever
a packet fails authentication, it must be dropped and a
notification may be sent to alert the sender of the potential
attack. Section 8 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 30 skipping to change at page 22, line 4
Figure 11 shows one example of how the BGP packets originated by Figure 11 shows one example of how the BGP packets originated by
router A are passed to router B. In this example, the ForCES router A are passed to router B. In this example, the ForCES
protocol is used to transport the packets from the CE to the FE protocol is used to transport the packets from the CE to the FE
inside router A, and then from the FE to the CE inside router B. inside router A, and then from the FE to the CE inside router B.
In light of the fact that the ForCES protocol is responsible for In light of the fact that the ForCES protocol is responsible for
transporting both the control messages and the data packets between transporting both the control messages and the data packets between
the CE and FE over Fp reference point, it is possible to use either the CE and FE over Fp reference point, it is possible to use either
a single protocol or multiple protocols to achieve this. a single protocol or multiple protocols to achieve this.
4.2.5. Proxy FE 4.2.5. Proxy FE
In the case where a physical FE cannot implement (e.g., due to the In the case where a physical FE cannot implement (e.g., due to the
lack of a general purpose CPU) the ForCES protocol directly, a lack of a general purpose CPU) the ForCES protocol directly, a
proxy FE can be used in the middle of Fp reference point. This proxy FE can be used in the middle of Fp reference point. This
allows the CE communicate to the physical FE via the proxy by using allows the CE communicate to the physical FE via the proxy by using
ForCES, while the proxy manipulates the physical FE using some ForCES, while the proxy manipulates the physical FE using some
intermediary form of communication (e.g., a non-ForCES protocol or intermediary form of communication (e.g., a non-ForCES protocol or
DMA). In such an implementation, the combination of the proxy and DMA). In such an implementation, the combination of the proxy and
the physical FE becomes one logical FE entity. the physical FE becomes one logical FE entity.
One needs to be aware of the security implication introduced by the
proxy FE. Since the physical FE is not capable of implementing
ForCES itself, the security mechanism of ForCES can only secure the
communication channel between the CE and the proxy FE, but not all
the way to the physical FE. It is recommended that other security
mechanisms (including physical security property) be employed to
ensure the security between the CE and the physical FE.
4.3. Association Re-establishment 4.3. Association Re-establishment
FEs and CEs may join and leave NEs dynamically (see [3] Section 5, FEs and CEs may join and leave NEs dynamically (see [3] Section 5,
requirements #12). When an FE or CE leaves the NE, the association requirements #12). When an FE or CE leaves the NE, the association
with the NE is broken. If the leaving party rejoins an NE later, with the NE is broken. If the leaving party rejoins an NE later,
to re-establish the association, it may need to re-enter the pre- to re-establish the association, it may need to re-enter the pre-
association phase. Loss of association can also happen association phase. Loss of association can also happen
unexpectedly due to loss of connection between the CE and the FE. unexpectedly due to loss of connection between the CE and the FE.
Therefore, the framework allows the bi-directional transition Therefore, the framework allows the bi-directional transition
between these two phases, but the ForCES protocol is only between these two phases, but the ForCES protocol is only
skipping to change at page 22, line 4 skipping to change at page 22, line 33
FEs and CEs may join and leave NEs dynamically (see [3] Section 5, FEs and CEs may join and leave NEs dynamically (see [3] Section 5,
requirements #12). When an FE or CE leaves the NE, the association requirements #12). When an FE or CE leaves the NE, the association
with the NE is broken. If the leaving party rejoins an NE later, with the NE is broken. If the leaving party rejoins an NE later,
to re-establish the association, it may need to re-enter the pre- to re-establish the association, it may need to re-enter the pre-
association phase. Loss of association can also happen association phase. Loss of association can also happen
unexpectedly due to loss of connection between the CE and the FE. unexpectedly due to loss of connection between the CE and the FE.
Therefore, the framework allows the bi-directional transition Therefore, the framework allows the bi-directional transition
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 (including both authentication and authorization) exists
before and after the association re-establishment.
When an FE leaves or joins an existing NE that is already in post- 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 association phase, the CE needs to be aware of the impact on FE
topology and deals with the change accordingly. 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
skipping to change at page 31, line 7 skipping to change at page 31, line 36
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.
8.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 as having
accepting and processing it. come from an FE or CE on the list of the authorized ForCES elements
(provided by the CE or FE Manager in the pre-association phase)
before accepting and processing it.
8.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 solution to defend against this attack. security solution to defend against this attack.
skipping to change at page 33, line 16 skipping to change at page 33, line 51
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
(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. Other approaches may be used as well but are not ForCES protocol. In addition, other approaches may be used as well
documented here, including using L2 security mechanisms for a given but are not documented here, including using L2 security mechanisms
L2 interconnect technology, as long as the requirements can be for a given L2 interconnect technology, as long as the requirements
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,
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 8.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.
 End of changes. 

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