draft-ietf-opsec-infrastructure-security-00.txt   draft-ietf-opsec-infrastructure-security-01.txt 
Opsec Working Group J. Gill Opsec Working Group J. Gill
Internet-Draft Verizon Business Internet-Draft Verizon Business
Intended status: Informational D. Lewis Intended status: Best Current D. Lewis
Expires: March 4, 2007 P. Quinn Practice P. Quinn
Cisco Systems Inc. Expires: October 8, 2007 Cisco Systems Inc.
P. Schoenmaker P. Schoenmaker
NTT America NTT America
August 31, 2006 April 6, 2007
Service Provider Infrastructure Security Service Provider Infrastructure Security
draft-ietf-opsec-infrastructure-security-00 draft-ietf-opsec-infrastructure-security-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 4, 2007. This Internet-Draft will expire on October 8, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This RFC describes best current practices for implementing Service This RFC describes best current practices for implementing Service
Provider network infrastructure protection for network elements. Provider network infrastructure protection for network elements.
This RFC complements and extends RFC 2267 and RFC 3704. RFC 2267 This RFC complements and extends RFC 2267 and RFC 3704. RFC 2267
provides guidelines for filtering traffic on the ingress to service provides guidelines for filtering traffic on the ingress to service
provider networks. RFC 3704 expands the recommendations described in provider networks. RFC 3704 expands the recommendations described in
RFC 2267 to address operational filtering guidelines for single and RFC 2267 to address operational filtering guidelines for single and
multi-homed environments. The focus of those RFCs is on filtering multi-homed environments. The focus of those RFCs is on filtering
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Requirements Language Requirements Language
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 this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Infrastructure Protection Techniques . . . . . . . 5 2. Overview of Infrastructure Protection Techniques . . . . . . . 4
2.1. Edge Remarking . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Edge Remarking . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Device and Element Protection . . . . . . . . . . . . . . 5 2.2. Device and Element Protection . . . . . . . . . . . . . . 5
2.3. Infrastructure Hiding . . . . . . . . . . . . . . . . . . 5 2.3. Infrastructure Hiding . . . . . . . . . . . . . . . . . . 5
3. Edge Infrastructure Access Control Lists . . . . . . . . . . . 6 3. Edge Infrastructure Access Control Lists . . . . . . . . . . . 5
3.1. Constructing the Access List . . . . . . . . . . . . . . . 6 3.1. Constructing the Access List . . . . . . . . . . . . . . . 5
3.2. Other Traffic . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Other Traffic . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Edge Infrastructure Conclusion . . . . . . . . . . . . . . 7 3.3. Edge Infrastructure Conclusion . . . . . . . . . . . . . . 6
4. Edge Rewrite/Remarking . . . . . . . . . . . . . . . . . . . . 7 4. Edge Rewrite/Remarking . . . . . . . . . . . . . . . . . . . . 7
4.1. Edge Rewrite/Remarking Discussion . . . . . . . . . . . . 7 4.1. Edge Rewrite/Remarking Discussion . . . . . . . . . . . . 7
4.2. Edge Rewriting/Remarking Performance Considerations . . . 8 4.2. Edge Rewriting/Remarking Performance Considerations . . . 8
5. Device/Element Protection . . . . . . . . . . . . . . . . . . 8 5. Device/Element Protection . . . . . . . . . . . . . . . . . . 8
5.1. Service Specific Access Control . . . . . . . . . . . . . 8 5.1. Service Specific Access Control . . . . . . . . . . . . . 8
5.1.1. Common Services . . . . . . . . . . . . . . . . . . . 9 5.1.1. Common Services . . . . . . . . . . . . . . . . . . . 8
5.2. Aggregate Device Access Control . . . . . . . . . . . . . 9 5.2. Aggregate Device Access Control . . . . . . . . . . . . . 9
5.2.1. IP Fragments . . . . . . . . . . . . . . . . . . . . . 9 5.2.1. IP Fragments . . . . . . . . . . . . . . . . . . . . . 9
5.2.2. Performance Considerations . . . . . . . . . . . . . . 9 5.2.2. Performance Considerations . . . . . . . . . . . . . . 9
5.2.3. Access Control Implementation Guide . . . . . . . . . 9 5.2.3. Access Control Implementation Guide . . . . . . . . . 9
5.3. Device Access Authorization and Accounting . . . . . . . . 10 5.3. Device Access Authorization and Accounting . . . . . . . . 10
6. Infrastructure Hiding . . . . . . . . . . . . . . . . . . . . 10 6. Infrastructure Hiding . . . . . . . . . . . . . . . . . . . . 10
6.1. Use Less IP . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Use Less IP . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. MPLS Techniques . . . . . . . . . . . . . . . . . . . . . 10 6.2. MPLS Techniques . . . . . . . . . . . . . . . . . . . . . 10
6.3. IGP Configuration . . . . . . . . . . . . . . . . . . . . 11 6.3. IGP Configuration . . . . . . . . . . . . . . . . . . . . 11
6.4. Route Advertisement Control . . . . . . . . . . . . . . . 11 6.4. Route Advertisement Control . . . . . . . . . . . . . . . 11
6.4.1. Route Announcement Filtering . . . . . . . . . . . . . 11 6.4.1. Route Announcement Filtering . . . . . . . . . . . . . 11
6.4.2. Address Core Out of RFC 1918 Space . . . . . . . . . . 11 6.4.2. Address Core Out of RFC 1918 Space . . . . . . . . . . 11
6.5. Further obfuscation . . . . . . . . . . . . . . . . . . . 12 6.5. Further obfuscation . . . . . . . . . . . . . . . . . . . 12
7. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Use LIPv6 Edge Infrastructure Access Control Lists . . . . 12 7.1. Use IPv6 Edge Infrastructure Access Control Lists . . . . 13
7.2. IPv6 Edge Remarking . . . . . . . . . . . . . . . . . . . 12 7.2. IPv6 Infrastructure Hiding . . . . . . . . . . . . . . . . 13
7.3. IPv6 Device and Element Protection . . . . . . . . . . . . 13
7.4. IPv6 Infrastructure Hiding . . . . . . . . . . . . . . . . 13
8. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Multicast Group Protection . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8.2. Performance Considerations . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8.3. IPv6 and Multicast . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
This RFC describes best current practices for implementing Service This RFC describes best current practices for implementing Service
Provider network infrastructure protection for network elements. RFC Provider network infrastructure protection. This document both
2267 and RFC 3704 focuses on limiting the effects of denial of
service attacks by filtering ingress packets with spoofed source
addresses. This offers additional benefits by ensuring that packets
coming into a network originate from validly allocated and consistent
sources. RFC 3704 extends the recommendations described in RFC 2267
to address operational filtering guidelines for single and multi-
homed environments. In both cases (RFC 2267 and RFC 3704), the focus
is on dropping packets on ingress, regardless of destination, if
those packets are have a spoofed source address or if the source of
the packet falls within "reserved" address space. This document both
refines and extends the filtering best practices outlined in RFC 2267 refines and extends the filtering best practices outlined in RFC 2267
and RFC 3704 and focuses only on traffic destined to the network [RFC2267] and RFC 3704 [RFC3704] and focuses only on traffic destined
infrastructure itself to protect the service provider network from to the network infrastructure itself to protect the service provider
denial of service and other attacks. This document presents network from denial of service and other attacks. This document
techniques that, together with network edge ingress filtering and RFC presents techniques that, together with network edge ingress
2267 and RFC 3704, provides a defense in depth approach for filtering and RFC 2267 [RFC2267] and RFC 3704 [RFC3704], provides a
infrastructure protection. Denial of Service (DoS) attacks are defense in depth approach for infrastructure protection.
common and the network infrastructure itself is a target.
Attacks targeting the network infrastructure can take many forms, Attacks targeting the network infrastructure can take many forms,
including bandwidth saturation to crafted packets destined to a including bandwidth saturation to crafted packets destined to a
router. These attacks might use spoofed source addresses or they router. These attacks might use spoofed or non spoofed source
might use the true source address of of the traffic. Regardless of addresses. Regardless of the nature of the attack, the network
the nature of the attack, the network infrastructure must be infrastructure must be protected from both accidental floods and
protected from both accidental floods and intentional attacks. intentional attacks. Additionally, this protection will assist in
Additionally, this protection will assist in preventing the network preventing the network elements from being used as reflectors in
elements from being used as reflectors in attacks against others. attacks against others.
The techniques outlined in this document and described in section 2 The techniques outlined in this document and described in section 2
below, describe best practices for infrastructure protection: edge below, describe best practices for infrastructure protection: edge
policy (filtering and precedence), per device traffic policy policy (filtering and precedence), per device traffic policy
enforcement for packets destined to a device and, limiting of address enforcement for packets destined to a device and, limiting of address
and routing visibility to reduce exposure to limit core network -- and routing visibility to reduce exposure to limit core network --
that is provider (P) and provider edge (PE) infrastructure -- that is provider (P) and provider edge (PE) infrastructure --
attacks. This document is targeted at network operators seeking to attacks. This document is targeted at network operators seeking to
limit their exposure to risks associated with denial of service limit their exposure to risks associated with denial of service
targeting the infrastructure. These techniques are designed to be targeting the infrastructure. These techniques are designed to be
skipping to change at page 5, line 8 skipping to change at page 4, line 46
features implemented in network devices. features implemented in network devices.
Infrastructure protection is a complex topic. While the best Infrastructure protection is a complex topic. While the best
practices outlines in this document do not provide perfect practices outlines in this document do not provide perfect
protection, they can significantly improve the protection of the protection, they can significantly improve the protection of the
network infrastructure. network infrastructure.
2. Overview of Infrastructure Protection Techniques 2. Overview of Infrastructure Protection Techniques
This section provides an overview of recommended techniques that may This section provides an overview of recommended techniques that may
be used to protect network infrastructure. The details of each area, be used to protect network infrastructure. The areas described below
along with some deployment consideration, are described in detail in are not exhaustive; other mechanisms can be used to provide
subsequent sections. The four technique describes in this document additional protection. The techniques discussed in this document
are: - Edge Infrastructure Access Control List - Edge Remarking - have been widely deployed and have proven operational security
Device and Element Protection - Infrastructure Hiding The above list benefits in large networks.
is not exhaustive; other mechanisms can be used to provide additional
protection. The techniques discussed in this document have been
widely deployment and have proven operational security benefits in
large networks.
2.1. Edge Remarking 2.1. Edge Remarking
Edge Remarking, detailed in section 4, ensures that ingress IP Edge Remarking, detailed in section 4, ensures that ingress IP
precedence or DSCP values match expected values within the context of precedence or DSCP values match expected values within the context of
security. This provides another layer of defense, particularly for security. This provides another layer of defense, particularly for
traffic permitted through any of the Edge Infrastructure Access traffic permitted through any of the Edge Infrastructure Access
Control Lists. This document focuses only on using Edge Remarking Control Lists. This document focuses only on using Edge Remarking
best practices to enforce security policies. best practices to enforce security policies.
2.2. Device and Element Protection 2.2. Device and Element Protection
Each network infrastructure device should enforce local rules for Each network infrastructure device should enforce local rules for
traffic destined to the device itself. These rules can take the form traffic destined to itself. These rules can take the form of filters
of filters (permit/deny) or rate limiting rules that allow ingress (permit/deny) or rate limiting rules that allow ingress traffic at
traffic at specified rates. These should complement any existing specified rates. These should complement any existing Edge
Edge Infrastructure Access Control Lists and are described in more Infrastructure Access Control Lists and are described in more detail
detail in section 5. The deployment of these local device protection in section 5. The deployment of these local device protection rules
rules complements the edge techniques by protecting the device from complements the edge techniques by protecting the device from traffic
traffic that: i) was permitted but violates device policy, ii) could that: i) was permitted but violates device policy, ii) could not be
not be filtered at the edge, iii) entered the network on an interface filtered at the edge, iii) entered the network on an interface that
that did not have ingress filtering enabled. did not have ingress filtering enabled.
2.3. Infrastructure Hiding 2.3. Infrastructure Hiding
Hiding the infrastructure of the network provides an elegant Hiding the infrastructure of the network provides an elegant
mechanism for protecting the network infrastructure. If the mechanism for protecting the network infrastructure. If the
destination of an attack is to an infrastructure address that is destination of an attack is to an infrastructure address that is
unreachable, attacks become far more difficult. Infrastructure unreachable, attacks become far more difficult. Infrastructure
hiding can be achieved in several ways: - MPLS techniques - IGP hiding can be achieved in several ways: i) MPLS techniques ii) IGP
configuration - Route advertisement control Section 6 covers configuration iii) Route advertisement control. Section 6 addresses
infrastructure hiding techniques. these infrastructure hiding techniques in detail.
3. Edge Infrastructure Access Control Lists 3. Edge Infrastructure Access Control Lists
Edge Infrastructure Access Control Lists (EIACLs) are a specific Edge Infrastructure Access Control Lists (EIACLs) are a specific
implementation of the more general Ingress Access List. As opposed implementation of the more general Ingress Access List. As opposed
to generic ingress filtering which denies data (sometimes referred to to generic ingress filtering which denies data (sometimes referred to
as user) plane traffic, edge infrastructure access control lists do as user) plane traffic, edge infrastructure access control lists do
not attempt to deny transit traffic; rather, this form of access not attempt to deny transit traffic; rather, this form of access
control limits traffic destined to infrastructureequipment while control limits traffic destined to infrastructureequipment while
permitting -- if needed, explicitly -- traffic through the network. permitting -- if needed, explicitly -- traffic through the network.
3.1. Constructing the Access List 3.1. Constructing the Access List
Edge Infrastructure Access Control Lists permit only required traffic Edge Infrastructure Access Control Lists permit only required traffic
destined to the network infrastructure, while allowing data plane destined to the network infrastructure, while allowing data plane
traffic to flow through unfiltered. The basic premise of EIACLs is traffic to flow through unfiltered. The basic premise of EIACLs is
that only a relatively limited subset of traffic, sourced from that only a relatively limited subset of traffic sourced from outside
outside an AS, needs to be destined towards a core router and that by an AS should be allowed to transit towards a core router and that by
explicitly permitting only that known and understood traffic, the explicitly permitting only that known and understood traffic the core
core devices are not subjected to unnecessary traffic that might devices are not subjected to unnecessary traffic that might result in
result in a denial of service. Since edge infrastructure access a denial of service. Since edge infrastructure access control lists
control lists protect only the infrastructure, the development of the protect only the infrastructure, the development of the list differs
list differs somewhat from "traditional" access filter lists: somewhat from "traditional" access filter lists:
1. Review addressing scheme, and identify address block(s) that 1. Review addressing scheme, and identify address block(s) that
represent core devices. represent core devices.
2. Determine what traffic must be destined to the core devices from 2. Determine what traffic must be destined to the core devices from
outside the AS. outside the AS.
3. Create a filter that allow the required traffic, denies all 3. Create a filter that allows the required traffic, denies all
traffic destined to the core address block and then finally, traffic destined to the core address block and then finally,
permits all other traffic. permits all other traffic.
4. Optionally, prior to implementing the deny action for all traffic
destined to the core address block, a log action may be used and
the results of the deny actions evaluated.
As with other ingress filtering techniques, EIACLs are applied on As with other ingress filtering techniques, EIACLs are applied on
ingress interfaces, as close to the edge as possible. Comprehensive ingress interfaces, as close to the edge as possible. Comprehensive
coverage (i.e. on as many interface as possible) yields the most coverage (i.e. on as many interfaces as possible) yields the most
protection. protection.
3.2. Other Traffic 3.2. Other Traffic
In addition to the explicitly permitted traffic, EIACLs can be In addition to the explicitly permitted traffic, EIACLs can be
combined with other common edge filters such as: 1. Source spoof combined with other common edge filters such as: 1. Source spoof
prevention (as per RFC 3704) by denying internal AS addresses as prevention (as per RFC 3704 [RFC3704]) by denying internal AS
external sources. 2. Filtering of reserved addresses (e.g. rfc1918 addresses as external sources. 2. Filtering of reserved addresses
addresses) as traffic should not be sourced from reserved address. 3. (e.g. RFC 1918 [RFC1918] addresses) since traffic should not be
Other unneeded or unnecessary traffic Filtering this traffic can be sourced from reserved address. 3. Other unneeded or unnecessary
part of the list explicitly or implicitly; explicit filters often traffic. Filtering this traffic can be part of the list explicitly
provide log-able information that can be of use during a security or implicitly; explicit filters often provide log-able information
event. that can be of use during a security audit.
3.3. Edge Infrastructure Conclusion 3.3. Edge Infrastructure Conclusion
Edge Infrastructure Access Control Lists provide a very effective Edge Infrastructure Access Control Lists provide a very effective
first line of defense. EIACLs are not perfect and cannot protect the first line of defense. EIACLs are not perfect and cannot protect the
network against every attack. Furthermore, to be manageable, EIACLs network against every attack. Furthermore, to be manageable, EIACLs
must be able to clearly and simply identify infrastructure address must be able to clearly and simply identify infrastructure address
space. To be effective, the EIACLs should be deployed as widely as space. To be effective, the EIACLs should be deployed as widely as
possible at the edge of the network on devices that support the possible at the edge of the network on devices that support the
required filtering performance characteristics. required filtering performance characteristics.
The potential impact on the device's performance must be taken into
consideration when deploying EIACLs.
4. Edge Rewrite/Remarking 4. Edge Rewrite/Remarking
RFC 1812 section 5.3 defines the use of IP Preference in IPv4 packets Typically edge packet rewrite/remarking deals primarily with traffic
for routing, management and control traffic. In addition, the RFC passing through a device. However, IP Precedence/DSCP values are
recommends that devices use a mechanism for providing preferential used in prioritizing traffic sent to the devices as well. RFC 1812
forwarding for packets marked as routing, management or control [RFC1812] section 5.3 defines the use of IP Precedence in IPv4
traffic using IP Preference bits 6 or 7 (110 or 111 in binary.) packets for routing, management and control traffic. In addition,
RFC2474 defines DSCP and the compatibility of IP Preference bits when the RFC [RFC1812] recommends that devices use a mechanism for
using DSCP. All packets received by customer- and peer-facing providing preferential forwarding for packets marked as routing,
Provider Edge (PE) router interfaces with IP Preference values of 6 management or control traffic using IP Preference bits 6 or 7 (110 or
or 7 or DSCP bits of 11xxxx, as specified in RFC2474 Differentiated 111 in binary). RFC 2474 [RFC2474] defines DSCP and the
Services Field Definition, should have the IP Preference bits compatibility of IP Preference bits when using DSCP.
rewritten. Routing traffic received from customer- and peer-facing
interfaces can safely have the IP Preference bits rewritten because All packets received by customer- and peer-facing Provider Edge (PE)
only a limited number of protocols are transmitted beyond the first router interfaces with IP Preference values of 6 or 7 or DSCP bits of
PE router. The bits may be rewritten to any value other than IP 11xxxx, as specified in RFC2474 [RFC2474] Differentiated Services
Field Definition, should have the IP Preference bits rewritten.
Routing traffic received from customer- and peer-facing interfaces
can safely have the IP Preference bits rewritten because only a
limited number of protocols are transmitted beyond the first PE
router. The bits may be rewritten to any value other than IP
Preference values 6 or 7, or any DSCP value other than 11xxxx. The Preference values 6 or 7, or any DSCP value other than 11xxxx. The
new value can be based on the network operators IP Preference or DSCP new value can be based on the network operators IP Preference or DSCP
policy. If no policy exists the bits should be rewritten to 0. policy. If no policy exists the bits should be rewritten to 0. In
cases where control, management, and routing traffic enters the
In cases where control, management, and routing traffic enters the provider network via the customer and peer facing interfaces policy
provider network via the customer- and peer-facing interfaces policy
should be employed to ensure proper prioritization of critical should be employed to ensure proper prioritization of critical
traffic. EIACLs maybe be used facilitate the proper classification traffic. EIACLs maybe be used facilitate the proper classification
of traffic. To offer fully transparent service, a provider may not of traffic. To offer fully transparent service, a provider may not
wish to modify the IP precedence on transit traffic through the wish to modify the IP precedence on transit traffic through the
network. If a provider has alternate means of applying different network. If a provider has alternate means of applying different
prioritization to router management and control traffic and transit prioritization to router management and control traffic and transit
traffic then rewriting IP precedence bits is not required. traffic then rewriting IP precedence bits is not required.
4.1. Edge Rewrite/Remarking Discussion 4.1. Edge Rewrite/Remarking Discussion
By default router vendors do not differentiate an interface on a PE By default router vendors do not differentiate an interface on a PE
router connected to a P router from an interface connected to a CE router connected to a P router from an interface connected to a CE
router. As a result any packet with the proper IP Preference or DSCP router. As a result any packet with the proper IP Preference or DSCP
bits set may receive the same preferential forwarding behavior as bits set may receive the same preferential forwarding behavior as
legitimate routing, management, and control traffic. A malicious legitimate routing, management, and control traffic. A malicious
attack may be able to take advantage of the vulnerability to increase attack may be able to take advantage of the vulnerability to increase
the effectiveness of the attack or to attack the routing, management, the effectiveness of the attack or to attack the routing, management,
and/or control traffic directly. This document is aimed at and/or control traffic directly. The forwarding prioritization given
protecting network infrastructure from traffic to the device rather to routing, management, and control traffic by default leaves devices
than traffic through the device. Even though the edge rewrite/ vulnerable to indirect attacks to the infrastructure. By rewriting
remarking deals primarily with traffic through a device it is the IP Precedence at the PE protection is provided for both traffic
included because the traffic has a direct impact on traffic to a through the network along with traffic that is to the network that is
device. The forwarding prioritization given to routing, management, not blocked by other methods discussed in this document. This
and control traffic by default leaves devices vulnerable to indirect document assumes that all customer and peer facing interfaces cannot
attacks to the infrastructure. By rewriting the IP Precedence at the be trusted for inter- domain diff-serv. In cases where a trust
PE protection is provided for both traffic through the network along relationship exists for inter-domain diff-serv, diff-serv bits
with traffic that is to the network that is not blocked by other 1xxxxxxx do not have to be rewritten.
methods discussed in this document. This document assumes that all
customer- and peer-facing interfaces cannot be trusted for inter-
domain diff-serv. In cases where a trust relationship exists for
inter-domain diff-serv, diff-serv bits 1xxxxxxx do not have to be
rewritten.
4.2. Edge Rewriting/Remarking Performance Considerations 4.2. Edge Rewriting/Remarking Performance Considerations
Device resources required must be taken into consideration when The potential impact on the device's performance must be taken into
rewriting/remarking IP Precedence/DSCP bits. Devices may require consideration when rewriting/remarking IP Precedence/DSCP bits.
additional resources to rewrite/remark packets. Devices may require additional resources to rewrite/remark packets
compared to merely forwarding them.
5. Device/Element Protection 5. Device/Element Protection
Even with the widest possible deployment of the techniques described Even with the widest possible deployment of the techniques described
above in the section Infrastructure Edge Access Control, the above in section 3, Infrastructure Edge Access Control, the
individual devices of the network must implement access control individual devices of the network must implement access control
mechanisms. This is required because, in addition to the case of mechanisms. In addition to the cases incomplete or imperfect
incomplete or imperfect deployment of edge infrastructure control, deployment of edge infrastructure controls, threats may come from
threats may coem from from trusted sources within the perimeter of from trusted sources within the perimeter of the network.
the network.
5.1. Service Specific Access Control 5.1. Service Specific Access Control
Typically these mechanisms are not directly concerned with protecting Many vendor's implementation of service specific controls are not
the availability of the device as a whole, but the device from made with overall system availability as a primary concern. With
exploitation via the service concerned. Analysis of the behavior of this in mind, it is recommended that these controls be used in
widly deployed serivce security features shows that maximizing the conjunction with any aggregate mechanisms to control device access as
security of the particular service, not overall system availability, well as techniques like EIACLs and Core Hiding. There are many
is the primary goal of the feature. There are many practical practical examples available of vendor specific service security
examples of vendor specific security mechanisms, the references mechanisms, the references section provides links to several of them.
section provides likes to several of them. These should guide the These should guide the operator in securing the services that they
operator in securing the services that they enable. enable.
5.1.1. Common Services 5.1.1. Common Services
While each service implemented by network equipment manufacturers While each service implemented by network equipment manufacturers
differs in its available security features there are some common differs in its available security features there are some common
services and security features for those services that have been services and security features for those services that have been
widely deployed. The most important first step for the operator is widely deployed. The most important first step for the operator is
to disable any unneeded/unused services. This reduces the devices to disable any unneeded/unused services. This reduces the device's
profile. If the device is not listening to a port, it is much more profile. If the device is not listening to a port, it is much more
difficult to attack via that port. Second, the operator should difficult to attack via that port. Second, the operator should
utilize the services access control mechanisms to limit the access to utilize the services access control mechanisms to limit the access to
the devices service to only required sources. Examples of per serive the devices service to only required sources. Examples of per
security are using virtual terminal access control lists, or SNMP service security are using virtual terminal access control lists, or
Community access control lists. SNMP Community access control lists.
5.2. Aggregate Device Access Control 5.2. Aggregate Device Access Control
The device must be protected from denial of service threats, in Aggregating the security policy -- as opposed to defining it on a per
addition, aggregating the security policy -- as opposed to defining service basis -- allows for a simplified view of the access policies
it on a per service basis -- allows for a simplified view of the traffic going to the device. Many vendors leverage this simplified
access policies traffic going to the device. A key requirement of view to allow for the policy to be implemented in hardware,
these mechanisms is that it must not impact transit data plane protecting the device's control plane. A key requirement of these
traffic. mechanisms is that it must not impact transit data plane traffic.
5.2.1. IP Fragments 5.2.1. IP Fragments
Traffic destined to a router is not typically fragmented. Use of Traffic destined to a router is not typically fragmented. Use of
mechanisms to deny fragments to the device are recommended. mechanisms to deny fragments to the device are recommended.
5.2.2. Performance Considerations 5.2.2. Performance Considerations
Care should be taken to understand a vendors implementation of Care should be taken to understand a vendors implementation of
aggregate device access control and to make sure that device aggregate device access control and to make sure that device
skipping to change at page 10, line 19 skipping to change at page 10, line 14
5.3. Device Access Authorization and Accounting 5.3. Device Access Authorization and Accounting
Operators should use per command authorization and accounting Operators should use per command authorization and accounting
wherever possible. Aside from their utility in mitigating other wherever possible. Aside from their utility in mitigating other
security threats, they provide an invaluable tool in the post event security threats, they provide an invaluable tool in the post event
forensics. forensics.
6. Infrastructure Hiding 6. Infrastructure Hiding
While core equipment is in the transit path it is necessarily Hiding the infrastructure of the network provides one layer of
reachable and succeptible to attacks that fall beyond the scope of protection to the devices that make up the network core. By hiding
this document. Primarily, transit equipment is always at risk for those devices (making them unreachable) successful execution of
collateral damage when hosts downstream come under substantial denial of service attacks becomes far more difficult. Before
attack. Hiding the infrastructure of the network provides an elegant implementing measures to make network infrastructure unreachable from
mechanism for protecting the network infrastructure. If the an outside consider carefully that these actions can create limitations
attack vector requires that packets are sent to infrastructure that staff, customers, and applications may not expect and weigh
address that is unreachable, successful execution of such attacks these results against the additional security afforded by a hiding
becomes far more difficult. The following sections present different the network core. The following sections present different options
options for accomplishing infrastructure hiding. for accomplishing infrastructure hiding. The operator should
carefully consider the merits of each approach based on their
network's architecture.
6.1. Use Less IP 6.1. Use Less IP
One way to reduce exposure of network infrastructure is to use One way to reduce exposure of network infrastructure is to use
unnumbered links wherever possible. This is particularly useful for unnumbered links wherever possible. This is particularly useful in
customers in the simple case of a single provider with a default path the simple case of a customer with single link used as their default
to the Internet. Not only can such a configuration reduce the path to the Internet. Not only can such a configuration reduce the
exposure of the equipment on both ends of the link to malicious exposure of the equipment on both ends of the link to malicious
attack, the overall effort required to manage a link can be reduced attack, the overall effort required to manage a link can be reduced
considerably with a simplified configuration and without the considerably with a simplified configuration and without the
additional overhead and expense of managing the addresses. additional overhead and expense of managing the IP addresses.
6.2. MPLS Techniques 6.2. MPLS Techniques
While it may not be feasible to hide the entire infrastructure of While it may not be feasible to hide the entire infrastructure of
large networks from edge to edge using MPLS, it is certainly possible large networks, it is certainly possible to reduce exposure of
to reduce exposure of critical core infrastructure beyond the first critical core infrastructure by hiding the existence and complexity
hop by creating an MPLS mesh where TTL is not decremented as packets of that infrastructure using an MPLS mesh where TTL is not
pass through it. In this manner the number, addresses, and even decremented as packets pass through it as described in RFC 3443
existence of intermediary devices can be hidden from traffic as it [RFC3443]. In this manner the number, addresses, and even existence
passes through the core. of intermediary devices can be hidden from traffic as it passes
through the core. As pointed out by RFC 4381 [RFC4381], not only can
this method hide the structure, it simplifies access restrictions to
core devices. e.g. Core equipment addresses are inaccessible from
the "Public Internet" VPN. The fact that this technique is
transparent from a layer-3 viewpoint recommends it to providers of
public services. Because basic external troubleshooting and presents
to all external views a simplified network structure with few
potential target addresses exposed it offers a better balance of
security against effort than most techniques for public networks.
6.3. IGP Configuration 6.3. IGP Configuration
Using a non-IP control plane for the core routing protocol can Using a non-IP control plane for the core routing protocol can
substantially reduce the number of IP addresses that comprise (and substantially reduce the number of IP addresses that comprise (and
therefore, expose) the core. This simplifies the task of maintaining therefore, expose) the core. This simplifies the task of maintaining
edge ACLs or route announcement filters. IS-IS is an elegant and edge ACLs or route announcement filters. IS-IS is an elegant and
mature protocol that may be suitable for this task. mature protocol that some operators have found suitable for this
task.
6.4. Route Advertisement Control 6.4. Route Advertisement Control
6.4.1. Route Announcement Filtering 6.4.1. Route Announcement Filtering
Inasmuch as it is unavoidable that some network elements must be Inasmuch as it is unavoidable that some network elements must be
configured with IP addresses, it may be possible to assign these configured with IP addresses, it may be possible to assign these
address out of netblocks for which the routing advertisement can be address out of netblocks for which the routing advertisement can be
filtered out, thereby limiting possible sources of traffic to core filtered out, thereby limiting possible sources of traffic to core
netblocks down to customers for whom you provide a default route, or netblocks down to customers for whom you provide a default route, or
direct peers who would make the effort to create a static route for direct peers who would make the effort to create a static route for
your core netblock into your AS. By assigining address for network your core netblock into your AS. By assigining address for network
infrastructure out of a limited number of address blocks which are infrastructure out of a limited number of address blocks which are
well known to internal network administrators, the operator can well known to internal network administrators, the operator can
greatly simplify ACL configuration. This can also minimise the greatly simplify EIACL configuration. This can also minimise the
frequency with which ACLs need to be updated based on changes in the frequency with which ACLs need to be updated based on changes in the
network. This can also have performance implications, especially for network. This can also have performance implications, especially for
equipment where the length of ACLs is limited. By keeping ACLs short equipment where the length of ACLs is limited. By keeping ACLs short
they may be deployable on a wider range of existing equipment. they may be deployable on a wider range of existing equipment.
Further, it may be possible in those situations where customer point- Further, it may be possible in those situations where customer point-
to-point links must be numbered, to address such links out of another to-point links must be numbered, to address such links out of another
range of addresses for which announcements could be similarly range of addresses for which announcements could be similarly
filtered. While this has implications for a customer's ability to filtered. While this has implications for a customer's ability to
remote-monitor their circuit, this can often be overcome with remote-monitor their circuit, this can often be overcome with
application of an address from the customer's routed space to the CPE application of an address from the customer's routed space to the CPE
loopback. loopback.
6.4.2. Address Core Out of RFC 1918 Space 6.4.2. Address Core Out of RFC 1918 Space
In addition to filtering the visibility of core addresses to the In addition to filtering the visibility of core addresses to the
wider Internet, it may be possible to use rfc1918 netblocks for wider Internet, it may be possible to use private RFC 1918 [RFC1918]
numbering infrastructure when IP addresses are required (eg, netblocks for numbering infrastructure when IP addresses are required
loopbacks). This added level of obscurity takes prevention of wide (eg, loopbacks). This added level of obscurity takes prevention of
distribution of your infrastructure address space one step further. wide distribution of your infrastructure address space one step
Many networks filter out packets with rfc1918 address at ingress/ further. Many networks filter out packets with RFC 1918 [RFC1918]
egress points as a matter of course. In this circumstance, tools address at ingress/ egress points as a matter of course. In this
such as traceroute can work through your core, but reverse- circumstance, tools such as traceroute can work for operations and
resolution of descriptive names should be restricted to queries from support staff but not from outside networks. Care should be taken to
internal/support groups. limit reverse-resolution of descriptive DNS names to queries from
internal/support groups. The fact that this technique can break
simple troubleshooting tools such as traceroute may frustrate
customers who expect to be able to perform basic troubleshooting
tasks on their own. Campus or corporate networks may find some
advantage to this configuration, on balance. Use caution when
employing this technique, particularly in public internet service
provider environments.
6.5. Further obfuscation 6.5. Further obfuscation
The strategy of changing services to run on ports different from the The strategy of changing services to run on ports different from the
default and well-known ones will not protect you from a determined default and well-known ones will not protect you from a determined
attacker. It can, however, provide some level of protection from attacker. It can, however, provide some level of protection from
many attack tools, worms, auto-rooters, etc. Should they find access many attack tools, worms, auto-rooters, etc. Should they find access
to the infrastructure equipment in some way. Again, this does to the infrastructure equipment in some way. Again, this does
nothing to restrict access, nor to make network devices more nothing to restrict access, nor to make network devices more
difficult to reach. As with the other methods, a careful difficult to reach. As with the other methods, a careful
skipping to change at page 12, line 26 skipping to change at page 12, line 37
the necessity of that protection in light of all measures taken to the necessity of that protection in light of all measures taken to
protect a network. protect a network.
7. IPv6 7. IPv6
IPv6 Networks contain the same infrastructure security risks as IPv4. IPv6 Networks contain the same infrastructure security risks as IPv4.
All techniques described in this document for IPv4 should be directly All techniques described in this document for IPv4 should be directly
applicable to IPv6 networks. Limitations exist where devices do not applicable to IPv6 networks. Limitations exist where devices do not
have feature parity between IPv4 and IPv6. Different techniques have feature parity between IPv4 and IPv6. Different techniques
maybe required where IPv4 and IPv6 networks deviate in maybe required where IPv4 and IPv6 networks deviate in
implementation. Multi-vendor networks create greater difficulties implementation. Multi-vendor networks can create greater
when each vendor does not have feature parity with each other. difficulties when each vendor does not have feature parity with each
Hardware differences in devices that support both IPv4 and IPv6 must other. Hardware differences in devices that support both IPv4 and
also be taken into consideration. Because IPv6 uses a longer address IPv6 must also be taken into consideration. Because IPv6 uses a
space the scaling, and performance characteristics of ACLs maybe longer address space the scaling, and performance characteristics of
lower for IPv6 vs IPv4. The fields or number of fields that an ACL ACLs maybe lower for IPv6 vs IPv4. The fields or number of fields
can match on may also differ. The fact that all PE devices do not that an ACL can match on may also differ. The fact that all PE
support all the recommended ipv6 security features should not devices do not support all the recommended IPv6 security features
preclude the implementation of the recommendations in this document should not preclude the implementation of the recommendations in this
on the devices that do support the security features. With the document on the devices that do support the security features. With
number of Network Operators deploying IPv6 growing, along with the the number of Network Operators deploying IPv6 growing, along with
continued availability of IPv6 Tunnel services, connecting to the the continued availability of IPv6 Tunnel services, connecting to the
IPv6 internet is less difficult. Dual stack IPv6 networks run on IPv6 Internet is less difficult. Dual stack IPv6 networks run on
10Gbps and greater backbones with edge speeds equal to IPv4. Neither Networks with speeds equal to IPv4. Neither the edge nor the core
the edge nor the core limit potential IPv6 attacks. limit potential IPv6 attacks. Despite the increased deployment of
IPv6 it still does not have the same level of operational experience
7.1. Use LIPv6 Edge Infrastructure Access Control Lists as IPv4.
The same process should be used for constructing the IPv6 eiacl as
the IPv4 EIACL.
7.2. IPv6 Edge Remarking
IPv6 DSCP bits should be rewritten in the same manner that IPv4 DSCP
bits. Differences between DSCP rewriting of IPv4 and IPv6 will
minimal except in cases where the device capabilities differ between
IPv4 and IPv6.
7.3. IPv6 Device and Element Protection 7.1. Use IPv6 Edge Infrastructure Access Control Lists
Device and Element protection should be created using the same IPv6 Infrastructure security policy will be similar to the IPv4
methods described in this document for IPv4. The policy may differ policy for EIACLs, Edge remarking and Device and Element protection.
for IPv6 from IPv4 in cases where services are exclusively IPv4 or Construction of the IPv6 EIACL should use the same process as the
exclusively IPv6. Services not used with IPv6 should be disabled. IPv4 EIACL. The construction of the EIACL can be made less difficult
with IPv6 because of the sparse address assignment capability given
the larger total address space. IPv6 DSCP bits should be rewritten
in the same manner that IPv4 DSCP bits. Differences between DSCP
rewriting of IPv4 and IPv6 will minimal except in cases where the
device capabilities differ between IPv4 and IPv6. Device and Element
protection should be created using the same methods described in this
document for IPv4. The policy may differ for IPv6 from IPv4 in cases
where services are exclusively IPv4 or exclusively IPv6. Services
not used with IPv6 should be disabled.
7.4. IPv6 Infrastructure Hiding 7.2. IPv6 Infrastructure Hiding
Network operators may deploy IPv4 differently from IPv6 in their Network operators may deploy IPv4 differently from IPv6 in their
network. Providers may use native forwarding for IPv6 while using network. Providers may use native forwarding for IPv6 while using
MPLS for IPv4, other combinations. IPv6 infrastructure hiding should MPLS for IPv4, other combinations. IPv6 infrastructure hiding should
have parity with IPv4 infrastructure hiding even if the technique have parity with IPv4 infrastructure hiding even if the technique
used is different. Implementation of IPv6 route advertisement used is different. Implementation of IPv6 route advertisement
control for infrastructure hiding is difficult when using global control for infrastructure hiding is difficult when using global
address space. Registeries assign fewer large blocks of IPv6 space address space. Registeries assign fewer large blocks of IPv6 space
compared to IPv4. Providers cannot control the announcement of compared to IPv4. Providers cannot control the announcement of
infrastructure global IPv6 blocks for infrastructure hiding without infrastructure global IPv6 blocks for infrastructure hiding without
deaggregating their IPv6 announcements. deaggregating their IPv6 announcements.
8. IP Multicast 8. IP Multicast
IP Multicast behaves differently from IP unicast therefore must be IP Multicast behaves differently from IP unicast therefore must be
secured in a different manner. Some of the protocols used with secured in a different manner. Some of the protocols used with
Multicast rely on IP unicast to transport the routing, and control multicast rely on IP unicast to transport the routing, and control
information. Unicast based protocols should be secured using the information. Unicast based protocols should be secured using the
technique described in much of this document. Because this document technique described in much of this document. Multicast security is
is focused on hardening a service providers infrastructure rather better addressed in a multicast specific security document.
than validating routing announcements, much of IP Multicast filtering
will be better covered in other documents. In much the same way a
host must listen on a certain IP address and port for an IP unicast
connection, Multicast must join a group in order to receive any
information via Multicast. The major difference is that multicast
groups are global and not assigned to a specific customer or end
user. Administrative boundaries and scope are created to isolate
Multicast groups within one network or desired area.
8.1. Multicast Group Protection
Certain Multicast groups should never be joined from outside an
operators network or administrative boundary. Filters should be
placed on the protocols used to communicate with external hosts and
networks. IGMP should have a join filter to prevent hosts from
joining internal groups. MSDP should be configured with a Source
Address (SA) filter to prevent other networks from joining internal
groups. EIACLs should include administratively bounded multicast
groups, along with any groups used for protocols internal to a
providers network. When constructing router Access Control as
described in section 5.2.4, multicast protocols must be taken into
consideration.
8.2. Performance Considerations 9. Security Considerations
Multicast protocols and implementation have different performance and This entire document is concerned with security.
scaling limitation than IP unicast. Multicast users create state on
the router every time the user joins a group. Router resources can
be exhausted if the amount of state created exceeds the resources
available on the router. Placing limits on the resources used by the
Multicast protocols can prevent collateral damage to services other
than Multicast on a router. MSDP should have a limit placed on the
number of SA announcements received. A fixed limit should be placed
on the number of entries the router stores in the IP Multicast
routing table. The number of SAP entries should have a limit placed
on them.
8.3. IPv6 and Multicast 10. Acknowledgements
IPv6 Multicast policy should be consistent with the IP Multicast Don Smith provided invaluable comments and suggestions. Pat Cain,
policy. Ross Callon, Vince Fuller, Barry Greene, George Jones, David Meyer,
Peka Savola reviewed this document and provided feedback.
9. Security Considerations 11. References
This entire document is concerned with security. 11.1. Normative References
10. References [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
June 1995.
10.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., Lear, E., "Address Allocation for Private Internets",
February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References [RFC2474] Nichols, K., Blake, S., Baker, F., Black, D., "Definition
of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers", December 1998.
[RFC2334] "Guidelines for Writing an IANA Considerations Section in [RFC3443] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in
RFCs", October 1998. Multi-Protocol Label Switching (MPLS) Networks",
January 2003.
[RFC3667] "IETF Rights in Contributions", February 2004. [RFC3704] Baker, F., Savola, P., "Ingress Filtering for Multihomed
Networks", March 2004.
[RFC3668] "Intellectual Property Rights in IETF Technology", [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP
Virtual Private Networks (VPNs)", February 2006.
11.2. Informative References
[AKIN] "Hardening Cisco Routers", T. Akin, O'Reilly Media,
2002, ISBN 0596001665.
[CYMRU-J] "JUNOS Secure Template", S. Gill, Team Cymru, March 2005,
http://www.cymru.com/gillsr/documents/junos-template.pdf
[CYMRU-C] "Secure IOS Template", R. Thomas, Team Cymru, March 2007,
http://www.cymru.com/Documents/secure-ios-template.html
[GREENE] "Cisco ISP Essentials", B. Greene and P. Smith,
Cisco Press, 2002, ISBN 1587050412.
[NANOG-M] "Implications of Securing Backbone Router
Infrastructure", R. McDowell, NANOG 31, May 2004.
http://www.nanog.org/mtg-0405/mcdowell.html
[RFC2334] Narten, T., and H. Alverstand, "Guidelines for Writing an
IANA Considerations Section in RFCs", October 1998.
[RFC2827] Ferguson, P., Senie, D., "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", May 2000.
[RFC3669] Bradner, S., "Intellectual Property Rights in IETF
Technology", February 2004.
[RFC3871] Jones, G., Ed., "Operational Security Requirements for
Large Internet Service Provider (ISP) IP Network
Infrastructure", September 2004.
[RFC3978] Bradner, S., Ed., "IETF Rights in Contributions",
February 2004. February 2004.
[RFC4778] Kaeo, M., "Current Operational Security Practices in
Internet Service Provider Environments", January 2007.
Authors' Addresses Authors' Addresses
James Gill James Gill
Verizon Business Verizon Business
22001 Louden County Parkway 22001 Louden County Parkway
Ashburn, VA 20147 Ashburn, VA 20147
US US
Phone: +1-703-886-3834 Phone: +1-703-886-3834
Email: james.gill@verizonbusiness.com Email: james.gill@verizonbusiness.com
skipping to change at page 16, line 7 skipping to change at page 17, line 7
New York, NY 10178 New York, NY 10178
US US
Phone: +1-202-808-2298 Phone: +1-202-808-2298
Fax: Fax:
Email: pds@ntt.net Email: pds@ntt.net
URI: URI:
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
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 Rights or other rights that might be claimed to Intellectual Property Rights 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; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 62 change blocks. 
263 lines changed or deleted 281 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/