7. Security Considerations
Security considerations essentially come from the Trust Assumption
Section 6.3.1, ie, that all PCN-nodes are PCN-enabled and are trusted
for truthful PCN-metering and PCN-marking. PCN splits functionality
between PCN-interior-nodes and PCN-boundary-nodes, and the security
considerations are somewhat different for each, mainly because PCN-
boundary-nodes are flow-aware and PCN-interior-nodes are not.
o Because PCN-boundary-nodes are flow-aware, they are trusted to use
that awareness correctly. The degree of trust required depends on
the kinds of decisions they have to make and the kinds of
information they need to make them. There is nothing specific to
o The PCN-ingress-nodes police packets to ensure a PCN-flow sticks
within its agreed limit, and to ensure that only PCN-flows that
have been admitted contribute PCN-traffic into the PCN-domain.
The policer must drop (or perhaps downgrade to a different DSCP)
any PCN-packets received that are outside this remit. This is
similar to the existing IntServ behaviour. Between them, the PCN-
boundary-nodes must encircle the PCN-domain; otherwise, PCN-
packets could enter the PCN-domain without being subject to
admission control, which would potentially destroy the QoS of
o PCN-interior-nodes are not flow-aware. This prevents some
security attacks where an attacker targets specific flows in the
data plane -- for instance, for DoS or eavesdropping.
o The PCN-boundary-nodes rely on correct PCN-marking by the PCN-
interior-nodes. For instance, a rogue PCN-interior-node could
PCN-mark all packets so that no flows were admitted. Another
possibility is that it doesn't PCN-mark any packets, even when it
is pre-congested. More subtly, the rogue PCN-interior-node could
perform these attacks selectively on particular flows, or it could
PCN-mark the correct fraction overall but carefully choose which
flows it marked.
o The PCN-boundary-nodes should be able to deal with DoS attacks and
state exhaustion attacks based on fast changes in per-flow
o The signalling between the PCN-boundary-nodes must be protected
from attacks. For example, the recipient needs to validate that
the message is indeed from the node that claims to have sent it.
Possible measures include digest authentication and protection
against replay and man-in-the-middle attacks. For the RSVP
protocol specifically, hop-by-hop authentication is in [RFC2747],
and [Behringer09] may also be useful.
Operational security advice is given in Section 5.5.
This document describes a general architecture for flow admission and
termination based on pre-congestion information, in order to protect
the quality of service of established, inelastic flows within a
single Diffserv domain. The main topic is the functional
architecture. This document also mentions other topics like the
assumptions and open issues associated with the PCN architecture.
This document is a revised version of an earlier individual working
draft authored by: P. Eardley, J. Babiarz, K. Chan, A. Charny, R.
Geib, G. Karagiannis, M. Menth, and T. Tsou. They are therefore
contributors to this document.
Thanks to those who have made comments on this document: Lachlan
Andrew, Joe Babiarz, Fred Baker, David Black, Steven Blake, Ron
Bonica, Scott Bradner, Bob Briscoe, Ross Callon, Jason Canon, Ken
Carlberg, Anna Charny, Joachim Charzinski, Andras Csaszar, Francis
Dupont, Lars Eggert, Pasi Eronen, Adrian Farrel, Ruediger Geib, Wei
Gengyu, Robert Hancock, Fortune Huang, Christian Hublet, Cullen
Jennings, Ingemar Johansson, Georgios Karagiannis, Hein Mekkes,
Michael Menth, Toby Moncaster, Dimitri Papadimitriou, Dan Romascanu,
Daisuke Satoh, Ben Strulo, Tom Taylor, Hannes Tschofenig, Tina Tsou,
David Ward, Lars Westberg, Magnus Westerlund, and Delei Yu. Thanks
to Bob Briscoe who extensively revised the Operations and Management
This document is the result of discussions in the PCN WG and
forerunner activity in the TSVWG. A number of previous drafts were
presented to TSVWG; their authors were: B. Briscoe, P. Eardley, D.
Songhurst, F. Le Faucheur, A. Charny, J. Babiarz, K. Chan, S. Dudley,
G. Karagiannis, A. Bader, L. Westberg, J. Zhang, V. Liatsos, X-G.
Liu, and A. Bhargava.
The admission control mechanism evolved from the work led by Martin
Karsten on the Guaranteed Stream Provider developed in the M3I
project [Karsten02] [M3I], which in turn was based on the theoretical
work of Gibbens and Kelly [Gibbens99].
10.1. Normative References
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V.,
and D. Stiliadis, "An Expedited Forwarding PHB (Per-
Hop Behavior)", RFC 3246, March 2002.
10.2. Informative References
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
[RFC2211] Wroclawski, J., "Specification of the Controlled-
Load Network Element Service", RFC 2211,
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for
Differentiated Services", RFC 2475, December 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747,
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A
Framework for Policy-based Admission Control",
RFC 2753, January 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F.,
Zhang, L., Speer, M., Braden, R., Davie, B.,
Wroclawski, J., and E. Felstaine, "A Framework for
Integrated Services Operation over Diffserv
Networks", RFC 2998, November 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN)
to IP", RFC 3168, September 2001.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and J.
Heinanen, "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270,
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay
Variation Metric for IP Performance Metrics (IPPM)",
RFC 3393, November 2002.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks",
STD 62, RFC 3411, December 2002.
[RFC3726] Brunner, M., "Requirements for Signaling Protocols",
RFC 3726, April 2004.
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous
System (AS) Traffic Engineering (TE) Requirements",
RFC 4216, November 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,
and M. Zekauskas, "A One-way Active Measurement
Protocol (OWAMP)", RFC 4656, September 2006.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field",
BCP 124, RFC 4774, November 2006.
[RFC4778] Kaeo, M., "Operational Security Current Practices in
Internet Service Provider Environments", RFC 4778,
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit
Congestion Marking in MPLS", RFC 5129, January 2008.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label
Switching (MPLS) Label Stack Entry: "EXP" Field
Renamed to "Traffic Class" Field", RFC 5462,
[P.800] "Methods for subjective determination of
transmission quality", ITU-T Recommendation P.800,
[Y.1541] "Network Performance Objectives for IP-based
Services", ITU-T Recommendation Y.1541,
[Babiarz06] Babiarz, J., Chan, K., Karagiannis, G., and P.
Eardley, "SIP Controlled Admission and Preemption",
Work in Progress, October 2006.
[Behringer09] Behringer, M. and F. Le Faucheur, "Applicability of
Keying Methods for RSVP Security", Work in Progress,
[Briscoe06] Briscoe, B., Eardley, P., Songhurst, D., Le
Faucheur, F., Charny, A., Babiarz, J., Chan, K.,
Dudley, S., Karagiannis, G., Bader, A., and L.
Westberg, "An edge-to-edge Deployment Model for Pre-
Congestion Notification: Admission Control over a
Diffserv Region", Work in Progress, October 2006.
[Briscoe08] Briscoe, B., "Emulating Border Flow Policing using
Re-PCN on Bulk Data", Work in Progress,
[Briscoe09] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", Work in Progress, March 2009.
[Bryant08] Bryant, S., Davie, B., Martini, L., and E. Rosen,
"Pseudowire Congestion Control Framework", Work
in Progress, May 2008.
[Charny07-1] Charny, A., Babiarz, J., Menth, M., and X. Zhang,
"Comparison of Proposed PCN Approaches", Work
in Progress, November 2007.
[Charny07-2] Charny, A., Zhang, X., Le Faucheur, F., and V.
Liatsos, "Pre-Congestion Notification Using Single
Marking for Admission and Termination", Work
in Progress, November 2007.
[Charny07-3] Charny, A., "Email to PCN WG mailing list",
November 2007, <http://www1.ietf.org/mail-archive/
[Charny08] Charny, A., "Email to PCN WG mailing list",
March 2008, <http://www1.ietf.org/mail-archive/web/
[Eardley07] Eardley, P., "Email to PCN WG mailing list",
October 2007, <http://www1.ietf.org/mail-archive/
[Eardley09] Eardley, P., "Metering and marking behaviour of PCN-
nodes", Work in Progress, May 2009.
[Gibbens99] Gibbens, R. and F. Kelly, "Distributed connection
acceptance control for a connectionless network",
Proceedings International Teletraffic Congress
(ITC16), Edinburgh, pp. 941-952, 1999.
[Hancock02] Hancock, R. and E. Hepworth, "Slide 14 of 'NSIS: An
Outline Framework for QoS Signalling'", May 2002, <h
[Moncaster09-1] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion
Information", Work in Progress, May 2009.
[Moncaster09-2] Moncaster, T., Briscoe, B., and M. Menth, "A PCN
encoding using 2 DSCPs to provide 3 or more states",
Work in Progress, April 2009.
[Sarker08] Sarker, Z. and I. Johansson, "Usecases and Benefits
of end to end ECN support in PCN Domains", Work
in Progress, November 2008.
[Songhurst06] Songhurst, DJ., Eardley, P., Briscoe, B., Di Cairano
Gilfedder, C., and J. Tay, "Guaranteed QoS Synthesis
for Admission Control with Shared Capacity", BT
Technical Report TR-CXR9-2006-001, Feburary 2006,
[Taylor09] Charny, A., Huang, F., Menth, M., and T. Taylor,
"PCN Boundary Node Behaviour for the Controlled Load
(CL) Mode of Operation", Work in Progress,
[Tsou08] Tsou, T., Huang, F., and T. Taylor, "Applicability
Statement for the Use of Pre-Congestion Notification
in a Resource-Controlled Network", Work in Progress,
[Westberg08] Westberg, L., Bhargava, A., Bader, A., Karagiannis,
G., and H. Mekkes, "LC-PCN: The Load Control PCN
Solution", Work in Progress, November 2008.
Appendix A. Possible Future Work Items
This section mentions some topics that are outside the PCN WG's
current charter but that have been mentioned as areas of interest.
They might be work items for the PCN WG after a future re-chartering,
some other IETF WG, another standards body, or an operator-specific
usage that is not standardised.
Note: It should be crystal clear that this section discusses
The first set of possibilities relate to the restrictions described
in Section 6.3:
o A single PCN-domain encompasses several autonomous systems that do
not trust each other. A possible solution is a mechanism like re-
o Not all the nodes run PCN. For example, the PCN-domain is a
multi-site enterprise network. The sites are connected by a VPN
tunnel; although PCN doesn't operate inside the tunnel, the PCN
mechanisms still work properly because of the good QoS on the
virtual link (the tunnel). Another example is that PCN is
deployed on the general Internet (ie, widely but not universally
o Applying the PCN mechanisms to other types of traffic, ie, beyond
inelastic traffic -- for instance, applying the PCN mechanisms to
traffic scheduled with the Assured Forwarding per-hop behaviour.
One example could be flow-rate adaptation by elastic applications
that adapt according to the pre-congestion information.
o The aggregation assumption doesn't hold, because the link capacity
is too low. Measurement-based admission control is less accurate,
with a greater risk of over-admission for instance.
o The applicability of PCN mechanisms for emergency use (911, GETS,
WPS, MLPP, etc.).
Other possibilities include:
o Probing. This is discussed in Appendix A.1 below.
o The PCN-domain extends to the end users. This scenario is
described in [Babiarz06]. The end users need to be trusted to do
their own policing. If there is sufficient traffic, then the
aggregation assumption may hold. A variant is that the PCN-domain
extends out as far as the LAN edge switch.
o Indicating pre-congestion through signalling messages rather than
in-band (in the form of PCN-marked packets).
o The decision-making functionality is at a centralised node rather
than at the PCN-boundary-nodes. This requires that the PCN-
egress-node signals PCN-feedback-information to the centralised
node, and that the centralised node signals to the PCN-ingress-
node the decision about admission (or termination). Such
possibility may need the centralised node and the PCN-boundary-
nodes to be configured with each other's addresses. The
centralised case is described further in [Tsou08].
o Signalling extensions for specific protocols (eg, RSVP and NSIS)
-- for example, the details of how the signalling protocol
installs the flowspec at the PCN-ingress-node for an admitted PCN-
flow, and how the signalling protocol carries the PCN-feedback-
information. Perhaps also for other functions such as for coping
with failure of a PCN-boundary-node ([Briscoe06] considers what
happens if RSVP is the QoS signalling protocol) and for
establishing a tunnel across the PCN-domain if it is necessary to
carry ECN marks transparently.
o Policing by the PCN-ingress-node may not be needed if the PCN-
domain can trust that the upstream network has already policed the
traffic on its behalf.
o PCN for Pseudowire. PCN may be used as a congestion avoidance
mechanism for edge-to-edge pseudowire emulations [Bryant08].
o PCN for MPLS. [RFC3270] defines how to support the Diffserv
architecture in MPLS (Multiprotocol Label Switching) networks.
[RFC5129] describes how to add PCN for admission control of
microflows into a set of MPLS aggregates. PCN-marking is done in
MPLS's EXP field (which [RFC5462] re-names the Class of Service
o PCN for Ethernet. Similarly, it may be possible to extend PCN
into Ethernet networks, where PCN-marking is done in the Ethernet
header. Note: Specific consideration of this extension is outside
of the IETF's remit.
Probing is a potential mechanism to assist admission control.
PCN's admission control, as described so far, is essentially a
reactive mechanism where the PCN-egress-node monitors the pre-
congestion level for traffic from each PCN-ingress-node; if the level
rises, then it blocks new flows on that ingress-egress-aggregate.
However, it's possible that an ingress-egress-aggregate carries no
traffic, and so the PCN-egress-node can't make an admission decision
using the usual method described earlier.
One approach is to be "optimistic" and simply admit the new flow.
However, it's possible to envisage a scenario where the traffic
levels on other ingress-egress-aggregates are already so high that
they're blocking new PCN-flows, and admitting a new flow onto this
"empty" ingress-egress-aggregate adds extra traffic onto a link that
is already pre-congested. This may 'tip the balance' so that PCN's
flow termination mechanism is activated or some packets are dropped.
This risk could be lessened by configuring, on each link, a
sufficient 'safety margin' above the PCN-threshold-rate.
An alternative approach is to make PCN a more proactive mechanism.
The PCN-ingress-node explicitly determines, before admitting the
prospective new flow, whether the ingress-egress-aggregate can
support it. This can be seen as a "pessimistic" approach, in
contrast to the "optimism" of the approach above. It involves
probing: a PCN-ingress-node generates and sends probe packets in
order to test the pre-congestion level that the flow would
One possibility is that a probe packet is just a dummy data packet,
generated by the PCN-ingress-node and addressed to the PCN-egress-
A.1.2. Probing Functions
The probing functions are:
o Make the decision that probing is needed. As described above,
this is when the ingress-egress-aggregate (or the ECMP path -- see
Section 6.4) carries no PCN-traffic. An alternative is to always
probe, ie, probe before admitting any PCN-flow.
o (if required) Communicate the request that probing is needed; the
PCN-egress-node signals to the PCN-ingress-node that probing is
o (if required) Generate probe traffic; the PCN-ingress-node
generates the probe traffic. The appropriate number (or rate) of
probe packets will depend on the PCN-metering algorithm; for
example, an excess-traffic-metering algorithm triggers fewer PCN-
marks than a threshold-metering algorithm, and so will need more
o Forward probe packets; as far as PCN-interior-nodes are concerned,
probe packets are handled the same as (ordinary data) PCN-packets
in terms of routing, scheduling, and PCN-marking.
o Consume probe packets; the PCN-egress-node consumes probe packets
to ensure that they don't travel beyond the PCN-domain.
A.1.3. Discussion of Rationale for Probing, Its Downsides and Open
It is an unresolved question whether probing is really needed, but
two viewpoints have been put forward as to why it is useful. The
first is perhaps the most obvious: there is no PCN-traffic on the
ingress-egress-aggregate. The second assumes that multipath routing
(eg, ECMP) is running in the PCN-domain. We now consider each in
The first viewpoint assumes the following:
o There is no PCN-traffic on the ingress-egress-aggregate (so a
normal admission decision cannot be made).
o Simply admitting the new flow has a significant risk of leading to
overload: packets dropped or flows terminated.
On the former bullet, [Eardley07] suggests that, during the future
busy hour of a national network with about 100 PCN-boundary-nodes,
there are likely to be significant numbers of aggregates with very
few flows under nearly all circumstances.
The latter bullet could occur if new flows start on many of the empty
ingress-egress-aggregates, which together overload a link in the PCN-
domain. To be a problem, this would probably have to happen in a
short time period (flash crowd) because, after the reaction time of
the system, other (non-empty) ingress-egress-aggregates that pass
through the link will measure pre-congestion and so block new flows.
Also, flows naturally end anyway.
The downsides of probing for this viewpoint are:
o Probing adds delay to the admission control process.
o Sufficient probing traffic has to be generated to test the pre-
congestion level of the ingress-egress-aggregate. But the probing
traffic itself may cause pre-congestion, causing other PCN-flows
to be blocked or even terminated -- and, in the flash crowd
scenario, there will be probing on many ingress-egress-aggregates.
The second viewpoint applies in the case where there is multipath
routing (eg, ECMP) in the PCN-domain. Note that ECMP is often used
on core networks. There are two possibilities:
(1) If admission control is based on measurements of the ingress-
egress-aggregate, then the viewpoint that probing is useful
* There's a significant chance that the traffic is unevenly
balanced across the ECMP paths and, hence, there's a
significant risk of admitting a flow that should be blocked
(because it follows an ECMP path that is pre-congested) or of
blocking a flow that should be admitted.
Note: [Charny07-3] suggests unbalanced traffic is quite
possible, even with quite a large number of flows on a PCN-link
(eg, 1000), when Assumption 3 (aggregation) is likely to be
(2) If admission control is based on measurements of pre-congestion
on specific ECMP paths, then the viewpoint that probing is
* There is no PCN-traffic on the ECMP path on which to base an
* Simply admitting the new flow has a significant risk of
leading to overload.
* The PCN-egress-node can match a packet to an ECMP path.
Note: This is similar to the first viewpoint and so, similarly,
could occur in a flash crowd if a new flow starts more or less
simultaneously on many of the empty ECMP paths. Because there
are several ECMP paths between each pair of PCN-boundary-nodes,
it's presumably more likely that an ECMP path is "empty" than an
ingress-egress-aggregate is. To constrain the number of ECMP
paths, a few tunnels could be set up between each pair of PCN-
boundary-nodes. Tunnelling also solves the issue in the point
immediately above (which is otherwise hard to solve because an
ECMP routing decision is made independently on each node).
The downsides of probing for this viewpoint are:
o Probing adds delay to the admission control process.
o Sufficient probing traffic has to be generated to test the pre-
congestion level of the ECMP path. But there's the risk that the
probing traffic itself may cause pre-congestion, causing other
PCN-flows to be blocked or even terminated.
o The PCN-egress-node needs to consume the probe packets to ensure
they don't travel beyond the PCN-domain, since they might confuse
the destination end node. This is non-trivial, since probe
packets are addressed to the destination end node in order to test
the relevant ECMP path (ie, they are not addressed to the PCN-
egress-node, unlike the first viewpoint above).
The open issues associated with these viewpoints include:
o What rate and pattern of probe packets does the PCN-ingress-node
need to generate so that there's enough traffic to make the
o What difficulty does the delay (whilst probing is done), and
possible packet drops, cause applications?
o Can the delay be alleviated by automatically and periodically
probing on the ingress-egress-aggregate? Or does this add too
o Are there other ways of dealing with the flash crowd scenario?
For instance, by limiting the rate at which new flows are
admitted, or perhaps by a PCN-egress-node blocking new flows on
its empty ingress-egress-aggregates when its non-empty ones are
o (Second viewpoint only) How does the PCN-egress-node disambiguate
probe packets from data packets (so it can consume the former)?
The PCN-egress-node must match the characteristic setting of
particular bits in the probe packet's header or body, but these
bits must not be used by any PCN-interior-node's ECMP algorithm.
In the general case, this isn't possible, but it should be
possible for a typical ECMP algorithm (which examines the source
and destination IP addresses and port numbers, the protocol ID,
and the DSCP).