One document matched: draft-eastlake-weak-ato-00.txt
The Weak Authentication and Tracing Option
--- ---- -------------- --- ------- ------
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-eastlake-weak-ato-00.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),
nic.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 use by 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 packets are authorized by a host along the path routed
through when the packet's source address is used as a destination
address, and (2) limited statistical tracing information such that,
if many bad packets are logged, the path to their source will usually
be revealed.
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...........11
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.....................................14
6. Tracing and Logging....................................16
7. Cookies................................................17
7.1 Cookie Generation.....................................17
7.2 Cookie Rollover.......................................18
8. Tunneling and Fragmentation............................19
9. Deployment.............................................19
10. Security Considerations...............................20
References................................................21
Author's Address..........................................21
Expiration and File Name..................................21
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
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 any 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. This may be a helpful
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT Weak Authentication and Tracing Option
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
host to host 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. 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 frequently 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 in this option a plain text end-to-end cookie,
supplied 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 router 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 can perform WATO updating and
checking efficiently.
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 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 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
rigid 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.
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).
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 zero means the sender believes it is required but unknown.
A cookie value of one means the sender believes it is not required.
All other values are specific cookies. A WATO with both cookies one
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT Weak Authentication and Tracing Option
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 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 the Adjacent Cookie
is wrong or zero when adjacent WATO processing is enabled or is one
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 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 WATO is received in a unicast packet with
the End-to-End Cookie wrong or zero when WATO is not disabled or is
one 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 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 cookie the remote system expects to weakly authenticate
the source address. 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 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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[should IPv6 cookies be 64 bit? probably not worth going to more than
32 bits given the other weaknesses of the WATO.]
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.
Fields with the same name have the same meaning as for the IPv4
option. *-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 the HOP count was set to
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 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.
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,
and 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.
5.1 WATO Soft State
A host participating in WATO processing must maintain some state
associated with local/remote IP unicast address pairs as listed
below. 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 need 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 in the state on a host with 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 that 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
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
Donald E. Eastlake 3rd [Page 11]
INTERNET-DRAFT Weak Authentication and Tracing Option
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.)
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 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 disabled on send,
any existing WATO is passed on without modification.
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).
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
Donald E. Eastlake 3rd [Page 12]
INTERNET-DRAFT Weak Authentication and Tracing Option
- set the A-TTL (or A-HOP) field to the IP header TTL (or HOP) field,
and the Adjacent Address field to the 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 shouldn'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
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.
Donald E. Eastlake 3rd [Page 13]
INTERNET-DRAFT Weak Authentication and Tracing Option
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 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.
If the WATO is OK, the packet is passed on for further processing.
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 correcting giving the
required cookie of the type being set. If it is weakly
authenticated, it is considered confirmed. A proposed cookie is
remembered and used only if there is no confirmed cookie. A
confirmed cookie replaces any existing confirmed or proposed cookie
and is remembered 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
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 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
Donald E. Eastlake 3rd [Page 14]
INTERNET-DRAFT Weak Authentication and Tracing Option
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 should 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 [RFC1750] and
the middle four bits 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.
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 [RFC1321, HMAC] 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 weaker mixing function such as use as hashing the
concatenation of the secret and the remote IP address with a subset
of the calculations called for in MD5 or MD4.
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 just means
during the period between intersystem packet transmissions which
could be a substantial time interval.) 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 remote
cookie for that pair is cleared
Donald E. Eastlake 3rd [Page 18]
INTERNET-DRAFT Weak Authentication and Tracing Option
8. Tunneling and Fragmentation
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.
Insertion of the WATO option at an intermediate point can increase
packet size, cause fragmentation, and decrease apparent path MTU.
9. Deployment
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. This will
improve the reliability of WATO tracing information delivered to the
destinantion.
Firewalls can proxy for machines behind them so as to support
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
10. Security Considerations
It can not be emphasised too strongly 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 mean that it would no longer be
possible 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 certainly also be used for cookie sniffing.
In addition WATO provides almost no protection again 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. Analysis of enough packets
should enable tracing the path back to the host which is doing the
forging unless it is on your local media.
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
[RFC1321] - MD5
[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
Author's Address
Donald E. Eastlake 3rd
CyberCash, Inc.
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 508 287 4877
+1 703 620-4200 (main office, Reston, VA)
FAX: +1 508 371 7148
EMail: dee@cybercash.com
Expiration and File Name
This draft expires 25 May 1997.
Its file name is draft-eastlake-weak-ato-00.txt.
Donald E. Eastlake 3rd [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-23 21:18:52 |