INTERNET-DRAFT Weak Authentication and Tracing Option
February 1998
Expires August 1998
The Weak Authentication and Tracing Option
--- ---- -------------- --- ------- ------
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-eastlake-weak-ato-03.txt, is intended to
be become an Proposed Standard RFC. Distribution of this document is
unlimited. Comments should be sent to the author.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),
ftp.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT Weak Authentication and Tracing Option
Abstract
The packet switched nature of the Internet Protocol (IP) provides no
inherent method to assure that a packet has been issued with a source
address authorized for the sender and no inherent method to trace the
actual source of a packet. These characteristics make it difficult
to take effective action concerning injurious packets which may have
originated, by accident or maliciously, virtually anywhere in the
Internet.
A lightweight IP level option is proposed that provides (1) some
assurance that packet's source addresses are authorized for their
sender, and (2) limited statistical tracing information such that, if
many bad packets are logged, the path to their source will be
revealed.
These features, even if not implemented throughout the Internet,
would provide significantly improved protection against packet level
abuse.
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT Weak Authentication and Tracing Option
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Table of Contents..........................................3
1. The Packet Spam Problem.................................4
2. Other Possible Solutions................................4
2.1 Address Filtering......................................4
2.2 IPSEC / IPv6...........................................5
3. The WATO Solution.......................................6
4. Option and Message Formats..............................7
4.1 IPv4 Weak Authentication and Tracing Option Format.....7
4.2 IPv4 Weak Authentication ICMP Message..................8
4.3 IPv6 Weak Authentication and Tracing Option Format.....9
4.4 IPv6 Weak Authentication ICMP Message.................10
5. WATO State and Processing..............................11
5.1 WATO Soft State.......................................11
5.2 WATO End-to-End Processing at a Source Host...........12
5.3 WATO Adjacent Send Processing.........................12
5.4 WATO Adjacent Receive Processing......................13
5.5 WATO End-to-End Processing at a Destination Host......14
5.6 Weak Authentication ICMP Processing...................14
5.7 Multicast Packets.....................................15
6. Tracing and Logging....................................16
7. Cookies................................................17
7.1 Cookie Generation.....................................17
7.2 Cookie Rollover.......................................18
8. Deployment and Proxies.................................18
9. Security Considerations................................20
References................................................21
Author's Address..........................................21
Expiration and File Name..................................22
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT Weak Authentication and Tracing Option
1. The Packet Spam Problem
As the Internet increases in size, the probability of accidental or
malicious IP packet level accidents or attacks, including denial of
service attacks, increases as well. Misconfiguration or bugs in
software can produce anomalous and injurious packets. Network
interface or other hardware failure can also yield anomalous and
injurious packets. And a variety of software designed explicitly to
launch denial of service attacks has been widely distributed.
In general, the Internet Protocol does not constrain the source
address used on packets. Indeed, some forms of mobile IP make use of
this and hypothetical future uses of IP may require this liberty.
However, as a result, injurious packets can be sent with random or
inappropriate source addresses making the true source difficult to
locate.
The Internet Protocol does not provide a way for a destination to
require trace information to be included in a packet. There are
trace ("record route") options but they would have to be voluntarily
included by the sender, are relatively cumbersome variable length
options which may not be able to accommodate all the hops a packet
traverses, and include no facilities for authentication.
Accidental or malicious denial of service or similar attacks are a
difficult problem. They can not be prevented in general. However,
the facilities provided by the weak authentication and tracing option
(WATO), as described in section 3 below, should make most of such
attacks much easier to trace and terminate.
2. Other Possible Solutions
Address filtering has been suggested to improve the authenticity of
IP source addresses and IP security mechanisms are being developed to
strongly secure packets; however, as explained below these mechanisms
do not answer the needs addressed by the Weak Authentication and
Tracing Option (WATO).
2.1 Address Filtering
To the extent that routers connect an Internet area using limited
addresses to the global Internet, they can filter outgoing packets to
only permit those with source addresses within those limited
addresses and/or filter incoming packets to those with source
addresses not within those limited addresses [RFC 2267]. This may be
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT Weak Authentication and Tracing Option
a helpful strategy and is compatible with WATO but has the following
problems:
Tables of addresses must be maintained and updated at all routers
implementing this strategy.
The strategy becomes increasingly difficult for high level routers
that may be connected via complex, time variant topology.
There is no way for a destination to gain any assurance that a packet
it receives was in fact so filtered or to request such filtering
by a message to the source or any intermediate host.
Some mobile IP schemes utilize and hypothetical future uses of IP
might require the ability to send packets with non-local source
addresses.
Address filtering provides no trace information, although it may
constrain paths.
In contrast, the WATO's weak source address authentication data can
be automatically and dynamically maintained and it provides weakly
authenticated statistical trace information. A destination can
refuse packets that do not have weak authentication and can request
that a remote host use WATO.
2.2 IPSEC / IPv6
Strong IP security mechanisms (IPSEC, IPv6) [RFC1825] are being
standardized. However these mechanisms are targeted at the
establishment of highly authenticated and/or strongly confidential
point to point or process to process channels. For spontaneous
Internet communications, they typically require computationally
intensive set up, extensive per packet computation, and a deployed
public key infrastructure such as DNS security [RFC 2065]. In
particular, the amount of computation usually makes authentication at
routers impractical. Furthermore, even strongly authenticated packets
can be injurious and these strong security measures provides no
assistance in packet tracing and relatively little assistance in
efficient rejection of packets with forged source addresses.
In contrast, the WATO imposes only minimal additional computation,
uses no cryptography, and can reject packets based on a trivial
examination.
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT Weak Authentication and Tracing Option
3. The WATO Solution
The Weak Authentication and Tracing Option (WATO) can weakly
authenticate the source address of a unicast packet by demanding that
the remote host supply a plain text end-to-end cookie, specified to
the source host by the destination host. This cookie is associated
with the source/destination IP address ordered pair. These cookies
are in essence plain text re-usable passwords that are set up in soft
state by ICMP messages. They are not secure against parties that can
eavesdrop on the conversation but are reasonably secure against
others.
The WATO also provides a random sample of one intermediate IP address
of a WATO enabled machine in the path any packet follows. If enough
packets are logged, the entire path can be mapped as far as WATO
equipped intermediate hosts are concerned. These intermediate IP
addresses are weakly authenticated by an adjacent node cookie
mechanism similar to the end-to-end cookie mechanism described above.
The WATO is designed as a fixed format option and should be the first
option, if present, so that its fields are a fixed offset from the
packet beginning. This enables routers to perform WATO updating and
checking efficiently. It is not necessary that all or even any
intermediate routers implement WATO in order to gain substantial
advantages.
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT Weak Authentication and Tracing Option
4. Option and Message Formats
The following subsections describe the WATO option and ICMP message
formats.
4.1 IPv4 Weak Authentication and Tracing Option Format
The IP Version 4 Internet Protocol (IPv4) Weak Authentication and
Tracing Option (WATO) is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num=100*tbd* | size=00010100 | T-TTL | A-TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjacent Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-to-End Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjacent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first byte is the option number <TBD>. This number has 100 as
its top three bits which is in the range for control options that
must be copied into all fragments if a packet is fragmented.
The second byte is the option length which is always 20 decimal. (A
fixed format is used to minimize processing time and complexity, a
particularly important consideration at routers.) The WATO option
should be the first option in an IPv4 packet header.
T-TTL is the TTL at the time an Adjacent IP Address was copied to the
Trace Address field as a packet is transmitted at a network interface
(see section 5 below).
A-TTL is the TTL at the time this packet was last sent over a link
and the Adjacent Address was set to the IP address of the interface
on which it was transmitted (or zero if it was transmitted on an
unnumbered inter-router point-to-point link) (see section 5 below).
The Adjacent Cookie field is used in weak authentication between
successive WATO equipped hosts. (If all hosts are WATO equipped,
this will be authentication over a single hop link.) The End-to-End
Cookie is used for weak authentication from end to end. A cookie
value of 0 means the sender believes it is required but unknown. A
cookie value of 1 means the sender believes it is not required. All
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT Weak Authentication and Tracing Option
other values are specific cookies. A WATO with both cookies set to 1
would be unusual but is permitted.
The Trace Address is used for statistical tracing of packets (see
section 6 below).
4.2 IPv4 Weak Authentication ICMP Message
The IP Version 4 Internet Protocol (IPv4) Weak Authentication ICMP
message has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + 64 bits of Original Data Datagram |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type number is <TBD>. Values for Code are as follows:
0 Reserved
1 Adjacent cookie authentication failed. This is sent to the
Adjacent Address appearing in a WATO received if (a) the Adjacent
Cookie is wrong or 0 when adjacent WATO processing is enabled or (b)
the Adjacent Cookie is 1 when WATO is required.
2 Spontaneous notification sent to an adjacent IP address due
to a change in the adjacent cookie required from the remote address
by the ICMP sending host. The "Internet Header +" of the ICMP is
meaningless in this case.
3 End-to-End cookie authentication failed. The is sent to the
packet source address if (a) a WATO is received in a unicast packet
with the End-to-End Cookie wrong or 0 when WATO is enabled or (b) the
End-to-End Cookie is 1 when WATO is required.
4 Spontaneous notification sent to a remote IP address due to a
change in the End-to-End cookie required from the remote address by
the ICMP sending host. The "Internet Header +" of the ICMP is
meaningless in this case.
5 Proxy notification. This is used when a host wishes to
authorize another host to validly use its source address for a
particular destination on an End-to-End basis. It accomplishes this
by forwarding the weak authentication ICMP (code 1 or 2) by which it
learned the end-to-end cookie the remote system expects. WARNING:
unprotected use of this subtype of weak authentication ICMP may
expose the cookie to compromise by eavesdropping in a significantly
larger portion of the Internet than would be the case if occurance of
the cooke was restricted to the source/destination route.
Donald E. Eastlake 3rd [Page 8]
INTERNET-DRAFT Weak Authentication and Tracing Option
4.3 IPv6 Weak Authentication and Tracing Option Format
The IP Version 6 Internet Protocol (IPv6) Weak Authentication and
Tracing Option (WATO) is as follows:
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=TBD|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opt Data Len=43| W-HOP | T-HOP | A-HOP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjacent Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-to-End Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Adjacent Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Trace Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The alignment requirement is 8n+3.
This option appears within the Hop-by-Hop Option in IPv6. The top
three bits of the type are 001. Top two bits zero indicates that the
option may be skipped over and forwarded by a host that does not
understand the option. The next bit a 1 indicates that the content
of the option changes as the packet is forwarded through the Internet
and therefor should not be included in checksums.
Fields with the same name have the same meaning as for the IPv4
option specified in 4.1 above. *-HOP fields correspond to the same
*-TTL field for IPv4. The W-HOP field is a copy of the HOP count at
the time the WATO was inserted in the packet, possibly the value of
the HOP count at the original source host.
Donald E. Eastlake 3rd [Page 9]
INTERNET-DRAFT Weak Authentication and Tracing Option
4.4 IPv6 Weak Authentication ICMP Message
The IP Version 6 Internet Protocol (IPv6) Weak Authentication ICMP
message has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as will fit without the ICMPv6 packet +
| exceeding 576 octets |
The type number is <TBD> which is an error class IPv6 ICMP.
Values for Code are the same as for the IPv4 weak authentication ICMP
in section 4.2 above.
Donald E. Eastlake 3rd [Page 10]
INTERNET-DRAFT Weak Authentication and Tracing Option
5. WATO State and Processing
Subsection 5.1 below describe the minimum data which needs to be
maintained at a host to implemented the weak authentication and
tracing option (WATO). Subsections 5.2 through 5.6 describe the
processing that needs to be performed on a per unicast packet basis.
They talk about end-to-end source host processing, adjacent source
host processing, adjacent detination host processing, and end-to-end
destination host processing, in that order. Finally, section 5.7
describes the differences for multicast. Note that any form of state
maintenance or processing that results in the same bits on the wire
is equally valid.
In some cases packets are tunneled through IP in IP encapsulation or
the like. This is compatible with WATO, keeping in mind that the
entire tunnel will generally appear to any encapsulated WATO as one
hop. WATO may be independently used in the outer packet transmission
that makes up the tunnel.
5.1 WATO Soft State
A host participating in WATO processing must maintain some state, as
listed below, associated with local/remote IP unicast address ordered
pairs. The number of such states and when they are discarded is a
matter of local policy. This is soft state in that it can be
reconstructed at the expense of exchanging weak authentication ICMP
packets. Most implementations will want to keep additional state
information such as time of state establishment/update.
Local IP Address
Remote IP Address
Type (adjacent or end-to-end)
Send Cookie Status (confirmed/proposed)
Send Cookie
Required Receive Cookie
Local IP Address is not required on a per state basis if the host has
only one IP interface address.
The send cookie is initialized to zero which is not a valid cookie
and is set as specified in section 5.6 on ICMP processing.
Receive Cookie need not be included in the state if it can be
reconstructed quickly enough as described in section 7.1.
It is a matter of local policy as to when the WATO soft state
associated with a local/remote IP address pair is discarded.
However, if the state has no remote cookie associated with it and the
Donald E. Eastlake 3rd [Page 11]
INTERNET-DRAFT Weak Authentication and Tracing Option
local cookie is reconstructable, it is generally safe to discard the
state on receipt of any destination unreachable ICMP.
5.2 WATO End-to-End Processing at a Source Host
If the destination address of an outgoing packet is an address such
that packets from that address would be rejected if received without
a WATO having a correct end-to-end cookie, then a WATO MUST be
included in an output packet to that address. In the case of the
recent receipt of any packet with a WATO from that destination
address as a source address, the WATO MUST be included on outgoing
packets. If neither of these cases applies, inclusion of the WATO is
a matter of local policy but always including it SHOULD be the
default. Provisions may be made for disabling originating host WATO
processing based on the network interface to be used or destination
IP address, such as a list of values and masks for which it is
suppressed. (For un-numbered inter-router point to point links, the
IP address of each end is considered zero so some other means of
designating WATO suppression, such as a hardware interface number,
may be needed.)
If the WATO is being included, an original source host
- sets the trace address and T-TTL (or (T-HOP) fields to zero,
- for IPv6, sets the W-HOP field to the IP header HOP field,
- sets the End-to-End Cookie field to the end-to-end cookie it has
cached for the destination address or to zero if there isn't one,
- sets the Adjacent Cookie to one, and then
- performs adjacent WATO packet send processing as described
immediately below.
5.3 WATO Adjacent Send Processing
The following processing occurs on each WATO equipped host along the
packet's path, including the original source, on the sending of the
packet. It should be possible to enable/disable adjacent WATO
processing on a per interface basis. Provisions may be made for
disabling adjacent host WATO processing based on the adjacent IP
address, such as a list of values and masks for which it is
suppressed. If adjacent WATO processing is disabled on send, any
existing WATO is passed on without modification.
Donald E. Eastlake 3rd [Page 12]
INTERNET-DRAFT Weak Authentication and Tracing Option
If enabled and there isn't a WATO option in the packet, one must be
added with the End-to-End cookie set to one and the Trace Address and
T-TTL (or T-HOP) fields set to zero (and for IPv6, the W-HOP field
set to the IP header HOP field). Insertion of the WATO option at an
intermediate point can increase packet size, cause fragmentation, and
decrease apparent path MTU.
If the WATO option already in a packet has an incorrect length, the
packet is dropped. An ICMP parameter problem (with a WATO) is send
back (unless the packet's ultimate source is the host where this
problem is detected).
Then
- set the A-TTL (or A-HOP) field to the IP header TTL (or HOP) field,
and the Adjacent Address field to the IP address of the interface
the packet is being transmitted on, and
- set the Adjacent Cookie field to the adjacent cookie it has cached
for IP address of the next hop it is being sent to or to zero if
there isn't such a cached cookie.
- finally, with a 1/16th probability (see section 6), copy the A-TTL
(or A-HOP) and Adjacent Address fields into the T-TTL (or T-HOP)
and Trace Address fields.
5.4 WATO Adjacent Receive Processing
The following processing occurs on each WATO equipped host along the
packet's path on the receipt of a unicast packet.
On an interface where WATO is disabled, no processing is done and the
packet is passed on for other processing.
On an interface where the WATO is enabled, if a packet is received
without this option, an ICMP Destination Unreachable due to
Administrative Restriction should be returned with a WATO present on
the ICMP IP packet. [Or should this be a new Code for Destination
Unreachable? It can't just be the new weak authentication ICMP as
the sender may not understand that.]
If a packet is received with a wrong length or malformed WATO, an
ICMP parameter error (with WATO) is sent back and then the packet is
discarded.
If the WATO option present has zero, one, or the wrong value for the
Adjacent Cookie, an appropriate weak authentication ICMP is sent back
with the required adjacent cookie unless the packet is itself a weak
Donald E. Eastlake 3rd [Page 13]
INTERNET-DRAFT Weak Authentication and Tracing Option
authentication ICMP (see section 5.6) addressed to this node in which
case that ICMP is processed as if it had a wrong cookie before the
weak authentication ICMP is transmitted. Then the packet is
discarded.
After adjacent WATO receive processing, if the destination address is
this host, then perform end-to-end receive processing as describe
immediately below.
5.5 WATO End-to-End Processing at a Destination Host
If WATO processing is disabled for the interface, do nothing.
If WATO processing is enabled and the WATO option present has zero,
one, or the wrong value for the End-to-End Cookie, an appropriate
weak authentication ICMP is sent back with the required cookie unless
the packet is itself a weak authentication ICMP (see section 5.6)
addressed to this node. In that case the ICMP is processed before
the weak authentication ICMP response is transmitted. Then the
packet is discarded.
If the WATO is OK, the packet is passed on for further processing.
(Local policy may also take some action to indicate that the soft
state referenced to check the packet was in recent use and should
have higher priority for retention that idle soft WATO state.)
5.6 Weak Authentication ICMP Processing
Weak authentication ICMPs inform a host of what cookie another host
will require. However, this information is considered to only be
proposed unless it is weakly authenticated by the presence in the
weak authentication ICMP packet of a WATO correctly giving the
required cookie of the type being set. If it is weakly
authenticated, it is considered confirmed. A proposed cookie is
remembered in soft state and used only if there is no confirmed
cookie. A confirmed cookie replaces any existing confirmed or
proposed cookie and is remembered in soft state and used.
For example, an ICMP purporting to be from host A is sent to host B
stating that host A will require end-to-end cookie Ac. If this ICMP
has a WATO giving the correct end-to-end cookie required by host B of
host A (i.e., Bc), then Ac becomes the confirmed cookie for future
packets from B to A. If this ICMP has a WATO with no or the wrong
end-to-end cookie required by B of host A, it may be a forgery. Host
B takes Ac only as a proposed cookie and also sends to host A an ICMP
informing host A of Bc which is the cookie B is requiring of A. This
Donald E. Eastlake 3rd [Page 14]
INTERNET-DRAFT Weak Authentication and Tracing Option
ICMP to A will have a WATO that gives an earlier confirmed cooked (
Ac[-1] ), if there is one, or the proposed cookie (Ac).
Some hosts may adopt a strategy of temporarily retaining a copy of a
packet if they expect it to be dropped due to lack of a good cookie
and retransmitting it when they get a weak authentication ICMP code 1
or 3.
5.7 Multicast Packets
Normal end-to-end and adjacent WATO processing are not performed on a
multicast packet. A WATO option may be present and the adjacent and
trace address are set as normal, so statistical tracing is provided,
but the cookie fields are unused.
A multicast packet may be rejected with a WATO equipped ICMP to
indicate that a WATO should be sent on future packets but such
transmissions MUST be rate limited.
Donald E. Eastlake 3rd [Page 15]
INTERNET-DRAFT Weak Authentication and Tracing Option
6. Tracing and Logging
The weak authentication and tracing option (WATO) provides to the
destination system a single sample intermediate IP address along the
routed path of each packet.
This trace information is only collectable at links on the path where
WATO is enabled. The probability of collection at each point is
1/16th and overwrites any more remote trace address. This
probability was chosen to give good sampling with typical path
lengths in the current and foreseeable Internet and provide some
sampling even for very long paths.
If enough packets are received from the same source and the WATO is
enabled on the routers used, a complete path can be determined. While
the more random the determination of this 1/16th chance the better,
for the WATO application it is usually adequate to use a simple
linear congruence generator such as
x = ( ( x * 9301 ) + 49297 ) mod 233280
n+1 n
using 32 bit two's complement arithmetic where x is seeded at system
boot time with the date and time in seconds or the like [RFC 1750]
and four bits near the middle of each value of successive x's are
tested for zero for the 1/16 probability.
In attempting to reconstruct a complete path from WATO tracing
information, you should use the T-TTL (or T-HOP) count minus the
final TTL/HOP value, otherwise an attacker can confuse you by
jittering the initial TTL/HOP count.
Which incoming packets or WATO values to remember is a local logging
decision.
Donald E. Eastlake 3rd [Page 16]
INTERNET-DRAFT Weak Authentication and Tracing Option
7. Cookies
As explained below, cookies should be carefully generated and changed
periodically.
7.1 Cookie Generation
It is essential that the cookies used in weak authentication be
random in the sense of being hard for an attacker to guess. RFC 1750
discusses concepts and methods in this area.
The recommended technique is for a host to create a random secret,
which is periodically changed (see section 7.2 below), and then
calculate the cookie required to be presented by a remote IP address
as a function of this secret and that remote address. I.E.:
end-to-end-cookie = hash( end-to-end-secret, remote IP address)
Different secrets should be used for determining end-to-end and
adjacent cookies. Each secret should have at least 32 bits worth of
randomness which means that it must be at least 32 bits in length.
This method of calculating the required cookies permits WATOs from
remote systems to be validated even if the state associated with the
local/remote IP address pair has been lost due to cache overflow or
other reasons. The required cookie value can simply be regenerated
as long as the secret is still known.
For end-to-end cookies, the end-to-end secret should be strongly
mixed with the remote IP address. For example, calculating the
HMAC-MD5 [RFC 1321, 2104] hash of the secret and the remote IP
address and using the lower 32 bits of the result as the cookie.
While strong mixing is also desirable for adjacent cookies, the
implementation of adjacent WATO processing in routers may put a
premium on performance. The number of hosts adjacent to a router may
be limited to relatively trusted routers. In addition, the low delay
and tighter coupling between adjacent hosts may make more frequent
adjacent secret changes practical, perhaps on the order of once every
few seconds or even more often, giving an attacker little time to
calculate or brute force search for a cookie or cookie generating
secret. Under such circumstances, it may make sense to consider use
of a faster and weaker mixing function such as hashing the
concatenation of the secret and the remote IP address with a subset
of the calculations called for in MD5 or MD4 [RFC 1321, 1320].
Donald E. Eastlake 3rd [Page 17]
INTERNET-DRAFT Weak Authentication and Tracing Option
7.2 Cookie Rollover
The longer a cookie is used, the greater the probability that it has
been compromised through eavesdropping or otherwise. To minimize the
loss of weak authentication this would cause, cookies should be
changed periodically. In addition, since cookies are associated with
an IP source address, they must be changed or new ones generated when
a host interface is re-numbered.
For end to end WATO, the cookie MUST be changed no less often than
daily with a maximum validity time of 26 hours. Since excessive
cookie rollover can cause excessive retransmissions and WATO set up
packets, it is recommended that end to end cookies not be changed
more often than every four minutes.
Adjacent cookies SHOULD be changed more frequently than end-to-end
cookies.
If two communicating systems both change cookies at the same time
there is a potential deadlock situation. ("At the same time" means
during the period between intersystem packet transmissions which
could be a substantial time window.) In particular, if both systems
act as described above in section 5, each will start sending weak
authentication ICMP messages to the other advertising its new cookie
for the IP pair, the new cookie will be treated as a proposed cookie
at each end, but it will never displace the old confirmed cookie
because these ICMPs will always have WATOs giving the confirmed and
now wrong cookie. To solve this problem, all WATO implementations
MUST adopt the following strategy: when the cookie to be required
from a remote system on an IP pair is changed, any confirmed cookie
to be sent for that pair is cleared
8. Deployment and Proxies
Useful deployment of WATO will require widespread implementation but
WATO can be incrementally deployed.
End-to-end WATO is useful and requires only that it be implemented at
the two end points. Intervening hosts that don't know about WATO
will simply pass through packets including the option.
Adjacent WATO is useful and generally requires only that the adjacent
hosts within some part of the routing mesh implement it. Any such
implementation will improve the reliability of WATO tracing
information delivered to the destination.
Firewalls can proxy for machines behind them so as to support
Donald E. Eastlake 3rd [Page 18]
INTERNET-DRAFT Weak Authentication and Tracing Option
apparent end-to-end WATO without WATO being installed or enabled for
hosts behind the firewall. Network address translation (NAT) boxes
change the IP address pair to which end-to-end cookies are linked so
they MUST proxy both ways simulating end-to-end WATO to both inside
and outside hosts, if WATO is required by communications through the
NAT box.
Donald E. Eastlake 3rd [Page 19]
INTERNET-DRAFT Weak Authentication and Tracing Option
9. Security Considerations
It must be emphasised that the weak authentication and tracing option
(WATO) provides only a WEAK form of authentication and tracing. In
many cases other security measures, such as IPSEC, should be used in
conjunction with the WATO.
Widespread deployment of WATO would make it impossible for any host
to spray the Internet with packets having forged source addresses
that would be accepted at their destinations; however, there would
still be systems at high levels is the routing mesh that would be
exposed to and could capture cookies for enormous numbers of hosts.
Such systems could forge packets with many source addresses and
correct WATOs. Systems on backbone shared media trunks have been
compromised in the past and used for password sniffing. If
compromised, they could be used for cookie sniffing. In addition
WATO provides almost no protection against a determined local attack
from another machine on the same shared media as the machine you may
be trying to protect.
The trace information collected by the WATO can also be forged. In
particular a system could create a forged trace pattern stretching
off to other real or fictitious hosts. That could make it appear
that the traced packets only came through the system rather than
being originated by it. However, the true source would still be on
the apparent trace path.
The WATO will provide a major improvement in the situation for the
source determination and tracing of injurious packets but it is not a
complete solution. It should be considered only one element of
security in depth.
Donald E. Eastlake 3rd [Page 20]
INTERNET-DRAFT Weak Authentication and Tracing Option
References
[RFC 791] - "Internet Protocol", 09/01/1981, J. Postel
[RFC 792] - "Internet Control Message Protocol", 09/01/1981, J.
Postel
[RFC 1321] - "The MD5 Message-Digest Algorithm", 04/16/1992, R.
Rivest.
[RFC 1320] - "The MD4 Message-Digest Algorithm", 04/16/1992, R.
Rivest.
[RFC 1750] - "Randomness Recommendations for Security", 12/29/1994,
D. Eastlake, S. Crocker, J. Schiller
[RFC 1825] - "Security Architecture for the Internet Protocol",
08/09/1995, R. Atkinson
[RFC 1883] - "Internet Protocol, Version 6 (IPv6) Specification",
01/04/1996, S. Deering, R. Hinden
[RFC 1885] - "Internet Control Message Protocol (ICMPv6) for the
Internet Protocol Version 6 (IPv6)", 01/04/1996, A. Conta, S. Deering
[RFC 2104] - "HMAC: Keyed-Hashing for Message Authentication",
02/05/1997, H. Krawczyk, M. Bellare, R. Canetti.
[RFC 2267} - "Network Ingress Filtering: Defeating Denial of Service
Attacks which employ IP Source Address Spoofing", January 1998, P.
Ferguson, D. Senie.
Author's Address
Donald E. Eastlake 3rd
CyberCash, Inc.
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 978 287 4877
+1 703 620-4200 (main office, Reston, VA)
FAX: +1 978 371 7148
EMail: dee@cybercash.com
Donald E. Eastlake 3rd [Page 21]
INTERNET-DRAFT Weak Authentication and Tracing Option
Expiration and File Name
This draft expires August 1998.
Its file name is draft-eastlake-weak-ato-03.txt.
Donald E. Eastlake 3rd [Page 22]