Internet DRAFT - draft-haas-idr-bgp-attribute-escape
draft-haas-idr-bgp-attribute-escape
Inter-Domain Routing J. Haas
Internet-Draft Juniper Networks
Intended status: Informational 2 February 2024
Expires: 5 August 2024
BGP Attribute Escape
draft-haas-idr-bgp-attribute-escape-01
Abstract
BGP-4 [RFC 4271] has been very successful in being extended over the
years it has been deployed. A significant part of that success is
due to its ability to incrementally add new features to its Path
Attributes when they are marked "optional transitive".
Implementations that are ignorant of a feature for an unknown Path
Attribute that are so marked will propagate BGP routes with such
attributes.
Unfortunately, this blind propagation of unknown Path Attributes may
happen for features that are intended to be used in a limited scope.
When such Path Attributes inadvertently are carried beyond that
scope, it can lead to things such as unintended disclosure of
sensitive information, or cause improper routing. In their worst
cases, such propagation may be for malformed Path Attributes and lead
to BGP session resets or crashes.
This document calls such inadvertent propagation of BGP Path
Attributes, "attribute escape". This document further describes some
of the scenarios that leads to this behavior and makes
recommendations on practices that may limit its impact.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 August 2024.
Haas Expires 5 August 2024 [Page 1]
Internet-Draft BGP Attribute Escape February 2024
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. BGP Path Attributes and Transitivity . . . . . . . . . . . . 3
3. Motivation to Make New Path Attributes Transitive, and When
It's Not Safe . . . . . . . . . . . . . . . . . . . . . . 3
4. Attribute Escape . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Attribute Scoping . . . . . . . . . . . . . . . . . . . . 4
4.2. Escape . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Community Escapes . . . . . . . . . . . . . . . . . . . . 5
4.4. Inadvertent Use . . . . . . . . . . . . . . . . . . . . . 6
4.5. Outages Cause by Attribute Escape . . . . . . . . . . . . 6
5. Mitigating Attribute Escape . . . . . . . . . . . . . . . . . 7
5.1. Explicit Permit Lists, and Their Dangers . . . . . . . . 7
5.2. Stronger Implementation Filtering Mechanisms . . . . . . 7
5.3. Scoping by Protocol Feature . . . . . . . . . . . . . . . 8
5.3.1. AS Scoping . . . . . . . . . . . . . . . . . . . . . 8
5.3.2. Next Hop Scoping . . . . . . . . . . . . . . . . . . 9
5.3.3. Changes to the BGP protocol . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Haas Expires 5 August 2024 [Page 2]
Internet-Draft BGP Attribute Escape February 2024
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. BGP Path Attributes and Transitivity
BGP-4 [RFC4271] carries routing information in UPDATE messages. BGP
UPDATEs pair sets of network layer reachability information (NLRI),
i.e. destinations, with properties for those destinations. Those
properties are carried in Path Attributes (Section 4.3 of [RFC4271]).
The BGP-4 RFC defines a base set of Path Attributes, several of which
are "mandatory", and two that are optional.
Optional Path Attributes are flagged to be either "transitive" or
"non-transitive". This flag controls how a BGP implementation that
does not recognize a Path Attribute will handle it. In particular,
unrecognized non-transitive Path Attributes, "MUST be quietly ignored
and not passed along to other BGP peers". However, if the attribute
is non-transitive but recognized, the procedures documented for that
feature will control how it is propagated by such an implementation.
Emphasizing this point: Non-transitive Path Attributes are only
guaranteed to be dropped during BGP route propagation by
implementations that do not recognize them.
Unrecognized transitive Path Attributes, if they are accepted by the
implementation (and they usually are), will be propagated. However,
when they are unrecognized, the "Partial" flag is set indicating that
at least one BGP speaker in the propagation path did not recognize
the feature. In practice, this flag is solely informational and not
used by implementations to change their processing of the attribute
when they recognize it.
3. Motivation to Make New Path Attributes Transitive, and When It's Not
Safe
Authors of new BGP features often desire to make their new Path
Attributes to be transitive in order to avoid having to upgrade BGP
speakers in their networks to support the new feature. A particular
case where this is desired is to avoid upgrading BGP route reflectors
[RFC4456]. When it's the case that a feature only needs to be
supported by a partial set of BGP speakers in the network, this often
works well.
Haas Expires 5 August 2024 [Page 3]
Internet-Draft BGP Attribute Escape February 2024
A particular case where this strategy fails is when the feature
alters BGP's Decision Process (Section 9.1 of [RFC4271]); i.e. route
selection. In general, it is necessary for all BGP speakers in an
Autonomous System (AS) to agree on how to do route selection.
Inconsistent route selection may lead to routing or forwarding loops.
A consequence of this point is that any new feature that alters route
selection needs to be consistently deployed within an AS. In most
circumstances, this is true for the full scope of BGP route
propagation where the next hop is unchanged. Thus, this applies to
BGP Confederations [RFC5065] as well.
Non-transitive Path Attributes can be helpful for features that
impact route selection. A consequence of their behavior is that once
a route containing a non-transitive Path Attribute reaches a BGP
speaker that is ignorant of its behavior, that attribute will be
dropped. An example of this behavior is used in the AIGP [RFC7311]
feature.
4. Attribute Escape
4.1. Attribute Scoping
Propagation scope is typically described as part of a BGP protocol
extension's procedures. A common scoping boundary is intra-AS only;
for example, drop at eBGP boundaries. BGP Capabilities [RFC5492] can
also provide the ability to signal a scoping boundary. Another
implicit scoping boundary are features that are AFI/SAFI specific
([RFC4760]); the scope is the contiguous domain of all devices that
participate in that AFI/SAFI.
Non-transitive Path Attributes cannot be propagated outside of the
scope of the set of BGP speakers that understand them. If such a
Path Attribute is advertised "too far", it's a failure of the scoping
mechanisms for that feature.
Transitive Path Attributes may similarly take advantage of the
scoping mechanisms defined above, but only by devices that understand
those Path Attributes.
4.2. Escape
Any circumstance where a BGP Path Attribute attached to a route
manages to be propagated outside of its intended scope is an
"escape".
Haas Expires 5 August 2024 [Page 4]
Internet-Draft BGP Attribute Escape February 2024
A first example of escape are Path Attributes for new features that
are intended to be dropped at eBGP boundaries. That is, the feature
is intra-AS only. An example of such expected filtering is the BGP
Tunnel Encapsulation Attribute (TEA) (Section 11 of [RFC9012]). BGP
speakers implementing this feature are expected to remove the TEA
when sending routes to eBGP speakers by default. However, if a BGP
speaker that is an eBGP router doesn't understand the TEA, it can't
do this filtering. Similarly, the procedures recommend the TEA is
removed by default at eBGP boundaries. In such cases, if the eBGP
speaker doesn't understand the TEA, it won't be removed there either.
When both failures happen, and if it's the case that an AS receives
routes with the TEA from another AS the receiving AS may
inadvertently use that TEA within their network.
A second example of escape is when attributes are expected to change
at next hop reset boundaries. While this is typically the case for
eBGP, this could be done elsewhere within a network by configuration.
One example of this is the BGP Entropy Label feature [RFC6790]. A
second example is the BGP Prefix-SID feature [RFC8669].
A third example of escape is when attributes leak across AFI/SAFIs.
Layer-3 VPNs [RFC4364] operate by distributing routes learned from
customer networks as IPv4 Unicast routes through a provider backbone
using a different AFI/SAFI. Features that are used within the
provider network, and attributes attached to those routes that are
solely for use within the scope of the provider network and not
intended for the customer network, need to be filtered when the route
is again placed in a customer network context. However, it's often
the case that filtering is not carefully done when leaking the routes
back into the customer network (VRF). Unrecognized Path Attributes
may be copied wholly. An example of such a provider-network-only
feature is the ATTR_SET [RFC6368].
4.3. Community Escapes
BGP Communities of various forms ([RFC1997], [RFC4360], [RFC8092])
are often arbitrary operator-supplied route markup intended to have
local or closely coordinated significance. RFC 1997 provides for a
small set of well-known communities that have impact on BGP route
scoping, and are reasonably well-respected by various
implementations. RFC 1997 and RFC 8092 Large BGP communities often
are distributed further than necessary, and in most circumstances
simply contribute to "operational clutter".
However, some communities that are partially standardized but don't
have consistent global significance may also impact traffic. An
example of this is the BGP Blackhole Community [RFC7999].
Haas Expires 5 August 2024 [Page 5]
Internet-Draft BGP Attribute Escape February 2024
The majority of RFC 4360 BGP Extended Communities in use tend to be
for features related to VPN-feature signaling. Extended Communities
have their own internal transitivity scoping, which is intended to be
enforced at AS boundaries. However, such enforcement can only be
implemented by BGP speakers that understand Extended Communities.
In general, while BGP community features are well-deployed and well
understood, they may have similar escape issues. Section 11 of
[RFC7454] offers some guidance on locally scrubbing such things.
4.4. Inadvertent Use
One of the main, and typically accidental impacts of attribute
escape, are BGP speakers that have received such escaped attributes
and make use of them. In some cases, these are features that require
explicit configuration to be used. In many cases, BGP
implementations will simply process received attributes and make use
of them without additional configuration.
Such inadvertent use can have unexpected impacts on a network.
Impacts may include unexpected route selection, mis-routed traffic,
or traffic that blackholes.
Such behaviors may be maliciously exploited.
4.5. Outages Cause by Attribute Escape
While transitive Path Attributes have proved that BGP's extension
mechanisms have done well over the years, they've also provided the
vehicle for network incidents and outages. One form of this is when
an implementation of a partially deployed feature receives a
malformed transitive Path Attribute from a BGP speaker that didn't
understand that attribute. The author has previously termed this
problem, "optional transitive nonsense".
The underlying issue for such nonsense is the response of the
receiving BGP speaker. Using core RFC 4271 procedures, such a
malformed Path Attribute is reason to reset the BGP session.
(Section 6.3 of [RFC4271]) However, since the BGP speaker that
propagated the route may not have been the originator of that
attribute, this penalizes the BGP speaker that propagated the route.
In far more unfortunate circumstances, such malformed attributes may
exercise defects in the BGP stack and cause crashes. These crashes
impacts the entire BGP speaker rather than individual sessions. Such
issues may be maliciously exploited.
Haas Expires 5 August 2024 [Page 6]
Internet-Draft BGP Attribute Escape February 2024
These issues were motivations for the "Revised Error Handling for BGP
UPDATE Messages" document, [RFC7606].
5. Mitigating Attribute Escape
5.1. Explicit Permit Lists, and Their Dangers
One strategy to mitigate these sort of issues can be explicit permit
lists. Rather than simply propagate all unknown Path Attributes,
lists of permitted Path Attributes by Attribute Type Code may be
propagated through the network. However, this methodology has two
strong negative impacts:
Similar to running any other large permit list infrastructure, as is
often seen in large network firewall deployments, maintaining the
lists themselves can be immensely burdensome at an operational level.
Once a policy has been devised for the deployment, it must be
consistent deployed to have good effect.
Additionally, this methodology is an "attack" on the feature that has
provided for BGP's successful incremental deployment of new features.
This struggle is a common one for users in firewalled networks where
attempts to use new features are thwarted by the operators. However,
in this case, this can impact deployment of desirable new BGP
features for the Internet. Consider, for example, [RFC9234] which is
intended to provide additional protection vs. BGP route leaking.
Aggressive filtering may prevent such new features from being
deployed.
Aggressive filtering may be more reasonable in some contexts. For
example, a Layer-3 VPN customer may benefit from aggressive default
Path Attribute filtering as it provides protection from attribute
escape from their provider. However, in cases where newer BGP
features are desired to be carried across the VPN, additional
coordination with their service provider may be required.
5.2. Stronger Implementation Filtering Mechanisms
IETF review practices have evolved to start discussing attribute
escape and its impacts. This review may lead to text recommending
where filtering should be done and how. (See again the example for
the Tunnel Encapsulation Attribute, Section 11 of [RFC9012].) It is
important that implementors and vendors translate these filtering
requirements into easy to configure mechanisms for enforcement.
Haas Expires 5 August 2024 [Page 7]
Internet-Draft BGP Attribute Escape February 2024
Current IETF practice is to include an Operational Considerations
([RFC5706]) section in its documents. Such considerations are a hint
(or requirement!) to implementors to create mechanisms that permit
safe management of features. This is especially true during
incremental or partial deployment of new features.
5.3. Scoping by Protocol Feature
Similar to the accepted truism that IETF considered security after
the fact in its protocols, most older BGP features have not
considered what to do about attribute escape. Understanding now that
these are issues impacting incremental deployment of new features and
their operations, it's possible to consider including scoping
directly in new extensions.
5.3.1. AS Scoping
Many BGP features are intended to be scoped to one or more ASes. As
described above, such mechanisms can't rely on all devices in an AS
to have implemented a feature that's built using transitive Path
Attributes.
New features that are intended to be AS-Scoped SHOULD consider
including an scoping AS number, or AS number list, as part of the
attribute. BGP speakers that use such features should have as part
of their configuration a list of non-local ASes that they may wish to
trust for utilizing such new features. This can permit a single
"scope AS" to be included in the feature with a set of cooperating
providers using different ASes able to enforce the scoping of such
routes.
Implementations of such AS-Scoped features SHOULD have mechanisms
that permit filtering of the feature's Path Attributes at AS
boundaries. While the scoping-AS described above can help avoid
issues with inadvertent usage, it can't help vs. intentional
malicious exploitation where the scoping-AS is spoofed.
The BGP Wide Communities feature
([I-D.ietf-idr-wide-bgp-communities]) includes such an AS-Scoping
mechanism.
Haas Expires 5 August 2024 [Page 8]
Internet-Draft BGP Attribute Escape February 2024
5.3.2. Next Hop Scoping
Some BGP features rely on their semantics based on when the next hop
of the route has been changed. In circumstances where the feature is
only correct at such boundaries, embedding the "last set next hop"
can be used to detect when a Path Attribute has propagated past a
device that has reset the next hop without the associated change to
the feature.
New features that are intended to next hop scope SHOULD consider
including the next hop that was last present when the feature is
being used.
An example of this methodology is the BGP Router Capabilities
Attribute [I-D.ietf-idr-entropy-label].
5.3.3. Changes to the BGP protocol
More general changes to the BGP protocol could be considered to try
to standardize some of these behaviors. One such approach has been
documented, but not deployed in "Constrain Attribute announcement
within BGP" [I-D.ietf-idr-bgp-attribute-announcement].
Similar approaches to this, or more protocol generalized forms of the
other advice above, might be beneficial inputs if the core BGP
specification is ever revised.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
This document highlights properties of the BGP protocol and
situations where its defined behavior for propagating Path Attributes
may lead to inadvertent disclosure of information, improper routing,
or even session resets and crashes. Such behaviors can be
maliciously exploited.
8. References
8.1. Normative References
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Haas Expires 5 August 2024 [Page 9]
Internet-Draft BGP Attribute Escape February 2024
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
8.2. Informative References
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<https://www.rfc-editor.org/info/rfc1997>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065,
DOI 10.17487/RFC5065, August 2007,
<https://www.rfc-editor.org/info/rfc5065>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions",
RFC 5706, DOI 10.17487/RFC5706, November 2009,
<https://www.rfc-editor.org/info/rfc5706>.
Haas Expires 5 August 2024 [Page 10]
Internet-Draft BGP Attribute Escape February 2024
[RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T.
Yamagata, "Internal BGP as the Provider/Customer Edge
Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 6368, DOI 10.17487/RFC6368, September 2011,
<https://www.rfc-editor.org/info/rfc6368>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro,
"The Accumulated IGP Metric Attribute for BGP", RFC 7311,
DOI 10.17487/RFC7311, August 2014,
<https://www.rfc-editor.org/info/rfc7311>.
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
February 2015, <https://www.rfc-editor.org/info/rfc7454>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G.
Hankins, "BLACKHOLE Community", RFC 7999,
DOI 10.17487/RFC7999, October 2016,
<https://www.rfc-editor.org/info/rfc7999>.
[RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,
I., and N. Hilliard, "BGP Large Communities Attribute",
RFC 8092, DOI 10.17487/RFC8092, February 2017,
<https://www.rfc-editor.org/info/rfc8092>.
[RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah,
A., and H. Gredler, "Segment Routing Prefix Segment
Identifier Extensions for BGP", RFC 8669,
DOI 10.17487/RFC8669, December 2019,
<https://www.rfc-editor.org/info/rfc8669>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
Haas Expires 5 August 2024 [Page 11]
Internet-Draft BGP Attribute Escape February 2024
[RFC9234] Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K.
Sriram, "Route Leak Prevention and Detection Using Roles
in UPDATE and OPEN Messages", RFC 9234,
DOI 10.17487/RFC9234, May 2022,
<https://www.rfc-editor.org/info/rfc9234>.
[I-D.ietf-idr-bgp-attribute-announcement]
Patel, K., Uttaro, J., Decraene, B., Henderickx, W., and
J. Haas, "Constrain Attribute announcement within BGP",
Work in Progress, Internet-Draft, draft-ietf-idr-bgp-
attribute-announcement-03, 12 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
attribute-announcement-03>.
[I-D.ietf-idr-entropy-label]
Decraene, B., Scudder, J., Henderickx, W., Kompella, K.,
Mohanty, M., Uttaro, J., and B. Wen, "BGP Next Hop
Dependent Capabilities Attribute", Work in Progress,
Internet-Draft, draft-ietf-idr-entropy-label-13, 9 October
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
idr-entropy-label-13>.
[I-D.ietf-idr-wide-bgp-communities]
Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S.,
and P. Jakma, "BGP Community Container Attribute", Work in
Progress, Internet-Draft, draft-ietf-idr-wide-bgp-
communities-11, 9 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
wide-bgp-communities-11>.
Acknowledgements
Thanks to Greg Skinner for suggested edits on the document.
Contributors
TBD
Author's Address
Jeffrey Haas
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: jhaas@juniper.net
Haas Expires 5 August 2024 [Page 12]
