5 October 2013
Packet Staining
Related:
NSA tracks Google ads to find Tor users:
http://news.cnet.com/8301-1009_3-57606178-83/nsa-tracks-google-ads-to-find-tor-users/
GCHQ packet staining of Tor users:
http://cryptome.org/2013/10/gchq-mullenize.pdf
http://prezi.com/p5et9yawg2c6/ip-packet-staining/
![[Image]](pict0.jpg)
![[Image]](pict5.jpg)
![[Image]](pict4.jpg)
![[Image]](pict6.jpg)
![[Image]](pict7.jpg)
![[Image]](pict8.jpg)
http://tools.ietf.org/html/draft-macaulay-6man-packet-stain-00
Versions:
00
01
6man Working Group T. Macaulay
Internet-Draft Bell Canada
Intended status: Standards Track February 14, 2012
Expires: August 17, 2012
IPv6 packet staining
draft-macaulay-6man-packet-stain-00
Abstract
This document specifies the application of security staining on an
IPv6 datagrams and the minimum requirements for IPv6 nodes staining
flows, IPv6 nodes forwarding stained packets and interpreting stains
on flows.
The usage of the packet staining destination option enables proactive
delivery of security intelligence to IPv6 nodes such as firewalls and
intrusion prevention systems, and end-points such servers,
workstations, mobile and smart devices and an infinite array of as-
yet-to-be-invented sensors and controllers.
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 http://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 August 17, 2012.
Copyright Notice
Copyright (c) 2012 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Macaulay Expires August 17, 2012 [Page 1]
Internet-Draft IPv6 Packet Staining February 2012
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Packet Staining Benefits . . . . . . . . . . . . . . . . . 4
3.2. Implementation and support models . . . . . . . . . . . . 5
3.3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements for staining IPv6 packets . . . . . . . . . . . . 6
5. Packet Stain Destination Option (PSDO) . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Macaulay Expires August 17, 2012 [Page 2]
Internet-Draft IPv6 Packet Staining February 2012
1. Introduction
From the viewpoint of the network layer, a flow is a sequence of
packets sent from a particular source to a particular unicast,
anycast, or multicast destination. From an upper layer viewpoint, a
flow could consist of all packets in one direction of a specific
transport connection or media stream. However, a flow is not
necessarily 1:1 mapped to a transport connection.
Traditionally, flow classifiers have been based on the 5-tuple of the
source and destination addresses, ports, and the transport protocol
type. However, as the growth of internetworked devices continues
under IPv6, security issues associated with the reputation of the
source of flows are becoming a critical criterion associated with the
trust of the data payloads and the security of the destination end-
points and the networks on which they reside.
The usage of security reputational intelligence associated with the
source address field and possibly the port and protocol [REF1]
enables packet-by-packet IPv6 security classification, where the IPv6
header extensions in the form of Destination Options may be used to
stain each packet with security reputation information such that the
network routing is unaffected, but intermediate security nodes and
endpoint devices can apply policy decisions about incoming
information flows without the requirement to assemble and treat
payloads at higher levels of the stack.
IPv6 packet staining support consists of labeling datagrams with
security reputation information through the addition of an IPv6
destination option in the packet header by packet manipulation
devices (PMDs) in the carrier or enterprise network. This
destination option may be read by in-line security nodes upstream
from the packet destination, as well as by the destination nodes
themselves.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Background
Internet based threats in the form of both malicious software and the
agents that control this software (organized crime, spys,
hackitivits) have surpassed the abilities of signature-based security
Macaulay Expires August 17, 2012 [Page 3]
Internet-Draft IPv6 Packet Staining February 2012
systems; whether they be on the enterprise perimeter, within the
corporate network, on the endpoint point or in-the-cloud (internet-
based service). Additionally, the sensitivity of IP network
continues to grow as new generation of smart devices is appearing on
the networks in the form of broadband mobile devices, legacy
industrial control devices, and very low-power sensors. This diverse
collections of IP-based assets is coming to be known as the Internet
of Things (IOT).
In response to the accelerating threats, the security vendor
community have integrated their products with proprietary forms of
security reputation intelligence. This intelligence is about IP
addresses and domains which have been observed engaged in attack-
behaviours such as inappropriate messaging and traffic volumes,
domain management, Botnet command-and-control channel exchanges and
other indicators of either compromise or malicious intent. [REF 1]
IP address may also end up on a security reputation list if they are
identified as compromised through vendor-specific signature-based
processes. Security reputation intelligence from vendors is
typically made available to perimeter and end-point products through
proprietary, internet-based queries to vendor information bases.
This system of using proactive, security reputation intelligence has
many benefits, but also several weakness and scaling challenges.
Specifically, existing intelligence systems are:
1. subject to direct attack from the internet on distribution
points, for instance
2. are proprietary to vendor devices
3. require fat-clients consuming both bandwidth and CPU, and
4. introduces flow latency while queries are sent, received and
processed
5. introduces intelligence latency as reputation lists will be
inevitably cached and only periodically refreshed given the
number and range of vendor-specific processing elements
3.1. Packet Staining Benefits
In contrast to the challenges of current security reputation
intelligence systems, packet staining has the following strengths
1. packet staining can occur transparently in the network,
presenting no attack surface
2. packet staining uses standardized, public domain IPv6
capabilities
3. security rules can be easily applied in hardware or firmware
4. reading packet stains introduces little to no latency
5. near-real-time threat intelligence distribution systems can be
implemented can be implemented out of band in PMDs using a
standardized packet staining method allowing multiple
Macaulay Expires August 17, 2012 [Page 4]
Internet-Draft IPv6 Packet Staining February 2012
intelligence sources (vendor sources) to be aggregated and
applied in an agnostic (cross-vendor) manner.
3.2. Implementation and support models
Packet staining may be accomplished by different entities including
carriers, enterprises and third-party value-added service providers.
Carriers or service providers may elect to implement staining centres
at strategic locations in the network to provide value-added services
on a subscription basis. Under this model, subscribers to a security
staining service would see their traffic directed through a staining
centre where Destination Options are added to the IPv6 headers and
IPv4 traffic is encapsulated within IPv6 tunnels, with stained
headers.
Carriers or service providers may elect to stain all IPv6 traffic
entering their network, and allow subscribers to process the stains
at their own discretion.
If such upstream, network-based staining services are inappropriate
or unavailable, Enterprise data centre managers / cloud computing
service providers may elect to deploy IPv6 staining at the perimeter
into the internal network, tunnelling all IPv4 traffic, and allow
data centre/cloud service users to process stains at their
discretion.
Enterprise may wish to deploy IPv6 on internal networks, and stain
all internal traffic whereby security nodes and end-points may apply
corporate security policy related to reputation.
3.3. Use cases
The following are example use-cases for a security technique based
upon a packet staining system.
Organization Perimeter Use-case Traffic to a subscriber is routed
through a PMD in the carrier network configured to stain (apply
Destination Options extensions) all packets to the subscriber (TM)s
IP-range, which have entries in the threat intelligence information
base. The PMD accesses the information base from a locally cached
file or other method not defined in this draft. Packets from sources
not in the information base pass through the PDM unchanged. Packets
from sources in the information base have a Destinations Option added
to the datagram header. The Destination Options contains reputation
from the information base. The format of the destination option is
discussed later in this draft. IPv6 perimeter devices such as
firewalls, web proxies or security routers on the perimeter of the
Macaulay Expires August 17, 2012 [Page 5]
Internet-Draft IPv6 Packet Staining February 2012
subscriber network look for Destination Options on incoming packets
with reputation stains. If a stain is found, the perimeter device
applies the organization policy associated with the reputation
indicated by the stain. For instance, drop the packet, quarantine
the packet, issue alarms, or pass the packets and associated flow to
specially hardened extra-net authentication systems, or do nothing.
IPv4 support Use-case" IPv4 header fields and options are not
suitable for packet staining; however, there is a clear security
benefit to supporting IPv4 flows. IPv4 traffic to a subscriber is
routed through a PMD in the carrier network configured to encapsulate
the IPv4 traffic in an IPv6 tunnel. The PMD applies a stain
(Destination Options extension) to the IPv6 tunnel as per the
Perimeter Use-case above. Subscriber perimeter devices such as
firewalls, web proxies or security routers are configured to support
both native IPv6 flows and IPv6 tunnels contain legacy IPv4 flows.
Perimeter devices look for Destination Options on incoming IPv6
packets with reputation stains. If a stain is found, the perimeter
device applies the organization policy associated with the reputation
indicated by the stain to the IPv4 packet within the IPv6 tunnel. In
this manner IPv4 support may be transparent to end-users and
applications.
IPv6 end-point use-case" IPv6 end-points may make use of reputation
stains by processing Destination Options before engaging in any
application level processing. In the case of certain classes of
smart device, remote and mobile sensors, reputation stains may be a
critical form of security when other mitigations such as signature
bases and firewalls are too power and processor intensive to support.
URL-specific stains" it is a common occurrence to see large public
content portals with millions of users sharing dozens of addresses.
Frequently, malicious content will be loaded to such sites. This
content represents a very small fraction of the otherwise legitimate
content on the site, which may be under the direct control of
entirely separate entities . Degrading the reputation of IP
addresses used by these large portals based on a very small amount of
content is problematic. For such sites, reputation stains should
have the ability to include the URL of malicious content, such that
the reputation of the only specific portions of these large portals
is degraded according to threat evidence, rather than the entire IP
address, CIDR block, ASN or domain name.
4. Requirements for staining IPv6 packets
Macaulay Expires August 17, 2012 [Page 6]
Internet-Draft IPv6 Packet Staining February 2012
1. The default behaviour of a security node MUST be to leave a
packet unchanged (apply no stain).
2. Reputation stains may be inserted or overwritten by security
nodes in the path.
3. Reputation stains may not be applied by the sender/source of the
packet.
4. The reputation staining mechanism needs to be visible to all
stain-aware nodes on the path.
5. The mechanism needs to be able to traverse nodes that do not
understand the reputation stains. This is required to ensure
that packet-staining can be incrementally deployed over the
Internet.
6. The presence of the reputation staining mechanism should not
significantly alter the processing of the packet by nodes, unless
policy is explicitly configured. This is required to ensure that
stained packets do not face any undue delays or drops due to a
badly chosen mechanism.
7. A PMD should be able to distinguish a trusted stain from an
untrusted stain, through mechanism such as digital signatures or
intrinsic trust among network elements.
8. A staining node MAY apply more specific and selective staining
services according to subscriptions. Staining nodes SHOULD
support different reputation taxonomies to support different
subscribers and/or interoperability with other staining entities,
and have the ability to stain flows to different subscriber
sources according to different semantics.
5. Packet Stain Destination Option (PSDO)
The Packet Stain Destination Option (PSDO) is a destination option
that can be included in IPv6 datagrams that are inserted by PMDs in
order to inform packet staining aware nodes on the path, or
endpoints, that the PSDO has an alignment requirement of (none).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|U| Stain Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Packet Stain Destination Option Layout
Macaulay Expires August 17, 2012 [Page 7]
Internet-Draft IPv6 Packet Staining February 2012
Option Type
8-bit identifier of the type of option. The option identifier
for the reputation stain option will be allocated by the IANA.
Option Length
8-bit unsigned integer. The length of the option (excluding
the Option Type and Option Length fields).
S Bit
When this bit is set, the reputation stain option has been signed.
U Bit
When this bit is set, the reputation stain option contains a
malicious URL.
Stain Data
Contains the staining data.
6. Acknowledgements
The author wishes to achknowledge the guidance and support of Suresh
Krishnan from Ericsson's Montreal lab. The author also wishes to
credit Chris Mac-Stoker from NIKSUN for his substantial contributions
to the early stages of the packet staining concept.
7. Security Considerations
Some implementation may elect to no apply digital signature to
reputation stains in the Destination Option, in which case the stain
is not protected in any way, even if IPsec authentication [RFC4302]
is in use. Therefore an unsigned reputation stain can be forged by
an on-path attacker. Implementers are advised that any en-route
change to an unsigned security reputation stain value is
undetectable. Therefore packet staining use the Destination Options
extension without digital signatures requires intrinsic trust among
the network elements and the PMD, and the destination node or
intervening security nodes such as firewalls or IDS services. For
this reason, receiving nodes MAY need to take account of the network
from which the stained packet was received. For instance, a multi-
homed organization may have some service providers with staining
Macaulay Expires August 17, 2012 [Page 8]
Internet-Draft IPv6 Packet Staining February 2012
services and others that do not. A receiving node SHOULD be able to
distinguish which source from which stains are expected. A receiving
node SHOULD by default ignore any reputation stains from sources
(networks or devices) that have not been specifically configured as
trusted.
The reputation intelligence of IP source addresses, ASNs, CIDR blocks
and domains is fundamental to the application of reputation stains
within packet headers. Such reputation information can be seeded
from a variety of open and closed sources. Poorly managed or
compromised intelligence information bases can result in denial of
service against legitimate IP addresses, and allow malicious entities
to appear trustworthy. Intelligence information bases themselves may
be compromised in a variety of ways; for instance the raw information
feeds may be corrupted with erroneous information, alternately the
intelligence reputation algorithms could be flawed in design or
corrupted such that they generate false reputation scores. Therefore
seed intelligence SHOULD be sourced and monitored with demonstratable
diligence. Similarly, reputation algorithms should be protected from
unauthorized change with multi-layered access controls.
The value of reputation stains will be directly proportional to the
trustworthiness, reliability and reputation of the intelligence
source itself. Operators of security nodes SHOULD have defined and
auditable methods upon which they select and manage the source of
reputation intelligence and the packet staining infrastructure
itself.
8. IANA Considerations
This document defines a new IPv6 destination option for carrying
security reputation packet stains. IANA is requested to assign a new
destination option type (TBA1) in the Destination Options registry
maintained at http://www.iana.org/assignments/ipv6-parameters 1)
Signed Security Reputation Option, 2) Unsigned Security Reputation
Option 3) Signed Security Reputation Option with malicious URL 4)
Unsigned Security Reputation Option with malicious URL The act bits
for this option need to be 10 and the chg bit needs to be 0.
9. Normative References
[REF1] Macaulay, T., "Upstream Intelligence: anatomy,
architecture, case studies and use-cases.", Information
Assurance Newsletter, DOD , Aug to Feburary 2010 to 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Macaulay Expires August 17, 2012 [Page 9]
Internet-Draft IPv6 Packet Staining February 2012
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
Author's Address
Tyson Macaulay
Bell Canada
160 Elgin Floor 5
Ottawa, Ontario
Canada
Email: tyson.macaulay@bell.ca
Macaulay Expires August 17, 2012 [Page 10]
Html markup produced by rfcmarkup 1.104,
available from
http://tools.ietf.org/tools/rfcmarkup/
Related previous work:
INFORMATIONAL
Network Working Group S. Bellovin
Request for Comments: 3514 AT&T Labs Research
Category: Informational 1 April 2003
The Security Flag in the IPv4 Header
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Firewalls, packet filters, intrusion detection systems, and the like
often have difficulty distinguishing between packets that have
malicious intent and those that are merely unusual. We define a
security flag in the IPv4 header as a means of distinguishing the two
cases.
1. Introduction
Firewalls [CBR03], packet filters, intrusion detection systems, and
the like often have difficulty distinguishing between packets that
have malicious intent and those that are merely unusual. The problem
is that making such determinations is hard. To solve this problem,
we define a security flag, known as the "evil" bit, in the IPv4
[RFC791] header. Benign packets have this bit set to 0; those that
are used for an attack will have the bit set to 1.
1.1. Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
2. Syntax
The high-order bit of the IP fragment offset field is the only unused
bit in the IP header. Accordingly, the selection of the bit position
is not left to IANA.
Bellovin Informational [Page 1]
RFC 3514 The Security Flag in the IPv4 Header 1 April 2003
The bit field is laid out as follows:
0
+-+
|E|
+-+
Currently-assigned values are defined as follows:
0x0 If the bit is set to 0, the packet has no evil intent. Hosts,
network elements, etc., SHOULD assume that the packet is
harmless, and SHOULD NOT take any defensive measures. (We note
that this part of the spec is already implemented by many common
desktop operating systems.)
0x1 If the bit is set to 1, the packet has evil intent. Secure
systems SHOULD try to defend themselves against such packets.
Insecure systems MAY chose to crash, be penetrated, etc.
3. Setting the Evil Bit
There are a number of ways in which the evil bit may be set. Attack
applications may use a suitable API to request that it be set.
Systems that do not have other mechanisms MUST provide such an API;
attack programs MUST use it.
Multi-level insecure operating systems may have special levels for
attack programs; the evil bit MUST be set by default on packets
emanating from programs running at such levels. However, the system
MAY provide an API to allow it to be cleared for non-malicious
activity by users who normally engage in attack behavior.
Fragments that by themselves are dangerous MUST have the evil bit
set. If a packet with the evil bit set is fragmented by an
intermediate router and the fragments themselves are not dangerous,
the evil bit MUST be cleared in the fragments, and MUST be turned
back on in the reassembled packet.
Intermediate systems are sometimes used to launder attack
connections. Packets to such systems that are intended to be relayed
to a target SHOULD have the evil bit set.
Some applications hand-craft their own packets. If these packets are
part of an attack, the application MUST set the evil bit by itself.
In networks protected by firewalls, it is axiomatic that all
attackers are on the outside of the firewall. Therefore, hosts
inside the firewall MUST NOT set the evil bit on any packets.
Bellovin Informational [Page 2]
RFC 3514 The Security Flag in the IPv4 Header 1 April 2003
Because NAT [RFC3022] boxes modify packets, they SHOULD set the evil
bit on such packets. "Transparent" http and email proxies SHOULD set
the evil bit on their reply packets to the innocent client host.
Some hosts scan other hosts in a fashion that can alert intrusion
detection systems. If the scanning is part of a benign research
project, the evil bit MUST NOT be set. If the scanning per se is
innocent, but the ultimate intent is evil and the destination site
has such an intrusion detection system, the evil bit SHOULD be set.
4. Processing of the Evil Bit
Devices such as firewalls MUST drop all inbound packets that have the
evil bit set. Packets with the evil bit off MUST NOT be dropped.
Dropped packets SHOULD be noted in the appropriate MIB variable.
Intrusion detection systems (IDSs) have a harder problem. Because of
their known propensity for false negatives and false positives, IDSs
MUST apply a probabilistic correction factor when evaluating the evil
bit. If the evil bit is set, a suitable random number generator
[RFC1750] must be consulted to determine if the attempt should be
logged. Similarly, if the bit is off, another random number
generator must be consulted to determine if it should be logged
despite the setting.
The default probabilities for these tests depends on the type of IDS.
Thus, a signature-based IDS would have a low false positive value but
a high false negative value. A suitable administrative interface
MUST be provided to permit operators to reset these values.
Routers that are not intended as as security devices SHOULD NOT
examine this bit. This will allow them to pass packets at higher
speeds.
As outlined earlier, host processing of evil packets is operating-
system dependent; however, all hosts MUST react appropriately
according to their nature.
5. Related Work
Although this document only defines the IPv4 evil bit, there are
complementary mechanisms for other forms of evil. We sketch some of
those here.
For IPv6 [RFC2460], evilness is conveyed by two options. The first,
a hop-by-hop option, is used for packets that damage the network,
such as DDoS packets. The second, an end-to-end option, is for
packets intended to damage destination hosts. In either case, the
Bellovin Informational [Page 3]
RFC 3514 The Security Flag in the IPv4 Header 1 April 2003
option contains a 128-bit strength indicator, which says how evil the
packet is, and a 128-bit type code that describes the particular type
of attack intended.
Some link layers, notably those based on optical switching, may
bypass routers (and hence firewalls) entirely. Accordingly, some
link-layer scheme MUST be used to denote evil. This may involve evil
lambdas, evil polarizations, etc.
DDoS attack packets are denoted by a special diffserv code point.
An application/evil MIME type is defined for Web- or email-carried
mischief. Other MIME types can be embedded inside of evil sections;
this permit easy encoding of word processing documents with macro
viruses, etc.
6. IANA Considerations
This document defines the behavior of security elements for the 0x0
and 0x1 values of this bit. Behavior for other values of the bit may
be defined only by IETF consensus [RFC2434].
7. Security Considerations
Correct functioning of security mechanisms depend critically on the
evil bit being set properly. If faulty components do not set the
evil bit to 1 when appropriate, firewalls will not be able to do
their jobs properly. Similarly, if the bit is set to 1 when it
shouldn't be, a denial of service condition may occur.
8. References
[CBR03] W.R. Cheswick, S.M. Bellovin, and A.D. Rubin, "Firewalls
and Internet Security: Repelling the Wily Hacker", Second
Edition, Addison-Wesley, 2003.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC1750] Eastlake, D., 3rd, Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
Bellovin Informational [Page 4]
RFC 3514 The Security Flag in the IPv4 Header 1 April 2003
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
9. Author's Address
Steven M. Bellovin
AT&T Labs Research
Shannon Laboratory
180 Park Avenue
Florham Park, NJ 07932
Phone: +1 973-360-8656
EMail: bellovin@acm.org
Bellovin Informational [Page 5]
RFC 3514 The Security Flag in the IPv4 Header 1 April 2003
10. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bellovin Informational [Page 6]
Html markup produced by rfcmarkup 1.104,
available from
http://tools.ietf.org/tools/rfcmarkup/
See also:
http://en.wikipedia.org/wiki/Evercookie
|
