Appendix C - Appendix H
Intentionally Left Blank
APPENDIX I
Network Working Group
Request for Comment: 2003
Category: Standards Track
C. Perkins
IBM
October 1996
IP Encapsulation within IP
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document specifies a method by which an IP datagram may be
encapsulated (carried as payload) within an IP datagram.
Encapsulation is suggested as a means to alter the normal IP routing
for datagrams, by delivering them to an intermediate destination that
would otherwise not be selected by the (network part of the) IP
Destination Address field in the original IP header. Encapsulation
may serve a variety of purposes, such as delivery of a datagram to a
mobile node using Mobile IP.
1. Introduction
This document specifies a method by which an IP datagram may be
encapsulated (carried as payload) within an IP datagram.
Encapsulation is suggested as a means to alter the normal IP routing
for datagrams, by delivering them to an intermediate destination that
would otherwise not be selected based on the (network part of the) IP
Destination Address field in the original IP header. Once the
encapsulated datagram arrives at this intermediate destination node,
it is decapsulated, yielding the original IP datagram, which is then
delivered to the destination indicated by the original Destination
Address field. This use of encapsulation and decapsulation of a
datagram is frequently referred to as "tunneling" the datagram, and
the encapsulator and decapsulator are then considered to be the
"endpoints" of the tunnel.
In the most general tunneling case we have
source ---> encapsulator --------> decapsulator ---> destination
with the source, encapsulator, decapsulator, and destination being
separate nodes. The encapsulator node is considered the "entry
Perkins
Standards Track
[Page 1]
APPENDIX I
RFC 2003
IP-within-IP
October 1996
point" of the tunnel, and the decapsulator node is considered the
"exit point" of the tunnel. There in general may be multiple
source-destination pairs using the same tunnel between the
encapsulator and decapsulator.
2. Motivation
The Mobile IP working group has specified the use of encapsulation as
a way to deliver datagrams from a mobile node’s "home network" to an
agent that can deliver datagrams locally by conventional means to the
mobile node at its current location away from home [8]. The use of
encapsulation may also be desirable whenever the source (or an
intermediate router) of an IP datagram must influence the route by
which a datagram is to be delivered to its ultimate destination.
Other possible applications of encapsulation include multicasting,
preferential billing, choice of routes with selected security
attributes, and general policy routing.
It is generally true that encapsulation and the IP loose source
routing option [10] can be used in similar ways to affect the routing
of a datagram, but there are several technical reasons to prefer
encapsulation:
-
There are unsolved security problems associated with the use of
the IP source routing options.
-
Current Internet routers exhibit performance problems when
forwarding datagrams that contain IP options, including the IP
source routing options.
-
Many current Internet nodes process IP source routing options
incorrectly.
-
Firewalls may exclude IP source-routed datagrams.
-
Insertion of an IP source route option may complicate the
processing of authentication information by the source and/or
destination of a datagram, depending on how the authentication is
specified to be performed.
-
It is considered impolite for intermediate routers to make
modifications to datagrams which they did not originate.
These technical advantages must be weighed against the disadvantages
posed by the use of encapsulation:
-
Perkins
Encapsulated datagrams typically are larger than source routed
datagrams.
Standards Track
[Page 2]
APPENDIX I
RFC 2003
-
IP-within-IP
October 1996
Encapsulation cannot be used unless it is known in advance that
the node at the tunnel exit point can decapsulate the datagram.
Since the majority of Internet nodes today do not perform well when
IP loose source route options are used, the second technical
disadvantage of encapsulation is not as serious as it might seem at
first.
3. IP in IP Encapsulation
To encapsulate an IP datagram using IP in IP encapsulation, an outer
IP header [10] is inserted before the datagram’s existing IP header,
as follows:
+---------------------------+
|
|
|
Outer IP Header
|
|
|
+---------------------------+
+---------------------------+
|
|
|
|
|
IP Header
|
|
IP Header
|
|
|
|
|
+---------------------------+ ====> +---------------------------+
|
|
|
|
|
|
|
|
|
IP Payload
|
|
IP Payload
|
|
|
|
|
|
|
|
|
+---------------------------+
+---------------------------+
The outer IP header Source Address and Destination Address identify
the "endpoints" of the tunnel. The inner IP header Source Address
and Destination Addresses identify the original sender and recipient
of the datagram, respectively. The inner IP header is not changed by
the encapsulator, except to decrement the TTL as noted below, and
remains unchanged during its delivery to the tunnel exit point. No
change to IP options in the inner header occurs during delivery of
the encapsulated datagram through the tunnel. If need be, other
protocol headers such as the IP Authentication header [1] may be
inserted between the outer IP header and the inner IP header. Note
that the security options of the inner IP header MAY affect the
choice of security options for the encapsulating (outer) IP header.
Perkins
Standards Track
[Page 3]
APPENDIX I
RFC 2003
IP-within-IP
October 1996
3.1. IP Header Fields and Handling
The fields in the outer IP header are set by the encapsulator as
follows:
Version
4
IHL
The Internet Header Length (IHL) is the length of the outer IP
header measured in 32-bit words [10].
TOS
The Type of Service (TOS) is copied from the inner IP header.
Total Length
The Total Length measures the length of the entire encapsulated
IP datagram, including the outer IP header, the inner IP
header, and its payload.
Identification, Flags, Fragment Offset
These three fields are set as specified in [10]. However,
the "Don’t Fragment" bit is set in the inner IP header, it
be set in the outer IP header; if the "Don’t Fragment" bit
not set in the inner IP header, it MAY be set in the outer
header, as described in Section 5.1.
if
MUST
is
IP
Time to Live
The Time To Live (TTL) field in the outer IP header is set to a
value appropriate for delivery of the encapsulated datagram to
the tunnel exit point.
Protocol
4
Header Checksum
The Internet Header checksum [10] of the outer IP header.
Perkins
Standards Track
[Page 4]
APPENDIX I
RFC 2003
IP-within-IP
October 1996
Source Address
The IP address of the encapsulator, that is, the tunnel entry
point.
Destination Address
The IP address of the decapsulator, that is, the tunnel exit
point.
Options
Any options present in the inner IP header are in general NOT
copied to the outer IP header. However, new options specific
to the tunnel path MAY be added. In particular, any supported
types of security options of the inner IP header MAY affect the
choice of security options for the outer header. It is not
expected that there be a one-to-one mapping of such options to
the options or security headers selected for the tunnel.
When encapsulating a datagram, the TTL in the inner IP header is
decremented by one if the tunneling is being done as part of
forwarding the datagram; otherwise, the inner header TTL is not
changed during encapsulation. If the resulting TTL in the inner IP
header is 0, the datagram is discarded and an ICMP Time Exceeded
message SHOULD be returned to the sender. An encapsulator MUST NOT
encapsulate a datagram with TTL = 0.
The TTL in the inner IP header is not changed when decapsulating.
If, after decapsulation, the inner datagram has TTL = 0, the
decapsulator MUST discard the datagram. If, after decapsulation, the
decapsulator forwards the datagram to one of its network interfaces,
it will decrement the TTL as a result of doing normal IP forwarding.
See also Section 4.4.
The encapsulator may use any existing IP mechanisms appropriate for
delivery of the encapsulated payload to the tunnel exit point. In
particular, use of IP options is allowed, and use of fragmentation is
allowed unless the "Don’t Fragment" bit is set in the inner IP
header. This restriction on fragmentation is required so that nodes
employing Path MTU Discovery [7] can obtain the information they
seek.
3.2. Routing Failures
Routing loops within a tunnel are particularly dangerous when they
cause datagrams to arrive again at the encapsulator. Suppose a
datagram arrives at a router for forwarding, and the router
Perkins
Standards Track
[Page 5]
APPENDIX I
RFC 2003
IP-within-IP
October 1996
determines that the datagram has to be encapsulated before further
delivery. Then:
-
If the IP Source Address of the datagram matches the router’s own
IP address on any of its network interfaces, the router MUST NOT
tunnel the datagram; instead, the datagram SHOULD be discarded.
-
If the IP Source Address of the datagram matches the IP address
of the tunnel destination (the tunnel exit point is typically
chosen by the router based on the Destination Address in the
datagram’s IP header), the router MUST NOT tunnel the datagram;
instead, the datagram SHOULD be discarded.
See also Section 4.4.
4. ICMP Messages from within the Tunnel
After an encapsulated datagram has been sent, the encapsulator may
receive an ICMP [9] message from any intermediate router within the
tunnel other than the tunnel exit point. The action taken by the
encapsulator depends on the type of ICMP message received. When the
received message contains enough information, the encapsulator MAY
use the incoming message to create a similar ICMP message, to be sent
to the originator of the original unencapsulated IP datagram (the
original sender). This process will be referred to as "relaying" the
ICMP message from the tunnel.
ICMP messages indicating an error in processing a datagram include a
copy of (a portion of) the datagram causing the error. Relaying an
ICMP message requires that the encapsulator strip off the outer IP
header from this returned copy of the original datagram. For cases
in which the received ICMP message does not contain enough data to
relay the message, see Section 5.
4.1. Destination Unreachable (Type 3)
ICMP Destination Unreachable messages are handled by the encapsulator
depending upon their Code field. The model suggested here allows the
tunnel to "extend" a network to include non-local (e.g., mobile)
nodes. Thus, if the original destination in the unencapsulated
datagram is on the same network as the encapsulator, certain
Destination Unreachable Code values may be modified to conform to the
suggested model.
Perkins
Standards Track
[Page 6]
APPENDIX I
RFC 2003
IP-within-IP
October 1996
Network Unreachable (Code 0)
An ICMP Destination Unreachable message SHOULD be returned
to the original sender. If the original destination in
the unencapsulated datagram is on the same network as the
encapsulator, the newly generated Destination Unreachable
message sent by the encapsulator MAY have Code 1 (Host
Unreachable), since presumably the datagram arrived at the
correct network and the encapsulator is trying to create the
appearance that the original destination is local to that
network even if it is not. Otherwise, if the encapsulator
returns a Destination Unreachable message, the Code field MUST
be set to 0 (Network Unreachable).
Host Unreachable (Code 1)
The encapsulator SHOULD relay Host Unreachable messages to the
sender of the original unencapsulated datagram, if possible.
Protocol Unreachable (Code 2)
When the encapsulator receives an ICMP Protocol Unreachable
message, it SHOULD send a Destination Unreachable message with
Code 0 or 1 (see the discussion for Code 0) to the sender of
the original unencapsulated datagram. Since the original
sender did not use protocol 4 in sending the datagram, it would
be meaningless to return Code 2 to that sender.
Port Unreachable (Code 3)
This Code should never be received by the encapsulator, since
the outer IP header does not refer to any port number. It MUST
NOT be relayed to the sender of the original unencapsulated
datagram.
Datagram Too Big (Code 4)
The encapsulator MUST relay ICMP Datagram Too Big messages to
the sender of the original unencapsulated datagram.
Source Route Failed (Code 5)
This Code SHOULD be handled by the encapsulator itself.
It MUST NOT be relayed to the sender of the original
unencapsulated datagram.
Perkins
Standards Track
[Page 7]
APPENDIX I
RFC 2003
IP-within-IP
October 1996
4.2. Source Quench (Type 4)
The encapsulator SHOULD NOT relay ICMP Source Quench messages to the
sender of the original unencapsulated datagram, but instead SHOULD
activate whatever congestion control mechanisms it implements to help
alleviate the congestion detected within the tunnel.
4.3. Redirect (Type 5)
The encapsulator MAY handle the ICMP Redirect messages itself.
MUST NOT not relay the Redirect to the sender of the original
unencapsulated datagram.
It
4.4. Time Exceeded (Type 11)
ICMP Time Exceeded messages report (presumed) routing loops within
the tunnel itself. Reception of Time Exceeded messages by the
encapsulator MUST be reported to the sender of the original
unencapsulated datagram as Host Unreachable (Type 3, Code 1). Host
Unreachable is preferable to Network Unreachable; since the datagram
was handled by the encapsulator, and the encapsulator is often
considered to be on the same network as the destination address in
the original unencapsulated datagram, then the datagram is considered
to have reached the correct network, but not the correct destination
node within that network.
4.5. Parameter Problem (Type 12)
If the Parameter Problem message points to a field copied from the
original unencapsulated datagram, the encapsulator MAY relay the ICMP
message to the sender of the original unencapsulated datagram;
otherwise, if the problem occurs with an IP option inserted by the
encapsulator, then the encapsulator MUST NOT relay the ICMP message
to the original sender. Note that an encapsulator following
prevalent current practice will never insert any IP options into the
encapsulated datagram, except possibly for security reasons.
4.6. Other ICMP Messages
Other ICMP messages are not related to the encapsulation operations
described within this protocol specification, and should be acted on
by the encapsulator as specified in [9].
Perkins
Standards Track
[Page 8]
APPENDIX I
RFC 2003
IP-within-IP
October 1996
5. Tunnel Management
Unfortunately, ICMP only requires IP routers to return 8 octets (64
bits) of the datagram beyond the IP header. This is not enough to
include a copy of the encapsulated (inner) IP header, so it is not
always possible for the encapsulator to relay the ICMP message from
the interior of a tunnel back to the original sender. However, by
carefully maintaining "soft state" about tunnels into which it sends,
the encapsulator can return accurate ICMP messages to the original
sender in most cases. The encapsulator SHOULD maintain at least the
following soft state information about each tunnel:
- MTU of the tunnel (Section 5.1)
- TTL (path length) of the tunnel
- Reachability of the end of the tunnel
The encapsulator uses the ICMP messages it receives from the interior
of a tunnel to update the soft state information for that tunnel.
ICMP errors that could be received from one of the routers along the
tunnel interior include:
-
Datagram Too Big
Time Exceeded
Destination Unreachable
Source Quench
When subsequent datagrams arrive that would transit the tunnel, the
encapsulator checks the soft state for the tunnel. If the datagram
would violate the state of the tunnel (for example, the TTL of the
new datagram is less than the tunnel "soft state" TTL) the
encapsulator sends an ICMP error message back to the sender of the
original datagram, but also encapsulates the datagram and forwards it
into the tunnel.
Using this technique, the ICMP error messages sent by the
encapsulator will not always match up one-to-one with errors
encountered within the tunnel, but they will accurately reflect the
state of the network.
Tunnel soft state was originally developed for the IP Address
Encapsulation (IPAE) specification [4].
5.1. Tunnel MTU Discovery
When the Don’t Fragment bit is set by the originator and copied into
the outer IP header, the proper MTU of the tunnel will be learned
from ICMP Datagram Too Big (Type 3, Code 4) messages reported to the
encapsulator. To support sending nodes which use Path MTU Discovery,
Perkins
Standards Track
[Page 9]
APPENDIX I
RFC 2003
IP-within-IP
October 1996
all encapsulator implementations MUST support Path MTU Discovery [5,
7] soft state within their tunnels. In this particular application,
there are several advantages:
-
As a benefit of Path MTU Discovery within the tunnel, any
fragmentation which occurs because of the size of the
encapsulation header is performed only once after encapsulation.
This prevents multiple fragmentation of a single datagram, which
improves processing efficiency of the decapsulator and the
routers within the tunnel.
-
If the source of the unencapsulated datagram is doing Path MTU
Discovery, then it is desirable for the encapsulator to know
the MTU of the tunnel. Any ICMP Datagram Too Big messages from
within the tunnel are returned to the encapsulator, and as noted
in Section 5, it is not always possible for the encapsulator to
relay ICMP messages to the source of the original unencapsulated
datagram. By maintaining "soft state" about the MTU of the
tunnel, the encapsulator can return correct ICMP Datagram Too Big
messages to the original sender of the unencapsulated datagram to
support its own Path MTU Discovery. In this case, the MTU that
is conveyed to the original sender by the encapsulator SHOULD
be the MTU of the tunnel minus the size of the encapsulating
IP header. This will avoid fragmentation of the original IP
datagram by the encapsulator.
-
If the source of the original unencapsulated datagram is
not doing Path MTU Discovery, it is still desirable for the
encapsulator to know the MTU of the tunnel. In particular, it is
much better to fragment the original datagram when encapsulating,
than to allow the encapsulated datagram to be fragmented.
Fragmenting the original datagram can be done by the encapsulator
without special buffer requirements and without the need to
keep reassembly state in the decapsulator. By contrast, if
the encapsulated datagram is fragmented, then the decapsulator
must reassemble the fragmented (encapsulated) datagram before
decapsulating it, requiring reassembly state and buffer space
within the decapsulator.
Thus, the encapsulator SHOULD normally do Path MTU Discovery,
requiring it to send all datagrams into the tunnel with the "Don’t
Fragment" bit set in the outer IP header. However there are problems
with this approach. When the original sender sets the "Don’t
Fragment" bit, the sender can react quickly to any returned ICMP
Datagram Too Big error message by retransmitting the original
datagram. On the other hand, suppose that the encapsulator receives
an ICMP Datagram Too Big message from within the tunnel. In that
case, if the original sender of the unencapsulated datagram had not
Perkins
Standards Track
[Page 10]
APPENDIX I
RFC 2003
IP-within-IP
October 1996
set the "Don’t Fragment" bit, there is nothing sensible that the
encapsulator can do to let the original sender know of the error.
The encapsulator MAY keep a copy of the sent datagram whenever it
tries increasing the tunnel MTU, in order to allow it to fragment and
resend the datagram if it gets a Datagram Too Big response.
Alternatively the encapsulator MAY be configured for certain types of
datagrams not to set the "Don’t Fragment" bit when the original
sender of the unencapsulated datagram has not set the "Don’t
Fragment" bit.
5.2. Congestion
An encapsulator might receive indications of congestion from the
tunnel, for example, by receiving ICMP Source Quench messages from
nodes within the tunnel. In addition, certain link layers and
various protocols not related to the Internet suite of protocols
might provide such indications in the form of a Congestion
Experienced [6] flag. The encapsulator SHOULD reflect conditions of
congestion in its "soft state" for the tunnel, and when subsequently
forwarding datagrams into the tunnel, the encapsulator SHOULD use
appropriate means for controlling congestion [3]; However, the
encapsulator SHOULD NOT send ICMP Source Quench messages to the
original sender of the unencapsulated datagram.
6. Security Considerations
IP encapsulation potentially reduces the security of the Internet,
and care needs to be taken in the implementation and deployment of IP
encapsulation. For example, IP encapsulation makes it difficult for
border routers to filter datagrams based on header fields. In
particular, the original values of the Source Address, Destination
Address, and Protocol fields in the IP header, and the port numbers
used in any transport header within the datagram, are not located in
their normal positions within the datagram after encapsulation.
Since any IP datagram can be encapsulated and passed through a
tunnel, such filtering border routers need to carefully examine all
datagrams.
6.1. Router Considerations
Routers need to be aware of IP encapsulation protocols in order to
correctly filter incoming datagrams. It is desirable that such
filtering be integrated with IP authentication [1]. Where IP
authentication is used, encapsulated packets might be allowed to
enter an organization when the encapsulating (outer) packet or the
encapsulated (inner) packet is sent by an authenticated, trusted
source. Encapuslated packets containing no such authentication
represent a potentially large security risk.
Perkins
Standards Track
[Page 11]
APPENDIX I
RFC 2003
IP-within-IP
October 1996
IP datagrams which are encapsulated and encrypted [2] might also pose
a problem for filtering routers. In this case, the router can filter
the datagram only if it shares the security association used for the
encryption. To allow this sort of encryption in environments in
which all packets need to be filtered (or at least accounted for), a
mechanism must be in place for the receiving node to securely
communicate the security association to the border router. This
might, more rarely, also apply to the security association used for
outgoing datagrams.
6.2. Host Considerations
Host implementations that are capable of receiving encapsulated IP
datagrams SHOULD admit only those datagrams fitting into one or more
of the following categories:
-
The protocol is harmless:
not needed.
source address-based authentication is
-
The encapsulating (outer) datagram comes from an authentically
identified, trusted source. The authenticity of the source could
be established by relying on physical security in addition to
border router configuration, but is more likely to come from use
of the IP Authentication header [1].
-
The encapuslated (inner) datagram includes an IP Authentication
header.
-
The encapsulated (inner) datagram is addressed to a network
interface belonging to the decapsulator, or to a node with which
the decapsulator has entered into a special relationship for
delivering such encapsulated datagrams.
Some or all of this checking could be done in border routers rather
than the receiving node, but it is better if border router checks are
used as backup, rather than being the only check.
Perkins
Standards Track
[Page 12]
APPENDIX I
RFC 2003
IP-within-IP
October 1996
7. Acknowledgements
Parts of Sections 3 and 5 of this document were taken from portions
(authored by Bill Simpson) of earlier versions of the Mobile IP
Internet Draft [8]. The original text for section 6 (Security
Considerations) was contributed by Bob Smart. Good ideas have also
been included from RFC 1853 [11], also authored by Bill Simpson.
Thanks also to Anders Klemets for finding mistakes and suggesting
improvements to the draft. Finally, thanks to David Johnson for
going over the draft with a fine-toothed comb, finding mistakes,
improving consistency, and making many other improvements to the
draft.
References
[1] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[2] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
August 1995.
[3] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[4] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: The SIPP
Interoperability and Transition Mechanism", Work in Progress.
[5] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[6] Mankin, A., and K. Ramakrishnan, "Gateway Congestion Control
Survey", RFC 1254, August 1991.
[7] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[8] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
October 1996.
[9] Postel, J., Editor, "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[10] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
[11] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
Perkins
Standards Track
[Page 13]
APPENDIX I
RFC 2003
IP-within-IP
October 1996
Author’s Address
Questions about this memo can be directed to:
Charles Perkins
Room H3-D34
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532
Work:
+1-914-784-7350
Fax:
+1-914-784-6205
EMail: perk@watson.ibm.com
The working group can be contacted via the current chair:
Jim Solomon
Motorola, Inc.
1301 E. Algonquin Rd.
Schaumburg, IL 60196
Work:
+1-847-576-2753
EMail: solomon@comm.mot.com
Perkins
Standards Track
[Page 14]
Appendix J - Appendix M
Intentionally Left Blank
APPENDIX N
doc.: IEEE 802.11-05/0710r0
July 2005
IEEE P802.11
Wireless LANs
“WDS” Clarifications
Date: 2005-07-19
Author(s):
Name
Darwin
Engwer
Company
Nortel
Address
4655 Great America Pkwy,
Santa Clara, CA 95054
Phone
email
+1 408-495-7099
dengwer@nortel.com
Abstract
This document clarifies the term “WDS” as defined and described in IEEE 802.11-1999, noting that
the term is actually NOT defined and described and there is much confusion on this point. To prevent
further confusion the author recommends reducing the use of or deprecating the term in favour of the
underlying mechanism.
Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the
contributing individual(s) or organization(s). The material in this document is subject to change in form and content after
further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE
Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and
accepts that this contribution may be made public by IEEE 802.11.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http://
ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s),
including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of
patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development
process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
<stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under
patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you
have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
Submission
page 1
Darwin Engwer, Nortel
APPENDIX N
doc.: IEEE 802.11-05/0710r0
July 2005
Introduction
There is some confusion surrounding the IEEE 802.11-1999 term "WDS" (Wireless Distribution System).
Readers of the standard often misinterpret a WDS as:
a) a wireless DS
b) a DS that operates over a WLAN
A WDS (as defined by IEEE 802.11-1999) is neither. The misinterpretations perhaps result from an
extremely poor choice in naming the WDS capability, i.e. the inherent overloading of the term
“distribution system” and the abbreviated form “DS”. The “WDS” capability actually has nothing to do
with either of those other terms as this document will show.
Historical Analysis
The analysis begins with a review of the explicit references to the term WDS within 802.11-1999. There
are only two:
clause 4, where the acronym is defined
clause 7, where the frame control field is defined
Existing references to “WDS” in IEEE 802.11-1999:
4. Abbreviations and acronyms
“WDS wireless distribution system”
7.1.3.1 Frame Control field
Table 2—To/From DS combinations in data type frames
To/From DS values
Meaning
To DS = 0, From DS = 0
A data frame direct from one STA to another STA within the same IBSS,
as well as all management and control type frames.
To DS = 0, From DS = 1
Data frame exiting the DS.
To DS = 1, From DS = 0
Data frame destined for the DS.
To DS = 1, From DS = 1
Wireless distribution system (WDS) frame being distributed from one AP
to another AP.
Table 2 indirectly references clause 7.2.2 and Table 4:
7.2.2 Data frames
The content of the Address fields of the data frame is dependent upon the values of the To DS and From
DS bits and is defined in Table 4. Where the content of a field is shown as not applicable (N/A), the field
is omitted. Note that Address 1 always holds the receiver address of the intended receiver (or, in the case
of multicast frames, receivers), and that Address 2 always holds the address of the station that is
transmitting the frame.
To DS
0
0
1
1
Submission
From DS
0
1
0
1
Table 4 – Address field contents
Address 1
Address 2
Address 3
RA = DA
TA = SA
BSSID
RA = DA
TA = BSSID
SA
RA = BSSID
TA = SA
DA
RA
TA
DA
page 2
Address 4
N/A
N/A
N/A
SA
Darwin Engwer, Nortel
APPENDIX N
doc.: IEEE 802.11-05/0710r0
July 2005
Explanation
Here is a new, extended table that shows all those aspects together:
Table 5/710-T01: ToDs/ FromDS, Address Fields and Entities
ID Mode ToDS FromDS # of
Ext.
802.11
Flow 802.11
Address Entity Entity 1
Entity 2
Fields
ßà ad hoc
A Ad
0
0
3
ad hoc
hoc
STA
STA
infra mode
ß
B LAN
0
1
3
ACM_STA
STA
access
in an AP
infra mode
à ACM_STA
C LAN
1
0
3
STA
access
in an AP
ßà ??
D 4A
1
1
4
yy
??
Ext.
Entity
802.111999
clauses
5.6
xx
5.6
xx
5.6
zz
None
In case A both Entity 1 and Entity 2 are STAs operating in IBSS (aka ad hoc) mode.
Cases B and C describe an infrastructure mode STA accessing an external entity on the integrated nonIEEE 802.11 LAN through an AP and DS. The external entity is referred to as “xx”. Yes, an
infrastructure mode STA could be transferring data to another infrastructure mode STA, but note that
such traffic (from xx1 to xx2) transits the AP and also conceptually transits the DS.
Case D describes the 4 address scenario, referred to here as 4 Address (4A) mode, where the ultimate
source/ destination addresses can be something other than the Entity 1/ Entity 2 TA/RA or RA/TA
addresses.
4A mode can be used to construct a number of different types of devices, products and/ or systems.
Analysis
Hence, “WDS” is simply a mechanism for constructing 802.11 frames using the 4-address format, as
shown in the last row of Table 4 and subsequently the last row of Table 5/710-T01. The application of
the four-address addressing type and procedures for operating STAs that uses that type of addressing are
not defined or described by IEEE 802.11-1999.
The 4-address format enables the implementation of devices that move MPDUs between various points,
i.e. a relay type devices.
For example, the 4-address mechanism can be used to build some special products, like:
a) a point-to-point (or bldg-to-bldg) bridge,
b) a wireless Access Unit (AU), aka repeater AU (i.e. an AU, which includes an AP, with a wireless
backhaul connection to a real AU which in turn has a direct connection to the uplink network),
c) an infrastructure mode STA with bridging capabilities,
d) an 802.11 DS where the DSM is constructed from 802.11 STAs (the elusive, true, “wireless
distribution system”),
e) and so on.
The IEEE 802.11-1999 standard does not define how to construct any such implementations or how
stations interact to arrange for exchanging frames of this format, it merely defines the 4-address frame
format that makes it possible. Neither does the standard define all the other supporting operations or
protocols that would be required to build such devices.
Submission
page 3
Darwin Engwer, Nortel
APPENDIX N
doc.: IEEE 802.11-05/0710r0
July 2005
Example Instantiations
The collection of diagrams below help to illustrate some examples of the uses of the various addressing
modes.
1.
2.
3.
4.
5.
6.
7.
802.11 ad hoc LAN
802.11 Access Unit (connecting to non-IEEE 802.11 LAN)
large scale 802.11 LAN (with multiple APs connecting to non-IEEE 802.11 LAN)
point-to-point bridge (constructed from 802.11 4A-mode STAs)
802.11 DS (constructed from 802.11 4A-mode STAs)
large scale 802.11 LAN with 4A-mode STAs with bridging
large scale 802.11 LAN with fully wireless Access Units
July 2005
doc.: IEEE 802.11-05/0710r0
802.11 ad hoc LAN
A
ad hoc
STA
A
ad hoc
STA
A
ad hoc
STA
Submission
Submission
Slide 4
Darwin Engwer, Nortel
page 4
Darwin Engwer, Nortel
APPENDIX N
doc.: IEEE 802.11-05/0710r0
July 2005
July 2005
doc.: IEEE 802.11-05/0710r0
802.11 Access Unit
connecting to a non 802.11 LAN
non 802.11 LAN
Portal
Access
Unit
DS
AP
ACM_STA
B/C
B/C
Infra mode
STA
Infra mode
STA
Submission
Slide 5
July 2005
Darwin Engwer, Nortel
doc.: IEEE 802.11-05/0710r0
Large scale 802.11 access LAN
with multiple APs connecting to a non 802.11 LAN
non 802.11 LAN
Portal
DS
AP
AP
ACM_STA
ACM_STA
B/C
Infra mode
STA
Submission
Submission
B/C
B/C
Infra mode
STA
Infra mode
STA
Slide 6
Darwin Engwer, Nortel
page 5
Darwin Engwer, Nortel
APPENDIX N
doc.: IEEE 802.11-05/0710r0
July 2005
July 2005
doc.: IEEE 802.11-05/0710r0
Point-to-point bridges
constructed from 802.11 4A mode STAs
non 802.11 LAN “A”
Bridge
4A STA
Point-to-point
bridge
D
4A STA
Bridge
Point-to-point
bridge
non 802.11 LAN “B”
Submission
Slide 7
Darwin Engwer, Nortel
July 2005
doc.: IEEE 802.11-05/0710r0
802.11-based DS
constructed from 802.11 4A mode STAs
non 802.11 LAN
Portal
DS
4A STA
D
D
4A STA
4A STA
D
AP
ACM_STA
Submission
Submission
AP
ACM_STA
B/C
B/C
Infra mode
STA
Infra mode
STA
Slide 8
Darwin Engwer, Nortel
page 6
Darwin Engwer, Nortel
APPENDIX N
doc.: IEEE 802.11-05/0710r0
July 2005
July 2005
doc.: IEEE 802.11-05/0710r0
Large scale 802.11 access LAN
with 4A mode STA with bridging
non 802.11 LAN
Portal
DS
AP
ACM_STA
B/C
AP
ACM_STA
D
Infra mode
STA
B/C
4A STA
Infra mode
STA
non-802.11
STA
Submission
Bridge
4A mode
STA with
bridging
non-802.11
STA
non-802.11
STA
Slide 9
July 2005
Darwin Engwer, Nortel
doc.: IEEE 802.11-05/0710r0
Large scale 802.11 access LAN
with a wireless Access Unit
non 802.11 LAN
Portal
DS
AP
ACM_STA
B/C
Infra mode
STA
AP
ACM_STA
D
B/C
4A STA
Infra mode
STA
AP
ACM_STA
Wireless
Access
Unit
B/C
Infra mode
STA
Submission
Submission
Slide 10
Darwin Engwer, Nortel
page 7
Darwin Engwer, Nortel
APPENDIX N
doc.: IEEE 802.11-05/0710r0
July 2005
Summary
The 4-address frame format does not itself constitute a wireless distribution system or a wireless DS, it is
simply a frame addressing mechanism that allows creation of a multitude of specialized implementations,
one of which could be a wireless distribution system.
Conclusion
References to the term WDS should be reduced, or perhaps the term could even be considered for
deprecation. The material with respect to the 4-address addressing mechanism is valid, valuable and
should be maintained. At such time as new task groups define some specific uses for the 4-address
addressing mechanism that corresponding new material should be added to the appropriate clauses of the
standard to define the use of the 4 address mechanism for that specific purpose, while still allowing for
the addition of subsequent uses of the 4 address mechanism for other applications.
Submission
page 8
Darwin Engwer, Nortel
APPENDIX N
doc.: IEEE 802.11-05/0710r0
July 2005
References:
1. IEEE 802.11-1999
2. 11-05-0710-00-000m-wds-clarifications.ppt
-end-
Submission
page 9
Darwin Engwer, Nortel
Appendix O - Appendix S
Intentionally Left Blank
APPENDIX T
Wireless Networking
Basics
NETGEAR, Inc.
4500 Great America Parkway
Santa Clara, CA 95054 USA
n/a
October 2005
APPENDIX T
© 2005 by NETGEAR, Inc. All rights reserved.
Trademarks
NETGEAR and Auto Uplink are trademarks or registered trademarks of NETGEAR, Inc..
Microsoft, Windows, and Windows NT are registered trademarks of Microsoft Corporation.
Other brand and product names are registered trademarks or trademarks of their respective holders. Portions of this
document are copyright Intoto, Inc.
Statement of Conditions
In the interest of improving internal design, operational function, and/or reliability, NETGEAR reserves the right to
make changes to the products described in this document without notice.
NETGEAR does not assume any liability that may occur due to the use or application of the product(s) or circuit
layout(s) described herein.
Product and Publication Details
Model Number:
n/a
Publication Date:
October 2005
Product Family:
Product Family
Product Name:
n/a
Home or Business Product:
n/a
Language:
English
Publication Version Number:
1.0
ii
v1.0, October 2005
APPENDIX T
Contents
Wireless Networking Basics
Chapter 1
About This Manual
Audience, Scope, Conventions, and Formats ................................................................1-1
How to Use this Manual ..................................................................................................1-2
How to Print this Manual .................................................................................................1-2
Chapter 2
Wireless Networking Basics
Wireless Networking Overview .......................................................................................2-1
Infrastructure Mode ..................................................................................................2-1
Ad Hoc Mode (Peer-to-Peer Workgroup) .................................................................2-2
Network Name: Extended Service Set Identification (ESSID) .................................2-2
Wireless Channels ...................................................................................................2-2
WEP Wireless Security ...................................................................................................2-4
WEP Authentication .................................................................................................2-4
WEP Open System Authentication ..........................................................................2-5
WEP Shared Key Authentication .............................................................................2-6
How to Use WEP Parameters ..................................................................................2-8
WPA Wireless Security ...................................................................................................2-8
How Does WPA Compare to WEP? .........................................................................2-9
How Does WPA Compare to IEEE 802.11i? ...........................................................2-9
What are the Key Features of WPA Security? .......................................................2-10
Is WPA Perfect? .....................................................................................................2-15
Product Support for WPA .......................................................................................2-16
iii
v1.0, October 2005
APPENDIX T
iv
v1.0, October 2005
APPENDIX T
Chapter 1
About This Manual
This chapter describes the intended audience, scope, conventions, and formats of this manual.
Audience, Scope, Conventions, and Formats
This manual assumes that the reader has basic to intermediate computer and Internet skills.
However, basic computer network, Internet, and firewall technologies tutorial information is
provided on the NETGEAR Web site.
This manual uses the following typographical conventions:
Table 1-1. Typographical Conventions
italics
Emphasis, books, CDs, URL names
bold
User input
fixed font
Screen text, file and server names, extensions, commands, IP addresses
This manual uses the following formats to highlight special messages:
Note: This format is used to highlight information of importance or special interest.
Tip: This format is used to highlight a procedure that will save time or resources.
About This Manual
1-1
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
How to Use this Manual
The HTML version of this manual includes the following:
•
Buttons,
at a time
and
, for browsing forwards or backwards through the manual one page
•
A
button that displays the table of contents. Double-click on a link in the table of
contents to navigate directly to where the topic is described in the manual.
•
A
model.
•
Links to PDF versions of the full manual and individual chapters.
button to access the full NETGEAR, Inc. online knowledge base for the product
How to Print this Manual
To print this manual you can choose one of the following several options, according to your needs.
•
Printing a Page in the HTML View.
Each page in the HTML version of the manual is dedicated to a major topic. Use the Print
button on the browser toolbar to print the page contents.
•
Printing a Chapter.
Use the PDF of This Chapter link at the top left of any page.
— Click the “PDF of This Chapter” link at the top right of any page in the chapter you want
to print. The PDF version of the chapter you were viewing opens in a browser window.
— Your computer must have the free Adobe Acrobat reader installed in order to view and
print PDF files. The Acrobat reader is available on the Adobe Web site at
http://www.adobe.com.
— Click the print icon in the upper left of the window.
Tip: If your printer supports printing two pages on a single sheet of paper, you can
save paper and printer ink by selecting this feature.
1-2
About This Manual
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
•
Printing the Full Manual.
Use the Complete PDF Manual link at the top left of any page.
— Click the Complete PDF Manual link at the top left of any page in the manual. The PDF
version of the complete manual opens in a browser window.
— Click the print icon in the upper left of the window.
Tip: If your printer supports printing two pages on a single sheet of paper, you can
save paper and printer ink by selecting this feature.
About This Manual
1-3
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
1-4
About This Manual
v1.0, October 2005
APPENDIX T
Chapter 2
Wireless Networking Basics
Wireless Networking Overview
Some NETGEAR products conform to the Institute of Electrical and Electronics Engineers (IEEE)
802.11g standard for wireless LANs (WLANs). On an 802.11 wireless link, data is encoded using
direct-sequence spread-spectrum (DSSS) technology and is transmitted in the unlicensed radio
spectrum at 2.5 GHz. The maximum data rate for the 802.11g wireless link is 54 Mbps, but it will
automatically back down from 54 Mbps when the radio signal is weak or when interference is
detected.
The 802.11 standard is also called Wireless Ethernet or Wi-Fi by the Wireless Ethernet
Compatibility Alliance (WECA, see http://www.wi-fi.net), an industry standard group promoting
interoperability among 802.11 devices. The 802.11 standard offers two methods for configuring a
wireless network—ad hoc and infrastructure.
Infrastructure Mode
With a wireless access point, the wireless LAN can operate in the infrastructure mode. This mode
lets you connect wirelessly to wireless network devices within a fixed range or area of coverage.
The access point has one or more antennas that allow you to interact with wireless nodes.
In infrastructure mode, the wireless access point converts airwave data into wired Ethernet data,
acting as a bridge between the wired LAN and wireless clients. Connecting multiple access points
via a wired Ethernet backbone can further extend the wireless network coverage. As a mobile
computing device moves out of the range of one access point, it moves into the range of another.
As a result, wireless clients can freely roam from one access point domain to another and still
maintain seamless network connection.
Wireless Networking Basics
2-1
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
Ad Hoc Mode (Peer-to-Peer Workgroup)
In an ad hoc network, computers are brought together as needed; thus, the network has no structure
or fixed points—each node can be set up to communicate with any other node. No access point is
involved in this configuration. This mode enables you to quickly set up a small wireless
workgroup and allows workgroup members to exchange data or share printers as supported by
Microsoft® networking in the various Windows® operating systems. Some vendors also refer to ad
hoc networking as peer-to-peer group networking.
In this configuration, network packets are directly sent and received by the intended transmitting
and receiving stations. As long as the stations are within range of one another, this is the easiest
and least expensive way to set up a wireless network.
Network Name: Extended Service Set Identification (ESSID)
The Extended Service Set Identification (ESSID) is one of two types of Service Set Identification
(SSID). In an ad hoc wireless network with no access points, the Basic Service Set Identification
(BSSID) is used. In an infrastructure wireless network that includes an access point, the ESSID is
used, but may still be referred to as SSID.
An SSID is a 32-character (maximum) alphanumeric key identifying the name of the wireless local
area network. Some vendors refer to the SSID as the network name. For the wireless devices in a
network to communicate with each other, all devices must be configured with the same SSID.
Wireless Channels
IEEE 802.11g/b wireless nodes communicate with each other using radio frequency signals in the
ISM (Industrial, Scientific, and Medical) band between 2.4 GHz and 2.5 GHz. Neighboring
channels are 5 MHz apart. However, due to the spread spectrum effect of the signals, a node
sending signals using a particular channel will utilize frequency spectrum 12.5 MHz above and
below the center channel frequency. As a result, two separate wireless networks using neighboring
channels (for example, channel 1 and channel 2) in the same general vicinity will interfere with
each other. Applying two channels that allow the maximum channel separation will decrease the
amount of channel cross-talk and provide a noticeable performance increase over networks with
minimal channel separation.
2-2
Wireless Networking Basics
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
The radio frequency channels used are listed in Table 2-1:
Table 2-1. 802.11g Radio Frequency Channels
Channel
Center Frequency
Frequency Spread
1
2412 MHz
2399.5 MHz – 2424.5 MHz
2
2417 MHz
2404.5 MHz – 2429.5 MHz
3
2422 MHz
2409.5 MHz – 2434.5 MHz
4
2427 MHz
2414.5 MHz – 2439.5 MHz
5
2432 MHz
2419.5 MHz – 2444.5 MHz
6
2437 MHz
2424.5 MHz – 2449.5 MHz
7
2442 MHz
2429.5 MHz – 2454.5 MHz
8
2447 MHz
2434.5 MHz – 2459.5 MHz
9
2452 MHz
2439.5 MHz – 2464.5 MHz
10
2457 MHz
2444.5 MHz – 2469.5 MHz
11
2462 MHz
2449.5 MHz – 2474.5 MHz
12
2467 MHz
2454.5 MHz – 2479.5 MHz
13
2472 MHz
2459.5 MHz – 2484.5 MHz
Note: The available channels supported by wireless products in various countries are
different.
•
Regulations in the United States prohibit using channels greater than channel 11.
•
For NETGEAR products sold outside the United States, the wireless region
selection determines which channels are available for use in the product.
The preferred channel separation between the channels in neighboring wireless networks is
25 MHz (five channels). This means that you can apply up to three different channels within your
wireless network. In the United States, only 11 usable wireless channels are available, so we
recommended that you start using channel 1, grow to use channel 6, and add channel 11 when
necessary, because these three channels do not overlap.
Wireless Networking Basics
2-3
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
WEP Wireless Security
The absence of a physical connection between nodes makes the wireless links vulnerable to
eavesdropping and information theft. To provide a certain level of security, the IEEE 802.11
standard has defined two types of authentication methods, Open System and Shared Key. With
Open System authentication, a wireless computer can join any network and receive any messages
that are not encrypted. With Shared Key authentication, only those computers that possess the
correct authentication key can join the network. By default, IEEE 802.11 wireless devices operate
in an Open System network. Recently, Wi-Fi, the Wireless Ethernet Compatibility Alliance
(http://www.wi-fi.net) developed the Wi-Fi Protected Access (WPA), a new strongly enhanced WiFi security. WPA will soon be incorporated into the IEEE 802.11 standard. WEP (Wired
Equivalent Privacy) is discussed below, and WPA is discussed on page 2-8.
WEP Authentication
The 802.11 standard defines several services that govern how two 802.11 devices communicate.
The following events must occur before an 802.11 station can communicate with an Ethernet
network through an access point such as the one built in to the NETGEAR product:
1. Turn on the wireless station.
2. The station listens for messages from any access points that are in range.
3. The station finds a message from an access point that has a matching SSID.
4. The station sends an authentication request to the access point.
5. The access point authenticates the station.
6. The station sends an association request to the access point.
7. The access point associates with the station.
8. The station can now communicate with the Ethernet network through the access point.
An access point must authenticate a station before the station can associate with the access point or
communicate with the network. The IEEE 802.11 standard defines two types of WEP
authentication: Open System and Shared Key.
•
Open System Authentication allows any device to join the network, assuming that the device
SSID matches the access point SSID. Alternatively, the device can use the “ANY” SSID
option to associate with any available access point within range, regardless of its SSID.
•
Shared Key Authentication requires that the station and the access point have the same WEP
key to authenticate. These two authentication procedures are described below.
2-4
Wireless Networking Basics
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
WEP Open System Authentication
This process is illustrated below.
802.11 Authentication
Open System Steps
Access Point (AP)
1) Authentication request sent to AP
2) AP authenticates
IN TER N ET
Cable/DSL
ProSafeWirelessVPN Security Firewall
PWR
W LA N
ACT
FVM318
100
Enable
LNK/ACT
1
Client
attempting
to connect
MODEL
LO CA L
LNK
TEST
2
3
4
5
6
7
8
Cable or
DLS modem
3) Client connects to network
Figure 2-1
The following steps occur when two devices use Open System Authentication:
1. The station sends an authentication request to the access point.
2. The access point authenticates the station.
3. The station associates with the access point and joins the network.
Wireless Networking Basics
2-5
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
WEP Shared Key Authentication
This process is illustrated below.
802.11 Authentication
Shared Key Steps
Access Point (AP)
1) Authentication
request sent to AP
IN TER N ET
2) AP sends challenge text
Cable/DSL
ProSafeWirelessVPN Security Firewall
PWR
W LA N
MODEL
LO CA L
LNK
FVM318
100
TEST
ACT
Enable
LNK/ACT
1
2
3
4
5
6
7
Client
3) Client encrypts
attempting
challenge text and
to connect
sends it back to AP
8
Cable or
DLS modem
4) AP decrypts, and if correct,
authenticates client
5) Client connects to network
Figure 2-2
The following steps occur when two devices use Shared Key Authentication:
1. The station sends an authentication request to the access point.
2. The access point sends challenge text to the station.
3. The station uses its configured 64-bit or 128-bit default key to encrypt the challenge text, and
it sends the encrypted text to the access point.
4. The access point decrypts the encrypted text using its configured WEP key that corresponds to
the station’s default key. The access point compares the decrypted text with the original
challenge text. If the decrypted text matches the original challenge text, then the access point
and the station share the same WEP key, and the access point authenticates the station.
5. The station connects to the network.
If the decrypted text does not match the original challenge text (that is, the access point and station
do not share the same WEP key), then the access point will refuse to authenticate the station, and
the station will be unable to communicate with either the 802.11 network or Ethernet network.
2-6
Wireless Networking Basics
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
Key Size and Configuration
The IEEE 802.11 standard supports two types of WEP encryption: 40-bit and 128-bit.
The 64-bit WEP data encryption method allows for a five-character (40-bit) input. Additionally, 24
factory-set bits are added to the forty-bit input to generate a 64-bit encryption key. (The 24 factoryset bits are not user-configurable). This encryption key will be used to encrypt/decrypt all data
transmitted via the wireless interface. Some vendors refer to the 64-bit WEP data encryption as 40bit WEP data encryption because the user-configurable portion of the encryption key is 40 bits
wide.
The 128-bit WEP data encryption method consists of 104 user-configurable bits. Similar to the 40bit WEP data encryption method, the remaining 24 bits are factory-set and not user-configurable.
Some vendors allow passphrases to be entered instead of the cryptic hexadecimal characters to
ease encryption key entry.
The 128-bit encryption is stronger than 40-bit encryption, but 128-bit encryption may not be
available outside the United States due to U.S. export regulations.
When configured for 40-bit encryption, 802.11 products typically support up to four WEP keys.
Each 40-bit WEP key is expressed as five sets of two hexadecimal digits (0–9 and A–F). For
example, “12 34 56 78 90” is a 40-bit WEP key.
When configured for 128-bit encryption, 802.11g products typically support four WEP keys, but
some manufacturers support only one 128-bit key. The 128-bit WEP Key is expressed as 13 sets of
two hexadecimal digits (0–9 and A–F). For example, “12 34 56 78 90 AB CD EF 12 34 56 78 90”
is a 128-bit WEP key.
Typically, 802.11 access points can store up to four 128-bit WEP keys, but some 802.11 client
adapters can only store one. Therefore, make sure that your 802.11 access and client adapters’
configurations match.
Whatever keys you enter for an access point, you must also enter the same keys for the client
adapter in the same order. In other words, WEP key 1 on the AP must match WEP key 1 on the
client adapter, WEP key 2 on the AP must match WEP key 2 on the client adapter, etc.
Note: The access point and the client adapters can have different default WEP keys as
long as the keys are in the same order. In other words, the AP can use WEP key 2
as its default key to transmit, while a client adapter can use WEP key 3 as its
default key to transmit. The two devices will communicate as long as the access
point’s WEP key 2 is the same as the client’s WEP key 2, and the AP’s WEP key 3
is the same as the client’s WEP key 3.
Wireless Networking Basics
2-7
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
How to Use WEP Parameters
WEP data encryption is used when the wireless devices are configured to operate in Shared Key
authentication mode. There are two shared key methods implemented in most commercially
available products, 64-bit and 128-bit WEP data encryption.
Before enabling WEP on an 802.11 network, you must first consider what type of encryption you
require and the key size you want to use. Typically, there are three WEP Encryption options
available for 802.11 products:
•
Do Not Use WEP: The 802.11 network does not encrypt data. For authentication purposes,
the network uses Open System Authentication.
•
Use WEP for Encryption: A transmitting 802.11 device encrypts the data portion of every
packet it sends using a configured WEP key. The receiving 802.11g device decrypts the data
using the same WEP key. For authentication purposes, the 802.11g network uses Open System
Authentication.
•
Use WEP for Authentication and Encryption: A transmitting 802.11 device encrypts the
data portion of every packet it sends using a configured WEP key. The receiving 802.11 device
decrypts the data using the same WEP key. For authentication purposes, the 802.11 network
uses Shared Key Authentication.
Note: Some 802.11 access points also support Use WEP for Authentication Only
(Shared Key Authentication without data encryption). However, some NETGEAR
products do not offer this option.
WPA Wireless Security
Wi-Fi Protected Access (WPA) is a specification of standards-based, interoperable security
enhancements that increase the level of data protection and access control for existing and future
wireless LAN systems.
The IEEE introduced the WEP as an optional security measure to secure 802.11g (Wi-Fi) WLANs,
but inherent weaknesses in the standard soon became obvious. In response to this situation, the
Wi-Fi Alliance announced a new security architecture in October 2002 that remedies the
shortcomings of WEP. This standard, formerly known as Safe Secure Network (SSN), is designed
to work with existing 802.11 products and offers forward compatibility with 802.11i, the new
wireless security architecture being defined in the IEEE.
WPA offers the following benefits:
2-8
Wireless Networking Basics
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
•
•
•
•
Enhanced data privacy
Robust key management
Data origin authentication
Data integrity protection
Starting in August of 2003, all new Wi-Fi certified products had to support WPA, and all existing
Wi-Fi certified products had one year to comply with the new standard or lose their Wi-Fi
certification. NETGEAR has implemented WPA on client and access point products. As of August
2004, all Wi-Fi certified products must support WPA.
How Does WPA Compare to WEP?
WEP is a data encryption method and is not intended as a user authentication mechanism. WPA
user authentication is implemented using 802.1x and the Extensible Authentication Protocol
(EAP). Support for 802.1x authentication is required in WPA. In the 802.11 standard, 802.1x
authentication was optional. For details on EAP specifically, refer to IETF RFC 2284.
With 802.11 WEP, all access points and client wireless adapters on a particular wireless LAN must
use the same encryption key. A major problem with the 802.11 standard is that the keys are
cumbersome to change. If you do not update the WEP keys often, an unauthorized person with a
sniffing tool can monitor your network for less than a day and decode the encrypted messages.
Products based on the 802.11 standard alone offer system administrators no effective method to
update the keys.
For 802.11, WEP encryption is optional. For WPA, encryption using Temporal Key Integrity
Protocol (TKIP) is required. TKIP replaces WEP with a new encryption algorithm that is stronger
than the WEP algorithm, but that uses the calculation facilities present on existing wireless devices
to perform encryption operations. TKIP provides important data encryption enhancements
including a per-packet key mixing function, a message integrity check (MIC) named Michael, an
extended initialization vector (IV) with sequencing rules, and a re-keying mechanism. Through
these enhancements, TKIP addresses all known WEP vulnerabilities.
How Does WPA Compare to IEEE 802.11i?
WPA is forward-compatible with the IEEE 802.11i security specification currently under
development. WPA is a subset of the current 802.11i draft and uses certain pieces of the 802.11i
draft that were ready to bring to market in 2003, such as 802.1x and TKIP. The main pieces of the
802.11i draft that are not included in WPA are secure IBSS (Ad-Hoc mode), secure fast handoff
(for specialized 802.11 VoIP phones), as well as enhanced encryption protocols such as AESCCMP. These features are either not yet ready for market or will require hardware upgrades to
implement.
Wireless Networking Basics
2-9
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
What are the Key Features of WPA Security?
The following security features are included in the WPA standard:
• WPA Authentication
• WPA Encryption Key Management
•
–
Temporal Key Integrity Protocol (TKIP)
–
Michael message integrity code (MIC)
– AES Support
Support for a Mixture of WPA and WEP Wireless Clients
These features are discussed below.
WPA addresses most of the known WEP vulnerabilities and is primarily intended for wireless
infrastructure networks as found in the enterprise. This infrastructure includes stations, access
points, and authentication servers (typically Remote Authentication Dial-In User Service servers,
called RADIUS servers). The RADIUS server holds (or has access to) user credentials (for
example, user names and passwords) and authenticates wireless users before they gain access to
the network.
The strength of WPA comes from an integrated sequence of operations that encompass 802.1X/
EAP authentication and sophisticated key management and encryption techniques. Its major
operations include:
•
Network security capability determination. This occurs at the 802.11 level and is
communicated through WPA information elements in Beacon, Probe Response, and (Re)
Association Requests. Information in these elements includes the authentication method
(802.1X or Pre-shared key) and the preferred cipher suite (WEP, TKIP, or AES, which is
Advanced Encryption Standard).
The primary information conveyed in the Beacon frames is the authentication method and the
cipher suite. Possible authentication methods include 802.1X and Pre-shared key. Pre-shared
key is an authentication method that uses a statically configured passphrase on both the
stations and the access point. This removes the need for an authentication server, which in
many home and small office environments is neither available nor desirable. Possible cipher
suites include: WEP, TKIP, and AES. We say more about TKIP and AES when addressing data
privacy below.
•
Authentication. EAP over 802.1X is used for authentication. Mutual authentication is
gained by choosing an EAP type supporting this feature and is required by WPA. The 802.1X
port access control prevents full access to the network until authentication completes. The
802.1X EAPOL-Key packets are used by WPA to distribute per-session keys to those stations
successfully authenticated.
2-10
Wireless Networking Basics
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
The supplicant in the station uses the authentication and cipher suite information contained in
the information elements to decide which authentication method and cipher suite to use. For
example, if the access point is using the Pre-shared key method, then the supplicant need not
authenticate using full-blown 802.1X. Rather, the supplicant must simply prove to the access
point that it is in possession of the pre-shared key. If the supplicant detects that the service set
does not contain a WPA information element, then it knows it must use pre-WPA 802.1X
authentication and key management in order to access the network.
•
Key management. WPA features a robust key generation/management system that integrates
the authentication and data privacy functions. Keys are generated after successful
authentication and through a subsequent four-way handshake between the station and access
point.
•
Data Privacy (Encryption). Temporal Key Integrity Protocol (TKIP) is used to wrap WEP in
sophisticated cryptographic and security techniques to overcome most of its weaknesses.
•
Data integrity. TKIP includes a message integrity code (MIC) at the end of each plain text
message to ensure messages are not being spoofed.
Wireless Networking Basics
2-11
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
WPA Authentication:
Enterprise-level User Authentication via 802.1x/EAP and RADIUS
Wireless LAN
WPA
enabled
wireless
client with
“supplicant”
Login
Authentication
WPA enabled
Access Point
using
pre-shared key
or
802.1x
Wired Network with Optional
801.1x Port-based Network
Access Control
TCP/IP
Ports Closed
Until
TCP/IP
Ports Opened
After
Authentication
RADIUS Server
Login
Authentication
Certificate
Authority
(for
example,
Win Server,
Verisign,
etc.)
Figure 2-3
IEEE 802.1x offers an effective framework for authenticating and controlling user traffic to a
protected network, as well as providing a vehicle for dynamically varying data encryption keys via
EAP from a RADIUS server, for example. This framework enables using a central authentication
server, which employs mutual authentication, so that a rogue wireless user does not join the
network.
Note that 802.1x does not provide the actual authentication mechanisms. When using 802.1x, the
EAP type, such as Transport Layer Security (EAP-TLS) or EAP Tunneled Transport Layer
Security (EAP-TTLS), defines how the authentication takes place.
Note: For environments with a RADIUS infrastructure, WPA supports Extensible
Authentication Protocol (EAP). For environments without a RADIUS
infrastructure, WPA supports the use of a pre-shared key.
Together, these technologies provide a framework for strong user authentication.
2-12
Wireless Networking Basics
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
Windows XP implements 802.1x natively, and several NETGEAR switch and wireless access
point products support 802.1x.
Client with a WPAenabled wireless
adapter and supplicant
(Windows XP, Funk,
Meetinghouse, etc.)
For example, a
For example, a
WPA-enabled AP RADIUS server
1
2
3
4
6
5
7
Figure 2-4
The access point (AP) sends Beacon Frames with WPA information elements to the stations in the
service set. Information elements include the required authentication method (802.1x or Preshared key) and the preferred cipher suite (WEP, TKIP, or AES). Probe Responses (AP to station)
and Association Requests (station to AP) also contain WPA information elements.
1. Initial 802.1x communications begin with an unauthenticated supplicant (that is, client device)
attempting to connect with an authenticator (that is, 802.11 access point). The client sends an
EAP-start message. This begins a series of message exchanges to authenticate the client.
2. The access point replies with an EAP-request identity message.
Wireless Networking Basics
2-13
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
3. The client sends an EAP-response packet containing the identity to the authentication server.
The access point responds by enabling a port for passing only EAP packets from the client to
an authentication server located on the wired side of the access point. The access point blocks
all other traffic, such as HTTP, DHCP, and POP3 packets, until the access point can verify the
client's identity using an authentication server (for example, RADIUS).
4. The authentication server uses a specific authentication algorithm to verify the client's identity.
This could be through the use of digital certificates or some other EAP authentication type.
5. The authentication server will either send an accept or reject message to the access point.
6. The access point sends an EAP-success packet (or reject packet) to the client.
7. If the authentication server accepts the client, then the access point will transition the client's
port to an authorized state and forward additional traffic.
The important part to know at this point is that the software supporting the specific EAP type
resides on the authentication server and within the operating system or application “supplicant”
software on the client devices. The access point acts as a “pass through” for 802.1x messages,
which means that you can specify any EAP type without needing to upgrade an 802.1x-compliant
access point. As a result, you can update the EAP authentication type to such devices as token
cards (Smart Cards), Kerberos, one-time passwords, certificates, and public key authentication or
as newer types become available and your requirements for security change.
WPA Data Encryption Key Management
With 802.1x, the re-keying of unicast encryption keys is optional. Additionally, 802.11 and 802.1x
provide no mechanism to change the global encryption key used for multicast and broadcast
traffic. With WPA, re-keying of both unicast and global encryption keys is required.
For the unicast encryption key, the Temporal Key Integrity Protocol (TKIP) changes the key for
every frame, and the change is synchronized between the wireless client and the wireless access
point (AP). For the global encryption key, WPA includes a facility (the Information Element) for
the wireless AP to advertise the changed key to the connected wireless clients.
If configured to implement dynamic key exchange, the 802.1x authentication server can return
session keys to the access point along with the accept message. The access point uses the session
keys to build, sign and encrypt an EAP key message that is sent to the client immediately after
sending the success message. The client can then use contents of the key message to define
applicable encryption keys. In typical 802.1x implementations, the client can automatically change
encryption keys as often as necessary to minimize the possibility of eavesdroppers having enough
time to crack the key in current use.
2-14
Wireless Networking Basics
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
Temporal Key Integrity Protocol (TKIP). WPA uses TKIP to provide important data
encryption enhancements including a per-packet key mixing function, a message integrity check
(MIC) named Michael, an extended initialization vector (IV) with sequencing rules, and a rekeying mechanism. TKIP also provides for the following:
• The verification of the security configuration after the encryption keys are determined.
• The synchronized changing of the unicast encryption key for each frame.
• The determination of a unique starting unicast encryption key for each pre-shared key
authentication.
Michael. With 802.11 and WEP, data integrity is provided by a 32-bit integrity check value (ICV)
that is appended to the 802.11 payload and encrypted with WEP. Although the ICV is encrypted,
you can use cryptanalysis to change bits in the encrypted payload and update the encrypted ICV
without being detected by the receiver.
With WPA, a method known as Michael specifies a new algorithm that calculates an 8-byte
message integrity code (MIC) using the calculation facilities available on existing wireless
devices. The MIC is placed between the data portion of the IEEE 802.11 frame and the 4-byte ICV.
The MIC field is encrypted together with the frame data and the ICV.
Michael also provides replay protection. A new frame counter in the IEEE 802.11 frame is used to
prevent replay attacks.
AES Support. One of the encryption methods supported by WPA, besides TKIP, is the advanced
encryption standard (AES), although AES support will not be required initially for Wi-Fi
certification. This is viewed as the optimal choice for security-conscious organizations, but the
problem with AES is that it requires a fundamental redesign of the NIC’s hardware in both the
station and the access point. TKIP was a pragmatic compromise that allows organizations to
deploy better security while AES-capable equipment is being designed, manufactured, and
incrementally deployed.
Is WPA Perfect?
WPA is not without its vulnerabilities. Specifically, it is susceptible to denial of service (DoS)
attacks. If the access point receives two data packets that fail the Message Integrity Code (MIC)
check within 60 seconds of each other, then the network is under an active attack, and as a result
the access point employs counter measures, which include disassociating each station using the
access point. This prevents an attacker from gleaning information about the encryption key and
alerts administrators, but it also causes users to lose network connectivity for 60 seconds. More
than anything else, this may just prove that no single security tactic is completely invulnerable.
WPA is a definite step forward in WLAN security over WEP and has to be thought of as a single
part of an end-to-end network security strategy.
Wireless Networking Basics
2-15
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
Product Support for WPA
Some NETGEAR wireless Wi-Fi certified products support the WPA standard.
WPA requires software changes to the following:
• Wireless access points
• Wireless network adapters
• Wireless client programs
Supporting a Mixture of WPA and WEP Wireless Clients
To support the gradual transition of WEP-based wireless networks to WPA, a wireless AP can
support both WEP and WPA clients at the same time. During the association, the wireless AP
determines which clients use WEP and which clients use WPA. The disadvantage to supporting a
mixture of WEP and WPA clients is that the global encryption key is not dynamic. This is because
WEP-based clients cannot support it. All other benefits to the WPA clients, such as integrity, are
maintained.
However, a mixed mode supporting WPA and non-WPA clients offers network security that is no
better than that obtained with a non-WPA network, and thus this mode of operation is discouraged.
Changes to Wireless Access Points
Wireless access points must have their firmware updated to support the following:
• The new WPA information element
To advertise their support of WPA, wireless APs send the Beacon frame with a new 802.11
WPA information element that contains the wireless AP's security configuration (encryption
algorithms and wireless security configuration information).
• The WPA two-phase authentication
Open system, then 802.1x (EAP with RADIUS or Pre-shared key).
• TKIP
• Michael
• AES (optional)
To upgrade your wireless access points to support WPA, obtain a WPA firmware update from your
wireless AP vendor and upload it to your wireless AP.
2-16
Wireless Networking Basics
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
Changes to Wireless Network Adapters
Wireless network adapters must have their firmware updated to support the following:
•
The new WPA information element
Wireless clients must be able to process the WPA information element and respond with a
specific security configuration.
•
The WPA two-phase authentication
Open system, then 802.1x (EAP or Pre-shared key).
•
TKIP
•
Michael
•
AES (optional)
To upgrade your wireless network adapters to support WPA, obtain a WPA update from your
wireless network adapter vendor, and update the wireless network adapter driver.
For Windows wireless clients, you must obtain an updated network adapter driver that supports
WPA. For wireless network adapter drivers that are compatible with Windows XP (Service Pack 1)
and Windows Server 2003, the updated network adapter driver must be able to pass the adapter's
WPA capabilities and security configuration to the Wireless Zero Configuration service.
Microsoft has worked with many wireless vendors to embed the WPA firmware update in the
wireless adapter driver. So, to update you Windows wireless client, all you have to do is obtain the
new WPA-compatible driver and install the driver. The firmware is automatically updated when
the wireless network adapter driver is loaded in Windows.
Changes to Wireless Client Programs
Wireless client programs must be updated to permit the configuration of WPA authentication (and
Pre-shared key) and the new WPA encryption algorithms (TKIP and the optional AES
component).
To obtain the Microsoft WPA client program, visit the Microsoft Web site.
Wireless Networking Basics
2-17
v1.0, October 2005
APPENDIX T
Wireless Networking Basics
2-18
Wireless Networking Basics
v1.0, October 2005
APPENDIX U
Network Working Group
Request for Comment: 2003
Category: Standards Track
C. Perkins
IBM
October 1996
IP Encapsulation within IP
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document specifies a method by which an IP datagram may be
encapsulated (carried as payload) within an IP datagram.
Encapsulation is suggested as a means to alter the normal IP routing
for datagrams, by delivering them to an intermediate destination that
would otherwise not be selected by the (network part of the) IP
Destination Address field in the original IP header. Encapsulation
may serve a variety of purposes, such as delivery of a datagram to a
mobile node using Mobile IP.
1. Introduction
This document specifies a method by which an IP datagram may be
encapsulated (carried as payload) within an IP datagram.
Encapsulation is suggested as a means to alter the normal IP routing
for datagrams, by delivering them to an intermediate destination that
would otherwise not be selected based on the (network part of the) IP
Destination Address field in the original IP header. Once the
encapsulated datagram arrives at this intermediate destination node,
it is decapsulated, yielding the original IP datagram, which is then
delivered to the destination indicated by the original Destination
Address field. This use of encapsulation and decapsulation of a
datagram is frequently referred to as "tunneling" the datagram, and
the encapsulator and decapsulator are then considered to be the
"endpoints" of the tunnel.
In the most general tunneling case we have
source ---> encapsulator --------> decapsulator ---> destination
with the source, encapsulator, decapsulator, and destination being
separate nodes. The encapsulator node is considered the "entry
Perkins
Standards Track
[Page 1]
APPENDIX U
RFC 2003
IP-within-IP
October 1996
point" of the tunnel, and the decapsulator node is considered the
"exit point" of the tunnel. There in general may be multiple
source-destination pairs using the same tunnel between the
encapsulator and decapsulator.
2. Motivation
The Mobile IP working group has specified the use of encapsulation as
a way to deliver datagrams from a mobile node’s "home network" to an
agent that can deliver datagrams locally by conventional means to the
mobile node at its current location away from home [8]. The use of
encapsulation may also be desirable whenever the source (or an
intermediate router) of an IP datagram must influence the route by
which a datagram is to be delivered to its ultimate destination.
Other possible applications of encapsulation include multicasting,
preferential billing, choice of routes with selected security
attributes, and general policy routing.
It is generally true that encapsulation and the IP loose source
routing option [10] can be used in similar ways to affect the routing
of a datagram, but there are several technical reasons to prefer
encapsulation:
-
There are unsolved security problems associated with the use of
the IP source routing options.
-
Current Internet routers exhibit performance problems when
forwarding datagrams that contain IP options, including the IP
source routing options.
-
Many current Internet nodes process IP source routing options
incorrectly.
-
Firewalls may exclude IP source-routed datagrams.
-
Insertion of an IP source route option may complicate the
processing of authentication information by the source and/or
destination of a datagram, depending on how the authentication is
specified to be performed.
-
It is considered impolite for intermediate routers to make
modifications to datagrams which they did not originate.
These technical advantages must be weighed against the disadvantages
posed by the use of encapsulation:
-
Perkins
Encapsulated datagrams typically are larger than source routed
datagrams.
Standards Track
[Page 2]
APPENDIX U
RFC 2003
-
IP-within-IP
October 1996
Encapsulation cannot be used unless it is known in advance that
the node at the tunnel exit point can decapsulate the datagram.
Since the majority of Internet nodes today do not perform well when
IP loose source route options are used, the second technical
disadvantage of encapsulation is not as serious as it might seem at
first.
3. IP in IP Encapsulation
To encapsulate an IP datagram using IP in IP encapsulation, an outer
IP header [10] is inserted before the datagram’s existing IP header,
as follows:
+---------------------------+
|
|
|
Outer IP Header
|
|
|
+---------------------------+
+---------------------------+
|
|
|
|
|
IP Header
|
|
IP Header
|
|
|
|
|
+---------------------------+ ====> +---------------------------+
|
|
|
|
|
|
|
|
|
IP Payload
|
|
IP Payload
|
|
|
|
|
|
|
|
|
+---------------------------+
+---------------------------+
The outer IP header Source Address and Destination Address identify
the "endpoints" of the tunnel. The inner IP header Source Address
and Destination Addresses identify the original sender and recipient
of the datagram, respectively. The inner IP header is not changed by
the encapsulator, except to decrement the TTL as noted below, and
remains unchanged during its delivery to the tunnel exit point. No
change to IP options in the inner header occurs during delivery of
the encapsulated datagram through the tunnel. If need be, other
protocol headers such as the IP Authentication header [1] may be
inserted between the outer IP header and the inner IP header. Note
that the security options of the inner IP header MAY affect the
choice of security options for the encapsulating (outer) IP header.
Perkins
Standards Track
[Page 3]
APPENDIX U
RFC 2003
IP-within-IP
October 1996
3.1. IP Header Fields and Handling
The fields in the outer IP header are set by the encapsulator as
follows:
Version
4
IHL
The Internet Header Length (IHL) is the length of the outer IP
header measured in 32-bit words [10].
TOS
The Type of Service (TOS) is copied from the inner IP header.
Total Length
The Total Length measures the length of the entire encapsulated
IP datagram, including the outer IP header, the inner IP
header, and its payload.
Identification, Flags, Fragment Offset
These three fields are set as specified in [10]. However,
the "Don’t Fragment" bit is set in the inner IP header, it
be set in the outer IP header; if the "Don’t Fragment" bit
not set in the inner IP header, it MAY be set in the outer
header, as described in Section 5.1.
if
MUST
is
IP
Time to Live
The Time To Live (TTL) field in the outer IP header is set to a
value appropriate for delivery of the encapsulated datagram to
the tunnel exit point.
Protocol
4
Header Checksum
The Internet Header checksum [10] of the outer IP header.
Perkins
Standards Track
[Page 4]
APPENDIX U
RFC 2003
IP-within-IP
October 1996
Source Address
The IP address of the encapsulator, that is, the tunnel entry
point.
Destination Address
The IP address of the decapsulator, that is, the tunnel exit
point.
Options
Any options present in the inner IP header are in general NOT
copied to the outer IP header. However, new options specific
to the tunnel path MAY be added. In particular, any supported
types of security options of the inner IP header MAY affect the
choice of security options for the outer header. It is not
expected that there be a one-to-one mapping of such options to
the options or security headers selected for the tunnel.
When encapsulating a datagram, the TTL in the inner IP header is
decremented by one if the tunneling is being done as part of
forwarding the datagram; otherwise, the inner header TTL is not
changed during encapsulation. If the resulting TTL in the inner IP
header is 0, the datagram is discarded and an ICMP Time Exceeded
message SHOULD be returned to the sender. An encapsulator MUST NOT
encapsulate a datagram with TTL = 0.
The TTL in the inner IP header is not changed when decapsulating.
If, after decapsulation, the inner datagram has TTL = 0, the
decapsulator MUST discard the datagram. If, after decapsulation, the
decapsulator forwards the datagram to one of its network interfaces,
it will decrement the TTL as a result of doing normal IP forwarding.
See also Section 4.4.
The encapsulator may use any existing IP mechanisms appropriate for
delivery of the encapsulated payload to the tunnel exit point. In
particular, use of IP options is allowed, and use of fragmentation is
allowed unless the "Don’t Fragment" bit is set in the inner IP
header. This restriction on fragmentation is required so that nodes
employing Path MTU Discovery [7] can obtain the information they
seek.
3.2. Routing Failures
Routing loops within a tunnel are particularly dangerous when they
cause datagrams to arrive again at the encapsulator. Suppose a
datagram arrives at a router for forwarding, and the router
Perkins
Standards Track
[Page 5]
APPENDIX U
RFC 2003
IP-within-IP
October 1996
determines that the datagram has to be encapsulated before further
delivery. Then:
-
If the IP Source Address of the datagram matches the router’s own
IP address on any of its network interfaces, the router MUST NOT
tunnel the datagram; instead, the datagram SHOULD be discarded.
-
If the IP Source Address of the datagram matches the IP address
of the tunnel destination (the tunnel exit point is typically
chosen by the router based on the Destination Address in the
datagram’s IP header), the router MUST NOT tunnel the datagram;
instead, the datagram SHOULD be discarded.
See also Section 4.4.
4. ICMP Messages from within the Tunnel
After an encapsulated datagram has been sent, the encapsulator may
receive an ICMP [9] message from any intermediate router within the
tunnel other than the tunnel exit point. The action taken by the
encapsulator depends on the type of ICMP message received. When the
received message contains enough information, the encapsulator MAY
use the incoming message to create a similar ICMP message, to be sent
to the originator of the original unencapsulated IP datagram (the
original sender). This process will be referred to as "relaying" the
ICMP message from the tunnel.
ICMP messages indicating an error in processing a datagram include a
copy of (a portion of) the datagram causing the error. Relaying an
ICMP message requires that the encapsulator strip off the outer IP
header from this returned copy of the original datagram. For cases
in which the received ICMP message does not contain enough data to
relay the message, see Section 5.
4.1. Destination Unreachable (Type 3)
ICMP Destination Unreachable messages are handled by the encapsulator
depending upon their Code field. The model suggested here allows the
tunnel to "extend" a network to include non-local (e.g., mobile)
nodes. Thus, if the original destination in the unencapsulated
datagram is on the same network as the encapsulator, certain
Destination Unreachable Code values may be modified to conform to the
suggested model.
Perkins
Standards Track
[Page 6]
APPENDIX U
RFC 2003
IP-within-IP
October 1996
Network Unreachable (Code 0)
An ICMP Destination Unreachable message SHOULD be returned
to the original sender. If the original destination in
the unencapsulated datagram is on the same network as the
encapsulator, the newly generated Destination Unreachable
message sent by the encapsulator MAY have Code 1 (Host
Unreachable), since presumably the datagram arrived at the
correct network and the encapsulator is trying to create the
appearance that the original destination is local to that
network even if it is not. Otherwise, if the encapsulator
returns a Destination Unreachable message, the Code field MUST
be set to 0 (Network Unreachable).
Host Unreachable (Code 1)
The encapsulator SHOULD relay Host Unreachable messages to the
sender of the original unencapsulated datagram, if possible.
Protocol Unreachable (Code 2)
When the encapsulator receives an ICMP Protocol Unreachable
message, it SHOULD send a Destination Unreachable message with
Code 0 or 1 (see the discussion for Code 0) to the sender of
the original unencapsulated datagram. Since the original
sender did not use protocol 4 in sending the datagram, it would
be meaningless to return Code 2 to that sender.
Port Unreachable (Code 3)
This Code should never be received by the encapsulator, since
the outer IP header does not refer to any port number. It MUST
NOT be relayed to the sender of the original unencapsulated
datagram.
Datagram Too Big (Code 4)
The encapsulator MUST relay ICMP Datagram Too Big messages to
the sender of the original unencapsulated datagram.
Source Route Failed (Code 5)
This Code SHOULD be handled by the encapsulator itself.
It MUST NOT be relayed to the sender of the original
unencapsulated datagram.
Perkins
Standards Track
[Page 7]
APPENDIX U
RFC 2003
IP-within-IP
October 1996
4.2. Source Quench (Type 4)
The encapsulator SHOULD NOT relay ICMP Source Quench messages to the
sender of the original unencapsulated datagram, but instead SHOULD
activate whatever congestion control mechanisms it implements to help
alleviate the congestion detected within the tunnel.
4.3. Redirect (Type 5)
The encapsulator MAY handle the ICMP Redirect messages itself.
MUST NOT not relay the Redirect to the sender of the original
unencapsulated datagram.
It
4.4. Time Exceeded (Type 11)
ICMP Time Exceeded messages report (presumed) routing loops within
the tunnel itself. Reception of Time Exceeded messages by the
encapsulator MUST be reported to the sender of the original
unencapsulated datagram as Host Unreachable (Type 3, Code 1). Host
Unreachable is preferable to Network Unreachable; since the datagram
was handled by the encapsulator, and the encapsulator is often
considered to be on the same network as the destination address in
the original unencapsulated datagram, then the datagram is considered
to have reached the correct network, but not the correct destination
node within that network.
4.5. Parameter Problem (Type 12)
If the Parameter Problem message points to a field copied from the
original unencapsulated datagram, the encapsulator MAY relay the ICMP
message to the sender of the original unencapsulated datagram;
otherwise, if the problem occurs with an IP option inserted by the
encapsulator, then the encapsulator MUST NOT relay the ICMP message
to the original sender. Note that an encapsulator following
prevalent current practice will never insert any IP options into the
encapsulated datagram, except possibly for security reasons.
4.6. Other ICMP Messages
Other ICMP messages are not related to the encapsulation operations
described within this protocol specification, and should be acted on
by the encapsulator as specified in [9].
Perkins
Standards Track
[Page 8]
APPENDIX U
RFC 2003
IP-within-IP
October 1996
5. Tunnel Management
Unfortunately, ICMP only requires IP routers to return 8 octets (64
bits) of the datagram beyond the IP header. This is not enough to
include a copy of the encapsulated (inner) IP header, so it is not
always possible for the encapsulator to relay the ICMP message from
the interior of a tunnel back to the original sender. However, by
carefully maintaining "soft state" about tunnels into which it sends,
the encapsulator can return accurate ICMP messages to the original
sender in most cases. The encapsulator SHOULD maintain at least the
following soft state information about each tunnel:
- MTU of the tunnel (Section 5.1)
- TTL (path length) of the tunnel
- Reachability of the end of the tunnel
The encapsulator uses the ICMP messages it receives from the interior
of a tunnel to update the soft state information for that tunnel.
ICMP errors that could be received from one of the routers along the
tunnel interior include:
-
Datagram Too Big
Time Exceeded
Destination Unreachable
Source Quench
When subsequent datagrams arrive that would transit the tunnel, the
encapsulator checks the soft state for the tunnel. If the datagram
would violate the state of the tunnel (for example, the TTL of the
new datagram is less than the tunnel "soft state" TTL) the
encapsulator sends an ICMP error message back to the sender of the
original datagram, but also encapsulates the datagram and forwards it
into the tunnel.
Using this technique, the ICMP error messages sent by the
encapsulator will not always match up one-to-one with errors
encountered within the tunnel, but they will accurately reflect the
state of the network.
Tunnel soft state was originally developed for the IP Address
Encapsulation (IPAE) specification [4].
5.1. Tunnel MTU Discovery
When the Don’t Fragment bit is set by the originator and copied into
the outer IP header, the proper MTU of the tunnel will be learned
from ICMP Datagram Too Big (Type 3, Code 4) messages reported to the
encapsulator. To support sending nodes which use Path MTU Discovery,
Perkins
Standards Track
[Page 9]
APPENDIX U
RFC 2003
IP-within-IP
October 1996
all encapsulator implementations MUST support Path MTU Discovery [5,
7] soft state within their tunnels. In this particular application,
there are several advantages:
-
As a benefit of Path MTU Discovery within the tunnel, any
fragmentation which occurs because of the size of the
encapsulation header is performed only once after encapsulation.
This prevents multiple fragmentation of a single datagram, which
improves processing efficiency of the decapsulator and the
routers within the tunnel.
-
If the source of the unencapsulated datagram is doing Path MTU
Discovery, then it is desirable for the encapsulator to know
the MTU of the tunnel. Any ICMP Datagram Too Big messages from
within the tunnel are returned to the encapsulator, and as noted
in Section 5, it is not always possible for the encapsulator to
relay ICMP messages to the source of the original unencapsulated
datagram. By maintaining "soft state" about the MTU of the
tunnel, the encapsulator can return correct ICMP Datagram Too Big
messages to the original sender of the unencapsulated datagram to
support its own Path MTU Discovery. In this case, the MTU that
is conveyed to the original sender by the encapsulator SHOULD
be the MTU of the tunnel minus the size of the encapsulating
IP header. This will avoid fragmentation of the original IP
datagram by the encapsulator.
-
If the source of the original unencapsulated datagram is
not doing Path MTU Discovery, it is still desirable for the
encapsulator to know the MTU of the tunnel. In particular, it is
much better to fragment the original datagram when encapsulating,
than to allow the encapsulated datagram to be fragmented.
Fragmenting the original datagram can be done by the encapsulator
without special buffer requirements and without the need to
keep reassembly state in the decapsulator. By contrast, if
the encapsulated datagram is fragmented, then the decapsulator
must reassemble the fragmented (encapsulated) datagram before
decapsulating it, requiring reassembly state and buffer space
within the decapsulator.
Thus, the encapsulator SHOULD normally do Path MTU Discovery,
requiring it to send all datagrams into the tunnel with the "Don’t
Fragment" bit set in the outer IP header. However there are problems
with this approach. When the original sender sets the "Don’t
Fragment" bit, the sender can react quickly to any returned ICMP
Datagram Too Big error message by retransmitting the original
datagram. On the other hand, suppose that the encapsulator receives
an ICMP Datagram Too Big message from within the tunnel. In that
case, if the original sender of the unencapsulated datagram had not
Perkins
Standards Track
[Page 10]
APPENDIX U
RFC 2003
IP-within-IP
October 1996
set the "Don’t Fragment" bit, there is nothing sensible that the
encapsulator can do to let the original sender know of the error.
The encapsulator MAY keep a copy of the sent datagram whenever it
tries increasing the tunnel MTU, in order to allow it to fragment and
resend the datagram if it gets a Datagram Too Big response.
Alternatively the encapsulator MAY be configured for certain types of
datagrams not to set the "Don’t Fragment" bit when the original
sender of the unencapsulated datagram has not set the "Don’t
Fragment" bit.
5.2. Congestion
An encapsulator might receive indications of congestion from the
tunnel, for example, by receiving ICMP Source Quench messages from
nodes within the tunnel. In addition, certain link layers and
various protocols not related to the Internet suite of protocols
might provide such indications in the form of a Congestion
Experienced [6] flag. The encapsulator SHOULD reflect conditions of
congestion in its "soft state" for the tunnel, and when subsequently
forwarding datagrams into the tunnel, the encapsulator SHOULD use
appropriate means for controlling congestion [3]; However, the
encapsulator SHOULD NOT send ICMP Source Quench messages to the
original sender of the unencapsulated datagram.
6. Security Considerations
IP encapsulation potentially reduces the security of the Internet,
and care needs to be taken in the implementation and deployment of IP
encapsulation. For example, IP encapsulation makes it difficult for
border routers to filter datagrams based on header fields. In
particular, the original values of the Source Address, Destination
Address, and Protocol fields in the IP header, and the port numbers
used in any transport header within the datagram, are not located in
their normal positions within the datagram after encapsulation.
Since any IP datagram can be encapsulated and passed through a
tunnel, such filtering border routers need to carefully examine all
datagrams.
6.1. Router Considerations
Routers need to be aware of IP encapsulation protocols in order to
correctly filter incoming datagrams. It is desirable that such
filtering be integrated with IP authentication [1]. Where IP
authentication is used, encapsulated packets might be allowed to
enter an organization when the encapsulating (outer) packet or the
encapsulated (inner) packet is sent by an authenticated, trusted
source. Encapuslated packets containing no such authentication
represent a potentially large security risk.
Perkins
Standards Track
[Page 11]
APPENDIX U
RFC 2003
IP-within-IP
October 1996
IP datagrams which are encapsulated and encrypted [2] might also pose
a problem for filtering routers. In this case, the router can filter
the datagram only if it shares the security association used for the
encryption. To allow this sort of encryption in environments in
which all packets need to be filtered (or at least accounted for), a
mechanism must be in place for the receiving node to securely
communicate the security association to the border router. This
might, more rarely, also apply to the security association used for
outgoing datagrams.
6.2. Host Considerations
Host implementations that are capable of receiving encapsulated IP
datagrams SHOULD admit only those datagrams fitting into one or more
of the following categories:
-
The protocol is harmless:
not needed.
source address-based authentication is
-
The encapsulating (outer) datagram comes from an authentically
identified, trusted source. The authenticity of the source could
be established by relying on physical security in addition to
border router configuration, but is more likely to come from use
of the IP Authentication header [1].
-
The encapuslated (inner) datagram includes an IP Authentication
header.
-
The encapsulated (inner) datagram is addressed to a network
interface belonging to the decapsulator, or to a node with which
the decapsulator has entered into a special relationship for
delivering such encapsulated datagrams.
Some or all of this checking could be done in border routers rather
than the receiving node, but it is better if border router checks are
used as backup, rather than being the only check.
Perkins
Standards Track
[Page 12]
APPENDIX U
RFC 2003
IP-within-IP
October 1996
7. Acknowledgements
Parts of Sections 3 and 5 of this document were taken from portions
(authored by Bill Simpson) of earlier versions of the Mobile IP
Internet Draft [8]. The original text for section 6 (Security
Considerations) was contributed by Bob Smart. Good ideas have also
been included from RFC 1853 [11], also authored by Bill Simpson.
Thanks also to Anders Klemets for finding mistakes and suggesting
improvements to the draft. Finally, thanks to David Johnson for
going over the draft with a fine-toothed comb, finding mistakes,
improving consistency, and making many other improvements to the
draft.
References
[1] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[2] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
August 1995.
[3] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[4] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: The SIPP
Interoperability and Transition Mechanism", Work in Progress.
[5] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[6] Mankin, A., and K. Ramakrishnan, "Gateway Congestion Control
Survey", RFC 1254, August 1991.
[7] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[8] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
October 1996.
[9] Postel, J., Editor, "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[10] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
[11] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
Perkins
Standards Track
[Page 13]
APPENDIX U
RFC 2003
IP-within-IP
October 1996
Author’s Address
Questions about this memo can be directed to:
Charles Perkins
Room H3-D34
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532
Work:
+1-914-784-7350
Fax:
+1-914-784-6205
EMail: perk@watson.ibm.com
The working group can be contacted via the current chair:
Jim Solomon
Motorola, Inc.
1301 E. Algonquin Rd.
Schaumburg, IL 60196
Work:
+1-847-576-2753
EMail: solomon@comm.mot.com
Perkins
Standards Track
[Page 14]
APPENDIX V
Network Working Group
Request for Comments: 1701
Category: Informational
S. Hanks
NetSmiths, Ltd.
T. Li
D. Farinacci
P. Traina
cisco Systems
October 1994
Generic Routing Encapsulation (GRE)
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document specifies a protocol for performing encapsulation of an
arbitrary network layer protocol over another arbitrary network layer
protocol.
Introduction
A number of different proposals [RFC 1234, RFC 1226] currently exist
for the encapsulation of one protocol over another protocol. Other
types of encapsulations [RFC 1241, SDRP, RFC 1479] have been proposed
for transporting IP over IP for policy purposes. This memo describes
a protocol which is very similar to, but is more general than, the
above proposals. In attempting to be more general, many protocol
specific nuances have been ignored. The result is that this proposal
is may be less suitable for a situation where a specific "X over Y"
encapsulation has been described. It is the attempt of this protocol
to provide a simple, general purpose mechanism which is reduces the
problem of encapsulation from its current O(n^2) problem to a more
manageable state. This proposal also attempts to provide a
lightweight encapsulation for use in policy based routing. This memo
explicitly does not address the issue of when a packet should be
encapsulated. This memo acknowledges, but does not address problems
with mutual encapsulation [RFC 1326].
In the most general case, a system has a packet that needs to be
encapsulated and routed. We will call this the payload packet. The
payload is first encapsulated in a GRE packet, which possibly also
includes a route. The resulting GRE packet can then be encapsulated
in some other protocol and then forwarded. We will call this outer
Hanks, Li, Farinacci & Traina
[Page 1]
APPENDIX V
RFC 1701
Generic Routing Encapsulation (GRE)
October 1994
protocol the delivery protocol. The algorithms for processing this
packet are discussed later.
Overall packet
The entire encapsulated packet would then have the form:
--------------------------------|
|
|
Delivery Header
|
|
|
--------------------------------|
|
|
GRE Header
|
|
|
--------------------------------|
|
|
Payload packet
|
|
|
--------------------------------Packet header
The GRE packet header has the form:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R|K|S|s|Recur| Flags | Ver |
Protocol Type
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Checksum (optional)
|
Offset (optional)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key (optional)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Sequence Number (optional)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Routing (optional)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags and version (2 octets)
The GRE flags are encoded in the first two octets. Bit 0 is the
most significant bit, bit 15 is the least significant bit. Bits
13 through 15 are reserved for the Version field. Bits 5 through
12 are reserved for future use and MUST be transmitted as zero.
Hanks, Li, Farinacci & Traina
[Page 2]
APPENDIX V
RFC 1701
Generic Routing Encapsulation (GRE)
October 1994
Checksum Present (bit 0)
If the Checksum Present bit is set to 1, then the Checksum field
is present and contains valid information.
If either the Checksum Present bit or the Routing Present bit are
set, BOTH the Checksum and Offset fields are present in the GRE
packet.
Routing Present (bit 1)
If the Routing Present bit is set to 1, then it indicates that the
Offset and Routing fields are present and contain valid
information.
If either the Checksum Present bit or the Routing Present bit are
set, BOTH the Checksum and Offset fields are present in the GRE
packet.
Key Present (bit 2)
If the Key Present bit is set to 1, then it indicates that the Key
field is present in the GRE header. Otherwise, the Key field is
not present in the GRE header.
Sequence Number Present (bit 3)
If the Sequence Number Present bit is set to 1, then it indicates
that the Sequence Number field is present. Otherwise, the
Sequence Number field is not present in the GRE header.
Strict Source Route (bit 4)
The meaning of the Strict Source route bit is defined in other
documents. It is recommended that this bit only be set to 1 if
all of the the Routing Information consists of Strict Source
Routes.
Recursion Control (bits 5-7)
Recursion control contains a three bit unsigned integer which
contains the number of additional encapsulations which are
permissible. This SHOULD default to zero.
Version Number (bits 13-15)
The Version Number field MUST contain the value 0.
are outside of the scope of this document.
Hanks, Li, Farinacci & Traina
Other values
[Page 3]
APPENDIX V
RFC 1701
Generic Routing Encapsulation (GRE)
October 1994
Protocol Type (2 octets)
The Protocol Type field contains the protocol type of the payload
packet. In general, the value will be the Ethernet protocol type
field for the packet. Currently defined protocol types are listed
below. Additional values may be defined in other documents.
Offset (2 octets)
The offset field indicates the octet offset from the start of the
Routing field to the first octet of the active Source Route Entry
to be examined. This field is present if the Routing Present or
the Checksum Present bit is set to 1, and contains valid
information only if the Routing Present bit is set to 1.
Checksum (2 octets)
The Checksum field contains the IP (one’s complement) checksum of
the GRE header and the payload packet. This field is present if
the Routing Present or the Checksum Present bit is set to 1, and
contains valid information only if the Checksum Present bit is set
to 1.
Key (4 octets)
The Key field contains a four octet number which was inserted by
the encapsulator. It may be used by the receiver to authenticate
the source of the packet. The techniques for determining
authenticity are outside of the scope of this document. The Key
field is only present if the Key Present field is set to 1.
Sequence Number (4 octets)
The Sequence Number field contains an unsigned 32 bit integer
which is inserted by the encapsulator. It may be used by the
receiver to establish the order in which packets have been
transmitted from the encapsulator to the receiver. The exact
algorithms for the generation of the Sequence Number and the
semantics of their reception is outside of the scope of this
document.
Routing (variable)
The Routing field is optional and is present only if the Routing
Present bit is set to 1.
Hanks, Li, Farinacci & Traina
[Page 4]
APPENDIX V
RFC 1701
Generic Routing Encapsulation (GRE)
October 1994
The Routing field is a list of Source Route Entries (SREs).
SRE has the form:
Each
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Address Family
| SRE Offset
| SRE Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Routing Information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The routing field is terminated with a "NULL" SRE containing an
address family of type 0x0000 and a length of 0.
Address Family (2 octets)
The Address Family field contains a two octet value which indicates
the syntax and semantics of the Routing Information field. The
values for this field and the corresponding syntax and semantics for
Routing Information are defined in other documents.
SRE Offset (1 octet)
The SRE Offset field indicates the octet offset from the start of the
Routing Information field to the first octet of the active entry in
Source Route Entry to be examined.
SRE Length (1 octet)
The SRE Length field contains the number of octets in the SRE. If
the SRE Length is 0, this indicates this is the last SRE in the
Routing field.
Routing Information (variable)
The Routing Information field contains data which may be used in
routing this packet. The exact semantics of this field is defined in
other documents.
Forwarding of GRE packets
Normally, a system which is forwarding delivery layer packets will
not differentiate GRE packets from other packets in any way.
However, a GRE packet may be received by a system. In this case, the
system should use some delivery-specific means to determine that this
is a GRE packet. Once this is determined, the Key, Sequence Number
and Checksum fields if they contain valid information as indicated by
the corresponding flags may be checked. If the Routing Present bit
Hanks, Li, Farinacci & Traina
[Page 5]
APPENDIX V
RFC 1701
Generic Routing Encapsulation (GRE)
October 1994
is set to 1, then the Address Family field should be checked to
determine the semantics and use of the SRE Length, SRE Offset and
Routing Information fields. The exact semantics for processing a SRE
for each Address Family is defined in other documents.
Once all SREs have been processed, then the source route is complete,
the GRE header should be removed, the payload’s TTL MUST be
decremented (if one exists) and the payload packet should be
forwarded as a normal packet. The exact forwarding method depends on
the Protocol Type field.
Current List of Protocol Types
The following are currently assigned protocol types for GRE. Future
protocol types must be taken from DIX ethernet encoding. For
historical reasons, a number of other values have been used for some
protocols. The following table of values MUST be used to identify
the following protocols:
Protocol Family
--------------Reserved
SNA
OSI network layer
PUP
XNS
IP
Chaos
RFC 826 ARP
Frame Relay ARP
VINES
VINES Echo
VINES Loopback
DECnet (Phase IV)
Transparent Ethernet Bridging
Raw Frame Relay
Apollo Domain
Ethertalk (Appletalk)
Novell IPX
RFC 1144 TCP/IP compression
IP Autonomous Systems
Secure Data
Reserved
PTYPE
----0000
0004
00FE
0200
0600
0800
0804
0806
0808
0BAD
0BAE
0BAF
6003
6558
6559
8019
809B
8137
876B
876C
876D
FFFF
See the IANA list of Ether Types for the complete list of these
values.
URL = ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers.
Hanks, Li, Farinacci & Traina
[Page 6]
APPENDIX V
RFC 1701
Generic Routing Encapsulation (GRE)
October 1994
References
RFC 1479
Steenstrup, M. "Inter-Domain Policy Routing Protocol
Specification: Version 1", RFC1479, BBN Systems and Technologies,
July 1993.
RFC 1226
Kantor, B. "Internet Protocol Encapsulation of AX.25 Frames", RFC
1226, University of California, San Diego, May 1991.
RFC 1234
Provan, D. "Tunneling IPX Traffic through IP Networks", RFC 1234,
Novell, Inc., June 1991.
RFC 1241
Woodburn, R., and D. Mills, "Scheme for an Internet Encapsulation
Protocol: Version 1", RFC 1241, SAIC, University of Delaware, July
1991.
RFC 1326
Tsuchiya, P., "Mutual Encapsulation Considered Dangerous", RFC
1326, Bellcore, May 1992.
SDRP
Estrin, D., Li, T., and Y. Rekhter, "Source Demand Routing
Protocol Specification (Version 1)", Work in Progress.
RFC 1702
Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing
Encapsulation over IPv4 networks", RFC 1702, NetSmiths, Ltd.,
cisco Systems, October 1994.
Security Considerations
Security issues are not discussed in this memo.
Hanks, Li, Farinacci & Traina
[Page 7]
APPENDIX V
RFC 1701
Generic Routing Encapsulation (GRE)
October 1994
Acknowledgements
The authors would like to acknowledge Yakov Rekhter (IBM) and Deborah
Estrin (USC) for their advice, encouragement and insightful comments.
Authors’
Addresses
Stan Hanks
NetSmiths, Ltd.
2025 Lincoln Highway
Edison NJ, 08817
EMail: stan@netsmiths.com
Tony Li
cisco Systems, Inc.
1525 O’Brien Drive
Menlo Park, CA 94025
EMail: tli@cisco.com
Dino Farinacci
cisco Systems, Inc.
1525 O’Brien Drive
Menlo Park, CA 94025
EMail: dino@cisco.com
Paul Traina
cisco Systems, Inc.
1525 O’Brien Drive
Menlo Park, CA 94025
EMail: pst@cisco.com
Hanks, Li, Farinacci & Traina
[Page 8]
APPENDIX W
Network Working Group
Request for Comments: 2004
Category: Standards Track
C. Perkins
IBM
October 1996
Minimal Encapsulation within IP
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document specifies a method by which an IP datagram may be
encapsulated (carried as payload) within an IP datagram, with less
overhead than "conventional" IP encapsulation that adds a second IP
header to each encapsulated datagram. Encapsulation is suggested as
a means to alter the normal IP routing for datagrams, by delivering
them to an intermediate destination that would otherwise not be
selected by the (network part of the) IP Destination Address field in
the original IP header. Encapsulation may be serve a variety of
purposes, such as delivery of a datagram to a mobile node using
Mobile IP.
1. Introduction
This document specifies a method by which an IP datagram may be
encapsulated (carried as payload) within an IP datagram, with less
overhead than "conventional" IP encapsulation [4] that adds a second
IP header to each encapsulated datagram. Encapsulation is suggested
as a means to alter the normal IP routing for datagrams, by
delivering them to an intermediate destination that would otherwise
not be selected by the (network part of the) IP Destination Address
field in the original IP header. The process of encapsulation and
decapsulation of a datagram is frequently referred to as "tunneling"
the datagram, and the encapsulator and decapsulator are then
considered to be the the "endpoints" of the tunnel; the encapsulator
node is refered to as the "entry point" of the tunnel, and the
decapsulator node is refered to as the "exit point" of the tunnel.
Perkins
Standards Track
[Page 1]
APPENDIX W
RFC 2004
Minimal Encapsulation for IP
October 1996
2. Motivation
The Mobile IP working group has specified the use of encapsulation as
a way to deliver packets from a mobile node’s "home network" to an
agent that can deliver datagrams locally by conventional means to the
mobile node at its current location away from home [5]. The use of
encapsulation may also be indicated whenever the source (or an
intermediate router) of an IP datagram must influence the route by
which a datagram is to be delivered to its ultimate destination.
Other possible applications of encapsulation include multicasting,
preferential billing, choice of routes with selected security
attributes, and general policy routing.
See [4] for a discussion concerning the advantages of encapsulation
versus use of the IP loose source routing option. Using IP headers
to encapsulate IP datagrams requires the unnecessary duplication of
several fields within the inner IP header; it is possible to save
some additional space by specifying a new encapsulation mechanism
that eliminates the duplication. The scheme outlined here comes from
the Mobile IP Working Group (in earlier Internet Drafts), and is
similar to that which had been defined in [2].
3. Minimal Encapsulation
A minimal forwarding header is defined for datagrams which are not
fragmented prior to encapsulation. Use of this encapsulating method
is optional. Minimal encapsulation MUST NOT be used when an original
datagram is already fragmented, since there is no room in the minimal
forwarding header to store fragmentation information. To encapsulate
an IP datagram using minimal encapsulation, the minimal forwarding
header is inserted into the datagram, as follows:
+---------------------------+
+---------------------------+
|
|
|
|
|
IP Header
|
|
Modified IP Header
|
|
|
|
|
+---------------------------+ ====> +---------------------------+
|
|
| Minimal Forwarding Header |
|
|
+---------------------------+
|
IP Payload
|
|
|
|
|
|
|
|
|
|
IP Payload
|
+---------------------------+
|
|
|
|
+---------------------------+
Perkins
Standards Track
[Page 2]
APPENDIX W
RFC 2004
Minimal Encapsulation for IP
October 1996
The IP header of the original datagram is modified, and the minimal
forwarding header is inserted into the datagram after the IP header,
followed by the unmodified IP payload of the original datagram (e.g.,
transport header and transport data). No additional IP header is
added to the datagram.
In encapsulating the datagram, the original IP header [6] is modified
as follows:
-
The Protocol field in the IP header is replaced by protocol
number 55 for the minimal encapsulation protocol.
-
The Destination Address field in the IP header is replaced by the
IP address of the exit point of the tunnel.
-
If the encapsulator is not the original source of the datagram,
the Source Address field in the IP header is replaced by the IP
address of the encapsulator.
-
The Total Length field in the IP header is incremented by the
size of the minimal forwarding header added to the datagram.
This incremental size is either 12 or 8 octets, depending on
whether or not the Original Source Address Present (S) bit is set
in the forwarding header.
-
The Header Checksum field in the IP header is recomputed [6] or
updated to account for the changes in the IP header described
here for encapsulation.
Note that unlike IP-in-IP encapsulation [4], the Time to Live
(TTL) field in the IP header is not modified during encapsulation;
if the encapsulator is forwarding the datagram, it will decrement
the TTL as a result of doing normal IP forwarding. Also, since
the original TTL remains in the IP header after encapsulation,
hops taken by the datagram within the tunnel are visible, for
example, to "traceroute".
Perkins
Standards Track
[Page 3]
APPENDIX W
RFC 2004
Minimal Encapsulation for IP
October 1996
The format of the minimal forwarding header 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Protocol
|S| reserved
|
Header Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Original Destination Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:
(if present) Original Source Address
:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol
Copied from the Protocol field in the original IP header.
Original Source Address Present (S)
0
The Original Source Address field is not present. The
length of the minimal tunneling header in this case is
8 octets.
1
The Original Source Address field is present. The
length of the minimal tunneling header in this case is
12 octets.
reserved
Sent as zero; ignored on reception.
Header Checksum
The 16-bit one’s complement of the one’s complement sum of all
16-bit words in the minimal forwarding header. For purposes of
computing the checksum, the value of the checksum field is 0.
The IP header and IP payload (after the minimal forwarding
header) are not included in this checksum computation.
Original Destination Address
Copied from the Destination Address field in the original IP
header.
Original Source Address
Copied from the Source Address field in the original IP header.
This field is present only if the Original Source Address
Present (S) bit is set.
Perkins
Standards Track
[Page 4]
APPENDIX W
RFC 2004
Minimal Encapsulation for IP
October 1996
When decapsulating a datagram, the fields in the minimal forwarding
header are restored to the IP header, and the forwarding header is
removed from the datagram. In addition, the Total Length field in
the IP header is decremented by the size of the minimal forwarding
header removed from the datagram, and the Header Checksum field in
the IP header is recomputed [6] or updated to account for the changes
to the IP header described here for decapsulation.
The encapsulator may use existing IP mechanisms appropriate for
delivery of the encapsulated payload to the tunnel exit point. In
particular, use of IP options are allowed, and use of fragmentation
is allowed unless the "Don’t Fragment" bit is set in the IP header.
This restriction on fragmentation is required so that nodes employing
Path MTU Discovery [3] can obtain the information they seek.
4. Routing Failures
The use of any encapsulation method for routing purposes brings with
it increased susceptibility to routing loops. To cut down the
danger, a router should follow the same procedures outlined in [4].
5. ICMP Messages from within the Tunnel
ICMP messages are to be handled as specified in [4], including the
maintenance of tunnel "soft state".
6. Security Considerations
Security considerations are not addressed in this document, but are
generally similar to those outlined in [4].
7. Acknowledgements
The original text for much of Section 3 was taken from the Mobile IP
draft [1]. Thanks to David Johnson for improving consistency and
making many other improvements to the draft.
Perkins
Standards Track
[Page 5]
APPENDIX W
RFC 2004
Minimal Encapsulation for IP
October 1996
References
[1] Perkins, C., Editor, "IPv4 Mobility Support", Work in Progress,
May 1995.
[2] David B. Johnson. Scalable and Robust Internetwork Routing
for Mobile Hosts. In Proceedings of the 14th International
Conference on Distributed Computing Systems, pages 2--11, June
1994.
[3] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[4] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[5] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
October 1996.
[6] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
Author’s Address
Questions about this memo can be directed to:
Charles Perkins
Room H3-D34
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532
Work:
+1-914-784-7350
Fax:
+1-914-784-6205
EMail: perk@watson.ibm.com
The working group can be contacted via the current chair:
Jim Solomon
Motorola, Inc.
1301 E. Algonquin Rd.
Schaumburg, IL 60196
Work:
+1-847-576-2753
EMail: solomon@comm.mot.com
Perkins
Standards Track
[Page 6]
APPENDIX X
A History and Survey of Network Firewalls
KENNETH INGHAM
Kenneth Ingham Consulting
and
STEPHANIE FORREST
University of New Mexico
Firewalls are network devices which enforce an organization’s security policy. Since their development, various methods have been used to implement firewalls. These methods filter network
traffic at one or more of the seven layers of the ISO network model, most commonly at the application, transport, and network, and data-link levels. In addition, researchers have developed
some newer methods, such as protocol normalization and distributed firewalls, which have not yet
been widely adopted.
Firewalls involve more than the technology to implement them. Specifying a set of filtering rules,
known as a policy, is typically complicated and error-prone. High-level languages have been
developed to simplify the task of correctly defining a firewall’s policy. Once a policy has been
specified, the firewall needs to be tested to determine if it actually implements the policy correctly.
Little work exists in the area of firewall theory; however, this article summarizes what exists.
Because some data must be able to pass in and out of a firewall, in order for the protected network
to be useful, not all attacks can be stopped by firewalls. Some emerging technologies, such as
Virtual Private Networks (VPN) and peer-to-peer networking pose new challenges for firewalls.
Categories and Subject Descriptors: C.2.0 [COMPUTER-COMMUNICATION NETWORKS]:
General
General Terms: security
Additional Key Words and Phrases: Firewalls, Network Security
The University of New Mexico Computer Science Department Technical Report 2002-37.
Author’s addresses: K. Ingham, Kenneth Ingham Consulting, 1601 Rita Dr NE, Albuquerque,
NM 87106-1127, ingham@i-pi.com. S. Forrest, Department of Computer Science, University of
New Mexico, Albuquerque, NM 87131, forrest@cs.unm.edu.
Permission to make digital/hard copy of all or part of this material without fee for personal
or classroom use provided that the copies are not made or distributed for profit or commercial
advantage, the ACM copyright/server notice, the title of the publication, and its date appear, and
notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish,
to post on servers, or to redistribute to lists requires prior specific permission and/or a fee.
c 20YY ACM 0000-0000/20YY/0000-0001 $5.00
ACM Journal Name, Vol. V, No. N, Month 20YY, Pages 1–42.
APPENDIX X
2
1.
·
K. Ingham and S. Forrest
INTRODUCTION
The idea of a wall to keep out intruders dates back thousands of years. For example,
over two thousand years ago, the Chinese built the Great Wall as protection from
neighboring northern tribes. A second example is that of European kings who built
castles with high walls and moats to protect themselves and their subjects, both
from invading armies and from marauding bands intent on pillaging and looting.
The term “firewall” was in use by Lightoler as early as [1764] to describe walls
which separated the parts of a building most likely to have a fire (e.g., a kitchen)
from the rest of a structure. These physical barriers prevented or slowed a fire’s
spread throughout a building, saving both lives and property. A related use of the
term arose in connection with steam trains, as described by Schneier [2000]:
Coal-powered trains had a large furnace in the engine room, along with a
pile of coal. The engineer would shovel coal into the engine. This process
created coal dust, which was highly flammable. Occasionally the coal
dust would catch fire, causing an engine fire that sometimes spread into
the passenger cars. Since dead passengers reduced revenue, train engines
were built with iron walls right behind the engine compartment. This
stopped fires from spreading into the passenger cars, but didn’t protect
the engineer between the coal pile and the furnace.
In this paper we will be concerned with firewalls in a more modern setting—
computer networks. The predecessors to firewalls for network security were the
routers used in the late 1980s to separate networks from one another. A network
misconfiguration which caused problems on one side of the router was largely isolated from the network on the other side. In a similar vein, so-called “chatty”
protocols on one network (which used broadcasts for much of their configuration)
would not affect the other network’s bandwidth [Avolio 1999; Schneier 2000]. From
these historical examples we can see how the term “firewall” came to describe a
device or collection of devices which separates its occupants from potentially dangerous external environments (e.g., the Internet). A firewall is designed to prevent
or slow the spread of dangerous events.
For the purposes of this paper, we define a firewall as a machine or collection of
machines between two networks, meeting the following criteria:
—The firewall is at the boundary between the two networks;
—All traffic between the two networks must pass through the firewall;
—The firewall has a mechanism to allow some traffic to pass while blocking other
traffic. The rules describing what traffic is allowed enforce the firewall’s policy.
Additional desirable criteria include:
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
3
—Resistance to security compromise;
—Auditing and accounting capabilities;
—Resource monitoring;
—No user accounts or direct user access;
—Strong authentication for proxies (e.g., smart cards rather than simple passwords);
—Fail-safety. If it fails, the protected system(s) is(are) still secure because no traffic
is allowed to pass through the firewall.
Our review of firewall technologies proceeds roughly in historical order. Interestingly, the historical development of firewalls parallels the descending levels of the
protocol stack:
ISO level
Internet example
Application
File Transfer Protocol (FTP), Telnet
Presentation e.g., Common Object Request Broker Architecture
(CORBA)
Session
no directly corresponding protocol
Transport
Transport Control Protocol (TCP), User Datagram
Protocol (UDP)
Network
Internet Protocol (IP)
Data link
Ethernet or Asynchronous Transfer Mode (ATM)
Physical
twisted pair or fiber optic cable
The protocols used on the Internet for these layers, as well as all other Internet
standards are specified by documents known as Requests for Comments (RFCs).
RFCs often provide information beyond the bare specifications of the standard,
and can be useful network administrators, and they appear frequently as citations
in this article. For more information about RFCs, read the RFC frequently-asked
question list [The RFC Editor 2001].
Following the order of much of the historical development of firewalls, this paper
is organized around the levels of the protocol stack, describing approaches which
filter or are otherwise directed at each level. Section 2 sets the stage by describing the many reasons why organizations and individuals need firewalls. The next
section, Section 3, describes other surveys of firewall technologies. Sections 4-7
descend through the protocol stack, discussing firewall technologies at each of the
four relevant levels. Figure 1 provides a graphical view of several of the architectures that we cover in remainder of the paper. Many of the firewalls we discuss use
or have used proxies as a major part of how they protect networks. A proxy is a
program that receives the traffic destined for another computer. Proxies sometimes
require user authentication; they then verify that the user is allowed to connect to
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
4
·
K. Ingham and S. Forrest
the destination, and then they connect to the destination service on behalf of the
user.
Section 8 considers firewall designs which do not fit cleanly into one of the various network protocol layers, for example, methods addressing multicast services,
distributed firewalls, and protocol normalization. Firewalls are a large part of the
commercial network security market. Many companies market products which filter network traffic one of the ISO levels. Although not the primary focus of this
paper, in Section 9 we consider important examples of these commercial products
and show how they fit into the existing literature. Specifying firewall policies can be
a complex task, and consequently, some higher-level languages have been developed
in which to express policies (Section 10). Once a policy has been specified, the next
question is, “How can it be determined that a given firewall correctly implements
the policy?” Firewall testing is one way to address this question, Section 11 reviews the literature on this topic. Although little theory has been developed about
firewalls, Section 12 describes the existing theoretical literature.
Very few computer networks can afford to be completely isolated from external
networks. Thus, an important job of a modern firewall is controlling what traffic is
allowed through the firewall. Detecting hostile data in this traffic is an important
problem confronted by modern firewalls, one that we discuss in Section 13. This
discussion leads to the related topics of expected future challenges for firewalls (Section 14) and some speculations about how firewalls have influenced recent protocols
and how they are likely to change in the future (Section 15).
2.
THE NEED FOR FIREWALLS
In the early years, the Internet supported a relatively small community of compatible users who valued openness for sharing and collaboration. This view was
challenged by the Morris Worm [Spafford 1988; Eichin and Rochlis 1989; Denning
1989; Spafford 1991]. However, even without the Morris worm, the end of the
open, trusting community would have come soon through growth and diversification. Examples of successful or attempted intrusions around the same time include:
Clifford Stoll’s discovery of German spies tampering with his system [Stoll 1988;
1989], and Bill Cheswick’s “Evening with Berferd” [1992] in which he set up a simple electronic “jail” for an attacker. In this jail, the attacker was unable to affect
the real system but was left with the impression that he or she had successfully
broken in. Cheswick was able to observe everything the attacker did, learning from
these actions, and alerting system administrators of the networks from where the
attacks were originating. Such incidents clearly signaled the end of an open and
benign Internet. By [1992] Steve Bellovin described a collection of attacks that he
had noticed while monitoring the AT&T firewall and the networks around it. The
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
gatekeeper
A
B
router
router
5
mailgate
Application
Proxy
Server
gate
Packet
Filtering
Router
Email
Server
Application
or Transport
Proxy
Server
R
Outside
Network
C
·
Inside
Network
Packet
Filtering
Router
D
DMZ
Network
Packet
Filtering
Router
Bridging
firewall
Fig. 1. Common firewall architectures, referred to throughout this paper. The blue portion of
the picture represents the trusted parts of the network, and the red portion indicates machines
or networks which are not trusted; these colors came from the original DEC documentation for
their firewall described in Section 4.1. A) The DEC SEAL from Section 4.1. B) A firewall using
only application- or transport-level proxies, a more common architecture than the DEC SEAL
architecture due to the reduced cost of hardware. The box containing just the “R” is an optional
router in this architecture. This architecture with the transport-level proxy server is similar to the
AT&T firewall described in Section 5.1. C) A firewall using two packet filtering routers (described
in Section 6.1) and illustrating one way of creating a DMZ, sometimes also known as a screened
network. A DMZ network consists of a network of machines offering services to the Internet. If a
machine here is compromised, the inside network remains safe. D) A bridging firewall similar to
that described in Section 7.
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
6
·
K. Ingham and S. Forrest
result was clear—there were many untrustworthy and even malicious users on the
Internet.
Because not everybody can be trusted, when networks are connected together, a
different level of trust often exists on the different sides of the connection. “Trust”
in this sense means that an organization believes that the both the software and
the users on its computers are not malicious. Firewalls can be used to enforce trust
boundaries, which are imposed for a variety of reasons:
Security problems in operating systems:. Operating systems have a history of insecure configurations. For example, Windows 95 and Windows 98 were widely
distributed with windows file sharing turned on by default; a collection of viruses
exploited this vulnerability (e.g., [Computer Emergency Response Team (CERT)
2000b; 2000c]). A second example is Red Hat Linux versions 6.2 and 7.0, which
were vulnerable to three remote exploits when installed using default options [Computer Emergency Response Team (CERT) 2001a]. It is an on-going and expensive
process to secure every user’s machine, and many organizations make a conscious
decision not to secure the machines inside their firewall. If a machine on the inside is ever compromised, the remaining machines are likely as vulnerable [Muffett
1995], a situation that has been described by Cheswick as “a sort of crunchy shell
around a soft, chewy center” [1990].
Individuals can protect a single machine connected to the Internet by purchasing
a personal firewall. Rather than trying to secure the underlying operating system,
these firewalls simply prevent some types of communication. Such firewalls are
often used in homes and on laptops when they are outside their normal firewall. In
this case, the trust boundary is the network interface of the machine.
Preventing access to information:. A second example of protecting a network is
the use of national firewalls, for example, China [McKay 1998]. This firewall exists
not to protect them from attack, but instead to (attempt to) limit the activities of
their users on the Internet. A similar idea is the use of filtering mandated in the US
by the Children’s Internet Protection Act (CHIPA). This law requires that schools
and libraries which receive federal funding put certain filters on all web content.
Preventing Information Leaks. Because all traffic leaving a network must pass
through the firewall, it can be used to reduce information leaks, as in [Ranum
1992]:
The key criterion for success for the Digital corporate gateways is preventing an unauthorized or unnoticed leak of data to the outside.
Enforcing Policy. Firewalls are one part of an overall security policy; they enforce
the policy of network traffic allowed to enter or leave a network. These policies may
limit the applications used, remote machines which may be contacted, and/or the
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
7
bandwidth allowed [Treese and Wolman 1993; Hambridge and Sedayao 1993].
Auditing. If a security breach (which does not include the firewall) occurs, audit
trails can be used to help determine what happened. Audit trails have also been
used to take employment actions against employees using work network resources
for non-work purposes.
3.
OTHER SURVEYS
Firewalls have existed since about 1987, and several surveys and histories have
already been written. However, none of them provide both the depth and breadth
of this survey, nor do they focus on the peer-reviewed literature describing firewall
technology.
In [1994], Alec Muffett wrote a paper which provided an excellent review of the
firewall policies and architectures of the time. This paper was aimed at people
considering implementing a firewall, describing the technologies which they might
select, their tradeoffs, and how to maintain a firewall.
One section of the Internet standards document RFC 1636 [Braden et al. 1994] is
about the status of firewalls as of February, 1994. In this section, they discuss the
problem of false security that a firewall often provides to an organization behind one.
They also review the concepts of application- and transport-level proxies, as well as
simple packet filtering. They discuss the problems of authentication and enforcing
policy, and provide some solutions from the time. One of the most important parts
of the firewall section is a discussion of how to design firewall-friendly protocols in
the future.
A review of firewalls and their technology appeared in Spectrum [Lodin and
Schuba 1998]. This paper is an excellent description of firewalls and their technology
at the time it was written. However, it has no references to peer-reviewed literature.
Several books have been written which describe how to build a firewall (e.g.,
[Cheswick and Bellovin 1994; Zwicky et al. 2000]). These books are excellent for
people wanting to either evaluate a commercial firewall or who are implementing
their own firewall. However, neither spends much time on firewall history, nor do
they provide references to peer-reviewed literature.
In [1997], John Schimmel wrote a historical review of firewall technologies aimed
at technical people working in the field of system administration. This review
contains good history about early packet filters and a brief overview of proxies.
Schimmel also mentions limitations of firewalls, many of which remain to this day
and are discussed in this paper in Section 13. Unfortunately, this paper has no
references to the original sources of the works described.
A survey of existing firewall technology appeared in Schuba’s Ph.D. dissertation,
[Schuba 1997]. In this dissertation, Schuba cites many key papers, but he reviews
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
8
·
K. Ingham and S. Forrest
the literature as it relates to technology, and does not provide as comprehensive a
collection of firewall-related references as we do in this paper. Steph: is this too
harsh? His work is not bad, and his entire thesis has 148 references. However, his
review of firewall literature is only 23 references. His review is really weak compared
to this paper.
Also in [1998], Rik Farrow wrote a firewall product analysis which was related
to the CSI firewall comparison for that year. This analysis is aimed at management and people just arriving at firewalls, and provides them with the background
information they would need to talk with a firewall vendor intelligently.
More recent publications include Frederic Avolio’s history of firewalls published
in the Cisco Internet Protocol Journal [1999]. Avolio is well-qualified to write
such a document, as he was involved with some of the first firewalls. His history
describes some of the beginnings of firewalls, from a technical point of view, and
aimed at technical people and technically-oriented management. He provides a
short description of firewalls which use proxies at the application or transport levels,
as well as packet filtering and firewalls which may be a mix of technologies. Rather
than providing details, he refers the reader to Cheswick and Bellovin’s [1994] book
on firewalls. As a contrast with Avolio’s history, this paper places emphasis on the
academic literature and as a result has substantially more references than Avolio’s
history.
Habtamu Abie wrote an overview of current firewall technology options and
emerging trends in [2000]. He discusses the technology, but does not cite the papers by the people who originally developed this technology. Also, Yakomba Yavwa
wrote a similar but less in-depth overview [2000]. Like Abie, Yavwa cites none of
the original papers where the technology was first described.
Finally, several trade and consumer magazines have reviewed firewalls; [Markus
2001] is a web site with links to many of them; the Computer Security Institute
(CSI) in San Francisco, California has a search engine for comparing different commercial firewall products [Computer Security Institute 2001].
Several related topics which we do not address thoroughly in our review include
intrusion detection systems [Northcutt and Novak 2001; Axelsson 1998], honeypots
[Cheswick 1992; Honeynet Project 2001], IPsec implementations [Doraswamy and
Harkins 1999], and commercial products.
4.
THE APPLICATION LEVEL
The application layer contains programs that interact directly with a user. Many
application-level protocols exist, including FTP, the Simple Mail Transport Protocol (SMTP), the HyperText Transport Protocol (HTTP), Telnet, etc. The first
published paper to describe filtering network traffic for access control, by Jeffrey
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
9
Mogul in [1989], described a system which worked at the application level.
4.1
The DEC Securing External Access Link
Mogul described a user-level1 solution to deciding whether or not to pass packets
though a router running the Unix operating system [Mogul 1989]. The packet filter
monitored the protocol, source and destination addresses and ports to decide which
packets were allowed to continue. Mogul’s implementation did not keep track of the
state of TCP connections, nor the pseudo-state that can be applied to some UDP
requests and responses. However, his implementation could have been expanded
to handle these; performance limitations of the computers of the day might have
prevented this.
The technology described by Mogul was applied to Digital Equipment Corporation’s (DEC) firewall by Paul Vixie [Ranum 1992] and further extended by Marcus
Ranum when it became the Securing External Access Link (SEAL)2 , which was
the first commercial firewall [Ranum 2001; Avolio 1999], delivered on June 13, 1991
[Avolio 1999]. The DEC SEAL consisted of three components (pictured in Figure 1,
part A):
Gatekeeper. The application proxy3 server for users who were allowed to access
external services. Gatekeeper was also an externally-accessible machine for uses
such as anonymous FTP, the Domain Name System (DNS), etc.
Gate. A packet filtering router limiting what traffic was allowed to pass between
the local and external network. This router was configured so that all traffic to/from
the inside went to a proxy on gatekeeper. screend, as described in Mogul’s paper
[Mogul 1989], performed the packet filtering.
Mailgate. The internal mail server/mail router; this machine was not accessible
from the outside. Instead, mail from the outside is delivered to gatekeeper, which
passes it to mailgate.
External connections are permitted only to gatekeeper, and it may (depending on
the configuration) also be the only way internal users are allowed to access services
external to the network.
Gatekeeper ran application-level proxies. These proxies also ensured that the
proper protocol was used (e.g., that FTP traffic is what went to port 20, and
not a Telnet session). The proxies on gatekeeper were [Ranum 1992; Treese and
Wolman 1993]:
1 As
opposed to a kernel-level.
documentation referred to it as the Screening External Access Link.
3 Proxies were described in detail on page 3.
2 Some
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
10
·
K. Ingham and S. Forrest
—email and USENET news (since these are store-and-forward protocols, no special
handling was needed)
—Telnet
—FTP
—WHOIS (a protocol for looking up network contact information)
—sup (a software distribution system developed at Carnegie Mellon University)
—the X window system. X is an especially hard protocol to secure, since the
client and server are “backwards”: the server is on the desktop and the client is a
remote machine. Treese and Wolman at DEC Cambridge succeeded in developing
a proxy which needed no changes to the X client or server code at all [Treese and
Wolman 1993].
All access across the firewall was through these application proxies. The proxies
provided several services [Digital Equipment Corporation 1992]:
—They validated that the source and destination machines were allowed to communicate with each other.
—They ensured that the user was allowed to access the service and remote machine
specified.
—They maintained an audit trail—all successful and unsuccessful connections were
logged.
—They enforced that the protocol behaved as expected (e.g., that telnet was not
used to connect to an interactive access terminal server which happened to be
running on the FTP port).
When a user wanted to send traffic outside of the local network, the traffic was
passed through gate to the proxy on gatekeeper. If the traffic was allowed, gatekeeper then sent the traffic on to the destination machine. No traffic was allowed
to pass directly from the local machine to the remote machine (and correspondingly, no traffic was allowed to pass directly from the remote machine to the local
machine).
The DEC firewall did not allow any UDP traffic to pass through it at all. This
prohibition was probably for two reasons:
—Some of the UDP protocols at the time (e.g., NTP, DNS) could have a server
running on gatekeeper to which the clients connected.
—Other UDP-based protocols, such as the Network File System (NFS), would have
security risks if they were allowed through the firewall.
The DEC SEAL is a classic example of a firewall which uses application-level
proxies. Proxies at this level provide excellent security and auditing. Also, because
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
11
they are themselves generating the connection to the remote machine, a proxy has
no problems knowing which connections are real and which are being spoofed; this
is in contrast to some packet filtering firewalls (Section 6).
One drawback of an application proxy is that it must be designed for the specific
protocol. New protocols are developed frequently, requiring the development of
new proxies; if there is no proxy, there is no access. Often this time lag creates
friction with the users, who may be demanding access to the latest applications, an
example of the classic tradeoff between security and user convenience.
Application proxies have other drawbacks. In order to use them, the client program must be changed to accommodate the proxy, telling it about the actual packet
destination and authenticating directly to the proxy. Because source code is not
publicly available for some applications, in many cases these changes can be made
only by the application’s vendor, a significant bottleneck. A final drawback of
application proxies is performance related, because each packet requires two trips
through the complete network protocol stack. None of the papers about the DEC
firewall discussed performance directly.
Over time, the DEC SEAL evolved into the AltaVista firewall. The architecture
appears to have remained similar, although it was collapsed onto one machine,
probably to stay cost-competitive with its competition [Mariet 1997; Smith et al.
1997], resulting in an architecture hybrid of Figure 1, parts B and D. Today, the
AltaVista firewall appears to no longer exist.
5.
THE TRANSPORT LEVEL
In the Internet, the transport level consists of only two protocols, TCP and UDP.
This small number of protocols makes writing a proxy much easier—one proxy
suffices for all protocols which use TCP. Contrast this with the application-level
proxies, where a separate proxy is required for each service, e.g., Telnet, FTP,
HTTP, SMTP, etc.
Transport-level proxies retain the advantage that a machine outside of the firewall
cannot send packets through the firewall which claim to be a part of an established
connection (some of the packet filters described in Section 6 have this problem).
Because the state of the TCP connection is known by the firewall, only packets
which are a legitimate part of a communication are allowed inside of the firewall.
5.1
AT&T’s Transport-Level Firewall
While DEC was building SEAL, Dave Presotto wrote and Bill Cheswick re-wrote
a firewall for AT&T [Cheswick 1990]. AT&T’s firewall also relied on proxies, a
term first used in the context of firewalls by Bill Cheswick in [Cheswick 1990]. The
resulting firewall was similar in effect to that of Figure 1, part B, although it was
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
12
·
K. Ingham and S. Forrest
composed of multiple machines.
In contrast to the application-level proxies in the DEC SEAL, the AT&T proxies
worked at the transport level [Cheswick 2001]. This difference arose from the different policies at DEC and AT&T. The DEC policy limited outbound connections,
with the goal of preventing unauthorized leaks of information to the outside. AT&T
did not limit outbound access other than requiring it to pass through the proxy.
As with application-level proxies, users paid a performance penalty because each
datagram had to traverse the network protocol stack twice. Cheswick noted that
file transfers without the proxy ran at 60-90 Kb/sec, while through the proxy they
ranged from 17-44 Kb/sec. Like application-level proxies, transport-level proxies
require that the client program be modified to use the proxy (however, modifying
a program to use a transport-level proxy is easier than modifying it to use an
application-level proxy; see SOCKS in Section 5.2).
5.2
Later Proxies
Kolbas and Kolbas wrote SOCKS [Koblas and Koblas 1992; Leech et al. 1996;
Leech 1996; McMahon 1996] with the goal of simplifying the use of proxies. A
SOCKS call replaced a normal socket call, which resulted in all outbound traffic
using the proxy. This approach was a nice, clean solution, and worked well if one
had the source code for the relevant operating system utilities. Some commercial
applications (e.g., Netscape) also were written to accommodate SOCKS. A system
using SOCKS and TCP connections could be transparent to the user (assuming the
proxy allowed them access to their destination host). In [2000], Fung and Chang
describe an enhancement to SOCKS to allow it to handle UDP streams, such as
that used by RealNetworks’ RealPlayer.
Marcus Ranum and Frederick Avolio worked on the Trusted Information Systems
(TIS) Firewall Toolkit (FWTK), a collection of proxies for building firewalls [Ranum
and Avolio 1994; Avolio and Ranum 1994]. This freely-available toolkit provided
SMTP, the Network News Transport Protocol (NNTP), FTP and Telnet application
proxies as well as a generic circuit-level proxy. To improve security, the proxies
used the UNIX system call chroot to limit how much of the system became visible;
this way if a proxy were compromised, the rest of the firewall was more likely to
remain trustworthy. The TIS FWTK had no proxies for UDP services; instead,
the firewall machine ran DNS and the Network Time Protocol (NTP). The inside
machines used the firewall for those services. When Trusted Information Systems
and Network Associates, Inc. (NAI) merged in February 1998, the TIS firewall
became NAI’s Gauntlet Internet Firewall.
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
13
6. THE NETWORK LEVEL
If a limited number of protocols at the transport level is an advantage, then it
would seem that the single protocol, IP, at the network level would be even better.
In some ways, it is. Packet filtering is fast, and it does not require the knowledge
or cooperation of the users. However, a packet filter working only at the network
level means that it cannot determine whether a packet belongs to an established
communication or not. And, similarly to transport-level proxies, it cannot enforce
which application-level protocol is used. For organizations trying to prevent an
information leak, this is a serious limitation. It is relatively straightforward to
use allowed protocols to send arbitrary data; for an example, see [daemon9 and
Alhambra 1996] which describes communication using the Internet Control Message
Protocol (ICMP) echo (“ping”) and ICMP echo reply (“pong”) packets. In spite of
these impediments, packet filtering at the IP level has been successful when state
information about the connection is used (Section 6.2).
6.1
Packet Filtering
Packet filtering for network security began with Mogul’s paper about screend [1989].
Whereas application- and transport-level proxies require each datagram to make
a trip up and down the whole protocol stack, packet filtering can be much faster.
Most of the early papers on packet filtering for security stressed the performance
benefits [Corbridge et al. 1991; Chapman 1992; Bailey et al. 1994; Molitor 1995];
later papers continued this trend [Suri and Varghese 1999; Lyu and Lau 2000].
Besides the performance benefits, packet filtering does not require the cooperation
of the users, nor does it require any special action on their part [Weber 1999].
Packet filters use one or more of the following pieces of information to make their
decision on whether or not to forward the packet [Reed 2002a]:
—source address
—destination address
—options in the network header
—transport-level protocol (i.e., TCP, UDP, ICMP, etc.)
—flags in the transport header
—options in the transport header
—source port or equivalent if the protocol has such a construct
—destination port or equivalent if the protocol has such a construct
—the interface on which the packet was received or will be sent
—whether the packet is inbound or outbound
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
14
·
K. Ingham and S. Forrest
Although packet filtering is fast, it does have drawbacks. The most important
limitation is the difficulty of writing correct filters. Several researchers have pointed
out this problem and attempted to solve it. Mogul in [1991] discusses the difficulty
of setting up packet filtering rules and provides correct examples as illustrations.
In [1992], Chapman makes the point that most packet filter languages are similar
to assembly language. In [1995], Molitor describes an improved commercial filter
language.
Another drawback of packet filtering is that it cannot determine which user is
causing which network traffic. It can inspect the IP address of the host where the
traffic originates, but a host is not the same as a user. If an organization with
a packet-filtering firewall is trying to limit the services some users can access, it
must either implement an additional, separate protocol for authentication or use
the IP address of the user’s primary machine as a weak replacement for true user
authentication.
Also, because IP addresses can be spoofed, using them for authentication can
lead to other problems. If the router is running a properly configured filter, remote
attackers should not be able to spoof local addresses, but they could spoof other
remote addresses. Local machines can spoof other local machines easily. In spite
of these problems, many organizations are using IP addresses or DNS names for
access control.
When a proxy is used, the connection to the remote machine comes from the
machine running the proxy. With packet filters, the local machine directly initiates
the connection to the remote machine. A result of this difference is that the entire
internal network is potentially reachable from external connections; otherwise the
reply packets from the remote host would not be delivered properly. As a consequence, hostile remote computers may be able to exploit weaknesses in the protocol
implementation of the local machine (e.g., [Securityfocus.com 1997]).
Protocols such as FTP [Postel and Reynolds 1985] also cause problems for packet
filters. FTP uses a control channel opened from the client to the server for commands. However, when getting a file, one method of using FTP (active FTP) has
the server open a connection back to the client. This connection is initiated from
the FTP data port (TCP port 20) to a random client port. Since malicious programs could use the FTP data port as their source port, packet filter writers cannot
assume that a connection from TCP port 20 is a FTP transfer. One solution is to
use passive FTP, where the client opens the connection for the data transfer to the
server. However, not all FTP clients support passive transfers. RFC 1579 [Bellovin
1994] suggests that FTP client writers include support for the passive method of
file transfer, but this solution has yet to be universally adopted.
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
6.2
·
15
Packet Filtering with State
Originally, packet filters did not keep track of the state of a connection. This means
that a remote host could send in packets which appeared to be part of an established
TCP connection (with the TCP ACK flag set), but which in reality were not. This
allowed a remote attacker to map the local network as if the firewall did not even
exist. Attacks against bugs in the TCP/IP protocol stack (e.g., [Securityfocus.com
1997]) can pass through the firewall by claiming to be part of an established TCP
session.
The solution to this problem is to keep track of the state of a connection, a
property referred to variously as stateful firewalls, adaptive firewalling and packet
inspection. In other words, the packet filter looks at both the network level and the
transport level data. The router monitors the initial TCP packets with the SYN flag
set and allows the packets to return through only until the FIN packet is sent and
acknowledged. A similar pseudo-state can be kept for most UDP (e.g., DNS, NTP)
and some ICMP communication (e.g., ping)—a request sent out opens a hole for
the reply, but only for a short time. In [1992], Chapman was one of the first to point
out the problem of the lack of state in packet filtering firewalls. In [1995], Molitor
identified the problem of implementing state in his packet filtering architecture as a
“future direction.” The first peer-reviewed paper to describe adding state to packet
filters was by Julkunen and Chow in [1998], where they describe a dynamic packet
filter for Linux. This paper was proceeded by a technical report in [1997].
Although Julkunen and Chow were the first to publish a peer-reviewed paper
about keeping state in packet-filtering firewalls, they were not the first to keep
track of connection state. IP Filter (IPF) version 3.0 in 1996 by Darren Reed
predated their work [Reed 2002b; 2002c]. The first peer-reviewed description of
this work appeared much later in a discussion of state in IPF [van Rooij 2001].
6.3
Improving Packet Filter Specification
In [1992], Chapman makes the point that writing packet filter rules is similar to
writing in assembly language. Some researchers have therefore developed higherlevel languages for specifying packet filters. These improved packet filter languages
are simpler than the policy specifications mentioned in Section 10, and they do
somewhat ease the writing of filter rules. Specific examples include:
—In [2000], Hazelhurst proposed binary decision diagrams (BDDs) for visualizing router rule sets. Since BDDs represent boolean expressions, they are ideal
for representing the block/pass rules which occur in packet filters. BDDs also
make automated analysis of packet filter rules easier, as well as providing better
performance than the table lookups used in many routers.
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
16
·
K. Ingham and S. Forrest
—The filter language compiler, flc [Reed 19], allows the use of the C preprocessor,
specification of a default block or pass policy for various directions of traffic flow,
and provides a simple if-then-else facility. flc also generates rules for several
different packet filters (IPF, ipfw, ipfwadm, ipfirewall, Cisco extended access lists,
and screend ).
6.4
Network Address Translation (NAT)
Because the Internet is short of IPv4 addresses, many people use Network Address
Translation (NAT) to gain more mileage out of a single IP address [Egevang and
Francis 1994; Srisuresh and Egevang 2001; Hain 2000]. When a router uses NAT,
it changes the source address of outbound packets to its own address (or one from
a pool of addresses which it controls). It chooses a local, unused port for the upper
layer protocol (TCP or UDP), and stores in a table the association between the new
address and port and the real sender’s address and port. When the reply arrives,
it looks up the real destination in this table, rewrites the packet, and passes it to
the client. When the connection is finished (or after a timeout period for UDP
packets), the entry is removed from the table.
NAT provides a similar form of protection to that of proxies. In NAT, all connections originate from the router performing the address translation. As a result,
someone outside the local network cannot gain access to the protected local machines unless the proper entry exists in the table on the router. The network
administrator can manually install such an entry, causing all traffic destined for a
specific port to be forwarded to a server for that service (in effect, providing an
Internet-accessible service on an inside machine.4 ).
RFC 2663 [Srisuresh and Holdrege 1999] notes that NAT is not without its problems. For example, NAT may prevent IPsec from working correctly. One feature
of IPsec is the ability to know that a packet was not modified during transit. However, one of the purposes of NAT is to modify the packet—the source address and
possibly the source port must be modified for NAT to work. DNS problems can
also occur. A machine behind a router using NAT has a name and an IP address.
However, most networks using NAT also use RFC1918 [Rekhter et al. 1996] private
IP addresses, which are not globally unique. Therefore, DNS inside the network is
not meaningful outside the network.
4 Setting
up such an entry is usually a bad idea from a security standpoint. Maintaining a server
inside a firewall is risky because if it is compromised, the attacker then has access inside the
network, which as noted in Section 2 is likely to be insecure.
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
17
7. THE DATA-LINK LAYER
A bridge is a network device which works at the ISO data-link layer. Because it
operates at this level, it does not need to access to routing information. A bridging
firewall uses the information listed in Section 6.1 to decide whether or not to block
a packet. As a result, a bridging firewall can look at data in several other levels of
the Internet Protocol suite, including the network and transport layers. Because a
filtering bridge is still a filter, the disadvantages of packet filtering still apply to it.
What makes a bridging firewall different from a packet filtering router is that it
can be placed anywhere because it is transparent at the network level (see Figure 1,
part D). It can be used to protect a single machine or a small collection of machines
that would normally not warrant a separate network required when using a router.
As it does not need its own IP address, the bridge itself can be immune to any attack
which makes use of IP (or any of the protocols on top of IP). And, no configuration
changes are needed in the protected hosts when the firewall is installed. Installation
times can be minimal (for example, Limoncelli claims three second install times
[Limoncelli 1999]), so users are minimally disrupted when the bridge is installed.
The first bridging firewalls were described by Kahn et al. in [1997] and developed
for computers running DOS. They refer to earlier unpublished research concerning
packet filtering filtering on a bridge. Later work which also explores the idea of a
bridging firewall includes Jianbing Liu and Yan Ma in [Liu and Ma 1999]. Keromytis
and Wright discuss using IPsec on a bridging firewall to set up secure, virtual LANs
[2000].
8.
OTHER APPROACHES TO FIREWALLS
Some firewall designs do not fit cleanly into a single network protocol layer. Some
of them (e.g. Normalization, discussed in Section 8.2) are ideas that can be implemented in a firewall using one of the technologies already discussed. These proposals are just now being incorporated in firewall implementations. Others, such as
the distributed firewalls discussed in Section 8.5 are more revolutionary, changing
the entire architecture of the firewall. Although a few organizations may be using
firewalls based on these more revolutionary ideas, they are not yet in widespread
use.
8.1
Transparent Proxies
As mentioned in Sections 4.1 and 5.1, the primary problem with proxies has been
that the client software must be modified and/or the user must work differently
when using the. Transparent proxies address this limitation. With a transparent
proxy the client sends packets to the destination in a normal fashion. However, when
the packets reach the firewall, access control checks and logging are performed as in
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
18
·
K. Ingham and S. Forrest
a classical proxy system. The “magic” is implemented by the firewall, which notes
the destination address and port, opens up a connection to it and then replies to
the client, as if the proxy were the remote machine. This relaying can take place at
either the transport level or the application level. RFC 1919 [Chatel 1996] compares
classical proxies with transparent proxies. Bonachea and McPeak use transparent
proxies to improve the security of FTP in [2001]. Rodriguez et al. describe what
they call translucent proxying of TCP in [2001].
Transparent proxies are demanding because the firewall must operate both at the
network and application levels. Therefore, performance has remained a concern.
One solution proposed by Spatscheck et al. [2000] and Maltz and Bhagwat [1998]
is that of “splicing.” In splicing, after the proxy verifies that communication is
allowed to proceed, the firewall converts to a network-level packet filtering firewall
for that communication. Splicing provides the extra control of proxies but maintains
performance closer to that of packet filters.
8.2
Normalization
Attackers often abuse protocol specifications, e.g., by sending overlapping IP fragments or out-of-order TCP byte sequences. In [2001], Handley et al. stressed that
a firewall is a good location for enforcing tight interpretation of a protocol. Besides protecting the computers behind the firewall from attacks based on protocol
abuses, this so-called “normalization” also makes signature-based intrusion detection systems more reliable because they see a consistent data stream. Handley et
al. provide a list of possible normalizations, ranging from those guaranteed to be
safe to others that are potentially too strict in their interpretation of the standard.
They were not the first to suggest normalization, however. In [2000], Malan et al.
describe “transport scrubbing,” and more recently the idea is elaborated in [Watson
et al. 2001]. At about the same time, Strother [Strother 2000] proposed a similar
idea. Her solution involved different rings of trust, in which a network packet must
pass through one ring before proceeding to the next. Many of her rings achieve the
same effect as normalization.
8.3
Signature-based Firewalls
Malan et al. discuss “application scrubbing” in [2000]. In this approach, a user-level
program is established as a transparent proxy (see Section 8.1) which monitors the
data stream for strings known to be hazardous (and presumably to prevent these
strings from reaching the client). Watson et al. refer to the same concept as a
“fingerprint scrubber” in [2001].
Snort [Roesch 1999] is a common intrusion detection system. Hogwash [Larsen
2001] is a firewall that blocks packets matching the snort rules. It runs on a bridging
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
19
firewall (Section 7) and the authors claim it can handle network speeds of up to
100Mbps on hardware which is not state-of-the-art.
8.4
Firewalls at Other ISO Network Levels
The Common Object Request Broker (CORBA) allows applications written in one
language to make requests of objects which may be written in a different language
and which may be available on a different machine. The CORBAgate by Dotti and
Rees in [1999a; 1999b] is a presentation-level proxy. When a request is made to an
object which is on the other side of the firewall, the proxy transparently changes the
references. The result is that objects on either side of the firewall end up referring
to an object on the firewall.
8.5
Distributed Firewalls
There are several limitations to the firewall technology that we have presented so far.
One common assumptions is that all the hosts inside a firewall are trustworthy. This
assumption is not always valid—for example, see the discussion about the problems
with virtual private networks (VPNs) in Section 14.1. A related problem is that
firewalls ignore internal traffic, which may violate security policy. Because firewalls
are typically centralized in one location, they can become performance bottlenecks
as well as providing a single point of failure. A further limitation of conventional
firewalls arises because in some cases the local machines know the context of the
communication not available to the firewall. For example, a file transfer may be
allowed or denied based on what file is being transferred and by whom. The firewall
does not have this local, contextual knowledge.
One solution to these problems, proposed by Bellovin [1999], is a distributed
firewall. This was implemented by Ioannidis et al. in [2000] and by Markham and
Payne in [2001]. In this firewall, the network administrator has a single policy
specification, loaded onto all machines. Each host runs its own local firewall implementing the policy. Machines are identified by cryptographic certificates, a stronger
form of authentication than IP addresses. With a distributed firewall, the common
concept of a DMZ or screened network, where servers accessible to the outside world
are located, is no longer necessary (for an example of a DMZ or screened network,
see Figure 1, part C).
Hwang and Gangadharan [Hwang and Gangadharan 2001; Gangadharan and
Hwang 2001] propose using firewalls on all devices attached to the network, where
they can be combined with an intrusion detection system (IDS). When the IDS
detects an anomalous event, it modifies the firewall to react to the threat. Lower
overhead can be achieved with this approach than that reported for the distributed
firewall developed by Ioannidis [2000]. However, the architecture still uses a conACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
20
·
K. Ingham and S. Forrest
ventional firewall.
Distributed firewalls have a different set of problems than centralized ones. The
most significant is that a distributed firewall relies on its users (with physical access
to the machine) not to override or replace the policy. In other words, the network
administrator must trust his or her users. Additionally, if the firewall is running as
a part of the operating system, then the operating system must protect the firewall
software. However, the local firewall is protecting the operating system, creating a
circular set of dependencies. In [2001], Markham and Payne propose implementing
the distributed firewall on a programmable network interface card (NIC) to reduce
reliance on the operating system for protection.
Around the same time that Bellovin proposed the distributed firewall, Ganger
and Nagle at Carnegie Mellon University also proposed a distributed approach to
security in [2000], in which each device was responsible for its part of the security
policy. Ganger and Nagle argue that if each device were more secure, then an
attacker who succeeds in passing the outer defenses (the firewall) would not find
vulnerable targets inside. They propose installing security devices on many parts of
a network, such as NICs, storage devices, display devices, and networking hardware
such as routers and switches. The idea is that the devices would dynamically
adjust their approach to security based on the overall network defense level. As
with Bellovin’s proposal, programmable NICs are an important part of the overall
strategy.
8.6
Protection against denial of service attacks
In a denial of service attack, the attacker’s goal is to reduce or eliminate an authorized user’s access to a service, machine or network by disabling the service or
machine, or by overloading some aspect of the system with voluminous but legal
activities. Because all traffic for the network travels through the firewall, some
denial-of-service attacks can be stopped at the firewall. For example, protocolbased attacks (e.g., [Computer Emergency Response Team (CERT) 1997b] and
[Computer Emergency Response Team (CERT) 1998]), which cause the remote
machine to crash, can be stopped by protocol normalization (Section 8.2). When
attackers are attempting to saturate available bandwidth, Ioannidis and Bellovin
proposed the idea of pushback—the ability for a router to detect and preferentially
drop packets which are part of an attack, and also to notify upstream routers of
the attack [Ioannidis and Bellovin 2002].
In [2000], Balasubramanian described an architecture in which network- and hostbased intrusion detection systems are combined with a policy-driven coordinator to
respond to denial of service attacks. This response is a job that traditionally would
be given to the firewall. As presented, the response could be anything a process
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
21
can do; it is up to the network administrator to determine the proper response to
the attacks. Balasubramanian recognizes but does not address the problem of false
positives or spoofed network packets being used to cause a reaction desired by the
attacker.
In [1997], Schuba et al. review various approaches to SYN-flood denial-of-service
attacks and present a new approach (not limited only to firewalls). They suggest
using a program to monitor all traffic on the LAN. They describe a program which
categorizes SYN packets into four classes: never seen, belonging to correctly behaving hosts, potentially spoofed, and certainly spoofed. In addition to the program’s
classification, the administrator can provide a collection of addresses known to be
good or bad. When the program sees SYN packets from bad hosts (dynamically
characterized by their behavior), it sends a RST packet to kill the half-open connection.
8.7
Multicast
On the Internet, multicast is often used for various forms of multimedia. In contrast
with traditional unicast communication, in multicast the sender does not necessarily
know the identities of all the participants in the session. And, this is also true for the
recipients, who do not know in advance all the possible people who might be sending
to them. This difference also makes proxies such as SOCKS difficult to implement
unless they change the multicast into a collection of unicasts, a change that defeats
the benefits of multicast—with multicast, once one client inside of the firewall has
joined a group, others may join without needing to authenticate. Additionally,
the multicast routing protocol, the Internet Group Management Protocol (IGMP),
specifies only multicast groups and not UDP ports; in a default configuration, a
multicast source has access to the complete set of UDP ports on client machines. If
a source has access to all UDP ports, then it could potentially attack other services,
(e.g. Microsoft networking) which are unrelated to the service it is providing.
The classic paper on multicast and firewalls was published by Djahandari and
Sterne in [1997]. In this paper they describe an application proxy for the TIS
Firewall Toolkit. The proxy has the following features:
—It allows authentication and auditing;
—It prevents multicast traffic from reaching hosts which did not request it;
—It allows the multicast traffic to be sent only to “safe” ports.
The proxy converts multicast traffic into unicast traffic. Unfortunately, this approach also means that it does not scale well, as a collection of N users all receiving
the same multicast stream increases the traffic inside the firewall by a factor of N
over what it would have been if multicast had been retained. On the other hand,
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
22
·
K. Ingham and S. Forrest
they do solve all of the security problems mentioned in the previous paragraph and
later in this section.
RFC 2588 [Finlayson 1999] suggests several possible solutions to the problem of
multicast and firewalls. For example, communication between external and internal
machines could be tunneled through the firewall using the UDP Multicast Tunneling
Protocol (UMTP). This protocol was designed to connect clients to the Multicast
Backbone (the MBone), but would work for tunneling through multicast-unaware
firewalls.
RFC 2588 also mentions the possibility of dynamic firewall rules, and in [1999],
Oria describes in further detail how they can be implemented. A program runs on
the router, which monitors multicast session announcements. The program reads
the announcements, and if the specified group and UDP port are allowed by the
policy, it generates the necessary rules permitting the data to pass through the
firewall. When a client informs the router that it wishes to join a multicast group,
it sends an IGMP join message to the router. The dynamically generated rules
permit or deny this access. This approach to multicast on the firewall assumes that
session announcements can be trusted. Unfortunately, this is not a valid assumption
because they can be spoofed.
8.8
Transient Addressing
Many protocols, such as FTP, RealAudio, and H.323 (a protocol used for programs
such as Microsoft’s NetMeeting), open secondary channels for additional communication. These additional channels are a problem for firewalls unless the firewall
makes use of a stateful proxy. In [2001] Gleitz and Bellovin propose a solution
to this problem by taking advantage of version 6 of the Internet Protocol (IPv6),
which has 128 bits of address space. This is large enough for each host to have multiple addresses. A client initiating a connection to a FTP server uses an address
which includes the process group ID of the FTP client process. The firewall sees
a connection from a specific IPv6 address going to a FTP server at a remote site,
and then allows all communication from the server back to the client’s address. On
the client side, this address is only used for the FTP process; connections from the
FTP server to other ports on the client will not be accepted, because only the FTP
client is using that specific address.
9.
COMMERCIAL FIREWALL PRODUCTS
It is difficult to separate completely advances in firewall technology from the commercial products that implement them. There is a large market for commercial
firewall products, which has driven many important recent developments. At the
same time, without direct inspection of the source code, it can be quite difficult
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
23
to ascertain exactly how or why a particular product operates. Further, the success or failure of commercial products depends as much on business issues as on
technical merit. In spite of these problems, no review of firewall technology would
be complete without some discussion of commercial products. In the following, we
highlight a few of the many products currently on the market, emphasizing those
that we believe are interesting intellectually, have had unusual impact on the development of firewalls, or are particularly clear examples of a particular methodology.
9.1
Network Associates, Inc. (NAI)
As mentioned in Section 5.2, the TIS firewall toolkit was an early firewall based
on proxies. After the merger with NAI, it became the basis for the Gauntlet firewall. This firewall continued to evolve and now incorporates the following features
[Network Associates Technology, Inc. 2001b; 2001c; 2001d]:
—Packet filtering with state;
—Transport-level proxies;
—Transparent application-level proxies for common protocols such as RealAudio,
QuickTime, HTTP, SMTP, and FTP;
—Groups to ease the packet filter specification;
—Splicing like was described in Section 8.1 to improve performance;
—Content scanning for known viruses and hostile applications.
9.2
Cisco
Cisco has two firewall products (IOS firewall and Private Internet Exchange (PIX))
which share many features, but also have some differences. Both are based on
packet filtering with state. They also perform what is known as “inspection,” in
which the packet filter inspects the data inside the application layer and modifies
the packet filtering rules to adapt to what the application is expected to do. For
example, the inspection algorithm could determine that a FTP client will need a
port opened, changing the filtering rules appropriately. The result of such packet
inspection is similar to that provided by a transparent application proxy, but with
less overhead. It also suffers from the same problems—as protocols evolve, the
inspection code must also evolve in order to take advantage of the new features in
the protocol.
Both firewalls can require authentication against Terminal Access Controller Access Control System (TACACS)+ or Remote Authentication Dial-In User Service
(RADIUS) before passing packets from or to specified hosts and/or services. The
IOS firewall can also use Kerberos for authentication [Cisco Systems, Inc. 2001].
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
24
·
K. Ingham and S. Forrest
The PIX is especially notable because it was the first commercially available implementation of NAT [Cisco Systems, Inc. 2000]. It also regenerates TCP sequence
numbers, using strong random numbers. This is important because machines which
have weak TCP sequence number generation algorithms are vulnerable to session
hijacking and spoofed one-way connections.
The IOS firewall protects against pre-identified malicious Java applets, presumably by matching against a static signature file. The IOS firewall defends and
protects against SYN floods and other closely related TCP attacks. As explained
in [Cisco Systems, Inc. 2001], SYN-floods are detected by
comparing the rate of requests for new connections and the number of
half-open connections to a configurable threshold level to detect SYN
flooding. When the router detects unusually high rates of new connections, it issues an alert message and takes a preconfigured action
The preconfigured action either instructs the protected host to drop half-open connections (presumably by sending it a TCP reset packet), or temporarily filters all
TCP SYN packets destined for the protected host. Unfortunately, this action disables all inbound connections to the protected host. The IOS firewall also monitors
TCP sequence numbers and drops all packets with suspicious numbers.
9.3
Lucent’s firewall family
Lucent’s firewall family [Lucent Technologies 2001] is based on packet filtering with
state. Similar to Cisco, packets are inspected, and the packet filter examines at the
higher-level data (including some protocols at the application layer). Unlike the
Cisco products, the firewall can be a bridging firewall.
9.4
Sun’s Sunscreen Secure Net
Sun’s Sunscreen Secure Net 3.1 [Sun Microsystems 2000] is based on packet filtering
with state and a collection of application proxies. Its HTTP proxy can be configured
to pass or drop Java applets. It can also filter:
—Java applets based on the cryptographic signature included in the applet,
—Java applets based on a hash of the applet,
—Cookie requests, and
—ActiveX content.
The FTP proxy is a true application proxy and therefore can limit access to certain
file transfer commands such as put or get based on source and destination addresses
and/or user authentication.
Sunscreen Secure Net can also be configured as a bridging firewall.
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
10.
·
25
FIREWALL POLICY SPECIFICATION
Firewalls were originally built and configured by experts. Now, firewalls are commodity products which are sold with the intent that nearly anyone can be responsible for their network’s security. The network administrator uses a graphical user
interface (GUI) to configure packet filtering rules. Unfortunately, this GUI still
requires the user to understand the complexities of packet filters. These complexities were originally pointed out in [1992] by Chapman. In many cases, the only
difference between then and now is that the user interacts with the packet filter
rules through a GUI. The common use of transparent proxies only increases the
complexity of the administrator’s task.
Some researchers have tried to improve the way that firewalls are managed.
Guttman [1997] described a LISP-like language for expressing access control policies for networks where more than one firewall router is used to enforce the policy.
The language is then used to compute a set of packet filters which will properly
implement the policy. He also presents an algorithm for comparing previously
generated filters to the policy to identify any policy breaches. However, the automatically generated filters are not expressed in the language of any router; the
network administrator must build them manually from the LISP-like output.
In [2000], Hazelhurst et al. describe binary decision diagrams (BDDs) for visualizing router rule sets. BDDs have the benefit that they can represent boolean
expressions—this makes them ideal for representing the block/pass rules which occur in packet filters. Once a set of packet filter rules has been converted to BDDs,
it becomes easy to apply automated analysis. BDDs are also an efficient method
for storing and using the rules; they can be used by a router to provide better
performance than the simple table-based lookup which is used in many routers in
2002.
The Internet standards RFC2748 [Durham et al. 2000], RFC3060 [Moore et al.
2001] and RFC3084 [Chan et al. 2001] describe the Common Open Policy Service
(COPS) protocol. This protocol is used between a policy server (Policy Decision
Point or PDP) and its clients (Policy Enforcement Points or PEPs). The basic
idea is that the policy is specified at a different location from the firewall (a PEP),
and the policy server ensures that the various policy enforcers have and use the
correct policy. The policy may relate to Quality of Service (QoS), it may relate
to security, or it may relate to some other part of network policy (e.g., IPsec); the
COPS protocol is extensible. The network is modeled as a finite state machine
and a policy is modeled as a collection of policy rules. These rules have a logical
expression of conditions and a set of actions. If the logical expression is true, then
the actions are executed. These actions may cause a state change in the network
finite state machine. The policy rules can be prioritized, allowing conflict resolution
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
26
·
K. Ingham and S. Forrest
when two or more rules match but specify conflicting actions. As these proposed
standards are adopted, they will have a significant impact on how firewalls are
constructed.
Stone et al. survey policy languages through late 2000 and describe a new approach to policy specification [Stone et al. 2001]. In addition to security concerns,
their approach also takes into account Quality of Service (QoS). In specifying policies, they note that some policies are static, i.e., for security reasons, all access to
certain network addresses are prohibited. Other policies, however, are dynamic,
i.e., if the available bandwidth is too low, streaming video is no longer allowed.
Finally, different users may receive different levels of service (e.g., customers in the
company web store have priority over employees browsing the web). Their policy
language is called the Path-Based Policy Language (PPL), and it corrects some of
the deficiencies in the other policy languages.
Damianou et al. describe a policy language, Ponder, in [2001]. Ponder is a declarative, object-oriented language, which through its structures can represent policies.
Constraints on a policy can also be represented in Ponder. Although Ponder appears to be a particularly rich and expressive language for expressing policies, there
is not yet an automated policy implementation path.
Bartal et al. describe firmato [Bartal et al. 1999]. firmato has an underlying
entity-relationship model which specifies the global security policy, a language in
which to represent the model, a compiler which translates the model into firewall
rules, and a tool which displays a graphical view of the result to help the user
visualize the model.
A module for use with firmato is the firewall analysis engine, Fang (Firewall
ANalysis enGine) by Mayer et al. [2000]. Fang reads the firewall configurations
and discovers what policy is described. The network administrator can then verify that the policy being implemented by the various routers matches the desired
policy. For example, the network administrator can ask questions such as “From
which machines can our DMZ be reached, and with which services?” Fang builds
a representation of the policy; it is not an active testing program. This difference allows Fang to test both that authorized packets actually succeed as well as
that unauthorized packets are blocked. It also allows testing before the firewall is
deployed; by contrast, active test tools require the firewall to be up and running
to test it. Also, active testing cannot test the network’s vulnerability to spoofing
attacks, whereas Fang can. Fang provides a GUI to collect the queries from the
network administrator and to display the results.
A recent example of this family of firewall test and analysis tools is the Lumeta
Firewall Analyzer (LFA) [Wool 2001]. LFA is a commercial product which goes
beyond Fang by automatically generating the “interesting” queries. The network
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
27
administrator needs only to provide the firewall configuration. The result is a system that hides the complexities of the underlying router configurations, providing
a much more comprehensible picture of the resulting policy.
11.
FIREWALL TESTING
Firewall testing was originally an ad-hoc exercise, the thoroughness being determined by the skill of the person running the tests. A second phase of testing
methodology included security scanners such as the Security Administrator Tool
for Analyzing Networks (SATAN) [Venema 1995] and the Internet Security Systems (ISS) Internet scanner [Internet Security Systems, Inc. 2002]. These scanners
provided the basis for the National Computer Security Association (NCSA) certification [Vigna 1997] for a period of time. Vigna extended this approach by defining
a formal model of a network’s topology in [1997]. His model can also represent
the TCP/IP protocol stack up through the transport level. Using this model, he
was able to generate logical statements describing the requirements for the firewall.
Given these requirements, he then generated a series of locations for probes and
packets to attempt to send when testing the real firewall. From a formal standpoint, this work is promising, but it fails to address the common problem of how to
develop a correct formal description. Producing complete formal descriptions for
realistic networks represents a significant amount of work and is difficult to do correctly. Additionally, the test generator must have a complete list of vulnerabilities
for which to generate tests.
Marcus Ranum took a different approach to firewall testing in [Ranum 1995]; he
notes that firewalls are (or at least should be) different for different organizations.
After a firewall is deployed, an expert can study the policy specification for the
firewall and decide which tests will verify that the firewall properly implements
the policy, using a top-down approach. He emphasizes the importance of testing
both the security of the firewall itself (that the firewall is secure from attack) and
the correctness of the policy implementation. Unfortunately, such testing is both
expensive and time-consuming.
Some of the tools for firewall policy specification (Section 10) also provide testing
or guidance for testing.
12.
FIREWALL THEORY
Firewalls have evolved in an ad-hoc fashion, reacting to various attacks. Lyles
and Schuba [1996b; 1996a] and Schuba et al. [1997] developed the first formal
model for firewalls. Their model described firewall technology in terms of a policy
P , communication traffic T , and a network policy domain D. This model allows
firewall functions to be distributed across multiple machines. It also allows for
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
28
·
K. Ingham and S. Forrest
repeated application of the theory; for example, at the link, network, and transport
layers of a network. Schuba expanded the model in his Ph.D. dissertation [1997],
developing a theoretical basis for firewalls based on Hierarchical Colored Petri Nets
(HCPN).
A different and less detailed formal model of firewalls is presented by Vigna in
[Vigna 1996; 1997]. Here, a network is modeled as a hypergraph, protocols such
as IP, UDP, and TCP are modeled as tuples (possibly containing other tuples). A
vulnerability is a boolean expression of quantified boolean expressions relating the
tuples and hypergraphs. These vulnerabilities can be used to generate tests for
firewalls.
Packet classification is an important part of filtering traffic. Gupta and McKeown
wrote a review of packet classification algorithms in [2001]. They provide examples
of four different types of algorithms, and discuss when the algorithms might be
most useful.
13.
WHAT FIREWALLS DO NOT PROTECT AGAINST
No firewall provides perfect security. Several problems exist which are not addressed
by the current generation of firewalls. In the event that a firewall does try to provide
protection for the problems discussed in this section, either it is not in widespread
use or it has problems with the protection it provides.
13.1
Data Which Passes Through the Firewall
A firewall is probably best thought of as a permeable membrane. That is, it is
only useful if it allows some traffic to pass through it (if not, then the network
could be physically isolated from the outside world and the firewall not needed).
Unfortunately, any traffic passing though the firewall is a potential avenue of attack.
For example, most firewalls have some provision for email, but email is a common
method of attack; a few of the many email attacks are described in [Cohen et al.
2001; Computer Emergency Response Team (CERT) 1999; 2000a; 2001b; 2001c;
2001d]. The serious problem of email-based attacks has resulted in demand for
some part of the firewall to check email for hostile code. Products such as AMaViS
[amavis.org 2002] and commercial email virus scanners (e.g., [Network Associates
Technology, Inc. 2001a]) have responded to this problem. However, they are only
as good as the signatures for which they scan; novel attacks pass through without
a problem.
If web traffic is allowed through the firewall, then network administrators must
cope with possibility of malicious web sites. With scripting languages such as Java,
JavaScript, and ActiveX controls, malicious web administrators can read arbitrary
files on client machines (e.g., [Hernan 2000]) and execute arbitrary code on the client
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
29
(e.g., [Cohen and Hernan 2000; Computer Emergency Response Team (CERT)
1997a]). ActiveX controls are of particular concern, because they do not run in
any form of “sandbox” the way Java applets do [Bellovin et al. 2000]. ActiveX
controls can be digitally signed, and if properly used, can be used to authenticate
the author, if not the author’s intentions.
In [1997], Martin et al. describe some attacks written in Java. They advocate
the draconian solution of blocking all applets, on the grounds that it cannot be
determined which Java applets are dangerous. They suggest the following methods
of blocking Java applets at the firewall:
(1) Using a proxy to rewrite <applet> tags. This requires that the proxy be smart
enough to rewrite only the tags in HTML files and not if they appear in other
file types, such as image files. This requires that the proxy parse the HTML
documents in the same manner as the browser.
(2) Java class files always begin with four byte hex signature CAFE BABE. A
firewall could block all files that begin with this sequence. A possibility of false
positives exists with this scheme, but Martin et al. believe that this problem is
less likely to occur than the <applet> tag appearing in non-HTML files.
(3) Block all files whose names end in .class. This solution is weak because Java
classes can come in files with other extensions, for example, packing class files
in a .zip file is common.
Their suggestion is to implement all three of these, and they write a proxy which
does everything except look inside of .zip files.
13.2
Servers on the DMZ
Because the networks inside of a firewall are often not secure, servers which must
be accessible from the Internet (e.g., web and mail servers) are often placed on a
screened network, called the DMZ (for demilitarized zone; for a picture of one way
a DMZ may be constructed, see Figure 1, part C). Machines on the DMZ are not
allowed to make connections to machines on the inside of the firewall, but machines
on the inside are allowed to make connections to the DMZ machines. The reason for
this architecture is that if a server on the DMZ is compromised, the attacker cannot
directly attack the other machines inside. Because a server must be accessible to
be of use, current firewalls other than signature-based ones (Section 8.3) can do
little against attacks through the services offered. Examples of attacks on servers
include worms such as those described in [Danyliw and Householder 2001; Danyliw
et al. 2001].
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
30
·
13.3
Insider Attacks
K. Ingham and S. Forrest
In spite of the fact that early firewalls such as the DEC SEAL were initially set up
to prevent information leaks, they cannot protect against insiders intent on getting
information out of an organization. Consider a hostile employee with access to a
CD burner. The resulting CD will not be traveling through the firewall, so the
firewall cannot prevent this data loss. In [1995], Muffett also points out that inside
a firewall, security tends to decrease over time unless the internal machines are
continually updated. Therefore, a hostile insider can generally penetrate other
internal machines, and since these attacks do not go through the firewall, it cannot
stop them. To reduce this threat, some organizations have set up internal firewalls.
14.
FUTURE CHALLENGES FOR FIREWALLS
All of the topics discussed in the prior section pose serious challenges for firewalls.
In addition, two emerging technologies will further complicate the job of a firewall,
Virtual Private Networks (VPNs) and peer-to-peer networking.
14.1
VPNs
Because firewalls are deployed at the network perimeter, if the network perimeter is
expanded the firewall must somehow protect this expanded territory. VPNs provide
an example of how this can happen. A laptop being used by a traveling employee
in an Internet cafe or a home machine which is connected to an ISP via a DSL
line or cable modem must be inside the firewall. However, if the laptop or home
machine’s security is breached, the entire internal network becomes available to the
attackers.
Remote access problems are first mentioned in [Avolio and Ranum 1994]. Due to
the fact that VPNs had not yet been invented, it is easy to understand why Avolio
and Ranum failed to discuss the problem of a remote perimeter which includes
hosts always-connected to the Internet (via DSL or cable modems) and which are
also allowed inside through a VPN tunnel.
14.2
Peer-to-peer Networking
The music sharing system Napster is the most famous example of peer-to-peer
networking. However, several other peer-to-peer systems exist as well, including
Gnutella (e.g., [Wego Systems, Inc 2001]) and AIMster (file sharing over AOL
Instant Messenger). When not used for music sharing, peer-to-peer file sharing
is used to support collaboration between distant colleagues. However, as Bellovin
points out in [2000], these systems raise serious security concerns. These include the
possibility of using Gnutella for attacks, buggy servents (server+client programs),
and the problems of web and email-based content in yet another form. Current
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
31
firewalls are unable to provide any protection against these types of attacks beyond
simply blocking the peer-to-peer networking.
15.
CONCLUSION
The need for firewalls has led to their ubiquity. Nearly every organization connected to the Internet has installed some sort of firewall. The result of this is that
most organizations have some level of protection against threats from the outside.
Attackers still probe for vulnerabilities that are likely to only apply to machines
inside of the firewall. They also target servers, especially web servers. However,
these attackers are also now targeting home users (especially those with full-time
Internet connections) who are less likely to be well protected.
Because machines inside a firewall are often vulnerable to both attackers who
breach the firewall as well as hostile insiders, we will likely see increased use of the
distributed firewall architecture. The beginnings of a simple form of distributed
firewalls are already here, with personal firewalls being installed on individual machines. However, many organizations will require that these individual firewalls
respond to configuration directives from a central policy server. This architecture
will simply serve as the next level in a sort of arms race, as the central server and
the protocol(s) it uses become special targets for attackers.
Firewalls and the restrictions they commonly impose have affected how application-level protocols have evolved. Because traffic initiated by an internal machine
is often not as tightly controlled, newer protocols typically begin with the client
contacting the server; not the reverse as active FTP did. The restrictions imposed
by firewalls have also affected the attacks that are developed. The rise of emailbased attacks is one example of this change.
An even more interesting development is the expansion of HTTP and port 80
for new services. File sharing and remote procedure calls can now be accomplished
using HTTP. This overloading of HTTP results in new security concerns, and as
a result, more organizations are beginning to use a (possibly transparent) web
proxy so they can control the remote services used by the protected machines. The
future is likely to see more of this co-evolution between protocol developers and
firewall designers until the protocol designers consider security when the protocol
is first developed. Even then, firewalls will still be needed to cope with bugs in the
implementations of these protocols.
REFERENCES
Abie, H. 2000. An overview of firewall technologies. Telektronikk 96, 3, 47–52.
http://www.nr.no/publications/FirewallTechnologies.pdf Accessed 2002 Feb 20.
amavis.org. 2002. AMaViS—a mail virus scanner. http://www.amavis.org/ Accessed 2002 Feb
20.
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
32
·
K. Ingham and S. Forrest
Avolio, F. 1999. Firewalls and Internet security, the second hundred (Internet) years. The
Internet Protocol Journal 2, 2 (June), 24–32.
http://www.cisco.com/warp/public/759/ipj_2-2/ipj_2-2_fis1.html Accessed 2002 Feb 20.
Avolio, F. M. and Ranum, M. J. 1994. A network perimeter with secure external access. In
Internet Society Symposium on Network and Distributed Systems Security, 3-4 Feb. 1994,
San Diego, CA, USA. Internet Society, Reston, VA, USA, 109–119.
http://www.ja.net/CERT/Avolio_and_Ranum/isoc94.ps Accessed 2002 Feb 20.
Axelsson, S. 1998. Research in intrusion-detection systems: A survey. Tech. Rep. 98–17, Dept.
of Computer Eng. Chalmers Univ. of Tech, SE-412 96 Göteborg, Sweden. December.
http://www.ce.chalmers.se/staff/sax/survey.ps Accessed 2002 Feb 20.
Bailey, M. L., Gopal, B., Pagels, M. A., Peterson, L. L., and Sarkar, P. 1994.
PATHFINDER: A pattern-based packet classifier. In 1st Symposium on Operating Systems
Design and Implementation, 14-17 November 1994, Monterey, CA, USA. USENIX
Association, Berkeley, CA, 115–123.
Balasubramanian, S. 2000. An architecture for protection of network hosts from denial of
service attacks. M.S. thesis, University of Florida.
http://etd.fcla.edu/etd/uf/2000/ana6124/Master.pdf Accessed 2002 Feb 20.
Bartal, Y., Mayer, A. J., Nissim, K., and Wool, A. 1999. Firmato: A novel firewall
management toolkit. In 1999 IEEE Symposium on Security and Privacy, 9-12 May 1999,
Oakland, CA, USA. IEEE, Los Alamitos, CA, USA, 17–31.
http://www.wisdom.weizmann.ac.il/~kobbi/papers/firmato.ps Accessed 2002 Feb 20.
Bellovin, S. 1994. Firewall-friendly FTP. RFC 1579.
ftp://ftp.isi.edu/in-notes/rfc1579.txt Accessed 2002 Feb 20.
Bellovin, S., Cohen, C., Havrilla, J., Herman, S., King, B., Lanza, J., Pesante, L.,
Pethia, R., McAllister, S., Henault, G., Goodden, R., Peterson, A. P., Finnegan, S.,
Katano, K., Smith, R., and Lowenthal, R. 2000. Results of the security in ActiveX
workshop Pittsburgh, Pennsylvania USA August 22-23, 2000. Tech. rep., CERT Coordination
Center, Software Engineering Institute, Carnegie Mellon University, Pittsburg, PA 15213,
USA. December. http://www.cert.org/reports/activeX_report.pdf Accessed 2002 Feb 20.
Bellovin, S. M. 1992. There be dragons. In UNIX Security Symposium III Proceedings, 14-16
Sept 1992, Baltimore, MD, USA. USENIX Association, Berkeley, CA, 1–16.
http://www.research.att.com/~smb/papers/dragon.pdf Accessed 2002 Feb 20.
Bellovin, S. M. 1999. Distributed firewalls. ;login: 24, Security (November).
http://www.usenix.org/publications/login/1999-11/features/firewalls.htm%l Accessed
2002 Feb 20.
Bellovin, S. M. 2000. Security aspects of napster and gnutella. Invited talk at the USENIX
2001 Annual Technical Conference, June 25-30, 2001.
http://www.research.att.com/~smb/talks/NapsterGnutella/index.htm Accessed 2002 Feb
20.
Bonachea, D. and McPeak, S. 2001. SafeTP: Transparently securing FTP network services.
Tech. Rep. UCB Tech Report CSD-01-1152, Computer Science Division, University of
California, Berkeley, 387 Soda Hall #1776, Berkeley, CA 94720-1776.
http://www.cs.berkeley.edu/~bonachea/safetp/CSD-01-1152.pdf Accessed 2002 Feb 20.
Braden, R., Clark, D., Crocker, S., and Huitema, C. 1994. Report of IAB workshop on
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
33
security in the Internet architecture February 8-10, 1994. RFC 1636.
ftp://ftp.isi.edu/in-notes/rfc1636.txt Accessed 2002 Feb 20.
Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F.,
Yavatkar, R., and Smith, A. 2001. COPS usage for policy provisioning (COPS-PR). RFC
3084. ftp://ftp.isi.edu/in-notes/rfc3084.txt Accessed 2002 Feb 20.
Chapman, D. B. 1992. Network (in)security through IP packet filtering. In UNIX Security
Symposium III Proceedings, 14-16 Sept 1992, Baltimore, MD, USA. USENIX Association,
Berkeley, CA, 63–76. http://www.greatcircle.com/pkt_filtering.html Accessed 2002 Feb
20.
Chatel, M. 1996. Classical versus transparent IP proxies. RFC 1919.
ftp://ftp.isi.edu/in-notes/rfc1919.txt Accessed 2002 Feb 20.
Cheswick, B. 1990. The design of a secure Internet gateway. In USENIX 1990 Summer
Conference. USENIX Association, Berkeley, CA.
http://www.cheswick.com/ches/papers/gateway.ps Accessed 2002 Feb 20.
Cheswick, B. 1992. An evening with Berferd in which a cracker is lured, endured, and studied.
In Winter 1992 USENIX Conference, 20-24 Jan 1992, San Francisco, CA, USA. USENIX
Association, Berkeley, CA, 163–173. http://www.cheswick.com/ches/papers/berferd.ps
Accessed 2002 Feb 20.
Cheswick, B. 2001. Personal communication.
Cheswick, W. R. and Bellovin, S. M. 1994. Firewalls and Internet Security: Repelling the
Wily Hacker. Addison-Wesley, One Jacob Way, Reading, MA, 01867.
Cisco Systems, Inc. 2000. Cisco - Cisco’s PIX firewall and stateful firewall security.
http://www.cisco.com/warp/public/cc/pd/fw/sqfw500/tech/nat_wp.htm Accessed 2002 Feb
20.
Cisco Systems, Inc. 2001. Cisco - building a perimeter security solution.
http://www.cisco.com/warp/public/cc/pd/iosw/ioft/iofwft/tech/firew_wp.h%tm
Accessed 2002 Feb 20.
Cohen, C., Danyliw, R., Finlay, I., Shaffer, J., Hernan, S., Houle, K., King, B. B., and
van Ittersum, S. 2001. CERT advisory CA-2001-03 VBS/OnTheFly (Anna Kournikova)
malicious code. http://www.cert.org/advisories/CA-2001-03.html Accessed 2002 Feb 20.
Cohen, C. and Hernan, S. 2000. CERT advisory CA-2000-12 HHCtrl ActiveX control allows
local files to be executed. http://www.cert.org/advisories/CA-2000-12.html Accessed 2002
Feb 20.
Computer Emergency Response Team (CERT). 1997a. CERT advisory CA-1996-07
weaknesses in Java bytecode verifier. http://www.cert.org/advisories/CA-1996-07.html
Accessed 2002 Feb 20.
Computer Emergency Response Team (CERT). 1997b. CERT advisory CA-1996-26
denial-of-service attack via ping. http://www.cert.org/advisories/CA-1996-26.html
Accessed 2002 Feb 20.
Computer Emergency Response Team (CERT). 1998. CERT advisory CA-1997-28 IP
denial-of-service attacks. http://www.cert.org/advisories/CA-1997-28.html Accessed 2002
Feb 20.
Computer Emergency Response Team (CERT). 1999. CERT advisory CA-1999-04 Melissa
macro virus. http://www.cert.org/advisories/CA-1999-04.html Accessed 2002 Feb 20.
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
34
·
K. Ingham and S. Forrest
Computer Emergency Response Team (CERT). 2000a. CERT advisory CA-2000-04 love
letter worm. http://www.cert.org/advisories/CA-2000-04.html Accessed 2002 Feb 20.
Computer Emergency Response Team (CERT). 2000b. CERT incident note IN-2000-02 :
Exploitation of unprotected windows networking shares.
http://www.cert.org/incident_notes/IN-2000-02.html Accessed 2002 Feb 20.
Computer Emergency Response Team (CERT). 2000c. CERT incident note IN-2000-03 : 911
worm. http://www.cert.org/incident_notes/IN-2000-03.html Accessed 2002 Feb 20.
Computer Emergency Response Team (CERT). 2001a. CERT incident note IN-2001-01 :
Widespread compromises via “ramen” toolkit.
http://www.cert.org/incident_notes/IN-2001-01.html Accessed 2002 Feb 20.
Computer Emergency Response Team (CERT). 2001b. Vulnerability note VU#131569:
Microsoft Outlook view control allows execution of arbitrary code and manipulation of user
data. http://www.kb.cert.org/vuls/id/131569 Accessed 2002 Feb 20.
Computer Emergency Response Team (CERT). 2001c. Vulnerability note VU#149424
Outlook Web Access (OWA) executes scripts contained in email attachment opened via
Microsoft Internet Explorer (IE). http://www.kb.cert.org/vuls/id/149424 Accessed 2002
Feb 20.
Computer Emergency Response Team (CERT). 2001d. Vulnerability note VU#5648: Buffer
overflows in various email clients. http://www.kb.cert.org/vuls/id/5648 Accessed 2002 Feb
20.
Computer Security Institute. 2001. CSI firewall product search center.
http://www.spirit.com/CSI/firewalls.html Accessed 2002 Feb 20.
Corbridge, B., Henig, R., and Slater, C. 1991. Packet filtering in an IP router. In
Proceedings of the USENIX Fifth System Administration Conference (LISA V). USENIX
Association, Berkeley, CA, 227–232.
http://www.netsys.com/library/papers/packet_filtering_in_an_ip_router.p%df
Accessed 2002 Feb 20.
daemon9 and Alhambra. 1996. Project Loki: ICMP tunneling. Phrack 7, 49 (August).
http://www.phrack.org/show.php?p=49&a=6 Accessed 2002 Feb 20.
Damianou, N., Dulay, N., Lapu, E., and Sloman, M. 2001. The ponder policy specification
language. In Policies for Distributed Systems and Networks. International Workshop,
POLICY 2001. Proceedings, 29-31 Jan. 2001, Bristol, UK. Springer-Verlag, Berlin, Germany.
http://www.doc.ic.ac.uk/~mss/Papers/Ponder-Policy01V5.pdf Accessed 2002 Feb 20.
Danyliw, R., Dougherty, C., Householder, A., and Ruefle, R. 2001. CERT advisory
CA-2001-26 Nimda worm. http://www.cert.org/advisories/CA-2001-26.html Accessed
2002 Feb 20.
Danyliw, R. and Householder, A. 2001. CERT advisory CA-2001-19 “code red” worm
exploiting buffer overflow in IIS indexing service DLL.
http://www.cert.org/advisories/CA-2001-19.html Accessed 2002 Feb 20.
Denning, P. J. March-April 1989. The Internet worm. American Scientist 77, 2, 126–128.
Digital Equipment Corporation. 1992. Securing external access link (SEAL) introductory
guide. This document was part of the documentation provided by DEC to purchasers of
SEAL.
Djahandari, K. and Sterne, D. 1997. An MBone proxy for an application gateway firewall. In
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
35
Proceedings of the 1997 Conference on Security and Privacy (S&P-97). IEEE Press, Los
Alamitos, 72–81.
Doraswamy, N. and Harkins, D. 1999. IPSec: the new security standard for the Internet,
intranets, and virtual private networks. Prentice-Hall, Upper Saddle River, NJ.
Dotti, P. and Rees, O. 1999a. Protecting the hosted application server. In Proceedings of the
IEEE 8th International Workshops on Enabling Technologies: Infrastructure for
Collaborative Enterprises. IEEE Computer Society, Los Alamitos, CA, USA.
Dotti, P. and Rees, O. 1999b. Protecting the hosted application server. Tech. Rep.
HPL-1999-54 990413, Hewlett-Packard Labs., Bristol, UK.
http://www.hpl.hp.com/techreports/1999/HPL-1999-54.pdf Accessed 2002 Feb 20.
Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and Sastry, A. 2000. The COPS
(Common Open Policy Service) protocol. RFC 2748.
ftp://ftp.isi.edu/in-notes/rfc2748.txt Accessed 2002 Feb 20.
Egevang, K. and Francis, P. 1994. The IP network address translator (NAT). RFC 1631.
ftp://ftp.isi.edu/in-notes/rfc1631.txt Accessed 2002 Feb 20.
Eichin, M. W. and Rochlis, J. A. 1989. With microscope and tweezers: An analysis of the
Internet virus of November 1988. In 1989 IEEE Computer Society Symposium on Security
and Privacy. IEEE Computer Society, Los Alamitos, CA, USA, 326–343.
Farrow, R. 1998. CSI 1997 firewalls matrix [an analysis of current firewall technologies].
http://www.spirit.com/CSI/Papers/farrowpa.htm Accessed 2002 Feb 20.
Finlayson, R. 1999. IP multicast and firewalls. RFC 2588.
ftp://ftp.isi.edu/in-notes/rfc2588.txt Accessed 2002 Feb 20.
Fung, K. P. and Chang, R. K. C. 2000. A transport-level proxy for secure multimedia
streams. IEEE Internet Computing 4, 6 (November–December), 57–67.
Gangadharan, M. and Hwang, K. 2001. Intranet security with micro-firewalls and mobile
agents for proactive intrusion response. In Proceedings of the International Conference on
Computer Networks and Mobile Computing, 2001. IEEE Computer Society, Los Alamitos,
CA, USA, 325–332.
Ganger, G. R. and Nagle, D. F. 2000. Enabling dynamic security management of networked
systems via device-embedded security. Tech. Rep. CMU-CS-00-174, School of Computer
Science, Carnegie Mellon University, Pittsburgh, PA 15213-3890. December.
http://reports-archive.adm.cs.cmu.edu/anon/2000/CMU-CS-00-174.pdf Accessed 2002 Feb
20.
Gleitz, P. M. and Bellovin, S. M. 2001. Transient addressing for related processes: Improved
firewalling by using IPV6 and multiple addresses per host. In Proceedings of the 10th
USENIX Security Symposium. USENIX Association, Berkleley, CA, USA, 99–113.
http://www.usenix.org/publications/library/proceedings/sec01/full_paper%s/gleitz/
gleitz.pdf Accessed 2002 Feb 20.
Gupta, P. and McKeown, N. 2001. Algorithms for packet classification. IEEE Network 15, 2
(March-April), 24–32.
Guttman, J. D. 1997. Filtering postures: local enforcement for global policies. In 1997 IEEE
Symposium on Security and Privacy, 4-7 May 1997, Oakland, CA, USA. IEEE Computer
Society Press, Los Alamitos, CA, USA, 120–129.
http://www.mitre.org/support/papers/filtering_postures/filtering_postures.pdf
Accessed 2002 Feb 20.
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
36
·
K. Ingham and S. Forrest
Hain, T. 2000. Architectural implications of NAT. RFC 2993.
ftp://ftp.isi.edu/in-notes/rfc2993.txt Accessed 2002 Feb 20.
Hambridge, S. and Sedayao, J. C. 1993. Horses and barn doors: Evolution of corporate
guidelines for Internet usage. In Proceedings of the USENIX Seventh System Administration
Conference (LISA ’93). USENIX Association, Berkeley, CA. http:
//www.usenix.org/publications/library/proceedings/lisa93/full_pape%rs/hambridge.ps
Accessed 2002 Feb 20.
Handley, M., Paxson, V., and Kreibich, C. 2001. Network intrusion detection: Evasion,
traffic normalization, and end-to-end protocol semantics. In Conference Proceedings: 10th
USENIX Security Symposium. USENIX Association, Berkleley, CA, USA, 115–131.
http://www.aciri.org/vern/papers/norm-usenix-sec-01.pdf Accessed 2002 Feb 20.
Hazelhurst, S., Attar, A., and Sinnappan, R. 2000. Algorithms for improving the
dependability of firewall and filter rule lists. In Proceedings of the International Conference
on Dependable Systems and Networks (DSN 2000). IEEE Computer Society, Los Alamitos,
CA, USA. IEEE.
Hernan, S. 2000. CERT advisory CA-2000-15 Netscape allows Java applets to read protected
resources. http://www.cert.org/advisories/CA-2000-15.html Accessed 2002 Feb 20.
Honeynet Project. 2001. Know Your Enemy: Revealing the Security Tools, Tactics, and
Motives of the Blackhat Community. Addison-Wesley, Boston, MA.
Hwang, K. and Gangadharan, M. 2001. Micro-firewalls for dynamic network security with
distributed intrusion detection. In IEEE International Symposium on Network Computing
and Applications, NCA 2001. IEEE Computer Society, Los Alamitos, CA, USA, 68–79.
Internet Security Systems, Inc. 2002. ISS - security products - security assessment Internet scanner. http://www.iss.net/securing_e-business/security_products/security_
asses%sment/internet_scanner/ Accessed 2002 Feb 20.
Ioannidis, J. and Bellovin, S. M. 2002. Pushback: Router-based defense against DDoS
attacks. In Proceedings of Network and Distributed System Security Symposium, Catamaran
Resort Hotel San Diego, California 6-8 February 2002. The Internet Society, 1775 Wiehle
Ave., Suite 102, Reston, VA 20190.
http://www.research.att.com/~smb/papers/pushback-impl.pdf Accessed 2002 Feb 20.
Ioannidis, S., Keromytis, A. D., Bellovin, S. M., and Smith, J. M. 2000. Implementing a
distributed firewall. In ACM Conference on Computer and Communications Security.
Association for Computing Machinery, One Astor Plaza, 1515 Broadway, New York, New
York 10036-5701, USA, 190–199. http://www.cis.upenn.edu/~angelos/Papers/df.ps.gz
Accessed 2002 Feb 20.
Julkunen, H. and Chow, C. 1997. Enhance network security with dynamic packet filter. Tech.
Rep. EAS-CS-97-2, University of Colorado at Colorado Springs Department of Computer
Science, 1420 Austin Bluffs Parkway, P.O. Box 7150, Colorado Springs, CO 80933-7150. April.
http://www.cs.auc.dk/~fleury/papers/firewall/julkunen.pdf Accessed 2002 Feb 20.
Julkunen, H. and Chow, C. 1998. Enhance network security with dynamic packet filter. In 7th
International Conference on Computer Communications and Networks, 12-15 Oct. 1998,
Lafayette, LA, USA, K. Makki, I. Chalamrac, and N. Pissinou, Eds. IEEE, Piscataway, NJ,
USA, 268–275.
Kahn, A., Al-Darwish, N., Guizani, M., Menten, M., and Youssef, H. 1997. Design and
implementation of a software bridge with packet filtering and statistics collection functions.
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
37
International Journal of Network Management 7, 5 (September-October), 251–263.
http://www1.acm.org/pubs/articles/journals/ijnm/1997-7-5/p251-khan/p251%-khan.pdf
Accessed 2002 Feb 20.
Keromytis, A. D. and Wright, J. L. 2000. Transparent network security policy enforcement.
In FREENIX Track. 2000 USENIX Annual Technical Conference, 18-23 June 2000, San
Diego, CA, USA. USENIX Association, Berkeley, CA, USA, 215–225.
http://www.cis.upenn.edu/~angelos/Papers/bridgepaper.ps.gz Accessed 2002 Feb 20.
Koblas, D. and Koblas, M. R. 1992. SOCKS. In UNIX Security Symposium III Proceedings,
14-16 Sept. 1992, Baltimore, MD, USA. USENIX Association, Berkeley, CA, 77–83.
Larsen, J. 2001. HogWash. http://hogwash.sourceforge.net/ Accessed 2002 Feb 20.
Leech, M. 1996. Username/password authentication for SOCKS V5. RFC 1929.
ftp://ftp.isi.edu/in-notes/rfc1929.txt Accessed 2002 Feb 20.
Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and Jones, L. 1996. SOCKS protocol
version 5. RFC 1928. ftp://ftp.isi.edu/in-notes/rfc1928.txt Accessed 2002 Feb 20.
Lightoler, T. 1764. The gentleman and farmer’s architect. A new work. Containing a great
variety of ... designs. Being correct plans and elevations of parsonage and farm houses,
lodges for parks, pinery, peach, hot and green houses, with the fire-wall, tan-pit, &c
particularly described ... R. Sayer, London, UK.
Limoncelli, T. 1999. Tricks you can do if your firewall is a bridge. In 1st Conference on
Network Administration, 7-10 April 1999, Santa Clara, CA, USA. USENIX Association,
Berkeley, CA, USA, 47–55. http://www.bell-labs.com/user/tal/papers/ Accessed 2002 Feb
20.
Liu, J. and Ma, Y. 1999. Packet filtering in bridge. In 1999 Internet Workshop (WS’99), 18-20
Feb. 1999, Osaka, Japan. IEEE, Piscataway, NJ, USA, 94–98.
Lodin, S. W. and Schuba, C. L. 1998. Firewalls fend off invasions from the net. IEEE
Spectrum 35, 2 (February), 26–34.
Lucent Technologies. 2001. Lucent - VPN firewall family. http://www.lucent.com/products/
solution/0,,CTID+2012-STID+10080-SOID+12%01-LOCL+1,00.html Accessed 2002 Feb 20.
Lyles, J. and Schuba, C. 1996a. A reference model for firewall technology and its implications
for connection signaling. Tech. Rep. CSD-TR-96-073, Department of Computer Sciences,
Purdue University. December.
Lyles, J. B. and Schuba, C. L. 1996b. A reference model for firewall technology and its
implications for connection signaling. Tech. Rep. CSD-TR-94-061, Reprinted as Department
of Computer Sciences, Purdue University, Purdue University, 1398 Computer Science
Building, West Lafayette, IN 47907-1398. Proceedings Open Signaling Workshop, Columbia
University, New York, NY, October 1996.
https://www.cerias.purdue.edu/techreports-ssl/public/csd_94-061.pdf Accessed 2002
Feb 20.
Lyu, M. R. and Lau, L. K. 2000. Firewall security: Policies, testing and performance
evaluation. In Proceedings of The Twenty-Fourth Annual International Computer Software
and Applications Conference. IEEE Computer Society, Los Alamitos, CA, USA.
Malan, G. R., Watson, D., Jahanian, F., and Howell, P. 2000. Transport and application
protocol scrubbing. In IEEE INFOCOM 2000. Conference on Computer Communications.
Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies,
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
38
·
K. Ingham and S. Forrest
26-30 March 2000, Tel Aviv, Israel. IEEE Computer Society; IEEE Communications Society,
Piscataway, NJ, USA, 1381–1390.
Maltz, D. and Bhagwat, P. 1998. TCP splicing for application layer proxy performance.
Tech. Rep. RC 21139, IBM. March. http://domino.watson.ibm.com/library/cyberdig.nsf/
a3807c5b4823c53f85256%561006324be/88d1e552b09ffa65852565e6006616f1?OpenDocument
Accessed 2002 Feb 20.
Mariet, P. 1997. AltaVista firewall. In DECUS Switzerland conference. Decus Switzerland,
Sonnenbergstrasse 11 CH-8610 Uster.
http://elias.decus.ch/presentations/ge_19970415_av/index.htm Accessed 2002 Feb 20.
Markham, T. and Payne, C. 2001. Security at the network edge: a distributed firewall
architecture. In DARPA Information Survivability Conference & Exposition II, 2001.
DISCEX ’01. Proceedings. Vol. 1. IEEE Computer Society, Los Alamitos, CA, USA, 279–286.
Markus, H. S. 2001. Firewall guide software reviews.
http://www.firewallguide.com/software.htm Accessed 2002 Feb 20.
Martin, D.M., J., Rajagopalan, S., and Rubin, A. 1997. Blocking Java applets at the
firewall. In SNDSS ’97: Internet Society 1997 Symposium on Network and Distributed
System Security, 10-11 Feb. 1997, San Diego, CA, USA. IEEE Computer Society Press, Los
Alamitos, CA, USA.
Mayer, A., Wool, A., and Ziskind, E. 2000. Fang: A firewall analysis engine. In Proceedings
of the 2000 IEEE Symposium on Security and Privacy (S&P 2000). IEEE Computer Society,
Los Alamitos, CA, USA.
McKay, N. 1998. China: The great firewall. Web publication:
http://www.wired.com/news/politics/0,1283,16545,00.html Accessed 2002 Feb 20.
McMahon, P. 1996. GSS-API authentication method for SOCKS version 5. RFC 1961.
ftp://ftp.isi.edu/in-notes/rfc1961.txt Accessed 2002 Feb 20.
Mogul, J. 1991. Using screend to implement IP/TCP security policies. Tech. Rep. NSL
Technical Note TN-2, Digital Network Systems Laboratory, Palo Alto, CA. July.
http://research.compaq.com/nsl/publications/postscript/nsltn2.pdf Accessed 2002 Feb
20.
Mogul, J. C. 1989. Simple and flexible datagram access controls for Unix-based gateways. In
Proceedings of the USENIX Summer 1989 Conference. USENIX Association, Berkeley, CA,
203–222. ftp://ftp.digital.com/pub/Digital/WRL/research-reports/WRL-TR-89.4.ps.g%z
Accessed 2002 Feb 20.
Molitor, A. 1995. An architecture for advanced packet filtering. In Proceedings of the Fifth
USENIX UNIX Security Symposium. USENIX Association, Berkeley, CA, USA, 117–126.
http://www.usenix.org/publications/library/proceedings/security95/full_%papers/
molitor.ps Accessed 2002 Feb 20.
Moore, B., Ellesson, E., Strassner, J., and Westerinen, A. 2001. Policy core information
model—version 1 specification. RFC 3060. ftp://ftp.isi.edu/in-notes/rfc3060.txt
Accessed 2002 Feb 20.
Muffett, A. 1994. Proper care and feeding of firewalls. In Proceedings of the UKERNA
Computer Security Workshop. United Kingdom Education and Research Networking
Association, Atlas Centre, Chilton, Didcot, Oxfordshire, OX11 0QS UK.
ftp://coast.cs.purdue.edu/pub/doc/firewalls/Muffett_Alec_feeding_firewa%lls.ps.Z
Accessed 2002 Feb 20.
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
39
Muffett, A. 1995. Wan-hacking with AutoHack - auditing security behind the firewall. In The
Fifth USENIX UNIX Security Symposium. USENIX Association, Berkeley, CA, 21–34.
Network Associates Technology, Inc. 2001a. E-mail protection.
http://www.mcafeeb2b.com/products/email-protection.asp Accessed 2002 Feb 20.
Network Associates Technology, Inc. 2001b. Gauntlet firewall administrator’s guide
version 6.0. http://download.nai.com/products/media/pgp/support/gnt/admin_GNT60.pdf
Accessed 2002 Feb 20.
Network Associates Technology, Inc. 2001c. Gauntlet firewall for UNIX advanced
administrator’s guide version 6.0.
http://download.nai.com/products/media/pgp/support/gnt/adv_admin_60.pdf Accessed
2002 Feb 20.
Network Associates Technology, Inc. 2001d. Gauntlet firewall services guide version 6.0.
http://download.nai.com/products/media/pgp/support/gnt/services_60.pdf Accessed
2002 Feb 20.
Northcutt, S. and Novak, J. 2001. Network Intrusion Detection: An Analyst’s Handbook,
Second Edition. New Riders Publishing, 201 West 103rd St, Indianapolis, IN, 46290, USA.
Oria, L. 1999. Approaches to multicast over firewalls: an analysis. Tech. Rep.
HPL-IRI-1999-004 990827, Hewlett-Packard Laboratories. August.
http://www.hpl.hp.com/techreports/1999/HPL-IRI-1999-004.html Accessed 2002 Feb 20.
Postel, J. and Reynolds, J. 1985. File transfer protocol (FTP). RFC 959.
ftp://ftp.isi.edu/in-notes/rfc959.txt Accessed 2002 Feb 20.
Ranum, M. J. 1992. A network firewall. In Proceedings of the First World Conference on
System Administration and Security. SANS Institute, 5401 Westbard Ave. Suite 1501,
Bethesda, MD 20816.
Ranum, M. J. 1995. On the topic of firewall testing.
http://web.ranum.com/pubs/fwtest/index.htm Accessed 2002 Feb 20.
Ranum, M. J. 2001. personal communication.
Ranum, M. J. and Avolio, F. M. 1994. A toolkit and methods for Internet firewalls. In
Conference Proceedings: USENIX Summer 1994 Technical Conference. USENIX Association,
Berkeley, CA, 37–44.
Reed, D. 19?? Filter language compiler. Undated web page.
http://coombs.anu.edu.au/ipfilter/flc.html Accessed 2002 Feb 20.
Reed, D. 2002a. IP filter. Undated web page.
http://coombs.anu.edu.au/~avalon/ip-filter.html Accessed 2002 May 15.
Reed, D. 2002b. IP filter. HISTORY file from the IP Filter distribution.
http://coombs.anu.edu.au/~avalon/ip-fil3.4.27.tar.gz Accessed 2002 May 15.
Reed, D. 2002c. What’s new for IP filter. Undated web page.
http://coombs.anu.edu.au/~avalon/ipfil-new.html Accessed 2002 May 15.
Rekhter, Y., Moskowitz, B., Karrenberg, D., deGroot, G. J., and Lear, E. 1996.
Address allocation for private internets. RFC 1918.
ftp://ftp.isi.edu/in-notes/rfc1918.txt Accessed 2002 Feb 20.
Rodriguez, P., Sibal, S., and Spatscheck, O. 2001. TPOT: translucent proxying of TCP.
Computer Communications 24, 2, 249–255.
http://www.terena.nl/conf/wcw/Proceedings/S7/S7-3.pdf Accessed 2002 Feb 20.
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
40
·
K. Ingham and S. Forrest
Roesch, M. 1999. Snort - lightweight intrusion detection for networks. In LISA’99: 13th
System Administration Conference and Exhibition, 7-12 Nov. 1999, Seattle, WA, USA.
USENIX Association, Berkleley, CA, USA, 229–238.
http://www.usenix.org/events/lisa99/full_papers/roesch/roesch.pdf Accessed 2002 Feb
20.
Schimmel, J. 1997. A historical look at firewall technologies. ;login: 22, 7.
http://www.usenix.org/sage/best.of/breakins/firewall.html Accessed 2002 Feb 20.
Schneier, B. 2000. Secrets and Lies: Digital Security in a Networked World. John Wiley &
Sons, New York, NY, 188–193.
Schuba, C., Lyles, B., and Spafford, E. 1997. A reference model for firewall technology. In
13th Annual Computer Security Applications Conference (ACSAC), 8-12 Dec. 1997, San
Diego, CA, USA. IEEE Computer Society, Los Alamitos, CA, USA, 133–145.
Schuba, C. L. 1997. On the modeling, design, and implementation of firewall technology. Ph.D.
thesis, Purdue University.
ftp://ftp.cerias.purdue.edu/pub/papers/christoph_schuba/schuba_phddis.p%df
Accessed 2002 Feb 20.
Schuba, C. L., Krsul, I. V., Kuhn, M. G., Spafford, E. H., Sundaram, A., and Zamboni,
D. 1997. Analysis of a denial of service attack on TCP. In Proceedings of the 1997 IEEE
Symposium on Security and Privacy. IEEE Computer Society, IEEE Computer Society Press,
Los Alamitos, CA, USA, 208–223.
https://www.cerias.purdue.edu/techreports-ssl/public/97-06.ps Accessed 2002 Feb 20.
Securityfocus.com. 1997. Multiple vendor “out of band” data (winnuke.c) DoS vulnerability.
Vulnerability database. http://www.securityfocus.com/bid/2010 Accessed 2002 Feb 20.
Smith, J. M., Doherty, S. G., Leahy, O. J., and Tynan, D. M. 1997. Protecting a private
network: The AltaVista firewall. Digital Technical Journal 9, 2 (November), 17–32.
http://www.research.compaq.com/wrl/DECarchives/DTJ/DTJQ00/index.html Accessed 2002
Feb 20.
Spafford, E. H. 1988. The Internet worm program: An analysis. Tech. Rep. Purdue Technical
Report CSD-TR-823, Department of Computer Science, Purdue University, West Lafayette,
IN 47907-2004. ftp://ftp.cs.purdue.edu/pub/reports/TR823.PS.Z Accessed 2002 Feb 20.
Spafford, E. H. 1991. The Internet worm incident. Tech. Rep. Purdue Technical Report
CSD-TR-933, Department of Computer Science, Purdue University, West Lafayette, IN
47907-2004.
Spatscheck, O., Hansen, J. S., Hartman, J. H., and Peterson, L. L. 2000. Optimizing TCP
forwarder performance. IEEE/ACM Transactions on Networking 8, 2, 146–157.
http://www.cs.arizona.edu/scout/Papers/TR98-01.ps Accessed 2002 Feb 20.
Srisuresh, P. and Egevang, K. 2001. Traditional IP network address translator (traditional
NAT). RFC 3022. ftp://ftp.isi.edu/in-notes/rfc3022.txt Accessed 2002 Feb 20.
Srisuresh, P. and Holdrege, M. 1999. IP network address translator (NAT) terminology and
considerations. RFC 2663. ftp://ftp.isi.edu/in-notes/rfc2663.txt Accessed 2002 Feb 20.
Stoll, C. 1989. The Cuckoo’s Egg. Doubleday, New York, NY.
Stoll, C. May, 1988. Stalking the wily hacker. Commun. ACM 31, 5, 484–497.
Stone, G. B., Lundy, B., and Xie, G. G. 2001. Network policy languages: A survey and a new
approach. IEEE Network 15, 1 (January-February), 10–21.
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
A History and Survey of Network Firewalls
·
41
Strother, E. 2000. Denial of service protection: the nozzle. In Annual Computer Security
Applications Conference, 11-15 Dec. 2000, New Orleans, LA, USA. IEEE Computer Society,
Los Alamitos, CA, USA, 32–41. http://www.acsac.org/2000/papers/41.pdf Accessed 2002
Feb 20.
Sun Microsystems, I. 2000. Sunscreen 3.1 reference manual.
http://www.sun.com/software/securenet/ds/ Accessed 2002 Feb 20.
Suri, S. and Varghese, G. 1999. Packet filtering in high speed networks. In Tenth Annual
ACM-SIAM Symposium on Discrete Algorithms (SODA’99). SIAM, 3600 University City
Science Center, Philadelphia, PA 19104-2688, 969–970.
http://siesta.cs.wustl.edu/~suri/psdir/soda_filter.ps Accessed 2002 Feb 20.
The RFC Editor. 2001. Request for comments (RFC) frequently asked questions.
http://www.rfc-editor.org/rfcfaq.html Accessed 2002 Feb 20.
Treese, G. W. and Wolman, A. 1993. X through the firewall and other application relays. In
Proceedings of the USENIX Summer Conference. USENIX Association, Berkeley, CA.
ftp://crl.dec.com/pub/DEC/CRL/tech-reports/93.10.ps.Z Accessed 2002 Feb 20.
van Rooij, G. 2001. Real stateful TCP packet filtering in IP-filter. Invited talk at the 10th
USENIX Security Symposium August 13-17, 2001 Washington DC. Talk slides available at:
http://www.usenix.org/events/sec01/invitedtalks/rooij.pdf.
Venema, W. 1995. Project SATAN: UNIX/Internet security. In COMPSEC International 95.
Twelfth World Conference on Computer Security, Audit and Control, 25-27 Oct. 1995,
London, UK. Elsevier, Oxford, UK.
Vigna, G. 1996. A topological characterization of TCP/IP security. Tech. Rep. TR-96.156,
Dipartimento di Elettronica e Informazione, Politecnico di Milano, Piazza Leonardo da Vinci,
32, 20133 Milano, Italy. December.
http://www2.elet.polimi.it/pub/data/Giovanni.Vigna/www_docs/pub/tr96156%.ps.gz
Accessed 2002 Feb 20.
Vigna, G. 1997. A formal model for firewall testing. Unpublished paper.
http://citeseer.nj.nec.com/279361.html Accessed 2002 Feb 20.
Watson, D., Smart, M., Malan, G., and Jahanian, F. 2001. Protocol scrubbing: network
security through transparent flow modification. In DARPA Information Survivability
Conference & Exposition II, 2001. DISCEX ’01. Proceedings. Vol. 2. IEEE Computer Society,
Los Alamitos, CA, USA, 108–118.
Weber, W. 1999. Firewall basics. In 4th International Conference on Telecommunications in
Modern Satellite, Cable and Broadcasting Services. TELSIKS’99. Proceedings of Papers,
13-15 Oct. 1999, Nis, Yugoslavia. Vol. 1. IEEE, Piscataway, NJ, USA, 300–305.
Wego Systems, Inc. 2001. Welcome to gnutella. http://gnutella.wego.com/ Accessed 2002
Feb 20.
Wool, A. 2001. Architecting the Lumeta firewall analyzer. In Conference Proceedings: 10th
USENIX Security Symposium. USENIX Association, Berkleley, CA, USA, 85–97.
http://www.usenix.org/events/sec01/full_papers/wool/wool.pdf Accessed 2002 Feb 20.
Yavwa, Y. 2000. The firewall technology. Student paper, available at:
http://www.cs.uct.ac.za/courses/CS400W/NIS/resources.html Accessed 2002 Feb 20.
Zwicky, E. D., Cooper, S., and Chapman, D. B. 2000. Building Internet Firewalls, 2nd
Edition. O’Reilly & Associates, 101 Morris St, Sebastopol, CA 95472 USA.
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX X
42
·
K. Ingham and S. Forrest
Received Month Year; revised Month Year; accepted Month Year
ACM Journal Name, Vol. V, No. N, Month 20YY.
APPENDIX Y
IP Access List Entry Sequence Numbering
Users can apply sequence numbers to permit or deny statements and also reorder, add, or remove such
statements from a named IP access list. This feature makes revising IP access lists much easier. Prior to
this feature, users could add access list entries to the end of an access list only; therefore needing to add
statements anywhere except the end required reconfiguring the access list entirely.
Feature History for the IP Access List Entry Additions Feature
Release
Modification
12.2(14)S
This feature was introduced.
12.2(15)T
This feature was integrated into Cisco IOS Release 12.2(15)T.
12.3(2T
This feature was integrated into Cisco IOS Release 12.3(2)T.
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image
support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on
Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at
the login dialog box and follow the instructions that appear.
Contents
•
Restrictions for IP Access List Entry Sequence Numbering, page 2
•
Information About IP Access Lists, page 2
•
How to Use Sequence Numbers in an IP Access List, page 5
•
Configuration Examples for IP Access List Entry Sequence Numbering, page 8
•
Additional References, page 10
•
Command Reference, page 11
Corporate Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Copyright © 2003 Cisco Systems, Inc. All rights reserved.
APPENDIX Y
IP Access List Entry Sequence Numbering
Restrictions for IP Access List Entry Sequence Numbering
Restrictions for IP Access List Entry Sequence Numbering
•
This feature does not support dynamic, reflexive, or firewall access lists.
•
This feature does not support old-style numbered access lists, which existed before named access
lists. Keep in mind that you can name an access list with a number, so numbers are allowed when
they are entered in the standard or extended named access list (NACL) configuration mode.
Information About IP Access Lists
Before you resequence or add entries to an IP access list, you should understand the following concepts:
•
Purpose of IP Access Lists, page 2
•
How an IP Access List Works, page 2
•
IP Access List Entry Sequence Numbering, page 4
Purpose of IP Access Lists
Access lists perform packet filtering to control which packets move through the network and where.
Such control can help limit network traffic and restrict the access of users and devices to the network.
Access lists have many uses, and therefore many commands accept a reference to an access list in their
command syntax. Access lists can be used to do the following:
•
Filter incoming packets on an interface.
•
Filter outgoing packets on an interface.
•
Restrict the contents of routing updates.
•
Limit debug output based on an address or protocol.
•
Control virtual terminal line access.
•
Identify or classify traffic for advanced features, such as congestion avoidance, congestion
management, and priority and custom queuing.
•
Trigger dial-on-demand routing (DDR) calls.
How an IP Access List Works
An access list is a sequential list consisting of at least one permit statement and possibly one or more
deny statements that apply to IP addresses and possibly upper-layer IP protocols. The access list has a
name by which it is referenced. Many software commands accept an access list as part of their syntax.
An access list can be configured and named, but it is not in effect until the access list is referenced by a
command that accepts an access list. Multiple commands can reference the same access list. An access
list can control traffic arriving at the router or leaving the router, but not traffic originating at the router.
IP Access List Process and Rules
•
The software tests the source or destination address or the protocol of each packet being filtered
against the conditions in the access list, one condition (permit or deny statement) at a time.
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
2
IP Access List Entry Sequence Numbering
APPENDIX Y
Information About IP Access Lists
•
If a packet does not match an access list statement, the packet is then tested against the next
statement in the list.
•
If a packet and an access list statement match, the rest of the statements in the list are skipped and
the packet is permitted or denied as specified in the matched statement. The first entry that the packet
matches determines whether the software permits or denies the packet. That is, after the first match,
no subsequent entries are considered.
•
If the access list denies the address or protocol, the software discards the packet and returns an ICMP
Host Unreachable message.
•
If no conditions match, the software drops the packet. This is because each access list ends with an
unwritten or implicit deny statement. That is, if the packet has not been permitted by the time it was
tested against each statement, it is denied.
•
The access list must contain at least one permit statement or else all packets are denied.
•
Because the software stops testing conditions after the first match, the order of the conditions is
critical. The same permit or deny statements specified in a different order could result in a packet
being passed under one circumstance and denied in another circumstance.
•
If an access list is referenced by name in a command, but the access list does not exist, all packets
pass.
•
Only one access list per interface, per protocol, per direction is allowed.
•
Inbound access lists process packets arriving at the router. Incoming packets are processed before
being routed to an outbound interface. An inbound access list is efficient because it saves the
overhead of routing lookups if the packet is to be discarded because it is denied by the filtering tests.
If the packet is permitted by the tests, it is then processed for routing. For inbound lists, permit
means continue to process the packet after receiving it on an inbound interface; deny means discard
the packet.
•
Outbound access lists process packets before they leave the router. Incoming packets are routed to
the outbound interface and then processed through the outbound access list. For outbound lists,
permit means send it to the output buffer; deny means discard the packet.
Helpful Hints for Creating IP Access Lists
•
Create the access list before applying it to an interface. An interface with an empty access list
applied to it permits all traffic.
•
Another reason to configure an access list before applying it is because if you applied a nonexistent
access list to an interface and then proceed to configure the access list, the first statement is put into
effect, and the implicit deny statement that follows could cause you immediate access problems.
•
Because the software stops testing conditions after it encounters the first match (to either a permit
or deny statement), you will reduce processing time and resources if you put the statements that
packets are most likely to match at the beginning of the access list. Place more frequently occurring
conditions before less frequent conditions.
•
Organize your access list so that more specific references in a network or subnet appear before more
general ones.
•
In order to make the purpose of individual statements more easily understood at a glance, you can
write a helpful remark before or after any statement.
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
3
APPENDIX Y
IP Access List Entry Sequence Numbering
Information About IP Access Lists
Source and Destination Addresses
Source address and destination addresses are two of the most typical fields in an IP packet on which to
base an access list. Specify source addresses to control packets from certain networking devices or hosts.
Specify destination addresses to control packets being sent to certain networking devices or hosts.
Wildcard Mask and Implicit Wildcard Mask
Address filtering uses wildcard masking to indicate to the software whether to check or ignore
corresponding IP address bits when comparing the address bits in an access list entry to a packet being
submitted to the access list. By carefully setting wildcard masks, an administrator can select single or
several IP addresses for permit or deny tests.
Wildcard masking for IP address bits uses the number 1 and the number 0 to specify how the software
treats the corresponding IP address bits. A wildcard mask is sometimes referred to as an inverted mask
because a 1 and 0 mean the opposite of what they mean in a subnet (network) mask.
•
A wildcard mask bit 0 means check the corresponding bit value.
•
A wildcard mask bit 1 means ignore that corresponding bit value.
If you do not supply a wildcard mask with a source or destination address in an access list statement, the
software assumes a default wildcard mask of 0.0.0.0.
Unlike subnet masks, which require contiguous bits indicating network and subnet to be ones, wildcard
masks allow noncontiguous bits in the mask.
Transport Layer Information
You can filter packets based on transport layer information, such as whether the packet is a TCP, UDP,
ICMP or IGMP packet.
IP Access List Entry Sequence Numbering
Benefits
The ability to apply sequence numbers to IP access list entries simplifies access list changes. Prior to the
IP Access List Entry Sequence Numbering feature, there was no way to specify the position of an entry
within an access list. If a user wanted to insert an entry (statement) in the middle of an existing list, all
of the entries after the desired position had to be removed, then the new entry was added, and then all
the removed entries had to be reentered. This method was cumbersome and error prone.
This feature allows users to add sequence numbers to access list entries and resequence them. When a
user adds a new entry, the user chooses the sequence number so that it is in a desired position in the
access list. If necessary, entries currently in the access list can be resequenced to create room to insert
the new entry.
Sequence Numbering Behavior
•
For backward compatibility with previous releases, if entries with no sequence numbers are applied,
the first entry is assigned a sequence number of 10, and successive entries are incremented by 10.
The maximum sequence number is 2147483647. If the generated sequence number exceeds this
maximum number, the following message is displayed:
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
4
APPENDIX Y
IP Access List Entry Sequence Numbering
How to Use Sequence Numbers in an IP Access List
Exceeded maximum sequence number.
•
If the user enters an entry without a sequence number, it is assigned a sequence number that is 10
greater than the last sequence number in that access list and is placed at the end of the list.
•
If the user enters an entry that matches an already existing entry (except for the sequence number),
then no changes are made.
•
If the user enters a sequence number that is already present, the following error message is
generated:
Duplicate sequence number.
•
If a new access list is entered from global configuration mode, then sequence numbers for that access
list are generated automatically.
•
Distributed support is provided so that the sequence numbers of entries in the Route Processor (RP)
and line card (LC) are in synchronization at all times.
•
Sequence numbers are not nvgened. That is, the sequence numbers themselves are not saved. In the
event that the system is reloaded, the configured sequence numbers revert to the default sequence
starting number and increment. The function is provided for backward compatibility with software
releases that do not support sequence numbering.
•
This feature works with named standard and extended IP access lists. Because the name of an access
list can be designated as a number, numbers are acceptable.
How to Use Sequence Numbers in an IP Access List
This section describes how to use sequence numbers in an IP access list.
•
Sequencing Access-List Entries and Revising the Access List, page 5
Sequencing Access-List Entries and Revising the Access List
This task shows how to assign sequence numbers to entries in a named IP access list and how to add or
delete an entry to or from an access list. It is assumed a user wants to revise an access list. The context
of this task is the following:
•
A user need not resequence access lists for no reason; resequencing in general is optional. The
resequencing step in this task is shown as required because that is one purpose of this feature and
this task demonstrates the feature.
•
Step 5 happens to be a permit statement and Step 6 happens to be a deny statement, but they need
not be in that order.
1.
enable
2.
configure terminal
3.
ip access-list resequence access-list-name starting-sequence-number increment
4.
ip access-list {standard | extended} access-list-name
5.
sequence-number permit source source-wildcard
SUMMARY STEPS
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
5
APPENDIX Y
IP Access List Entry Sequence Numbering
How to Use Sequence Numbers in an IP Access List
or
sequence-number permit protocol source source-wildcard destination destination-wildcard
[precedence precedence] [tos tos] [log] [time-range time-range-name] [fragments]
6.
sequence-number deny source source-wildcard
or
sequence-number deny protocol source source-wildcard destination destination-wildcard
[precedence precedence] [tos tos] [log] [time-range time-range-name] [fragments]
7.
Repeat Step 5 and/or Step 6 as necessary, adding statements by sequence number where you
planned. Use the no sequence-number command to delete an entry.
8.
end
9.
show ip access-lists access-list-name
DETAILED STEPS
Step 1
Command or Action
Purpose
enable
Enables privileged EXEC mode. Enter your password if
prompted.
Example:
Router> enable
Step 2
configure terminal
Enters global configuration mode.
Example:
Router# configure terminal
Step 3
ip access-list resequence access-list-name
starting-sequence-number increment
Resequences the specified IP access list using the starting
sequence number and the increment of sequence numbers.
•
Example:
Router(config)# ip access-list resequence kmd1
100 15
Step 4
ip access-list {standard | extended}
access-list-name
Specifies the IP access list by name and enters named access
list configuration mode.
•
If you specify standard, make sure you subsequently
specify permit and/or deny statements using the
standard access list syntax.
•
If you specify extended, make sure you subsequently
specify permit and/or deny statements using the
extended access list syntax.
Example:
Router(config)# ip access-list standard kmd1
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
6
This example resequences an access list named kmd1.
The starting sequence number is 100 and the increment
is 15.
APPENDIX Y
IP Access List Entry Sequence Numbering
How to Use Sequence Numbers in an IP Access List
Step 5
Command or Action
Purpose
sequence-number permit source source-wildcard
Specifies a permit statement in named IP access list mode.
or
•
sequence-number permit protocol source
source-wildcard destination
destination-wildcard [precedence precedence]
[tos tos] [log] [time-range time-range-name]
[fragments]
This access list happens to use a permit statement first,
but a deny statement could appear first, depending on
the order of statements you need.
•
See the permit (IP) command for additional command
syntax to permit upper layer protocols (ICMP, IGMP,
TCP, and UDP).
•
Use the no sequence-number command to delete an
entry.
•
As the prompt indicates, this access list was a standard
access list. If you had specified extended in Step 4, the
prompt for this step would be
Router(config-ext-nacl) and you would use the
extended permit command syntax.
Example:
Router(config-std-nacl)# 105 permit 10.5.5.5
0.0.0 255
Step 6
sequence-number deny source source-wildcard
or
sequence-number deny protocol source
source-wildcard destination
destination-wildcard [precedence precedence]
[tos tos] [log] [time-range time-range-name]
[fragments]
Example:
Router(config-std-nacl)# 105 deny 10.6.6.7
0.0.0 255
Step 7
Repeat Step 5 and/or Step 6 as necessary, adding
statements by sequence number where you planned.
Use the no sequence-number command to delete an
entry.
(Optional) Specifies a deny statement in named IP access
list mode.
•
This access list happens to use a permit statement first,
but a deny statement could appear first, depending on
the order of statements you need.
•
See the deny (IP) command for additional command
syntax to permit upper layer protocols (ICMP, IGMP,
TCP, and UDP).
•
Use the no sequence-number command to delete an
entry.
•
As the prompt indicates, this access list was a standard
access list. If you had specified extended in Step 4, the
prompt for this step would be
Router(config-ext-nacl) and you would use the
extended deny command syntax.
Allows you to revise the access list.
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
7
APPENDIX Y
IP Access List Entry Sequence Numbering
Configuration Examples for IP Access List Entry Sequence Numbering
Step 8
Command or Action
Purpose
end
(Optional) Exits the configuration mode and returns to
privileged EXEC mode.
Example:
Router(config-std-nacl)# end
Step 9
show ip access-lists access-list-name
(Optional) Displays the contents of the IP access list.
•
Example:
Router# show ip access-lists kmd1
Review the output to see that the access list includes the
new entry.
Router# show ip access-lists kmd1
Standard IP access list kmd1
100 permit 10.4.4.0, wildcard
105 permit 10.5.5.0, wildcard
115 permit 10.0.0.0, wildcard
130 permit 10.5.5.0, wildcard
145 permit 10.0.0.0, wildcard
bits
bits
bits
bits
bits
0.0.0.255
0.0.0.255
0.0.0.255
0.0.0.255
0.0.0.255
What to Do Next
If your access list is not already applied to an interface or line or otherwise referenced, apply the access
list. Refer to the “Configuring IP Services” chapter of the Cisco IOS IP Configuration Guide for
information about how to apply an IP access list.
Configuration Examples for IP Access List Entry Sequence
Numbering
This section provides the following examples related to sequence numbering of entries in an IP access
list:
•
Resequencing Entries in an Access List: Example, page 8
•
Adding Entries with Sequence Numbers: Example, page 9
•
Entry without Sequence Number: Example, page 9
Resequencing Entries in an Access List: Example
The following example shows access list resequencing. The starting value is 1, and increment value is 2.
The subsequent entries are ordered based on the increment values that users provide, and the range is
from 1 to 2147483647.
When an entry with no sequence number is entered, by default it has a sequence number of 10 more than
the last entry in the access list.
Router# show access-list 150
Extended IP access list 150
10 permit ip host 10.3.3.3 host 172.16.5.34
20 permit icmp any any
30 permit tcp any host 10.3.3.3
40 permit ip host 10.4.4.4 any
50 Dynamic test permit ip any any
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
8
APPENDIX Y
IP Access List Entry Sequence Numbering
Configuration Examples for IP Access List Entry Sequence Numbering
60 permit ip host 172.16.2.2 host 10.3.3.12
70 permit ip host 10.3.3.3 any log
80 permit tcp host 10.3.3.3 host 10.1.2.2
90 permit ip host 10.3.3.3 any
100 permit ip any any
Router(config)# ip access-list extended 150
Router(config)# ip access-list resequence 150 1 2
Router(config)# end
Router# show access-list 150
Extended IP access list 150
1 permit ip host 10.3.3.3 host 172.16.5.34
3 permit icmp any any
5 permit tcp any host 10.3.3.3
7 permit ip host 10.4.4.4 any
9 Dynamic test permit ip any any
11 permit ip host 172.16.2.2 host 10.3.3.12
13 permit ip host 10.3.3.3 any log
15 permit tcp host 10.3.3.3 host 10.1.2.2
17 permit ip host 10.3.3.3 any
19 permit ip any any
Adding Entries with Sequence Numbers: Example
In the following example, an new entry is added to a specified access list:
Router# show ip access-list
Standard IP access list tryon
2 permit 10.4.4.2, wildcard bits 0.0.255.255
5 permit 10.0.0.44, wildcard bits 0.0.0.255
10 permit 10.0.0.1, wildcard bits 0.0.0.255
20 permit 10.0.0.2, wildcard bits 0.0.0.255
Router(config)# ip access-list standard tryon
Router(config-std-nacl)# 15 permit 10.5.5.5 0.0.0.255
Router# show ip access-list
Standard IP access list tryon
2 permit 10.4.0.0, wildcard bits 0.0.255.255
5 permit 10.0.0.0, wildcard bits 0.0.0.255
10 permit 10.0.0.0, wildcard bits 0.0.0.255
15 permit 10.5.5.0, wildcard bits 0.0.0.255
20 permit 10.0.0.0, wildcard bits 0.0.0.255
Entry without Sequence Number: Example
The following example shows how an entry with no specified sequence number is added to the end of an
access list. When an entry is added without a sequence number, it is automatically given a sequence
number that puts it at the end of the access list. Because the default increment is 10, the entry will have
a sequence number 10 higher than the last entry in the existing access list.
Router(config)# ip access-list standard 1
Router(config-std-nacl)# permit 1.1.1.1 0.0.0.255
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
9
APPENDIX Y
IP Access List Entry Sequence Numbering
Additional References
Router(config-std-nacl)# permit 2.2.2.2 0.0.0.255
Router(config-std-nacl)# permit 3.3.3.3 0.0.0.255
Router# show access-list
Standard IP access list 1
10 permit 0.0.0.0, wildcard bits 0.0.0.255
20 permit 0.0.0.0, wildcard bits 0.0.0.255
30 permit 0.0.0.0, wildcard bits 0.0.0.255
Router(config)# ip access-list standard 1
Router(config-std-nacl)# permit 4.4.4.4 0.0.0.255
Router(config-std-nacl)# end
Router# show access-list
Standard IP access
10 permit 0.0.0.0,
20 permit 0.0.0.0,
30 permit 0.0.0.0,
40 permit 0.4.0.0,
list 1
wildcard
wildcard
wildcard
wildcard
bits
bits
bits
bits
0.0.0.255
0.0.0.255
0.0.0.255
0.0.0.255
Additional References
The following sections provide references related to IP access lists.
Related Documents
Related Topic
Document Title
Configuring IP access lists
“Configuring IP Services” chapter in the Cisco IOS IP
Configuration Guide, Release 12.2
IP access list commands
“IP Services Commands” chapter in the Cisco IOS IP Command
Reference, Volume 1 of 3: Addressing and Services, Release 12.2
Standards
Standards
Title
No new or modified standards are supported by this
—
feature, and support for existing standards has not been
modified by this feature.
MIBs
MIBs
MIBs Link
No new or modified MIBs are supported by this
feature, and support for existing MIBs has not been
modified by this feature.
To locate and download MIBs for selected platforms, Cisco IOS
releases, and feature sets, use Cisco MIB Locator found at the
following URL:
http://www.cisco.com/go/mibs
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
10
APPENDIX Y
IP Access List Entry Sequence Numbering
Command Reference
RFCs
RFCs
Title
No new or modified RFCs are supported by this
feature, and support for existing RFCs has not been
modified by this feature.
—
Technical Assistance
Description
Link
Technical Assistance Center (TAC) home page,
http://www.cisco.com/public/support/tac/home.shtml
containing 30,000 pages of searchable technical
content, including links to products, technologies,
solutions, technical tips, tools, and lots more.
Registered Cisco.com users can log in from this page to
access even more content.
Command Reference
This section documents new and revised commands. All other commands used with this feature are
documented in the Cisco IOS Release 12.2T command reference publications.
New Command
•
ip access-list resequence
Revised Commands
•
deny (IP)
•
permit (IP)
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
11
APPENDIX Y
IP Access List Entry Sequence Numbering
deny (IP)
deny (IP)
To set conditions in a named IP access list that will deny packets, use the deny command in access-list
configuration mode.To remove a deny condition from an access list, use the no form of this command.
[sequence-number] deny source [source-wildcard]
[sequence-number] deny protocol source source-wildcard destination destination-wildcard
[precedence precedence] [tos tos] [log] [time-range time-range-name] [fragments]
no sequence-number
no deny source [source-wildcard]
no deny protocol source source-wildcard destination destination-wildcard
Internet Control Message Protocol (ICMP)
For ICMP, you can also use the following syntax:
[sequence-number] deny icmp source source-wildcard destination destination-wildcard [icmp-type
[icmp-code] | icmp-message] [precedence precedence] [tos tos] [log] [time-range
time-range-name] [fragments]
Internet Group Management Protocol (IGMP)
For IGMP, you can also use the following syntax:
[sequence-number] deny igmp source source-wildcard destination destination-wildcard
[igmp-type] [precedence precedence] [tos tos] [log] [time-range time-range-name]
[fragments]
Transmission Control Protocol (TCP)
For TCP, you can also use the following syntax:
[sequence-number] deny tcp source source-wildcard [operator port [port]] destination
destination-wildcard [operator [port]] [established] [precedence precedence] [tos tos] [log]
[time-range time-range-name] [fragments]
User Datagram Protocol (UDP)
For UDP, you can also use the following syntax:
[sequence-number] deny udp source source-wildcard [operator port [port]] destination
destination-wildcard [operator [port]] [precedence precedence] [tos tos] [log] [time-range
time-range-name] [fragments]
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
12
APPENDIX Y
IP Access List Entry Sequence Numbering
deny (IP)
Syntax Description
sequence-number
(Optional) Sequence number assigned to the deny statement, causing the
system to insert the statement in that numbered position in the access list.
source
Number of the network or host from which the packet is being sent. There
are three alternative ways to specify the source:
source-wildcard
•
Use a 32-bit quantity in four-part, dotted-decimal format.
•
Use the any keyword as an abbreviation for a source and
source-wildcard of 0.0.0.0 255.255.255.255.
•
Use host source as an abbreviation for a source and source-wildcard
of source 0.0.0.0.
Wildcard bits to be applied to the source. There are three alternative ways
to specify the source wildcard:
•
Use a 32-bit quantity in four-part, dotted decimal format. Place 1s in
the bit positions you want to ignore.
•
Use the any keyword as an abbreviation for a source and
source-wildcard of 0.0.0.0 255.255.255.255.
•
Use host source as an abbreviation for a source and source-wildcard
of source 0.0.0.0.
protocol
Name or number of an Internet protocol. It can be one of the keywords
eigrp, gre, icmp, igmp, igrp, ip, ipinip, nos, ospf, tcp, or udp, or an
integer in the range from 0 to 255 representing an Internet protocol
number. To match any Internet protocol (including ICMP, TCP, and
UDP), use the ip keyword. Some protocols allow further qualifiers
described later.
destination
Number of the network or host to which the packet is being sent. There
are three alternative ways to specify the destination:
destination-wildcard
•
Use a 32-bit quantity in four-part, dotted-decimal format.
•
Use the any keyword as an abbreviation for the destination and
destination-wildcard of 0.0.0.0 255.255.255.255.
•
Use host destination as an abbreviation for a destination and
destination-wildcard of destination 0.0.0.0.
Wildcard bits to be applied to the destination. There are three alternative
ways to specify the destination wildcard:
•
Use a 32-bit quantity in four-part, dotted decimal format. Place 1s in
the bit positions you want to ignore.
•
Use the any keyword as an abbreviation for a destination and
destination-wildcard of 0.0.0.0 255.255.255.255.
•
Use host destination as an abbreviation for a destination and
destination-wildcard of destination 0.0.0.0.
precedence precedence
(Optional) Packets can be filtered by precedence level, as specified by a
number from 0 to 7 or by name as listed in the section “Usage
Guidelines.”
tos tos
(Optional) Packets can be filtered by type of service (ToS) level, as
specified by a number from 0 to 15, or by name as listed in the section
“Usage Guidelines” of the access-list (IP extended) command.
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
13
APPENDIX Y
IP Access List Entry Sequence Numbering
deny (IP)
log
(Optional) Causes an informational logging message about the packet that
matches the entry to be sent to the console. (The level of messages logged
to the console is controlled by the logging console command.)
The message includes the access list number, whether the packet was
permitted or denied; the protocol, whether it was TCP, UDP, ICMP, or a
number; and, if appropriate, the source and destination addresses and
source and destination port numbers. The message is generated for the
first packet that matches, and then at 5-minute intervals, including the
number of packets permitted or denied in the prior 5-minute interval.
Use the ip access-list log-update command to generate logging messages
when the number of matches reaches a configurable threshold (rather than
waiting for a 5-minute interval). See the ip access-list log-update
command for more information.
The logging facility might drop some logging message packets if there are
too many to be handled or if there is more than one logging message to be
handled in 1 second. This behavior prevents the router from crashing due
to too many logging packets. Therefore, the logging facility should not be
used as a billing tool or an accurate source of the number of matches to
an access list.
If you enable CEF and then create an access list that uses the log keyword,
the packets that match the access list are not CEF switched. They are fast
switched. Logging disables CEF.
time-range
time-range-name
(Optional) Name of the time range that applies to this deny statement.
The name of the time range and its restrictions are specified by the
time-range and absolute or periodic commands, respectively.
icmp-type
(Optional) ICMP packets can be filtered by ICMP message type. The type
is a number from 0 to 255.
icmp-code
(Optional) ICMP packets that are filtered by ICMP message type can also
be filtered by the ICMP message code. The code is a number from 0 to
255.
icmp-message
(Optional) ICMP packets can be filtered by an ICMP message type name
or ICMP message type and code name. The possible names are listed in
the section “Usage Guidelines” of the access-list (IP extended)
command.
igmp-type
(Optional) IGMP packets can be filtered by IGMP message type or
message name. A message type is a number from 0 to 15. IGMP message
names are listed in the section “Usage Guidelines” of the access-list (IP
extended) command.
operator
(Optional) Compares source or destination ports. Possible operands
include lt (less than), gt (greater than), eq (equal), neq (not equal), and
range (inclusive range).
If the operator is positioned after the source and source-wildcard, it must
match the source port.
If the operator is positioned after the destination and
destination-wildcard, it must match the destination port.
The range operator requires two port numbers. All other operators
require one port number.
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
14
APPENDIX Y
IP Access List Entry Sequence Numbering
deny (IP)
port
(Optional) The decimal number or name of a TCP or UDP port. A port
number is a number from 0 to 65535. TCP and UDP port names are listed
in the section “Usage Guidelines” of the access-list (IP extended)
command.
TCP port names can only be used when filtering TCP. UDP port names
can only be used when filtering UDP.
established
(Optional) For the TCP protocol only: Indicates an established
connection. A match occurs if the TCP datagram has the ACK or RST bits
set. The nonmatching case is that of the initial TCP datagram to form a
connection.
fragments
(Optional) The access list entry applies to noninitial fragments of packets;
the fragment is either permitted or denied accordingly. For more details
about the fragments keyword, see the “Access List Processing of
Fragments” and “Fragments and Policy Routing” sections in the “Usage
Guidelines” section.
Defaults
There is no specific condition under which a packet is denied passing the named access list.
Command Modes
Access-list configuration
Command History
Release
Modification
11.2
This command was introduced.
Usage Guidelines
12.0(1)T
The time-range time-range-name keyword and argument were added.
12.0(11) and 12.1(2)
The fragments keyword was added.
12.2(14)S
The sequence-number argument was added.
Use this command following the ip access-list command to specify conditions under which a packet
cannot pass the named access list.
The time-range option allows you to identify a time range by name. The time-range, absolute, and
periodic commands specify when this deny statement is in effect.
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
15
APPENDIX Y
IP Access List Entry Sequence Numbering
deny (IP)
Access List Processing of Fragments
The behavior of access-list entries regarding the use or lack of the fragments keyword can be
summarized as follows:
If the Access-List Entry has...
Then..
...no fragments keyword (the default For an access-list entry containing only Layer 3 information:
behavior), and assuming all of the
• The entry is applied to nonfragmented packets, initial
access-list entry information matches,
fragments and noninitial fragments.
For an access list entry containing Layer 3 and Layer 4
information:
•
The entry is applied to nonfragmented packets and initial
fragments.
– If the entry is a permit statement, the packet or
fragment is permitted.
– If the entry is a deny statement, the packet or
fragment is denied.
•
The entry is also applied to noninitial fragments in the
following manner. Because noninitial fragments contain
only Layer 3 information, only the Layer 3 portion of an
access-list entry can be applied. If the Layer 3 portion of
the access-list entry matches, and
– If the entry is a permit statement, the noninitial
fragment is permitted.
– If the entry is a deny statement, the next access-list
entry is processed.
...the fragments keyword, and
assuming all of the access-list entry
information matches,
Note
The deny statements are handled differently for
noninitial fragments versus nonfragmented or
initial fragments.
Note
The access-list entry is applied only to noninitial
fragments.The fragments keyword cannot be
configured for an access-list entry that contains
any Layer 4 information.
Be aware that you should not simply add the fragments keyword to every access list entry because the
first fragment of the IP packet is considered a nonfragment and is treated independently of the
subsequent fragments. An initial fragment will not match an access list permit or deny entry that
contains the fragments keyword, the packet is compared to the next access list entry, and so on, until it
is either permitted or denied by an access list entry that does not contain the fragments keyword.
Therefore, you may need two access list entries for every deny entry. The first deny entry of the pair
will not include the fragments keyword, and applies to the initial fragment. The second deny entry of
the pair will include the fragments keyword and applies to the subsequent fragments. In the cases where
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
16
APPENDIX Y
IP Access List Entry Sequence Numbering
deny (IP)
there are multiple deny access list entries for the same host but with different Layer 4 ports, a single
deny access-list entry with the fragments keyword for that host is all that needs to be added. Thus all
the fragments of a packet are handled in the same manner by the access list.
Packet fragments of IP datagrams are considered individual packets and each counts individually as a
packet in access list accounting and access list violation counts.
Note
The fragments keyword cannot solve all cases involving access lists and IP fragments.
Fragments and Policy Routing
Fragmentation and the fragment control feature affect policy routing if the policy routing is based on the
match ip address command and the access list had entries that match on Layer 4 through 7 information.
It is possible that noninitial fragments pass the access list and are policy routed, even if the first fragment
was not policy routed or the reverse.
By using the fragments keyword in access list entries as described earlier, a better match between the
action taken for initial and noninitial fragments can be made and it is more likely policy routing will
occur as intended.
Examples
The following example sets a deny condition for a standard access list named Internetfilter:
ip access-list standard Internetfilter
deny 192.5.34.0 0.0.0.255
permit 128.88.0.0 0.0.255.255
permit 36.0.0.0 0.255.255.255
! (Note: all other access implicitly denied)
The following example denies HTTP traffic on Monday through Friday from 8:00 a.m. to 6:00 p.m.:
time-range no-http
periodic weekdays 8:00 to 18:00
!
ip access-list extended strict
deny tcp any any eq http time-range no-http
!
interface ethernet 0
ip access-group strict in
The following example adds an entry with the sequence number 25 to extended IP access list 150:
Router(config)# ip access-list extended 150
Router(config-std-nacl)# 25 deny ip host 3.3.3.3 host 45.5.5.34
The following example removes the entry with the sequence number 25 from the standard access list
example shown above:
Router(config-std-nacl)# no 25
Related Commands
Command
Description
access-list (IP extended)
Defines an extended IP access list.
access-list (IP standard)
Defines a standard IP access list.
ip access-group
Controls access to an interface.
ip access-list
Defines an IP access list by name.
ip access-list log-update
Sets the threshold number of packets that cause a logging message.
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
17
APPENDIX Y
IP Access List Entry Sequence Numbering
deny (IP)
Command
Description
ip access-list resequence
Applies sequence numbers to the access list entries in an access list.
permit (IP)
Sets conditions under which a packet passes a named IP access list.
remark
Writes a helpful comment (remark) for an entry in a named IP access list.
show ip access-list
Displays the contents of all current IP access lists.
time-range
Specifies when an access list or other feature is in effect.
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
18
APPENDIX Y
IP Access List Entry Sequence Numbering
ip access-list resequence
ip access-list resequence
To apply sequence numbers to the access list entries in an access list, use the ip access-list resequence
command in global configuration mode.This command does not have a no version.
ip access-list resequence access-list-name starting-sequence-number increment
Syntax Description
access-list-name
Name of the access list. Names cannot contain a space or quotation
mark.
starting-sequence-number
Access list entries will be resequenced using this initial value. The
default value is 10. The range of possible sequence numbers is 1 through
2147483647.
increment
The number by which the sequence numbers change. The default value
is 10. For example, if the increment value is 5 and the beginning
sequence number is 20, the subsequent sequence numbers are 25, 30, 25,
40, and so on.
Defaults
Disabled
Command Modes
Global configuration
Command History
Release
Modification
12.2(14)S
This command was introduced.
Usage Guidelines
This feature allows the permit and deny entries of a specified access list to be resequenced with an
initial sequence number value determined by the starting-sequence-number argument, and continuing in
increments determined by the increment argument. If the highest sequence number exceeds the
maximum possible sequence number, then no sequencing occurs.
For backward compatibility with previous releases, if entries with no sequence numbers are applied, the
first entry is assigned a sequence number of 10, and successive entries are incremented by 10. The
maximum sequence number is 2147483647. If the generated sequence number exceeds this maximum
number, the following message is displayed:
Exceeded maximum sequence number.
If the user enters an entry without a sequence number, it is assigned a sequence number that is 10 greater
than the last sequence number in that access list and is placed at the end of the list.
If the user enters an entry that matches an already existing entry (except for the sequence number), then
no changes are made.
If the user enters a sequence number that is already present, the following error message is generated:
Duplicate sequence number.
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
19
APPENDIX Y
IP Access List Entry Sequence Numbering
ip access-list resequence
If a new access list is entered from global configuration mode, then sequence numbers for that access
list are generated automatically.
Distributed support is provided so that the sequence numbers of entries in the Route Processor (RP) and
line card (LC) are in synchronization at all times.
Sequence numbers are not nvgened. That is, the sequence numbers themselves are not saved. In the event
that the system is reloaded, the configured sequence numbers revert to the default sequence starting
number and increment.
This feature works with named standard and extended IP access lists. Because the name of an access list
can be designated as a number, numbers are acceptable as names as long as they are entered in named
access list configuration mode.
Examples
The following example resequences an access list named kmd1. The starting sequence number is 100,
and the increment value is 5:
Router(config)# ip access-list resequence kmd1 100 5
Related Commands
Command
Description
deny (IP)
Sets conditions under which a packet does not pass a named IP access list.
permit (IP)
Sets conditions under which a packet passes a named IP access list.
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
20
APPENDIX Y
IP Access List Entry Sequence Numbering
permit (IP)
permit (IP)
To set conditions to allow a packet to pass a named IP access list, use the permit access-list configuration
command. To remove a permit condition from an access list, use a no form of this command.
[sequence-number] permit source [source-wildcard]
[sequence-number] permit protocol source source-wildcard destination destination-wildcard
[precedence precedence] [tos tos] [log] [time-range time-range-name] [fragments]
no sequence-number
no permit source [source-wildcard]
no permit protocol source source-wildcard destination destination-wildcard
[precedence precedence] [tos tos] [log] [time-range time-range-name] [fragments]
Internet Control Message Protocol (ICMP)
For ICMP, you can also use the following syntax:
[sequence-number] permit icmp source source-wildcard destination destination-wildcard
[icmp-type [icmp-code] | icmp-message] [precedence precedence] [tos tos] [log] [time-range
time-range-name] [fragments]
Internet Group Management Protocol (IGMP)
For IGMP, you can also use the following syntax:
[sequence-number] permit igmp source source-wildcard destination destination-wildcard
[igmp-type] [precedence precedence] [tos tos] [log] [time-range time-range-name]
[fragments]
Transmission Control Protocol (TCP)
For TCP, you can also use the following syntax:
[sequence-number] permit tcp source source-wildcard [operator [port]] destination
destination-wildcard [operator [port]] [established] [precedence precedence] [tos tos] [log]
[time-range time-range-name] [fragments]
User Datagram Protocol UDP)
For UDP, you can also use the following syntax:
[sequence-number] permit udp source source-wildcard [operator [port]] destination
destination-wildcard [operator [port]] [precedence precedence] [tos tos] [log] [time-range
time-range-name] [fragments]
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
21
APPENDIX Y
IP Access List Entry Sequence Numbering
permit (IP)
Syntax Description
sequence-number
(Optional) Sequence number assigned to the permit statement, causing
the system to insert the statement in that numbered position in the access
list.
source
Number of the network or host from which the packet is being sent. There
are three alternative ways to specify the source:
source-wildcard
•
Use a 32-bit quantity in four-part, dotted decimal format.
•
Use the any keyword as an abbreviation for a source and
source-wildcard of 0.0.0.0 255.255.255.255.
•
Use host source as an abbreviation for a source and source-wildcard
of source 0.0.0.0.
Wildcard bits to be applied to source. There are three alternative ways to
specify the source wildcard:
•
Use a 32-bit quantity in four-part, dotted decimal format. Place 1s in
the bit positions you want to ignore.
•
Use the any keyword as an abbreviation for a source and
source-wildcard of 0.0.0.0 255.255.255.255.
•
Use host source as an abbreviation for a source and source-wildcard
of source 0.0.0.0.
protocol
Name or number of an Internet protocol. It can be one of the keywords
eigrp, gre, icmp, igmp, igrp, ip, ipinip, nos, ospf, tcp, or udp, or an
integer in the range from 0 to 255 representing an Internet protocol
number. To match any Internet protocol (including ICMP, TCP, and
UDP), use the ip keyword. Some protocols allow further qualifiers
described later.
destination
Number of the network or host to which the packet is being sent. There
are three alternative ways to specify the destination:
destination-wildcard
•
Use a 32-bit quantity in four-part, dotted-decimal format.
•
Use the any keyword as an abbreviation for the destination and
destination-wildcard of 0.0.0.0 255.255.255.255.
•
Use host destination as an abbreviation for a destination and
destination-wildcard of destination 0.0.0.0.
Wildcard bits to be applied to the destination. There are three alternative
ways to specify the destination wildcard:
•
Use a 32-bit quantity in four-part, dotted decimal format. Place 1s in
the bit positions you want to ignore.
•
Use the any keyword as an abbreviation for a destination and
destination-wildcard of 0.0.0.0 255.255.255.255.
•
Use host destination as an abbreviation for a destination and
destination-wildcard of destination 0.0.0.0.
precedence precedence
(Optional) Packets can be filtered by precedence level, as specified by a
number from 0 to 7 or by name as listed in the section “Usage
Guidelines.”
tos tos
(Optional) Packets can be filtered by type of service (ToS) level, as
specified by a number from 0 to 15, or by name as listed in the section
“Usage Guidelines” of the access-list (IP extended) command.
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
22
IP Access List Entry Sequence Numbering
APPENDIX Y
permit (IP)
log
(Optional) Causes an informational logging message about the packet that
matches the entry to be sent to the console. (The level of messages logged
to the console is controlled by the logging console command.)
The message includes the access list number, whether the packet was
permitted or denied; the protocol, whether it was TCP, UDP, ICMP or a
number; and, if appropriate, the source and destination addresses and
source and destination port numbers. The message is generated for the
first packet that matches, and then at 5-minute intervals, including the
number of packets permitted or denied in the prior 5-minute interval.
Use the ip access-list log-update command to generate logging messages
when the number of matches reaches a configurable threshold (rather than
waiting for a 5-minute interval). See the ip access-list log-update
command for more information.
The logging facility might drop some logging message packets if there are
too many to be handled or if there is more than one logging message to be
handled in 1 second. This behavior prevents the router from crashing due
to too many logging packets. Therefore, the logging facility should not be
used as a billing tool or an accurate source of the number of matches to
an access list.
If you enable CEF and then create an access list that uses the log keyword,
the packets that match the access list are not CEF switched. They are fast
switched. Logging disables CEF.
time-range
time-range-name
(Optional) Name of the time range that applies to this permit statement.
The name of the time range and its restrictions are specified by the
time-range and absolute or periodic commands, respectively.
icmp-type
(Optional) ICMP packets can be filtered by ICMP message type. The type
is a number from 0 to 255.
icmp-code
(Optional) ICMP packets that are filtered by ICMP message type can also
be filtered by the ICMP message code. The code is a number from 0 to
255.
icmp-message
(Optional) ICMP packets can be filtered by an ICMP message type name
or ICMP message type and code name. The possible names are found in
the section “Usage Guidelines” of the access-list (IP extended)
command.
igmp-type
(Optional) IGMP packets can be filtered by IGMP message type or
message name. A message type is a number from 0 to 15. IGMP message
names are listed in the section “Usage Guidelines” of the access-list (IP
extended) command.
operator
(Optional) Compares source or destination ports. Possible operands
include lt (less than), gt (greater than), eq (equal), neq (not equal), and
range (inclusive range).
If the operator is positioned after the source and source-wildcard, it must
match the source port.
If the operator is positioned after the destination and
destination-wildcard, it must match the destination port.
The range operator requires two port numbers. All other operators
require one port number.
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
23
APPENDIX Y
IP Access List Entry Sequence Numbering
permit (IP)
port
(Optional) The decimal number or name of a TCP or UDP port. A port
number is a number from 0 to 65535. TCP and UDP port names are listed
in the section “Usage Guidelines” of the access-list (IP extended)
command.
TCP port names can only be used when filtering TCP. UDP port names
can only be used when filtering UDP.
established
(Optional) For the TCP protocol only: Indicates an established
connection. A match occurs if the TCP datagram has the ACK or RST bits
set. The nonmatching case is that of the initial TCP datagram to form a
connection.
fragments
(Optional) The access list entry applies to noninitial fragments of packets;
the fragment is either permitted or denied accordingly. For more details
about the fragments keyword, see the “Access List Processing of
Fragments” and “Fragments and Policy Routing” sections in the “Usage
Guidelines” section.
Defaults
There are no specific conditions under which a packet passes the named access list.
Command Modes
Access-list configuration
Command History
Release
Modification
11.2
This command was introduced.
Usage Guidelines
12.0(1)T
The time-range time-range-name keyword and argument were added.
12.0(11) and 12.1(2)
The fragments keyword was added.
12.2(14)S
The sequence-number argument was added.
Use this command following the ip access-list command to define the conditions under which a packet
passes the access list.
The time-range option allows you to identify a time range by name. The time-range, absolute, and
periodic commands specify when this permit statement is in effect.
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
24
APPENDIX Y
IP Access List Entry Sequence Numbering
permit (IP)
Access List Processing of Fragments
The behavior of access-list entries regarding the use or lack of the fragments keyword can be
summarized as follows:
If the Access-List Entry has...
Then..
...no fragments keyword (the default For an access-list entry containing only Layer 3 information:
behavior), and assuming all of the
• The entry is applied to nonfragmented packets, initial
access-list entry information matches,
fragments and noninitial fragments.
For an access list entry containing Layer 3 and Layer 4
information:
•
The entry is applied to nonfragmented packets and initial
fragments.
– If the entry is a permit statement, the packet or
fragment is permitted.
– If the entry is a deny statement, the packet or
fragment is denied.
•
The entry is also applied to noninitial fragments in the
following manner. Because noninitial fragments contain
only Layer 3 information, only the Layer 3 portion of an
access-list entry can be applied. If the Layer 3 portion of
the access-list entry matches, and
– If the entry is a permit statement, the noninitial
fragment is permitted.
– If the entry is a deny statement, the next access-list
entry is processed.
Note
...the fragments keyword, and
assuming all of the access-list entry
information matches,
The deny statements are handled differently for
noninitial fragments versus nonfragmented or
initial fragments.
The access-list entry is applied only to noninitial fragments.
Note
The fragments keyword cannot be configured for
an access-list entry that contains any Layer 4
information.
Be aware that you should not simply add the fragments keyword to every access list entry because the
first fragment of the IP packet is considered a nonfragment and is treated independently of the
subsequent fragments. An initial fragment will not match an access list permit or deny entry that
contains the fragments keyword, the packet is compared to the next access list entry, and so on, until it
is either permitted or denied by an access list entry that does not contain the fragments keyword.
Therefore, you may need two access list entries for every deny entry. The first deny entry of the pair
will not include the fragments keyword, and applies to the initial fragment. The second deny entry of
the pair will include the fragments keyword and applies to the subsequent fragments. In the cases where
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
25
APPENDIX Y
IP Access List Entry Sequence Numbering
permit (IP)
there are multiple deny access list entries for the same host but with different Layer 4 ports, a single
deny access-list entry with the fragments keyword for that host is all that needs to be added. Thus all
the fragments of a packet are handled in the same manner by the access list.
Packet fragments of IP datagrams are considered individual packets and each counts individually as a
packet in access list accounting and access list violation counts.
Note
The fragments keyword cannot solve all cases involving access lists and IP fragments.
Fragments and Policy Routing
Fragmentation and the fragment control feature affect policy routing if the policy routing is based on the
match ip address command and the access list had entries that match on Layer 4 through 7 information.
It is possible that noninitial fragments pass the access list and are policy routed, even if the first fragment
was not policy routed or the reverse.
By using the fragments keyword in access list entries as described earlier, a better match between the
action taken for initial and noninitial fragments can be made and it is more likely policy routing will
occur as intended.
Examples
The following example sets conditions for a standard access list named Internetfilter:
ip access-list standard Internetfilter
deny 192.5.34.0 0.0.0.255
permit 128.88.0.0 0.0.255.255
permit 36.0.0.0 0.255.255.255
! (Note: all other access implicitly denied)
The following example permits Telnet traffic on Mondays, Tuesdays, and Fridays from 9:00 a.m. to
5:00 p.m.:
time-range testing
periodic Monday Tuesday Friday 9:00 to 17:00
!
ip access-list extended legal
permit tcp any any eq telnet time-range testing
!
interface ethernet 0
ip access-group legal in
The following example shows how to add an entry to an existing access list:
Router# show access-list
Standard IP access list 1
2 permit 10.4.0.0, wildcard bits 0.0.255.255
5 permit 10.0.0.0, wildcard bits 0.0.255.255
10 permit 10.0.0.0, wildcard bits 0.0.255.255
20 permit 10.0.0.0, wildcard bits 0.0.255.255
Router(config)# ip access-list standard 1
Router(config-std-nacl)# 15 permit 5.5.5.5 0.0.255.255
The following examples shows how the entry with the sequence number of 20 is removed from the access
list:
Router(config)# ip access-list standard 1
Router(config-std-nacl)# no 20
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
26
APPENDIX Y
IP Access List Entry Sequence Numbering
permit (IP)
Router# show access-list
Standard IP access
10 permit 0.0.0.1,
30 permit 0.0.0.3,
40 permit 0.4.0.4,
list 1
wildcard bits 0.0.0.255
wildcard bits 0.0.0.255
wildcard bits 0.0.0.255
The following examples shows how, if a user tries to enter an entry that is a duplicate of an entry already
on the list, no changes occur. The entry that the user is trying to add is a duplicate of the entry already
in the access list with a sequence number of 20.
Router# show access-list 101
Extended IP access list 101
10 permit ip host 3.3.3.3 host 45.5.5.34
20 permit icmp any any
30 permit ip host 65.34.2.2 host 43.2.54.2
40 permit ip host 45.3.4.31 host 34.3.32.3 log
Router(config)# ip access-list extended 101
Router(config-ext-nacl)# 100 permit icmp any any
Router(config-ext-nacl)# end
Router# show access-list 101
Extended IP access list 101
10 permit ip host 3.3.3.3 host 45.5.5.34
20 permit icmp any any
30 permit ip host 65.34.2.2 host 43.2.54.2
40 permit ip host 45.3.4.31 host 34.3.32.3 log
The following example shows what occurs if a user tries to enter a new entry with a sequence number of
20 when an entry with a sequence number of 20 is already in the list. An error message appears, and no
change is made to the access list.
Router# show access-list 101
Extended IP access list 101
10 permit ip host 3.3.3.3 host 45.5.5.34
20 permit icmp any any
30 permit ip host 65.34.2.2 host 43.2.54.2
40 permit ip host 45.3.4.31 host 34.3.32.3 log
Router(config)# ip access-list extended 101
Router(config-ext-nacl)# 20 permit udp host 1.1.1.1 host 2.2.2.2
Duplicate sequence number.
Router(config-ext-nacl)# end
Router# show access-list 101
Extended IP access list 101
10 permit ip host 3.3.3.3 host 45.5.5.34
20 permit icmp any any
30 permit ip host 65.34.2.2 host 43.2.54.2
40 permit ip host 45.3.4.31 host 34.3.32.3 log
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
27
APPENDIX Y
IP Access List Entry Sequence Numbering
permit (IP)
Related Commands
Command
Description
deny (IP)
Sets conditions under which a packet does not pass a named IP access list.
ip access-group
Controls access to an interface.
ip access-list
Defines an IP access list by name.
ip access-list
log-update
Sets the threshold number of packets that cause a logging message.
ip access-list
resequence
Applies sequence numbers to the access list entries in an access list.
show ip access-list
Displays the contents of all current IP access lists.
time-range
Specifies when an access list or other feature is in effect.
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco
Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity,
Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way to Increase Your Internet Quotient,
and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a
partnership relationship between Cisco and any other company. (0711R)
Copyright © 2003 Cisco Systems, Inc. All rights reserved.
Cisco IOS Release 12.2(14)S, 12.2(15)T, and 12.3(2)T
28
APPENDIX Z
Network Working Group
Request for Comments: 3519
Category: Standards Track
H. Levkowetz
ipUnplugged
S. Vaarala
Netseal
April 2003
Mobile IP Traversal of Network Address Translation (NAT) Devices
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003).
All Rights Reserved.
Abstract
Mobile IP’s datagram tunnelling is incompatible with Network Address
Translation (NAT). This document presents extensions to the Mobile
IP protocol and a tunnelling method which permits mobile nodes using
Mobile IP to operate in private address networks which are separated
from the public internet by NAT devices. The NAT traversal is based
on using the Mobile IP Home Agent UDP port for encapsulated data
traffic.
Table of Contents
1.
2.
3.
Introduction . . . . . . . . . . . . . . . . . . . .
1.1
Terminology . . . . . . . . . . . . . . . . . .
1.2
Problem description . . . . . . . . . . . . . .
1.3
Assumptions . . . . . . . . . . . . . . . . . .
NAT Traversal Overview. . . . . . . . . . . . . . . .
2.1
Basic Message Sequence. . . . . . . . . . . . .
New Message Formats . . . . . . . . . . . . . . . . .
3.1
UDP Tunnel Request Extension. . . . . . . . . .
3.1.1 F (Force) Flag. . . . . . . . . . . . . .
3.1.2 R (Registration through FA Required) flag
3.1.3 Reserved Fields . . . . . . . . . . . . .
3.1.4 Encapsulation . . . . . . . . . . . . . .
3.1.5 Mobile IP Registration Bits . . . . . . .
3.2
UDP Tunnel Reply Extension. . . . . . . . . . .
3.2.1 Reply Code. . . . . . . . . . . . . . . .
Levkowetz & Vaarala
Standards Track
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 2
. 2
. 3
. 4
. 5
. 5
. 6
. 6
. 7
. 8
. 8
. 8
. 9
. 9
. 10
[Page 1]
APPENDIX Z
RFC 3519
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
NAT Traversal for Mobile IP
April 2003
3.3
MIP Tunnel Data Message . . . . . . . . . . . . . .
3.4
UDP Tunnelling Flag in Agent Advertisements . . . .
3.5
New Registration Reply Codes. . . . . . . . . . . .
Protocol Behaviour. . . . . . . . . . . . . . . . . . . .
4.1
Relation to standard MIP tunnelling . . . . . . . .
4.2
Encapsulating IP Headers in UDP . . . . . . . . . .
4.3
Decapsulation . . . . . . . . . . . . . . . . . . .
4.4
Mobile Node Considerations. . . . . . . . . . . . .
4.5
Foreign Agent Considerations. . . . . . . . . . . .
4.6
Home Agent Considerations . . . . . . . . . . . . .
4.6.1 Error Handling. . . . . . . . . . . . . . . .
4.7
MIP signalling versus tunnelling. . . . . . . . . .
4.8
Packet fragmentation. . . . . . . . . . . . . . . .
4.9
Tunnel Keepalive. . . . . . . . . . . . . . . . . .
4.10 Detecting and compensating for loss of NAT mapping.
4.11 Co-located registration through FA. . . . . . . . .
Implementation Issues . . . . . . . . . . . . . . . . . .
5.1
Movement Detection and Private Address Aliasing . .
5.2
Mobility Binding Lifetime . . . . . . . . . . . . .
Security Considerations . . . . . . . . . . . . . . . . .
6.1
Traffic Redirection Vulnerabilities . . . . . . . .
6.1.1 Manipulation of the Registration
Request Message . . . . . . . . . . . . . . .
6.1.2 Sending a Bogus Keepalive Message . . . . . .
6.2
Use of IPsec. . . . . . . . . . . . . . . . . . . .
6.3
Firewall Considerations . . . . . . . . . . . . . .
UNSAF Considerations. . . . . . . . . . . . . . . . . . .
IANA Considerations . . . . . . . . . . . . . . . . . . .
Intellectual Property Rights. . . . . . . . . . . . . . .
Acknowledgements. . . . . . . . . . . . . . . . . . . . .
Normative References. . . . . . . . . . . . . . . . . . .
Informative References. . . . . . . . . . . . . . . . . .
Authors’ Addresses. . . . . . . . . . . . . . . . . . . .
Full Copyright Statement. . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
11
12
12
12
13
15
15
16
18
19
20
21
21
22
24
24
24
25
26
27
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
28
28
28
30
30
31
31
32
33
34
1. Introduction
1.1 Terminology
The Mobile IP related terminology described in RFC 3344 [10] is used
in this document. In addition, the following terms are used:
Forward Tunnel
A tunnel that forwards packets towards the mobile node. It starts
at the home agent, and ends at the mobile node’s care-of address.
Levkowetz & Vaarala
Standards Track
[Page 2]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
Reverse Tunnel
A tunnel that starts at the mobile node’s care-of address and
terminates at the home agent.
NAT
Network Address Translation. "Traditional NAT would allow hosts
within a private network to transparently access hosts in the
external network, in most cases. In a traditional NAT, sessions
are uni-directional, outbound from the private network." -- RFC
2663 [11]. Basic NAT and NAPT are two varieties of NAT.
Basic NAT
"With Basic NAT, a block of external addresses are set aside for
translating addresses of hosts in a private domain as they
originate sessions to the external domain. For packets outbound
from the private network, the source IP address and related fields
such as IP, TCP, UDP and ICMP header checksums are translated.
For inbound packets, the destination IP address and the checksums
as listed above are translated." -- RFC 2663 [11].
NAPT
Network Address Port Translation. "NAPT extends the notion of
translation one step further by also translating transport
identifier (e.g., TCP and UDP port numbers, ICMP query
identifiers). This allows the transport identifiers of a number
of private hosts to be multiplexed into the transport identifiers
of a single external address. NAPT allows a set of hosts to share
a single external address. Note that NAPT can be combined with
Basic NAT so that a pool of external addresses are used in
conjunction with port translation." -- RFC 2663 [11].
In this document, the more general term NAT is used to cover both
NATs and NAPTs. In most deployment cases today, we believe that the
NATs used are of the NAPT variety.
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 BCP 14, RFC 2119 [6].
1.2 Problem description
A basic assumption that Mobile IP [10] makes is that mobile nodes and
foreign agents are uniquely identifiable by a globally routable IP
address. This assumption breaks down when a mobile node attempts to
communicate from behind a NAT.
Levkowetz & Vaarala
Standards Track
[Page 3]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
Mobile IP relies on sending traffic from the home network to the
mobile node or foreign agent through IP-in-IP tunnelling. IP nodes
which communicate from behind a NAT are reachable only through the
NAT’s public address(es). IP-in-IP tunnelling does not generally
contain enough information to permit unique translation from the
common public address(es) to the particular care-of address of a
mobile node or foreign agent which resides behind the NAT; in
particular there are no TCP/UDP port numbers available for a NAT to
work with. For this reason, IP-in-IP tunnels cannot in general pass
through a NAT, and Mobile IP will not work across a NAT.
Mobile IP’s Registration Request and Reply will on the other hand be
able to pass through NATs and NAPTs on the mobile node or foreign
agent side, as they are UDP datagrams originated from the inside of
the NAT or NAPT. When passing out, they make the NAT set up an
address/port mapping through which the Registration Reply will be
able to pass in to the correct recipient. The current Mobile IP
protocol does however not permit a registration where the mobile
node’s IP source address is not either the CoA, the Home Address, or
0.0.0.0.
What is needed is an alternative data tunnelling mechanism for Mobile
IP which will provide the means needed for NAT devices to do unique
mappings so that address translation will work, and a registration
mechanism which will permit such an alternative tunnelling mechanism
to be set up when appropriate.
This mechanism will address 3 different scenarios:
-
A mobile node with co-located address behind a NAT; no FA
-
A mobile node registered with an FA where both the mobile node and
the FA are behind the same NAT
-
A mobile node with co-located address using an FA which demands
that registrations pass through the FA (sets the "R" bit) where
both the mobile node and the FA are behind the same NAT
1.3 Assumptions
The primary assumption in this document is that the network allows
communication between an UDP port chosen by the mobile node and the
home agent UDP port 434. If this assumption does not hold, neither
Mobile IP registration nor data tunnelling will work.
This document does NOT assume that mobility is constrained to a
common IP address space. On the contrary, the routing fabric between
the mobile node and the home agent may be partitioned into a
Levkowetz & Vaarala
Standards Track
[Page 4]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
"private" and a "public" network, and the assumption is that some
mechanism is needed in addition to vanilla Mobile IP according to RFC
3344 [10] in order to achieve mobility within disparate IP address
spaces.
For a more extensive discussion of the problems with disparate
address spaces, and how they may be solved, see RFC 3024 [9].
The reverse tunnels considered here are symmetric, that is, they use
the same configuration (encapsulation method, IP address endpoints)
as the forward tunnel.
2. NAT Traversal Overview
This section gives a brief overview of the MIP UDP tunnelling
mechanism which may be used to achieve NAT traversal for Mobile IP.
In MIP UDP tunnelling, the mobile node may use an extension
(described below) in its Registration Request to indicate that it is
able to use Mobile IP UDP tunnelling instead of standard Mobile IP
tunnelling if the home agent sees that the Registration Request seems
to have passed through a NAT. The home agent may then send a
registration reply with an extension indicating acceptance (or
denial). After assent from the home agent, MIP UDP tunnelling will
be available for use for both forward and reverse tunnelling. UDP
tunnelled packets sent by the mobile node use the same ports as the
registration request message. In particular, the source port may
vary between new registrations, but remains the same for all
tunnelled data and re-registrations. The destination port is always
434. UDP tunnelled packets sent by the home agent uses the same
ports, but in reverse.
2.1 Basic Message Sequence
The message sequence diagram below exemplifies setting up and using a
Mobile IP UDP tunnel as described in this document. The tunnel is
set up by the use of specific extensions in the initial Mobile IP
Registration Request and Reply exchange. Thereafter, any traffic
from the home agent to the mobile node is sent through the UDP
tunnel. The mobile node may at its discretion use the UDP tunnel for
reverse tunnelling or not, although in most cases where MIP UDP
tunnelling is needed, reverse tunnelling will also be needed.
Levkowetz & Vaarala
Standards Track
[Page 5]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
mobile node
NAT
home agent
|
|
|
|
|
|
| Registration
|
|
| Request with
|
|
|-----------------///--------------->>|
|UDP Tunnel Request|
|
|
|
+
|
|
|| IP Source and
|
|
|| CCoA address
|
|
|| discrepancy
|
|
|| seen
|
| Registration
+
|
| Reply with
|
|<<---------------///-----------------|
|
| UDP Tunnel Reply.|
|
|
|
| UDP tunnelled pkg|
|
|=================///===============>>|
|
| UDP tunnelled pkg|
|<<===============///=================|
|
|
||absence of
|
|
||traffic for
|
|
||UDP keepalive
| UDP keepalive
|
||period
|-----------------///--------------->>+
.
.
+
.
.
.
.
.
.
3. New Message Formats
3.1 UDP Tunnel Request Extension
This extension is a skippable extension. It signifies that the
sender is capable of handling MIP UDP tunnelling, and optionally that
a particular encapsulation format is requested in the MIP UDP tunnel.
The format of this extension is as shown below. It adheres to the
short extension format described in [10].
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
|
Length
|
Sub-Type
|
Reserved 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|R| Reserved 2| Encapsulation |
Reserved 3
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Levkowetz & Vaarala
Standards Track
[Page 6]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
Type
144
Length
6. Length in bytes of this extension, not
including the Type and Length bytes.
Sub-Type
0
Reserved 1
Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
F
F (Force) flag. Indicates that the mobile
node wants to force MIP UDP tunnelling to be
established.
R
R (Registration through FA Required) flag.
Indicates that the R bit was set in the FA’s
Agent Advertisement. Registration is being
made using a co-located care-of address, but
through the FA.
Reserved 2
Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
Encapsulation
Indicates the type of tunnelled data, using
the same numbering as the IP Header Protocol
Field.
Reserved 3
Reserved for future use. MUST be set to 0 on
sending, MUST be verified as 0 on receipt;
otherwise the extension must be handled as not
understood and silently skipped.
3.1.1 F (Force) Flag
Indicates that the mobile node wants to use traversal regardless of
the outcome of NAT detection performed by the home agent. This is
useful if the route between the mobile node and the home agent works
for Mobile IP signalling packets, but not for generic data packets
(e.g., because of firewall filtering rules). If the home agent
supports this protocol, it SHOULD either accept the traversal and
reply with a UDP Tunnel Reply Extension or reject the Registration
Request. In case of the registration failing, the Home Agent SHOULD
send a Registration Reply with Code field set to 129
("administratively prohibited").
Levkowetz & Vaarala
Standards Track
[Page 7]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
If the HA does not understand the UDP Tunnel Request Extension, it
will silently discard it, and if everything else is fine, it will
reply with a registration reply with reply code 0 (registration
accepted), but without any UDP Tunnel Reply Extension. In this case,
the mobile node MUST NOT use MIP UDP tunnelling.
3.1.2 R (Registration through FA Required) flag
This flag MUST be set by the mobile node when it is using a colocated address, but registering through an FA because it has
received an Agent Advertisement with the ’R’ bit set.
3.1.3 Reserved Fields
The ’Reserved 1’ and ’Reserved 2’ fields must be ignored on receipt,
while the ’Reserved 3’ field must be 0 on receipt, otherwise this
extension MUST be handled as not understood and silently skipped.
This permits future additions to this extension to be made which
either can co-exist with old implementations, or will force a
rejection of the extension from an old implementation.
3.1.4 Encapsulation
The ’Encapsulation’ field defines the mode of encapsulation requested
if MIP UDP tunnelling is accepted by the home agent. This field uses
the same values as the IP header Protocol field:
4
IP header (IP-in-UDP tunnelling) RFC 2003 [4]
47
GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]
55
Minimal IP encapsulation header RFC 2004 [5]
If the home agent finds that UDP tunnelling is not needed, the
encapsulation will be determined by the ’M’ and ’G’ flags of the
registration request; but if the home agent finds that MIP UDP
tunnelling should be done, the encapsulation is determined from the
value of the Encapsulation field. If the value of this field is
zero, it defaults to the value of ’M’ and ’G’ fields in the
Registration Request message, but if it is non-zero, it indicates
that a particular encapsulation is desired.
Levkowetz & Vaarala
Standards Track
[Page 8]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
3.1.5 Mobile IP Registration Bits
The Mobile IP registration bits S, B, D, M, G and T retain their
meaning as described in RFC 3344 [10] and RFC 3024 [9] (except that
the significance of the M and G bits may be modified by the
Encapsulation field when MIP UDP tunnelling is used, as described
above). The use of the M and G bits together with MIP UDP tunnelling
is also touched upon in Section 4.1.
When the MN requests MIP UDP tunnelling, the ’D’ bit (Decapsulation
by the mobile node) MUST be set, otherwise UDP tunnelling would not
be meaningful.
Both the MN and the FA SHOULD set the ’T’ bit when requesting MIP UDP
tunnelling, even if not all traffic will be reverse tunnelled. This
ensures that a HA which is not prepared to accept reverse tunnelling
will not accept a registration which may later turn out to be
unusable. Also see the discussion of use of the ’T’ bit in Foreign
Agent Considerations (Section 4.5).
3.2 UDP Tunnel Reply Extension
This extension is a non-skippable extension. It is sent in reply to
a UDP Tunnel Request extension, and indicates whether or not the HA
will use MIP UDP tunnelling for the current mobility binding. The
format of this extension is as shown below.
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
|
Length
|
Sub-Type
| Reply Code
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|
Reserved
|
Keepalive Interval
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
44
Length
6. Length in bytes of this extension, not
including the Type and Length bytes.
Sub-Type
0
Reply Code
Indicates whether the HA assents or declines
to use UDP tunnelling for the current mobility
binding. See Section 3.2.1 below.
Levkowetz & Vaarala
Standards Track
[Page 9]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
F
F (Forced) flag. Indicates that tunnelling is
being forced because the F flag was set in the
tunnelling request, irrespective of the
detection of a NAT or not.
Keepalive Interval
Specifies the NAT keepalive interval that the
mobile node SHOULD use. A keepalive packet
SHOULD be sent if Keepalive Interval seconds
have elapsed without any signalling or data
traffic being sent. If this field is set to
0, the mobile node MUST use its default
configured keepalive interval.
Reserved
Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
3.2.1 Reply Code
The Reply Code field of the UDP Tunnel Reply Extension indicates if
UDP tunnelling have been accepted and will be used by the HA. Values
in the range 0 .. 63 indicate assent, i.e., that tunnelling will be
done, while values in the range 64 .. 255 indicate that tunnelling
should not be done. More information may be given by the value of
the response code.
The following response codes are defined for use in the code field of
the UDP Tunnel Reply Extension:
0
Will do tunnelling
64
Tunnelling declined, reason unspecified
3.3 MIP Tunnel Data Message
This MIP message header serves to differentiate traffic tunnelled
through the well-known port 434 from other Mobile IP messages, e.g.,
Registration Requests and Registration Replies.
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
| Next Header |
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
Levkowetz & Vaarala
4
Standards Track
[Page 10]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
Next Header
Indicates the type of tunnelled data, using
the same numbering as the IP Header Protocol
Field.
Reserved
Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
The Next Header field uses the same values as the IP header Protocol
field. Immediately relevant for use with Mobile IP are the following
values:
4
IP header (IP-in-UDP tunnelling) RFC 2003 [4]
47
GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]
55
Minimal IP encapsulation header RFC 2004 [5]
The receiver of a tunnelled packet MUST check that the Next Header
value matches the tunnelling mode established for the mobility
binding with which the packet was sent. If a discrepancy is
detected, the packet MUST be dropped. A log entry MAY be written,
but in this case the receiver SHOULD ensure that the amount of log
entries written is not excessive.
In addition to the encapsulation forms listed above, the MIP UDP
tunnelling can potentially support other encapsulations, by use of
the Next Header field in the MIP Tunnel Data Header and the
Encapsulation Header field of the UDP Tunnel Request Extension
(Section 3.1).
3.4 UDP Tunnelling Flag in Agent Advertisements
The only change to the Mobility Agent Advertisement Extension defined
in RFC 3344 [10] is a flag indicating that the foreign agent
generating the Agent Advertisement supports MIP UDP Tunnelling. The
flag is inserted after the flags defined in [10].
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
|
Length
|
Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Lifetime
|R|B|H|F|M|G|r|T|U|
reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
zero or more Care-of Addresses
|
|
...
|
Levkowetz & Vaarala
Standards Track
[Page 11]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
The flag is defined as follows:
U
UDP Tunnelling support. This Agent supports MIP UDP Tunnelling
as specified in this document. This flag SHOULD be set in
advertisements sent by a foreign agent which supports MIP UDP
tunnelling and is situated behind a NAT. It MUST NOT be set in
advertisements from foreign agents which are not situated
behind a NAT, and thus has no need to advertise the capability.
3.5 New Registration Reply Codes
One new registration reply code is defined:
ERROR_HA_UDP_ENCAP_UNAVAIL
Requested UDP tunnel encapsulation
unavailable
This is used by the HA to distinguish the registration denial caused
by an unavailable UDP tunnel encapsulation mode from a denial caused
by unavailable standard tunnel encapsulation requested by use of the
’T’ bit together with either ’M’ or ’G’ bit.
4. Protocol Behaviour
4.1 Relation to standard MIP tunnelling
The default encapsulation mode for MIP UDP tunnelling is IP-in-UDP
encapsulation. The mobile node MAY request alternative forms of
encapsulation to be used with UDP tunnelling by setting the ’M’ bit
and/or the ’G’ bit of a Mobile IP registration request, or by
explicitly requesting a particular encapsulation for the MIP UDP
tunnel by using the Encapsulation field. The M and G bits retain the
meaning as described in RFC 3344 [10] within the context of MIP UDP
tunnelling. The UDP tunnelling version of the classic MIP
encapsulation methods can be summarised as:
IP in UDP. When Mobile IP UDP tunnelling is used, this is the
default encapsulation type. Any home agent and mobile node that
implements Mobile IP UDP tunnelling MUST implement this
encapsulation type.
GRE in UDP. If the ’G’ bit is set in a registration request and
the Encapsulation field is zero, the mobile node requests that its
home agent use GRE encapsulation [3] for datagrams tunnelled to
the mobile node. If MIP UDP tunnelling is also requested and
accepted, GRE-in-UDP encapsulation SHALL be used in the same cases
as GRE in IP encapsulation would be used if the MIP UDP tunnelling
had not been requested.
Levkowetz & Vaarala
Standards Track
[Page 12]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
Minimal encapsulation in UDP. If the ’M’ bit is set and the
Encapsulation field is zero, the mobile node requests that its
home agent use minimal encapsulation [5] for datagrams tunnelled
to the mobile node. If MIP UDP tunnelling is also used, minimal
encapsulation in UDP SHALL be used in the same cases as minimal
encapsulation according to RFC 2004 [5] would be used if the MIP
UDP tunnelling had not been requested.
When the Encapsulation field is non-zero, a particular encapsulation
format is requested for the MIP UDP tunnel. If tunnelling is
indicated, the request MUST either be accepted using the requested
encapsulation, or rejected with the error code
ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation
unavailable" defined in Section 3.5. On receipt of this error, the
mobile node MAY choose to send a new Registration Request with
different requirements on MIP UDP tunnelling encapsulation.
4.2 Encapsulating IP Headers in UDP
MIP IP-in-UDP tunnelling, or UDP tunnelling for short, is done in a
manner analogous to that described for IP-in-IP tunnelling in RFC
2003 [4], with the exception of the addition of an UDP header [1] and
MIP Message header [10] between the outer and inner IP header.
Mobile IP Registration Requests and Registration Replies are already
in the form of UDP messages, and SHALL NOT be tunnelled even when MIP
IP-in-UDP tunnelling is in force.
Levkowetz & Vaarala
Standards Track
[Page 13]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
To encapsulate an IP datagram using MIP IP-in-UDP encapsulation, an
outer IP header [2], UDP header [1] and MIP Message header [10] is
inserted before the datagram’s existing IP header, as follows:
+---------------------------+
|
|
|
Outer IP Header
|
+---------------------------+
|
|
|
UDP Header
|
+---------------------------+
|
MIP Tunnel Data
|
|
Message Header
|
+---------------------------+
+---------------------------+
|
|
|
|
|
IP Header
|
|
IP Header
|
+---------------------------+ ====> +---------------------------+
|
|
|
|
|
IP Payload
|
|
IP Payload
|
|
|
|
|
|
|
|
|
+---------------------------+
+---------------------------+
The outer IP header Source Address and Destination Address, together
with the UDP header Source Port and Destination Port, identify the
"endpoints" of the tunnel. The inner IP header Source Address and
Destination Addresses identify the original sender and the recipient
of the datagram, respectively. The inner IP header is not changed by
the encapsulator, except to decrement the TTL by one if the
tunnelling is being done as part of forwarding the datagram as noted
in RFC 2003 [4], and remains unchanged during its delivery to the
tunnel exit point. No change to IP options in the inner header
occurs during delivery of the encapsulated datagram through the
tunnel. Note that the security options of the inner IP header MAY
affect the choice of security options for the encapsulating (outer)
IP header.
Minimal Encapsulation and GRE encapsulation is done in an analogous
manner, following RFC 2004 [5] for Minimal Encapsulation and RFC 2784
[8] for GRE Encapsulation, but using outer IP, UDP and MIP headers in
place of the outer IP header.
All other provisions and requirements of RFC 2003 [4] and RFC 3024
[9] are in force, except in one respect, as covered in Packet
Fragmentation (Section 4.8).
Levkowetz & Vaarala
Standards Track
[Page 14]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
4.3 Decapsulation
Before decapsulation is actually done, the decapsulating node MUST
verify that the outer IP addresses and UDP port numbers exactly match
the values used for the tunnel, with the exception of tunnels that
are "half bound" (as described in Section 4.11) where the source UDP
port can change.
IP-in-UDP encapsulated traffic is decapsulated simply by stripping
off the outer IP, UDP and MIP header, which leaves the original IP
packet which is forwarded as is.
Minimal IP encapsulation is processed by the receiver conceptually as
follows. First, the UDP and the Mobile IP headers are removed from
the packet, and the Protocol field of the IP header replaced with the
Next Header field in the MIP Tunnel Data header. Second, the
remaining IP header total length and checksum are adjusted to match
the stripped packet. Third, ordinary minimal IP encapsulation
processing is done.
GRE encapsulated traffic is processed according to RFC 2784 [8] and
RFC 1701 [3], with the delivery header consisting of the outer IP,
UDP and MIP headers.
4.4 Mobile Node Considerations
The UDP Tunnel Request Extension MAY be used in a Mobile IP
Registration Request from the mobile node to the home agent when the
mobile node uses a co-located care-of address. It SHALL NOT be used
by the mobile node when it is registering with a foreign agent careof address.
The purpose of this extension is to indicate to the home agent that
the mobile node is able to accept MIP UDP tunnelling if the home
agent has an indication that the mobile node resides behind a NAT or
NAPT. It thus functions as a conditional solicitation for the use of
MIP UDP tunnelling.
As per Section 3.2 and 3.6.1.3 of RFC 3344 [10], the mobile node MUST
place this Extension before the Mobile-Home Authentication Extension
in registration messages, so that it is covered by the Mobile-Home
Authentication Extension.
If the mobile node includes the UDP Tunnel Request extension in a
registration request, but receives a registration reply without a UDP
Tunnel Reply extension, it MUST assume that the HA does not
Levkowetz & Vaarala
Standards Track
[Page 15]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
understand this extension, and it MUST NOT use UDP tunnelling. If
the mobile node is in fact behind a NAT, the registration may then
succeed, but traffic will not be able to traverse the NAT.
When the mobile node sends MIP UDP tunnelled data, it MUST use the
same UDP source port as was used for the most recent registration
request.
When the mobile node re-registers without having moved, it SHOULD
take care to use the same source port as was used for the original
registration of the current mobility binding. Otherwise, while the
home agent would change destination port on acceptance of the new
registration, and the mobile node would presumably start listening on
the new port, the packets in flight from the home agent at the time
of change will be dropped when arriving at the mobile node’s old
port. (This does not mean that the home agent should refuse a
registration request using MIP UDP tunnelling where a new port have
been used, as this might be the result of the NAT dropping state, the
mobile node re-booting, changing interface, etc.)
If a mobile node is registering through a foreign agent but using a
co-located care-of address, and the agent advertisement from the
foreign agent had the ’U’ bit set, the mobile node MUST set the ’R’
flag in its UDP Tunnel Request Extension, in order to make the HA use
MIP UDP tunnelling. In this case, the mobile node also MUST send a
keepalive as soon as its registration has been accepted.
If a mobile node is registering through a foreign agent but using a
co-located care-of address, and the agent advertisement from the
foreign agent does not have the ’U’ bit set, the mobile node MUST NOT
include a UDP Tunnel Request Extension in the registration request.
4.5 Foreign Agent Considerations
The UDP Tunnel Request Extension MAY be used by a foreign agent when
it is forwarding a Mobile IP Registration Request to a home agent,
when the foreign agent is situated behind a NAT or has some other
compelling reason to require MIP UDP tunnelling.
The purpose of this extension is to indicate to the home agent that
the foreign agent is able to accept MIP UDP tunnelling if the home
agent has an indication that the foreign agent resides behind a NAT
or NAPT. It thus functions as a conditional solicitation for the use
of MIP UDP tunnelling.
A foreign agent which requires the mobile node to register through a
foreign agent by setting the ’R’ bit in the agent advertisement, MUST
NOT add the UDP Tunnel Request Extension when forwarding a
Levkowetz & Vaarala
Standards Track
[Page 16]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
registration request which uses a co-located care-of address, as this
will lead to a UDP tunnel being set up from the home agent to the
foreign agent instead of to the mobile node.
As per Section 3.2 and 3.7.2.2 of RFC 3344 [10], the foreign agent
when using this extension MUST place it after the Mobile-Home
Authentication Extension in registration messages. If the foreign
agent shares a mobility security association with the home agent and
therefore appends a Foreign-Home Authentication Extension, the UDP
Tunnel Request Extension MUST be placed before the Foreign-Home
Authentication Extension.
As the home agent detects the presence of a NAT in the path between
the sender and itself by seeing a mismatch between the IP source
address and the care-of address given in the registration request, it
is REQUIRED that the foreign agent, when using this extension, sends
the registration request with an IP source address matching the
care-of address.
A foreign agent using MIP UDP tunnelling to a home agent because the
FA is situated behind a NAT may be configured to encourage reverse
tunnelling, or be neutral about it, depending on the characteristics
of the NAT. If the NAT translates all source addresses of outgoing
packets to its own public address, it will not be possible to
maintain sessions when moving away from this network if the mobile
node has used triangular routing instead of reverse tunnelling. On
the other hand, if it is known that the NAT is smart enough to not
translate publicly routable source addresses, AND does not do ingress
filtering, triangular routing may succeed. The leg from the home
agent to the foreign agent will still use MIP UDP tunnelling to pass
through the NAT.
Therefore, if it is known when configuring a foreign agent behind a
NAT that the NAT will translate public as well as private addresses,
or it is known that ingress filtering is being done between the
private and public networks, the foreign agent SHOULD reply to
registration requests which don’t have the ’T’ bit set with a reply
code 75, "reverse tunnel is mandatory and ’T’ bit not set".
Conversely, if it is known that the NAT is smart about not
translating public addresses, and no ingress filtering is done, so it
is reasonable to believe that a mobile node with a publicly routable
address may be able to keep up sessions when moving to or from this
network, the foreign agent MAY be configured to forward registration
requests even if they don’t have the ’T’ bit set.
Levkowetz & Vaarala
Standards Track
[Page 17]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
If the behaviour of the NAT is unknown in this respect, it SHOULD be
assumed that it will translate all addresses, thus the foreign agent
SHOULD be configured to reply to registration requests which don’t
have the ’T’ bit set with a reply code 75, "reverse tunnel is
mandatory and ’T’ bit not set".
4.6 Home Agent Considerations
The purpose of the MIP UDP Tunnel Reply Extension is to indicate
whether or not the home agent accepts the use of MIP UDP tunnelling
for this mobility binding, and to inform the mobile node or foreign
agent of the suggested tunnel keepalive interval to be used.
The UDP Tunnel Reply Extension MUST be used in a Mobile IP
Registration Reply from the home agent to the mobile node when it has
received and accepted a UDP Tunnel Request (Section 3.1) from a
mobile node.
The home agent MUST use a mismatch between source IP address and
care-of address in the Mobile IP Registration Request message as the
indication that a mobile node may reside behind a NAT. If the
Registration Request also contains the UDP Tunnel Request extension
without the ’R’ flag set, and the home agent is capable of, and
permits MIP UDP tunnelling, the home agent SHALL respond with a
registration reply containing an assenting UDP Tunnel Reply Extension
as described in Section 3.2. If the ’R’ flag is set, special
considerations apply, as described below.
If the home agent receives a Registration Request with matching
source IP address and co-located care-of address which contains a MIP
UDP Tunnel Request Extension, the home agent SHOULD respond with a
Registration Reply containing a declining UDP Tunnel Reply - unless
tunnelling has been explicitly requested by the mobile node using the
’F’ flag as described in Section 3.1.
If the home agent assents to UDP tunnelling, it MUST use the source
address of the registration request as the effective care-of address,
rather than the care-of address given in the registration request,
except in the case where the ’R’ flag is set in the UDP Tunnel
Request Extension.
If the home agent receives a Registration Request with the ’R’ flag
set in the UDP Tunnel Request Extension, it SHOULD reply with an
assenting UDP Tunnel Reply Extension if it is capable of, and permits
MIP UDP tunnelling. In this case, however, the source address and
port of the registration request may be a NAT’ed version of the
foreign agent source address and port. In order to direct tunnelled
traffic correctly to the mobile node, the home agent MUST wait for
Levkowetz & Vaarala
Standards Track
[Page 18]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
the first keepalive packet from the mobile node to arrive, before it
can send traffic back to the correct NAT port (the one which is
mapped to the MN). In this case, the home agent MUST check that the
outer source address (but not the port) of this keepalive packet is
identical with the source address of the corresponding registration
request. The inner source address (that of the encapsulated ICMP
echo request) MUST be the home address of the mobile node, and the
inner destination address MUST be that of the home agent. If all
this holds, the outer source address and port of this keepalive
packet SHALL be used by the HA as the outer destination address and
port of the MIP UDP tunnel when forwarding traffic to the mobile
node.
The home agent SHOULD be consistent in acknowledging support for UDP
tunnelling or not. A home agent which understands the UDP Tunnel
Request Extension and is prepared to respond positively to such a
request SHOULD also respond with a UDP Tunnel Reply Extension
containing a declining reply code if use of MIP UDP tunnelling is not
indicated for a session. The mobile node MUST NOT assume such
behaviour from the home agent, since the home agent may undergo a
software change with reboot, a policy change or a replacement; and
consequently a change of behaviour.
4.6.1 Error Handling
The following actions take place when things go wrong.
The HA does not support the UDP Tunnel Request extension:
The home agent ignores the extension and proceeds normally, which
would be to refuse the registration if the IP source address does
not match the care-of address, the home address or 0.0.0.0. Even
if the HA mistakenly does accept the registration, the mobile node
will not be able to receive forward tunnelled data if it is behind
a NAT.
(It would be beneficial to have the mobile node de-register in
this case. The mobile node, however, normally has no way of
telling that it is behind a NAT if it does not receive a UDP
Tunnelling Reply.)
NAT detected by home agent, but traversal not allowed:
In some cases the home agent may disable NAT traversal even though
it supports the UDP Tunnel Request extension and a NAT is
detected. In this case, the home agent SHOULD send a Registration
Reply with the Code field set to 129, "administratively
prohibited".
Levkowetz & Vaarala
Standards Track
[Page 19]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
NAT not detected, ’F’ flag set, but home agent does not allow forced
use of MIP UDP tunnelling:
The home agent SHOULD send a Registration Reply with the Code
field set to 129, "administratively prohibited".
UDP Tunnel Request extension sent by the mobile node (placed before
the MN-HA authentication extension), but ’D’ bit in registration
request header not set:
The home agent SHOULD send a Registration Reply with the Code
field set to 134, "poorly formed Request".
UDP Tunnel Request extension sent by the foreign agent (placed after
the MN-HA authentication extension), but ’D’ bit is set:
The home agent SHOULD send a Registration Reply with the Code
field set to 134, "poorly formed Request".
Reserved 3 field of UDP Tunnel Request extension is nonzero:
The home agent SHOULD send a Registration Reply with the Code
field set to 134, "poorly formed Request".
Encapsulation type requested in UDP Tunnel Request extension is
unsupported:
The home agent SHOULD send a Registration Reply with the Code
field set to ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel
encapsulation unavailable" defined in Section 3.5.
4.7 MIP signalling versus tunnelling
UDP tunnelling SHALL be used only for data packets, and only when the
mobility binding used for sending was established using the UDP
Tunnel Request, and accepted by an UDP Tunnel Reply from the home
agent. After MIP UDP tunnelling has been established for a mobility
binding, data packets that are forward or reverse tunnelled using
this mobility binding MUST be tunnelled using MIP UDP tunnelling, not
IP-in-IP tunnelling or some other tunnelling method.
As a consequence:
-
Mobile IP signalling is never tunnelled.
-
When using simultaneous bindings, each binding may have a
different type (i.e., UDP tunnelling bindings may be mixed with
non-UDP tunnelling bindings).
Levkowetz & Vaarala
Standards Track
[Page 20]
APPENDIX Z
RFC 3519
-
NAT Traversal for Mobile IP
April 2003
Tunnelling is only allowed for the duration of the binding
lifetime.
4.8 Packet fragmentation
From RFC 3022 [12]:
"Translation of outbound TCP/UDP fragments (i.e., those originating
from private hosts) in NAPT set-up are doomed to fail. The reason is
as follows. Only the first fragment contains the TCP/UDP header that
would be necessary to associate the packet to a session for
translation purposes. Subsequent fragments do not contain TCP/UDP
port information, but simply carry the same fragmentation identifier
specified in the first fragment. Say, two private hosts originated
fragmented TCP/UDP packets to the same destination host. And, they
happened to use the same fragmentation identifier. When the target
host receives the two unrelated datagrams, carrying same
fragmentation id, and from the same assigned host address, it is
unable to determine which of the two sessions the datagrams belong
to. Consequently, both sessions will be corrupted."
Because of this, if the mobile node or foreign agent for any reason
needs to send fragmented packets, the fragmentation MUST be done
prior to the encapsulation. This differs from the case for IP-in-IP
tunnelling, where fragmentation may be done before or after
encapsulation, although RFC 2003 [4] recommends doing it before
encapsulation.
A similar issue exists with some firewalls, which may have rules that
only permit traffic on certain TCP and UDP ports, and not arbitrary
outbound (or inbound) IP traffic. If this is the case and the
firewall is not set to do packet reassembly, a home agent behind a
firewall will also have to do packet fragmentation before MIP UDP
encapsulation. Otherwise, only the first fragment (which contains
the UDP header) will be allowed to pass from the home agent out
through the firewall.
For this reason, the home agent SHOULD do packet fragmentation before
it does MIP UDP encapsulation.
4.9 Tunnel Keepalive
As the existence of the bi-directional UDP tunnel through the NAT is
dependent on the NAT keeping state information associated with a
session, as described in RFC 2663 [11], and as the NAT may decide
that the session has terminated after a certain time, keepalive
messages may be needed to keep the tunnel open. The keepalives
should be sent more often than the timeout value used by the NAT.
Levkowetz & Vaarala
Standards Track
[Page 21]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
This timeout may be assumed to be a couple of minutes, according to
RFC 2663 [11], but it is conceivable that shorter timeouts may exist
in some NATs.
For this reason the extension used to set up the UDP tunnel has the
option of setting the keepalive message interval to another value
than the default value, see Section 3.2.
The keepalive message sent MUST consist of a properly UDP
encapsulated ICMP echo request directed to the home agent.
For each mobility binding which has UDP tunnelling established, the
non-HA endpoint of the Mobile-IP UDP tunnel MUST send a keepalive
packet if no other packet to the HA has been sent in K seconds. Here
K is a parameter with a default value of 110 seconds. K may be set
to another value by the HA as described in the UDP tunnelling reply
extension (Section 3.2).
Except for the case where the mobile node registers with a co-located
address through an FA (see Section 4.11) MIP UDP tunnelling is done
using the same ports that have already been used for the registration
request / reply exchange. The MN or FA will send its first keepalive
message at the earliest K seconds after the registration request was
sent. The same UDP source port MUST be used for the keepalive
messages as was used for the original Registration Messages and for
data messages.
The remote UDP tunnel endpoint MUST use two-way keepalives consisting
of UDP encapsulated ICMP Echo Request/Reply messages. The rationale
for using two-way keepalives is two-fold:
1. Two-way keepalives allow the mobile node to detect loss of a NAT
mapping. Detection of NAT mapping loss in turn allows the MN to
compensate by re-registering and using a shorter keepalive to
avoid loss of NAT mappings in the future.
2. One-way keepalives (keepalives sent by MN or FA, but without any
reply from the home agent) actually cause more keepalive traffic
overhead; the keepalive messages have to be sent more frequently
to compensate for occasional loss of keepalive messages. In
contrast, two-way keepalives are acknowledged, and retransmissions
occur only when a response is not received for a keepalive request
within a reasonable time.
4.10 Detecting and compensating for loss of NAT mapping
When a mobile node is using UDP encapsulated ICMP Echo Request/Reply
messages as keepalives, it will have to deal with the possibility
Levkowetz & Vaarala
Standards Track
[Page 22]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
that a NAT mapping is lost by a NAT device. The crucial thing here
is of course not the loss of the NAT mapping in itself; but rather
that the home agent, in the absence of a Registration Request through
the new mapping, will continue to send traffic to the NAT port
associated with the old mapping.
If the mobile node does not get a reply to its UDP encapsulated ICMP
Echo Request even after a number of retransmissions, and is still
connected to the same router that was used to establish the current
mobility binding, the mobile node SHOULD re-register with the home
agent by sending an Registration Request. This lets the HA know
about the new NAT mapping and restores connectivity between mobile
node and home agent.
Having established a new mobility binding, the mobile node MAY use a
shorter keepalive interval than before the NAT mapping was lost; in
particular, the mobile node MAY deviate from the keepalive interval
assigned by the home agent. If the binding loss continues to occur,
the mobile node may shorten the keepalive interval each time it reregisters, in order to end up with a keepalive interval that is
sufficient to keep the NAT mapping alive. The strategy used to
arrive at a keepalive interval when a NAT mapping is lost is
implementation dependent. However, the mobile node MUST NOT use a
keepalive less than 10 seconds.
Note that the above discussion only applies when the mobile node is
re-registering through the same router, and thus presumably through
the same NAT device that lost a NAT mapping earlier. If the MN moves
and still finds itself behind a NAT, it SHOULD return to its original
keepalive interval (the default value, or as assigned by the home
agent) and it SHOULD NOT do any keepalive interval compensation
unless it discovers a loss of NAT mapping in the new environment.
The home agent MUST NOT attempt to detect or compensate for NAT
binding loss by dynamically changing the keepalive interval assigned
in the Registration Reply; the home agent does not have enough
information to do this reliably and should thus not do it at all.
The mobile node is in a much better position to determine when a NAT
mapping has actually been lost. Note also that a MN is allowed to
let a NAT mapping expire if the MN no longer needs connectivity.
The discussion above does only in a limited sense apply to a foreign
agent which is situated behind a NAT and using MIP UDP tunnelling.
In this case, it is a matter of permanently configuring the FA to use
a keepalive interval which is lower than the NAT mapping lifetime,
rather than trying to dynamically adapt to the binding lifetimes of
different NATs.
Levkowetz & Vaarala
Standards Track
[Page 23]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
4.11 Co-located registration through FA
This section summarizes the protocol details which have been
necessary in order to handle and support the case when a mobile node
registers with a co-located address through a foreign agent, due to
the FA advertisements having the ’R’ bit set. It gives background
information, but lists no new requirements.
When a mobile registers a co-located care-of address through an FA,
the registration request which reaches the HA will have a different
care-of address in the registration request compared to the source
address in the registration request IP-header. If the registration
request also contains a UDP Tunnel Request Extension, the HA will
erroneously set up a UDP tunnel, which will go to the FA instead of
the MN. For this reason, as mentioned in Section 4.4, the mobile
node must not include a UDP Tunnel Request Extension in the
registration if it is registering a co-located address through an FA
which does not have the ’U’ bit set in its advertisements.
In order to still be able to use MIP UDP tunnelling in this case,
foreign agents which are situated behind a NAT are encouraged to send
advertisements which have the ’U’ bit set, as described in Section
3.4.
If the FA advertisement has the ’U’ bit set, indicating that it is
behind a NAT, and also the ’R’ bit set, and the mobile node wishes to
use a co-located care-of address, it MUST set the ’R’ flag in the UDP
Tunnel Request Extension, in order to inform the HA of the situation
so that it may act appropriately, as described in Section 4.4.
Because the UDP tunnel is now taking another path than the
registration requests, the home agent, when handling registrations of
this type, must wait till the arrival of the first keepalive packet
before it can set up the tunnel to the correct address and port. To
reduce the possibility of tunnel hijacking by sending a keepalive
with a phony source address, it is required that only the port of the
keepalive packet may be different from that of the registration
request; the source address must be the same. This means that if the
FA and MN are communicating with the HA through different NATs, the
connection will fail.
5. Implementation Issues
5.1 Movement Detection and Private Address Aliasing
In providing a mobile node with a mechanism for NAT traversal of
Mobile IP traffic, we expand the address space where a mobile node
may function and acquire care-of addresses. With this comes a new
Levkowetz & Vaarala
Standards Track
[Page 24]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
problem of movement detection and address aliasing. We here have a
case which may not occur frequently, but is mentioned for
completeness:
Since private networks use overlapping address spaces, they may be
mistaken for one another in some situations; this is referred to as
private address aliasing in this document. For this reason, it may
be necessary for mobile nodes implementing this specification to
monitor the link layer address(es) of the gateway(s) used for sending
packets. A change in the link layer address indicates probable
movement to a new network, even if the IP address remains reachable
using the new link layer address.
For instance, a mobile node may obtain the co-located care-of address
10.0.0.1, netmask 255.0.0.0, and gateway 10.255.255.254 using DHCP
from network #1. It then moves to network #2, which uses an
identical addressing scheme. The only difference for the mobile node
is the gateway’s link layer address. The mobile node should store
the link layer address it initially obtains for the gateway (using
ARP, for instance). The mobile node may then detect changes in the
link layer address in successive ARP exchanges as part of its
ordinary movement detection mechanism.
In rare cases the mobile nodes may not be able to monitor the link
layer address of the gateway(s) it is using, and may thus confuse one
point of attachment with another. This specification does not
explicitly address this issue. The potential traffic blackout caused
by this situation may be limited by ensuring that the mobility
binding lifetime is short enough; the re-registration caused by
expiration of the mobility binding fixes the problem (see Section
5.2).
5.2 Mobility Binding Lifetime
When responding to a registration request with a registration reply,
the home agent is allowed to decrease the lifetime indicated in the
registration request, as covered in RFC 3344 [10]. When using UDP
tunnelling, there are some cases where a short lifetime is
beneficial.
First, if the NAT mapping maintained by the NAT device is dropped, a
connection blackout will arise. New packets sent by the mobile node
(or the foreign agent) will establish a new NAT mapping, which the
home agent will not recognize until a new mobility binding is
established by a new registration request.
A second case where a short lifetime is useful is related to the
aliasing of private network addresses. In case the mobile node is
Levkowetz & Vaarala
Standards Track
[Page 25]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
not able to detect mobility and ends up behind a new NAT device (as
described in Section 5.1), a short lifetime will ensure that the
traffic blackout will not be exceedingly long, and is terminated by a
re-registration.
The definition of "short lifetime" in this context is dependent on
the requirements of the usage scenario. Suggested maximum lifetime
returned by the home agent is 60 seconds, but in case the
abovementioned scenarios are not considered a problem, longer
lifetimes may of course be used.
6. Security Considerations
The ordinary Mobile IP security mechanisms are also used with the NAT
traversal mechanism described in this document. However, there is
one noticeable change: the NAT traversal mechanism requires that the
HA trust unauthenticated address (and port) fields possibly modified
by NATs.
Relying on unauthenticated address information when forming or
updating a mobility binding leads to several redirection attack
vulnerabilities. In essence, an attacker may do what NATs do, i.e.,
modify addresses and ports and thus cause traffic to be redirected to
a chosen address. The same vulnerabilities apply to both MN-HA and
FA-HA NAT traversal.
In more detail: without a NAT, the care-of address in the
registration request will be directly used by the HA to send traffic
back to the MN (or the FA), and the care-of address is protected by
the MN-HA (or FA-HA) authentication extension. When communicating
across a NAT, the effective care-of address from the HA point of view
is that of the NAT, which is not protected by any authentication
extension, but inferred from the apparent IP source address of
received packets. This means that by using the mobile IP
registration extensions described in this document to enable
traversal of NATs, one is opening oneself up to having the care-of
address of a MN (or a FA) maliciously changed by an attacker.
Some, but not all, of the attacks could be alleviated to some extent
by using a simple routability check. However, this document does not
specify such a mechanism for simplicity reasons and because the
mechanism would not protect against all redirection attacks. To
limit the duration of such redirection attacks, it is RECOMMENDED to
use a conservative (that is, short) mobility binding lifetime when
using the NAT traversal mechanism specified in this document.
The known security issues are described in the sections that follow.
Levkowetz & Vaarala
Standards Track
[Page 26]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
6.1 Traffic Redirection Vulnerabilities
6.1.1 Manipulation of the Registration Request Message
An attacker on the route between the mobile node (or foreign agent)
and the home agent may redirect mobility bindings to a desired
address simply by modifying the IP and UDP headers of the
Registration Request message. Having modified the binding, the
attacker no longer needs to listen to (or manipulate) the traffic.
The redirection is in force until the mobility binding expires or the
mobile node re-registers.
This vulnerability may be used by an attacker to read traffic
destined to a mobile node, and to send traffic impersonating the
mobile node. The vulnerability may also be used to redirect traffic
to a victim host in order to cause denial-of-service on the victim.
The only defense against this vulnerability is to have a short time
between re-registrations, which limits the duration of the
redirection attack after the attacker has stopped modifying
registration messages.
6.1.2 Sending a Bogus Keepalive Message
When registering through an FA using a co-located care-of address,
another redirection vulnerability opens up. Having exchanged
Registration Request/Reply messages with the HA through the FA, the
MN is expected to send the first keepalive message to the HA, thus
finalizing the mobility binding (the binding will remain in a "half
bound" state until the keepalive is received).
Having observed a Registration Request/Reply exchange, an attacker
may send a bogus keepalive message assuming that the mobility binding
is in the "half bound" state. This opens up a similar redirection
attack as discussed in Section 6.1.1. Note, however, that the
attacker does not need to be able to modify packets in flight; simply
being able to observe the Registration Request/Reply message exchange
is sufficient to mount the attack.
With this in mind, the home agent MUST NOT accept a keepalive message
from a different source IP address than where the Registration
Request came from, as specified in Section 4.6. This requirement
limits the extent of the attack to redirecting the traffic to a bogus
UDP port, while the IP address must remain the same as in the initial
Registration Request.
Levkowetz & Vaarala
Standards Track
[Page 27]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
The only defenses against this vulnerability are: (1) to have a short
time between re-registrations, which limits the duration of the
redirection attack after the attacker has stopped sending bogus
keepalive messages, and (2) to minimize the time the binding is in a
"half bound" state by having the mobile node send the first keepalive
message immediately after receiving an affirmative registration
reply.
6.2 Use of IPsec
If the intermediate network is considered insecure, it is recommended
that IPsec be used to protect user data traffic. However, IPsec does
not protect against the redirection attacks described previously,
other than to protect confidentiality of hijacked user data traffic.
The NAT traversal mechanism described in this document allows all
IPsec-related traffic to go through NATs without any modifications to
IPsec. In addition, the IPsec security associations do not need to
be re-established when the mobile node moves.
6.3 Firewall Considerations
This document does not specify a general firewall traversal
mechanism. However, the mechanism makes it possible to use only a
single address and a port for all MN-HA (or FA-HA) communication.
Furthermore, using the same port for the MIP UDP tunnelled traffic as
for control messages makes it quite probable that if a MIP
registration can reach the home agent, MIP tunnelling and reverse
tunnelling using the described mechanism will also work.
7. UNSAF Considerations
The mechanism described in this document is not an "UNilateral SelfAddress Fixing" (UNSAF) mechanism. Although the mobile node makes no
attempt to determine or use the NAT translated address, the mobile
node through the registration process does attempt to keep the NAT
mapping alive through refresh messages. This section attempts to
address issues that may be raised through this usage through the
framework of the unsaf considerations IAB document [13].
1. Precise definition.
This proposal extends the Mobile IP v4 registration process to
work across intervening NATs. The Home Agent detects the presence
of the NAT by examining the source address in the packet header
and comparing it with the address contained in the registration
message.
Levkowetz & Vaarala
Standards Track
[Page 28]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
The NAT address and port detected by the home agent are not
exported or communicated to any other node anywhere.
2. Exit strategy.
This mechanism will go out of use as IPv6 and Mobile IP v6 is
deployed, obviating the need for MIPv4 NAT traversal.
It can also be noted that this mechanism makes no changes to the
base MIPv4 protocol which makes it dependent on the presence of
NATs or the current extensions - i.e., no additional protocol
changes would be needed if NATs were to go away.
3. Issues making systems more brittle.
The specific issue which is relevant here is that the effective
care-of address (being the source address in the IP header
received by the HA) is not protected by the Mobile IP
authentication extension, and therefore may be spoofed. This is
discussed in some detail in Section 6, Security Considerations.
4. Requirements for longer term solutions.
The trivial long term solution is a transition to an environment
where NATs are not required. The most obvious such environment
would be an IPv6 based internet.
In the presence of NATs, an improved solution would require
*
the ability to discover the translations done by each NAT along
the route
*
the ability to validate the authority of each NAT to do those
translations
*
communicating as part of the signed registration request the
address of the NAT closest to the HA, for use as the effective
care-of address from the viewpoint of the HA.
*
configuration of all intermediate NATs to accept only packets
from the neighbour NATs.
5. Impact on existing, deployed NATs.
One precursor of the mechanism described here has been used
successfully across deployed NATs in Sweden, Germany, England,
Japan and the USA, without necessitating neither adjustments of
the NATs in question, nor adjustment of any protocol parameters.
At the time of writing, little experience exist with the exact
implementation proposed in this document, but effort has been put
into making this mechanism even more robust and adaptive than its
precursors.
Levkowetz & Vaarala
Standards Track
[Page 29]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
With respect to the base Mobile IP specification, the impact of
this document is that an increased frequency of registration
requests is recommended from a security perspective when the NAT
traversal mechanism is used.
8. IANA Considerations
The numbers for the extensions defined in this document have been
taken from the numbering space defined for Mobile IP messages,
registration extensions and error codes defined in RFC 3344 [10].
This document proposes one new message, two new extensions and a new
error code that require type numbers and an error code value that
have been assigned by IANA. The two new extensions also introduce
two new sub-type numbering spaces to be managed by IANA.
Section 3.1 defines a new Mobile IP extension, the UDP Tunnel Request
Extension. The type number for this extension is 144. This
extension introduces a new sub-type numbering space where the value 0
has been assigned to this extension. Approval of new Tunnel Request
Extension sub-type numbers is subject to Expert Review, and a
specification is required [7].
Section 3.2 defines a new Mobile IP extension, the UDP Tunnel Reply
Extension. The type value for this extension is 44. This extension
introduces a new sub-type numbering space where the value 0 has been
assigned to this extension. Approval of new Tunnel Reply Extension
sub-type numbers is subject to Expert Review, and a specification is
required [7].
Section 3.3 defines a new Mobile IP message, the Tunnel Data message.
The type value for this message is 4.
Section 3.5 defines a new error code, ERROR_HA_UDP_ENCAP_UNAVAIL:
"Requested UDP tunnel encapsulation unavailable", from the numbering
space for values defined for use with the Code field of Mobile IP
Registration Reply Messages. Code number 142 has been assigned from
the subset "Error Codes from the Home Agent".
The values for the Next Header field in the MIP Tunnel Data Message
(Section 3.3) shall be the same as those used for the Protocol field
of the IP header [2], and requires no new number assignment.
9. Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights (www.ietf.org/ipr.html).
Levkowetz & Vaarala
Standards Track
[Page 30]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
10. Acknowledgements
Much of the text in Section 4.2 has been taken almost verbatim from
RFC 2003, IP Encapsulation within IP [4].
Adding support for the FA case was suggested by George Tsirtsis and
Frode B. Nilsen. Roy Jose pointed out a problem with binding
updates, and Frode, Roy and George pointed out that there are cases
where triangular routes may work, and suggested that reverse
tunnelling need not be mandatory. Roy and Qiang Zhang drew attention
to a number of sections which needed to be corrected or stated more
clearly.
Phil Roberts helped remove a number of rough edges. Farid Adrangi
pointed out the DoS issue now covered in Security Considerations
(Section 6). Francis Dupont’s helpful comments made us extend the
Security Considerations section to make it more comprehensive and
clear. Milind Kulkarni and Madhavi Chandra pointed out the required
match between the FA source and care-of addresses when the mechanism
is used by an FA, and also contributed a number of clarifications to
the text.
Thanks also to our co-workers, Ilkka Pietikainen, Antti Nuopponen and
Timo Aalto at Netseal and Hans Sjostrand, Fredrik Johansson and Erik
Liden at ipUnplugged. They have read and re-read the text, and
contributed many valuable corrections and insights.
11. Normative References
[1]
Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[2]
Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[3]
Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
Encapsulation (GRE)", RFC 1701, October 1994.
[4]
Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[5]
Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[6]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7]
Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Levkowetz & Vaarala
Standards Track
[Page 31]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
[8]
Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[9]
Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC
3024, January 2001.
[10] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
12. Informative References
[11] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[12] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001.
[13] Daigle, L., Editor, and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF)", RFC 3424, November 2002.
Levkowetz & Vaarala
Standards Track
[Page 32]
APPENDIX Z
RFC 3519
NAT Traversal for Mobile IP
April 2003
13. Authors’ Addresses
Henrik Levkowetz
ipUnplugged AB
Arenavagen 23
Stockholm S-121 28
SWEDEN
Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com
Sami Vaarala
Netseal
Niittykatu 6
Espoo 02201
FINLAND
Phone: +358 9 435 310
EMail: sami.vaarala@iki.fi
Levkowetz & Vaarala
Standards Track
[Page 33]
APPENDIX Z
RFC 3519
14.
NAT Traversal for Mobile IP
April 2003
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.
Levkowetz & Vaarala
Standards Track
[Page 34]
APPENDIX AA
US 20070206527A1
(19) United States
(2) Patent Application Publication (10) Pub. No.: US 2007/0206527 A1
Lo et al.
(43) Pub. Date:
(54) VIRTUAL ACCESS POINT FOR
(57)
Sep. 6, 2007
ABSTRACT
CONFIGURATION OF A LAN
(76) Inventors: Yuan-Chang Lo, Austin, TX (US);
Pratik M. Mehta, Austin, TX (US)
Correspondence Address:
O’KEEFE, EGAN, PETERMAN & ENDERS
LLP
1101 CAPITAL OF TEXAS HIGHWAY SOUTH
#C200
AUSTIN, TX 78746 (US)
(21) Appl. No.:
(22) Filed:
11/365,406
Mar. 1, 2006
Publication Classification
(51) Int. Cl.
H04Q 700
(2006.01)
(52) U.S. Cl. … 370/328
A technique is disclosed for setting up and configuring a
LAN. More particularly, secure communications may be
configured between an access point (AP) and a client device.
Virtual AP technology is utilized to assist the configuration
of the network. In particular, at least two wireless networks
are provided in a single A, a configuration LAN and an
operational LAN, by utilizing virtual AP technology. The
configuration LAN is utilized to provide communication
between the AP and the client devices that is related to
network setup, configuration, modification, etc. and the
operational LAN provides normal LAN data communica
tion. The configuration LAN may be provided in a relatively
insecure manner that eases setup of that communication
channel and the operational LAN may be provided in a more
fully secure communication channel. Different types of
service set identifiers (SSIDs) may be provided for configu
ration LANs and operational LANs so as to more easily
identify the type of LAN through its SSID.
100-,
CLIENT 1
2212"
NETWORK
RESOURCES
112
APPENDIX AA
Patent Application Publication Sep. 6, 2007 Sheet 1 of 3
US 2007/0206527 A1
100s,
2212"
RESOURCES
FIC. 1
110
:i
*
CLIENT 1
112
FIG. 2
CLIENT 2
114
CLIENT 3
116
APPENDIX AA
Patent Application Publication Sep. 6, 2007 Sheet 2 of 3
Access Point
Wireless Client
412 ~~4%
US 2007/0206527 A1
_2-410
420
Initialize
414
- - - -Initialize
416
Operational WLAN
Initialize Wi-Fi
4222 configuration Service
424
Configuration WLAN
418
cº
SS|D?
>
Configuration
426 Configure Wireless
§
428
ASSOCiate With
Configuration
SS|D
434
Setup Tempora
Secure jº
Setup Tempora
§: ?º
Mutual
Authentication
Mutual
Authentication
444
Authentication
Successful?
446
Authentication
Successful?
448
Send settings for
Operational SSID
452
Disassociate the
Y
for Operational SSID
456
DisassociateWLAN
from
Configuration
Insert operational WLAN into
the configuration WLAN from
thé profile store
458-\] the profile store and remove
FIG. 3
460
ASSOCiate with
Operational SSID
Ignore this
SSID
APPENDIX AA
Patent Application Publication Sep. 6, 2007 Sheet 3 of 3
US 2007/0206527 A1
2400
MFG
402
404
FIG. 4
406
APPENDIX AA
Sep. 6, 2007
US 2007/0206527 A1
VIRTUAL ACCESS POINT FOR CONFIGURATION
OF A LAN
TECHNICAL FIELD OF THE INVENTION
[0001] This invention relates to connections between a
wireless local area network (WLAN) client device and a
wireless LAN access point (AP), and more particularly for
setting up and configuring WLAN systems and devices.
BACKGROUND
[0002] Wireless local area networks are most often pro
vided in an AP/Client arrangement. In order to provide
proper data communications between the AP and the client
device, a proper communication protocol must generally be
setup and configured between the devices. The need for
creating a secure communication channel has added to the
complexity of the setup and configuration of the communi
cation channel between the AP and the client device. Typical
security precautions involve both the AP and the client
device being provided with some matching configurations.
The security mechanisms hinder the ease of setup of the AP
and the client device for typical users and often require
manual setup steps of both the AP and the client device.
Further, once a secure network has been configured, modi
fications or changes to the network are additionally difficult.
For example, once a secure network is configured, modifi
cations or changes may require making the network tempo
rarily insecure and/or unavailable for use.
[0003] In order to ease the setup and configuration process
various techniques have been utilized in the past. One group
of techniques relates to out of band communication meth
ods. In such techniques, communication channels outside
the typical communication channel are utilized. For
example, in wireless LANs (WLAN) (such as for example
communications under the IEEE 802.11 standards) tech
niques that utilize USB flash drive and/or cable technology,
or RFID technology to communicate configuration informa
tion between the AP and the client device have been pro
posed.
[0004] Other techniques have included in-band commu
nication using the WLAN channel to exchange configuration
information. Such techniques are known, for example, the
Broadcom SecureEZSetup or Athero JumpStart techniques.
However, such in band communication techniques still
typically include certain dedicated hardware such as buttons,
switches, or LEDs that the user must evaluate or set.
Additionally, the level of security afforded by such mecha
nisms may be lower than desired.
[0005] In general, it would be desirable to provide a more
cost efficient, more secure and more user friendly method for
setting up and configuring communication channels between
AP and client devices, particularly for wireless protocols.
[0006] A wide range of types of systems may benefit from
improved methods of setting up and configuring communi
cation channels between an AP and client device. As the
value and use of information continues to increase, indi
viduals and businesses seek additional ways to process and
store information. One option available to users is informa
tion handling systems. An information handling system
generally processes, compiles, stores, and/or communicates
information or data for business, personal, or other purposes
thereby allowing users to take advantage of the value of the
information. Because technology and information handling
needs and requirements vary between different users or
applications, information handling systems may also vary
regarding what information is handled, how the information
is handled, how much information is processed, stored, or
communicated, and how quickly and efficiently the infor
mation may be processed, stored, or communicated. The
variations in information handling systems allow for infor
mation handling systems to be general or configured for a
specific user or specific use such as financial transaction
processing, airline reservations, enterprise data storage, or
global communications. In addition, information handling
systems may include a variety of hardware and software
components that may be configured to process, store, and
communicate information and may include one or more
computer systems, data storage systems, and networking
systems.
SUMMARY OF THE INVENTION
[0007] A method and system are disclosed for setting up
and configuring a LAN. More particularly, secure commu
nications may be configured between an access point and a
client device. Virtual AP technology is utilized to assist the
configuration of the network. In particular, at least two
wireless networks are provided in a single AP a configura
tion LAN and an operational LAN, by utilizing virtual AP
technology. The configuration LAN is utilized to provide
communication between the AP and the client devices that
is related to network setup, configuration, modification, etc.
and the operational LAN provides normal LAN data com
munication. The configuration LAN may be provided in a
relatively open manner that eases setup of that communica
tion channel and the operational LAN may be provided in a
more fully secure communication channel. Different service
set identifiers (SSIDs) may be provided for configuration
LANs and operational LANs so as to more easily identify
the type of LAN through its SSID.
[0008] In one embodiment, a method of connecting a
client device to an access point is provided. The method may
include utilizing a configuration LAN to provide an initial
connection between the client device and the access point
and switching to an operational LAN to provide a connec
tion between the client device and the access point after the
configuration LAN connection is established. The configu
ration LAN and the operational LAN are configured as
separate LANs and the operational LAN is more secure than
the configuration LAN.
[0009] In another embodiment, a network access point is
disclosed. The network access point may include a configu
ration LAN interface wherein the configuration LAN inter
face communicates configuration traffic for establishing a
connection with a client device, the configuration traffic
having limited logical boundaries to which it may be trans
mitted. The network access point may further include an
operational LAN interface, wherein the operational LAN
interface communicates communication traffic of an opera
tional LAN to the client device, the operational LAN and the
configuration LAN being separate LANs operating through
the network access point. In addition the operational LAN
may be a more secure LAN as compared to the configuration
LAN.
[0010] In another embodiment, an information handling
system is disclosed. The information handling system may
APPENDIX AA
US 2007/0206527 A1
include a wireless access point, a configuration LAN and an
operational LAN. The configuration LAN may process
configuration and setup settings for connecting the wireless
access point and a client device. The configuration LAN and
the operational LAN are both transmitted through the wire
less access point wherein the operational LAN processes
normal LAN traffic between the wireless access point and
the client device. Further logical boundaries are provided
within the information handling system limiting the con
figuration LAN traffic to only a portion of the information
handling system.
[0011] In still another embodiment, a LAN identifier for
mat is disclosed. The format may comprise a plurality of
characters of which a subset of characters identify whether
the LAN is at least one of a configuration LAN or an
operational LAN.
[0012] In still another embodiment, a method of identify
ing a wireless LAN is disclosed. The method may include
generating or receiving a multi-character service set identi
fier value and utilizing at least a portion of the multi
character service set identifier value to identify whether the
wireless LAN is at least one of a configuration LAN or an
operational LAN. The method may be performed in either of
an access point or a client device.
Description of the Drawings
[0013] It is noted that the appended drawings illustrate
only exemplary embodiments of the invention and are,
therefore, not to be considered limiting of its scope, for the
invention may admit to other equally effective embodi
mentS.
[0014] FIG. 1 illustrates a wireless local area network.
[0015] FIG. 2 illustrates an access point supporting both a
configuration LAN and an operational LAN.
[0016] FIG. 3 illustrates an exemplary flowchart for setup
and configuration of a LAN connection utilizing both a
configuration LAN and an operational LAN.
[0017] FIG. 4 illustrates an exemplary SSID format that
includes a MODE field to identify a LAN as a configuration
LAN or an operational LAN.
DETAILED DESCRIPTION OF THE
INVENTION
[0018] As described in more detail below, a technique is
disclosed herein for disclosed for setting up and configuring
a WLAN. More particularly, secure communications may be
configured between an AP and a client device by utilizing
Virtual Access Point (virtual AP) technology. Virtual AP
technology is known to allow the creation of multiple
service set identifiers (SSID) on a single AP For example,
typical WLANs have a unique SSID for each basic service
set (BSS) such that all access points and devices attempting
to connect to the specific LAN utilize the same SSID.
However, virtual AP technology provides multiple SSIDs on
a single AP thus creating multiple wireless virtual LANs
(VLANs). Such techniques have been used to allow multiple
ISPs to share a single AP and to address QoS, load balanc
ing, and bandwidth allocation issues. Typically a client will
be provided access to only one VLAN and not the others
Sep. 6, 2007
[0019] According to the techniques described herein, vir
tual AP technology may be used to aid in the configuration
and setup of an AP and client device. In particular, at least
two wireless networks may be provided for in a single AP
a configuration LAN and an operational LAN utilizing
virtual AP technology. The configuration LAN is utilized to
provide communication between the AP and the client
devices that is related to network setup, configuration,
modification, etc. and the operational LAN provides normal
LAN data communication. The configuration LAN may be
provided in a relatively insecure manner that eases setup of
that communication channel and the operational LAN may
be provided in a more fully secure communication channel.
The techniques described herein beneficially balance cost,
security and ease of use variables.
[0020] More particularly, the configuration LAN and the
operational LAN may each be provided with its own SSID
and security settings. The creation of the virtual APs and
VLANs may be accomplished in firmware and as mentioned
above may utilize a common AP, thus minimizing the need
for additional hardware and the associated costs of such
hardware. Though described herein with reference to an AP
that is configured into two virtual networks, it will be
recognized that the techniques described herein may be
utilized with regard to APs that are configured to support
more than two networks. Further to aid in the understanding
of the concepts described herein, the techniques described
below are discussed with reference to a WLAN (such as the
various common IEEE 802.11 standards), however, with the
benefit of this disclosure it will be recognized that the
concepts described herein are not limited to WLAN appli
cations and may be utilized in other LAN applications.
[0021] In one embodiment, a configuration WLAN may
be utilized between a wireless AP and a wireless client in
which the AP has SSID broadcasting open (or enabled) and
no security protocols turned on. In this manner the configu
ration WLAN would be clearly visible and relatively easy to
connect to even for users that are not technically savvy as the
user would not have to at this point negotiate through the
typically more complex techniques, settings and the like. In
this manner an initial association and authentication may
occur between the AP and the client device. At this point, the
AP and the wireless device may communicate the appropri
ate settings and security parameters to implement connec
tivity between the AP and the client device through the
operational WLAN. When such data has been communi
cated, the configuration WLAN connection between the AP
and the client device may be disassociated and the opera
tional WLAN (with its increased security provisions) may
be associated between the AP and the client device. For
example, the operational WLAN may have SSID broadcast
ing disabled, may utilize security encryption/key protocols,
etc. In this manner initial communication may be established
through the configuration WLAN which to a user provides
an improved ease of use experience and then after the
association of the client and the AP communication may
then be transferred to the operational WLAN. Firmware may
automatically accomplish the transfer to from the configu
ration WLAN to the operational WLAN in a manner that is
seamless to the user. In this manner a client and an AP may
be associated in a manner that allows even unsophisticated
users a desirable ease of use experience yet results in a final
operating communication mode that is relatively secure.
APPENDIX AA
US 2007/0206527 A1
[0022] The configuration WLAN is advantageous in that it
is an in-band communication technique for initial setup and
configuration. Further, the configuration WLAN may be
available for both initial network configuration and also for
subsequent network modifications, additions, etc. Thus, the
configuration WLAN may continue to be utilized to add
additional clients. So as not to limit the available overall
communication resources for normal data communications
between the AP and client devices, the configuration WLAN
may operate at relatively low speeds. This reduces the
system load imposed by the configuration WLAN and
maximizes the bandwidth available for the operation
WLAN.
[0023] Because the configuration WLAN is provided in a
less secure manner that is more easily open and available to
users (and thus potentially more open to abuses and security
breaches), the configuration WLAN is configured to have
limited functionality for configuration purposes only. For
example, the configuration WLAN may be provided so that
all network traffic on the configuration WLAN terminates at
the AP. Thus, the configuration WLAN can not be utilized to
access the internet, other backbone resources of the network
that the AP is connected to, other clients that are connected
to the AP etc. In this manner, overall network security is
maintained. Thus, the configuration WLAN is relatively
easy to “see” and connect to but because it has limited
functional capabilities the network is still relatively secure.
Though described above with reference to the configuration
WLAN terminating at the AP, this is just one example of
how the configuration network may be limited to a logically
bounded area. For example, the logically bounded area of
the configuration network could be broader and include a
router, switch, or other network resource that is coupled to
the AP. Thus, all network traffic would be terminated at such
router, switch or other network resource. In such an
example, the network is constructed in a manner such that
there are some logical boundaries at which configuration
WLAN traffic is terminated, thus providing a level of
security to the overall system outside the bounds of the
logical boundaries of the configuration WLAN.
[0024] FIG. 1 illustrates an exemplary LAN 100 in which
the techniques described herein may be utilized. Some or all
the components of the LAN 100 may, in one example, be a
part of an information handling system. For purposes of this
disclosure, an information handling system may include any
instrumentality or aggregate of instrumentalities operable to
compute, classify, process, transmit, receive, retrieve, origi
nate, switch, store, display, manifest, detect, record, repro
duce, handle, or utilize any form of information, intelli
gence, or data for business, scientific, control, or other
purposes. For example, an information handling system may
be a personal computer, a network storage device, or any
other suitable device and may vary in size, shape, perfor
mance, functionality, and price. The information handling
system may include random access memory (RAM), one or
more processing resources such as a central processing unit
(CPU) or hardware or software control logic, ROM, and/or
other types of nonvolatile memory. Additional components
of the information handling system may include one or more
disk drives, one or more network ports for communicating
with external devices as well as various input and output
(I/O) devices, such as a keyboard, a mouse, and a video
display. The information handling system may also include
Sep. 6, 2007
one or more buses operable to transmit communications
between the various hardware components.
[0025] As shown in FIG. 1 the LAN 100 may include an
AP 110 that is connected to network resources 120 which
may include routers, switches, servers, network clients,
computers, or any other network resources. The AP 110 may
include one or more antennae 111 for communicating with
one or more clients 112, 114, and 116. As mentioned above,
although a WLAN is shown in FIG. 1 to aid the understand
ing of the techniques described herein, it will be recognized
that the techniques will be applicable to a wide variety of
types of LANs.
[0026] FIG. 2 illustrates in more detail an AP 110 which
supports both a configuration WLAN and an operational
WLAN. As shown in FIG. 2, the AP 110 may include logic
and firmware 210 for supporting both an operational WLAN
interface 220 and a configuration WLAN interface 230. Both
the operational interface WLAN 220 and the configuration
interface WLAN 230 may be coupled to the WLAN radio
hardware 240 of the AP 110. Communications received by
the WLAN radio 240 may thus include both configuration
WLAN communications and operational WLAN communi
cations. As the configuration WLAN and the operational
WLAN utilize different SSIDs, communications for the
configuration WLAN may be processed through the con
figuration WLAN interface and communications for the
operational WLAN may be processed through the opera
tional WLAN interface. Firmware or software may be
provided within the access point so as to properly direct
communication traffic to either the configuration WLAN
interface or the operation WLAN interface depending upon
the type of communication traffic. Operational WLAN com
munications may be provided to an Ethernet interface 260
for further communication to the network resources 120.
Though illustrated as an Ethernet connected AP, it will be
recognized that the AP 110 may be connected to the other
network resources through any of a wide range of commu
nication protocols and the Ethernet connection is merely
representative and not required to take advantage of the
techniques described herein. For example, the AP could also
be connected to other network resources through other
connections such as power line networking, phone line
networking, coaxial cable networking, fiber, etc.
[0027] FIG. 2 further illustrates an example of a LAN in
which three client devices 112, 114 and 116 are communi
cating with the AP 110. More or fewer clients may be used
as FIG. 2 is merely meant to illustrate the use of both an
operational WLAN and a configuration WLAN. As shown in
FIG. 2, client devices 112 and 114 are communicating (as
indicated by the dashed lines) in an operational WLAN
mode through the WLAN radio hardware 240 and the
operation WLAN interface 220. Client devices 112 and 114
would have previous been connected to the LAN through a
setup and configuration process (for example, using the
configuration WLAN) and have now been switched over to
the operational WLAN. The client device 116 is shown as
communicating with the configuration WLAN mode
through the WLAN radio hardware 240 and the configura
tion WLAN interface 230. Thus client device 116 is attempt
ing to establish a connection with the LAN. As shown with
respect to FIGS. 1 and 2 the AP may be a designated access
point device. However, it will be recognized that the access
point functionality may be embedded in other devices of an
APPENDIX AA
Sep. 6, 2007
US 2007/0206527 A1
information handling system, such as for example, routers,
switches, servers, computers, etc. and the designation as an
AP is not limited to stand alone AP devices. Furthermore,
though shown in FIG. 2 has utilizing common WLAN radio
hardware, separate dedicated radio hardware could be pro
vide for each of the operation LAN and the configuration
LAN.
[0028] FIG. 3 illustrates an exemplary flowchart of the
setup and configuration process utilizing a configuration
WLAN and the ultimate establishment of communications
over an operational WLAN. As shown in FIG. 3, the
flowchart illustrates the activity flow 405 in an AP and the
activity flow 410 in client device. At the AP side, after power
is turned on at step 412, the AP initializes both the opera
tional WLAN and the configuration WLAN settings within
the AP at steps 414 and 416. The initialization of the
configuration WLAN settings at step 416 may include
starting to broadcast the SSID for the configuration WLAN.
The AP is then merely waiting at a configuration request step
418 for a client device to request connection to the LAN
through a configuration request.
[0029] On the client side, after the client is powered on
and is not already connected to an operational WLAN at step
420, the WLAN service within the client is activated by
initializing the wireless configuration service at step 422. At
step 424, the client device is waiting to detect a broadcasted
configuration SSID. In one example, the detection of a
broadcasted SSID may be performed as a background ser
vice of a client side operating system (for example a
Microsoft Windows operating system) that activates when
ever the wireless hardware is turned on. Alternatively, such
functionality may be provided within the client side wireless
software/hardware. When the client device detects a con
figuration SSID provided by an AP, control in the client
device then moves to step 426. At step 426, a decision is
made as to whether to configure the client device for the
LAN associated with the detected configuration SSID. If a
decision is made not to associate with the detected SSID
(such as a user not selecting the detected LAN), control
passes to step 427 in which the detected SSID is ignored and
control then returns to step 424 again as shown. When the
decision is made at step 426 to connect to a detected LAN,
control moves to step 428 at which point the association with
a configuration WLAN that is identified by the selected
configuration SSID is made. At this point, the client device
initiates communication with the AP as indicated by com
munication line 430 to establish a connection with the AP
according to the protocol for the communication standard
that is being utilized.
[0030] When a communication connection between the
AP and client device has been established, the AP device and
client device may then communicate further as shown by
communication line 432 to setup a temporary secure channel
as shown by steps 434 and 436 (e.g. Diffie-Hellman based
protocol). When a secure channel is established further
communication 438 may occur to complete the mutual
authentication process as shown in steps 440 and 442 (e.g.
PIN verification). Steps 434, 436, 440 and 442 provide a
mechanism to temporarily create and authenticate a tempo
rarily secure communication channel even though the chan
nel is initiated in an open environment. Any of a variety of
methods may be used that allow a software configurable
secure channel to be temporarily established and authenti
cated and the techniques for the use of a configuration
WLAN and operational WLAN as described herein are not
limited to any particular technique. One such technique that
may be utilized is disclosed in pending U.S. patent appli
cation no. 2005/0160287 entitled METHOD TO DEPLOY
WIRELESS ROUTER filed Jul. 21, 2005 by Mehta et al.,
the disclosure of which is expressly incorporated herein by
reference; however, other techniques may be used.
[0031] If the AP detects that the temporarily secure com
munication channel has been established and authenticated,
control moves from AP step 444 to AP step 448. If the client
device detects that the temporarily secure communication
channel has been established and authenticated, control
moves from client step 446 to AP step 452. If either the AP
or client device determine that authentication was not suc
cessful, then control returns to the AP step 418 and the client
step 427 as shown and the process repeats as described
above.
[0032] After a secure and authenticated channel has been
established, the AP may then send to the client device the
settings for the operational WLAN including the operation
SSID and other associated security encryption codes/keys,
and the like. This is indicated at the AP step 448, commu
nication line 450 and client device 452 in which the settings
for the operational WLAN are sent from and to the AP and
client device respectively.
[0033] After the AP has sent the setting for the operational
WLAN, the AP may then disassociate the configuration
WLAN from the client device as indicated in step 454. The
AP configuration WLAN of the AP device may then have
control returned to step 418 to await the next configuration
request. At this point the AP device may await further
communications from the client device over the operation
WLAN. On the client side, after the operational WLAN
settings are received at step 452, control moves to step 454
where configuration WLAN disassociation communication
456 is provided from the AP. At this point the client device
also disassociates from the configuration WLAN. Next, at
step 458 the settings for the configuration WLAN are
removed from the setting profiles in the client and replaced
with the settings for the operational WLAN. Finally, at step
460 the client device associates with the operational WLAN
by providing the operation SSID and security settings to the
AP according to the protocol of the standard under which the
AP and client device are operating.
[0034] The techniques described herein may be utilized in
a system in which the configuration LAN and the opera
tional LAN both communicate according to the same tech
nology standard. Thus, in one example and operational
WLAN and a configuration WLAN may both communicate
according to an 802.11 standard. However, the operational
LAN and the configuration LAN may communicate accord
ing to different technology protocols also. Thus, for
example, the operational communications may occur
according to one standard and the configuration communi
cation may occur according to another standard. In one
example the configuration communication may occur
according to an 802.11 protocol while the operation LAN
may communicate according to a Wi-Max or Cellular pro
tocol. In such configurations, reference to “an access point”
may refer to a single access point device that conforms to
both standards or may refer to two separate devices (one for
APPENDIX AA
Sep. 6, 2007
US 2007/0206527 A1
each standard) that operate together and together may be
viewed to form “an access point.”
[0035] The SSID data formats that are utilized for the
techniques described above may be formats such as known
in the current art. For example, the SSID may be a 32
character string such as commonly used in WLANs. When
utilizing an operational LAN and configuration LAN, how
ever, it may be beneficial to utilize the knowledge of such a
system to define a particular format for the SSID characters
(this would avoid potential duplicate SSIDs). For example,
with a standard 32 character string SSID, the particular
characters may include identifiers that designate the SSID as
a configuration SSID or an operational SSID. In this manner,
the SSID may be more readily identified by client devices as
a potential configuration SSID. One example of such a
technique is shown in FIG. 4. As shown in FIG. 4, the 32
characters available for use as an SSID 400 may be split into
a MODE field 402, a manufacturer field 404, and a serial
number field 406. In the MODE field, the characters may be
set to a designator value that such as either “config” or “op”
to designate the SSID as belonging to a configuration LAN
or operational LAN respectively. In this manner, the type of
LAN may be more readily identified by the SSID data itself.
Further within the processes and steps described above, the
client devices may be designed to automatically only seek
SSIDs having the configuration SSID designation when
initially searching for a configuration SSID to begin the
establishment of a network connection. Other processes may
also take advantage of identifying within the SSID itself
whether the SSID relates to an operational LAN or a
configuration LAN. Although described herein with refer
ence to a mode field located at the beginning of the SSID
characters, it will be recognized that the mode field could be
located in other portions of the SSID character string. In
addition, in one alternative SSIDs may be considered to
default to one type of SSID (configuration or operational)
and the MODE field need only be populated for the other
type of SSID.
[0036] As described above the connection to an opera
tional LAN is achieved through first connecting to a con
figuration LAN. It will be recognized that such techniques
may also be utilized in LAN systems that allow a user to
bypass the configuration LAN steps. Thus, the systems
described above may allow for a client device to bypass the
configuration LAN step when the user knows the operational
LAN settings. Alternatively, if a connection becomes dis
connected, a client may re-connect to the operation LAN
through use of the previously determined operation LAN
settings without having to perform the configuration LAN
steps described herein.
[0037] Further modifications and alternative embodiments
of this invention will be apparent to those skilled in the art
in view of this description. It will be recognized, therefore,
that the present invention is not limited by these example
arrangements. Accordingly, this description is to be con
strued as illustrative only and is for the purpose of teaching
those skilled in the art the manner of carrying out the
invention. It is to be understood that the forms of the
invention herein shown and described are to be taken as the
presently preferred embodiments. Various changes may be
made in the implementations and architectures. For
example, equivalent elements may be substituted for those
illustrated and described herein, and certain features of the
invention may be utilized independently of the use of other
features, all as would be apparent to one skilled in the art
after having the benefit of this description of the invention.
For example, the various communication protocols
described herein (such as 802.11a/b/g/n, WPAN, 802.16 (or
Wi-MAX), Cellular technologies, etc.) are merely exem
plary and it will be recognized that other current and future
standards may equally utilized the techniques described
herein. Furthermore, the prioritization classes described
herein are merely exemplary and other classes of traffic
and/or other levels of priority may be utilized while still
providing the benefits of the concepts disclosed herein.
What is claimed is:
1. A method of connecting a client device to an access
point, comprising:
utilizing a configuration LAN to provide an initial con
nection between the client device and the access point;
and
switching to an operational LAN to provide a connection
between the client device and the access point after the
configuration LAN connection is established,
wherein the configuration LAN and the operational LAN
are configured as separate LANs and
wherein the operational LAN is more secure than the
configuration LAN.
2. The method of claim 1 wherein the configuration LAN
and the operational LAN have different identifiers.
3. The method of claim 2 wherein the LAN is a wireless
LAN and the identifiers are SSID values.
4. The method of claim 1 wherein the switching to an
operation LAN comprises the transmitting operational set
tings from the access point to the client device.
5. The method of claim 4 further comprising disassoci
ating the configuration LAN connection between client
device and the access point.
6. The method of claim 4 further comprising utilizing the
transmitted operational settings to connect the client device
to the access point to establish the operational LAN con
nection.
7. The method of claim 1 wherein the configuration LAN
has terminated logical boundaries such that configuration
LAN connections have more limited boundaries as com
pared to operational LAN connections.
8. The method of claim 1 wherein the access point creates
multiple identifiers through the use of at least one virtual
LAN.
9. The method of claim 1 wherein the configuration LAN
communicates according to a first technology protocol and
the operational LAN communicates according to a second
technology protocol.
10. The method of claim 9 wherein the access point
comprises a single device providing communication accord
ing to both the first and second technology protocols.
11. The method of claim 9 wherein the access point is
comprised of at least two separate devices, one providing
communication according to the first protocol and one
providing communication according to the second technol
ogy protocol.
12. A network access point, comprising:
a configuration LAN interface, the configuration LAN
interface communicating configuration traffic of a con
APPENDIX AA
Sep. 6, 2007
US 2007/0206527 A1
figuration LAN for establishing a connection with a
client device, the configuration traffic having limited
logical boundaries to which it may be transmitted; and
an operational LAN interface, the operational LAN inter
face communicating communication traffic of an opera
tional LAN to the client device, the operational LAN
and the configuration LAN being separate LANs oper
ating through the network access point, the operational
LAN being a more secure LAN as compared to the
configuration LAN.
13. The network access point of claim 12 wherein the
network access point is a wireless access point, the network
access point further comprising a wireless LAN radio.
14. The network access point of claim 12 wherein both the
configuration LAN interface and the operational LAN inter
face are both coupled to the wireless LAN radio such that at
least a portion of the wireless LAN radio is utilized for both
configuration LAN communications and operational LAN
20. The information handling system of claim 19 wherein
the operational LAN has a second identifier that is not
broadcast.
21. The information handling system of claim 17 wherein
the wireless access point may communicate through both the
operational LAN and the configuration LAN at the same
time.
22. The information handling system of claim 21 wherein
the bandwidth of the configuration LAN is less than the
operational LAN.
23. A LAN identifier format, comprising:
a plurality of characters; and
a subset of characters of the plurality of characters, the
subset of characters identifying whether the LAN is at
least one of a configuration LAN or an operational
LAN.
24. The LAN service set identifier format of claim 23
communications.
wherein the subset of characters is a designated MODE field.
15. The network access point of claim 12 wherein the
configuration LAN has a first SSID and the operational LAN
wherein the MODE field is at the beginning of the subset of
has a second SSID.
16. The network access point of claim 15 wherein at least
one of the first and second SSIDs has one or more characters
identifier the SSID as being associated with the configura
tion LAN or the operational LAN.
17. An information handling system, comprising:
a wireless access point;
a configuration LAN, the configuration LAN processing
configuration and setup settings for connecting the
wireless access point and a client device;
an operational LAN, wherein the configuration LAN and
the operational LAN are both transmitted through the
wireless access point, the operational LAN processing
normal LAN traffic between the wireless access point
and the client device;
logical boundaries within the information handling sys
tem limiting the configuration LAN traffic to only a
portion of the information handling system.
18. The information handling system of claim 17 wherein
the logical boundaries are limited to the wireless access
point.
19. The information handling system of claim 17 wherein
the configuration LAN broadcasts a first LAN identifier.
25. The LAN service set identifier format of claim 24
characters.
26. The LAN service set identifier format of claim 23
wherein a designator value for both configuration LANs and
operational LANs is provided.
27. A method of identifying a wireless LAN comprising:
generating or receiving a multi-character service set iden
tifier value;
utilizing at least a portion of the multi-character service
set identifier value to identify whether the wireless
LAN is at least one of a configuration LAN or a
wireless LAN.
28. The method of claim 27, wherein the utilizing step is
performed by a wireless client device to identify the type of
a received service set identifier.
29. The method of claim 27, wherein the utilizing step is
performed by a wireless access point device to identify the
type of a service set identifier generated and transmitted by
the wireless access point.
30. The method of claim 27 wherein the permitted values
of the portion of the multi-character service set identifier
include both configuration identifier values and operational
identifier values.
APPENDIX AB
US 20040214572A1
(19) United States
(2) Patent Application Publication (10) Pub. No.: US 2004/0214572 A1
Thompson et al.
(43) Pub. Date:
(54) SYSTEM AND METHOD FOR
Oct. 28, 2004
Publication Classification
CONCURRENTLY UTILIZING MULTIPLE
SYSTEM IDENTIFIERS
(51) Int. Cl." … H04Q 7/20
(52) U.S. Cl. … 455/435.2
(75) Inventors: James Thompson, Austin, TX (US);
Kathleen E. McClelland, Austin, TX
(US); Brett B. Stewart, Austin, TX
(US)
(57)
ABSTRACT
Correspondence Address:
MEYERTONS, HOOD, KIVLIN, KOWERT &
GOETZEL, P.C.
System and method for providing access to multiple wireless
P.O. BOX 398
coupled to a network which may be distributed in airports,
mass-transit stations, businesses, etc. The network may
couple to a wide area network, such as the Internet. Each AP
service providers (WSPs) on a shared network infrastruc
ture. The system includes a plurality of access points (APs)
AUSTIN, TX 78767-0398 (US)
(73) Assignee: Wayport, Inc.
(21) Appl. No.:
(22) Filed:
may include a plurality of virtual APs (VAPs), each corre
sponding to a WSP. A portable computing device (PCD) of
10/848,897
a user stores identification information indicating a WSP of
a plurality of possible WSPs, and which may include an
May 19, 2004
access level of the user. Each AP “listens for’’ or detects
identification information associated with numerous WSPs.
When the AP receives the identification information from
Related U.S. Application Data
(60) Division of application No. 09/767,374, filed on Jan.
22, 2001, which is a continuation-in-part of applica
tion No. 09/551,291, filed on Apr. 18, 2000, now Pat.
the PCD, it determines the VAP/WSP for the PCD using the
identification information. Network access is then provided
to the PCD through the determined WSP at the determined
No. 6,732,176.
access level.
Connect to network
Or AP
202
Transmit i?) info to
network or AP
204
AP transmits known
geographic location
to network
206
Known
identification
information?
Select default network provider
212
and method for acceSS
Yes
Determine network provider
216
222
Determine access information
for accessing determined
network provider andlor
privilege level for
Perform registration
of use?
access rights
218
223
224
Disallow a CCéSS
226
Access point communicates
with PCD, provides data to
destination specified by
determined network provide?
and using method specified by
determined * provider
Determine network provider
charges for 234
º 3CCESS
APPENDIX AB
Patent Application Publication Oct. 28 5 2004 Sheet 1 of 7
US 2004/021.4572 A1
|-61I?G
pS?0JIN\A/
APPENDIX AB
Patent Application Publication Oct. 28, 2004 Sheet 2 of 7
US 2004/021.4572 A1
Access
Controller A
AP
120
AP
120
AP
120
Access
Controller B
VLAN 2 I
=
Access
Controller C
Fig. 2
Router CH
AP 1
AP 1
Router W
AP 1
Fig. 3
APPENDIX AB
Patent Application Publication Oct. 28, 2004 Sheet 3 of 7
US 2004/021.4572 A1
Connect to network
Or AP
202
Transmit ID info to
network or AP
204
AP transmits known
geographic location
to network
206
Known
identification
information?
Select default network provider
212
Yes
Determine network provider
216
and method for access
222
Determine access information
for accessing determined
network provider and/or
privilege level for
access rights
Perform registration
of user
223
218
No
Allow access
Yes
224
iSallow acces
Access point communicates
-
with PCD; provides data to
destination specified by
determined network provider
CDone D
and
using method
determined
ºspecified
providerby
Determine network provider
charges for network access
Fig. 4
234
APPENDIX AB
Patent Application Publication Oct. 28, 2004 Sheet 4 of 7
US 2004/021.4572 A1
ldentification
information 1
Network
provider 1
Access method/destination 1
Access level 1
ldentification
information 2
Network
provider 2
Access method/destination 2
Access level 2
Identification
information 3
Network
provider 3
Access method/destination 3
Access level 3
Identification
information 4
Network
provider 4
Access method/destination 4
Access level 4
Identification
Network
Access method/destination 5
information 5
provider 5
Access level 5
External
a CCGSS
(public)
Fig. 6
APPENDIX AB
Patent Application Publication Oct. 28, 2004 Sheet 5 of 7
US 2004/0214572A1
AP detects PCD (or PCD detects AP)
702
PCD transmits ESS IO to physical AP
704
Extract user ID information from packet
706
Store user ID information (e.g., MAC ID)
into table corresponding to ESS ID
708
Determine VLAN tag based on ESS ID
710
Virtual AP corresponding to ESS ID
transmits packet into wired network using
VLAN tag
712
FIG. 7
APPENDIX AB
Patent Application Publication Oct. 28, 2004 Sheet 6 of 7
US 2004/021.4572 A1
PCD communication with AP
Receive packet from PCD
802
Determine user ID information
(e.g., MAC ID) from packet
804.
Access table to determine ESS ID and
VLAN tag based on user ID information
806
Virtual AP corresponding to ESS ID
transmits packet into wired network using
wired transport mechanism
(e.g., VLAN tag)
808
FIG. 8
APPENDIX AB
Patent Application Publication Oct. 28, 2004 Sheet 7 of 7
US 2004/021.4572 A1
Packet arrives from
wired medium to AP
AP receives from wired medium extended
for one or more PCDs
902
Purse the packet to determine VLAN tag
and detect user ID information
904
Ensure that arriving packet arrived in
VLAN corresponding to determined
VLAN tag
906
Access table to determine virtual AP
associated with user ID information
908
Virtual AP transmit packet to PCD
-
910
FIG. 9
APPENDIX AB
US 2004/021.4572 A1
Oct. 28, 2004
Ser. No. 09/767,374 titled “Distributed Network Communi
radios. In other geographies, such as France and Japan, only
one channel is available using 802.11 DS. When using
Frequency Hopping radios, only one “channel” is defined.
The use of different “spreading codes” in conjunction with
FH radios only obfuscates the co-interference. Once the
available channels are used, perhaps one by each provider of
cation System Which Allows Multiple Wireless Service
for other providers without the potential for harmful co
SYSTEM AND METHOD FOR CONCURRENTLY
UTILIZING MULTIPLE SYSTEM IDENTIFIERS
CONTINUATION DATA
[0001] This application is a divisional of U.S. application
Providers to Share a Common Network Infrastructure,” filed
on Jan. 22, 2001, whose inventors are James W. Thompson,
Kathleen E. McClelland and Brett B. Stewart, which is a
a wireless infrastructure, no further bandwidth is available
interference and the resultant reduction in available band
width.
continuation-in-part of U.S. application Ser. No. 09/551,
[0010] Thus, due to the problems associated with multiple
291, now U.S. Pat. No. 6,732,176 titled “A Distributed
wireless infrastructures installed in a common area, it is
Network Communication System which Enables Multiple
Network Providers to Use a Common Distributed Network
desirable to provide a single wireless infrastructure which
may be used by two or more wireless service providers
Infrastructure” and filed on Apr. 18, 2000, whose inventors
are Brett B. Stewart, James W. Thompson and Kathleen E.
(WSPs). This would allow a plurality of WSPs to utilize a
common set of access points (APs) to provide service to a
McClelland.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] This invention relates generally to wireless net
work communications, and more specifically to a system
and method enabling a network infrastructure to support
multiple wireless service providers and/or customers of
multiple wireless service providers. The invention also
relates to a system and method enabling different access
levels within a wired or wireless network system.
[0004] 2. Description of the Relevant Art
[0005] Various types of wired and wireless infrastructures
are being developed to service users of computing devices,
such as portable computing devices (PCDs). Currently,
numerous wireless service providers are attempting to install
wireless network infrastructures in various locations, such as
airports, hotels, office buildings, shopping malls, etc. for use
by various users, such as mobile users (MUs) of PCDs.
[0006] However, when two or more providers install a
wireless network infrastructure in a single location, such as
an airport, the providers begin to oversubscribe the RF
domain. In other words, the electromagnetic spectrum
usable by these wireless networks is limited, and if two or
more wireless networks are installed in the same location,
this may result in inadequate RF bandwidth for use by each
of these networks.
[0007] IEEE 802.11 defines the IEEE standard for wireless
Ethernet. IEEE 802.11 is designed to support multiple
overlapping wireless local area networks (LANs) in a given
coverage area. Each wireless local area network will typi
cally include one or more access points (APs) which com
municate in a wireless fashion with a corresponding com
puting device of a user, which typically includes a wireless
Ethernet transceiver. IEEE 802.11 currently uses a System
ID (SID) to “select” which LAN to use and the access point
with which to associate.
[0008] Currently, only 3 non-overlapping RF channels are
available for different wireless service providers. Once these
potentially overlapping set of customers or subscribers. It
may also be desirable to provide a wireless infrastructure
which can selectively provide different access levels to users
of the system.
[0011] In the installation of a common-use wireless sys
tem, there are commonly two approaches to providing
service to each WSP’s subscribers, wherein each approach
uses a common authentication/accounting system. A com
mon authentication/accounting system involves “tying
together” the authentication/accounting systems of each
provider, thereby forming a “roaming consortium”. The first
approach is called RADIUS (Remote Authentication Dial In
User Service), and the second approach is called TACACS4.
Typically these consortiums use the RADIUS as a common
authentication and accounting protocol. RADIUS is a pro
tocol defined by the IETF RADIUS Working Group for
carrying information between network access devices and
security/accounting servers, and is documented in RFCs
2138 and 2139. TACACS4, a similar protocol developed by
Cisco Systems, is also used by some providers, although it
suffers from security issues in common implementations.
[0012] The main advantage of tying the authentication/
accounting systems together is the relative ease of doing so.
Indeed, RADIUS was designed to support a tiered hierarchy
of services providers. However, this seeming ease of imple
mentation hides other issues which remain unsolved via this
approach. Most of these center around the fact that RADIUS
and TACACS4 were designed to support connectivity via a
dial-up network (using either modems or ISDN). Indeed, the
very acronym “RADIUS” references this dial-up heritage
and focus. Since Wireless LANs are not “dial-up” by their
very nature, several assumptions which are “built-in” to the
RADIUS and TACACS4 protocols have the potential to
limit the type and number of services deployed over wireless
LANs.
[0013] RADIUS has its share of security issues as well.
The RADIUS protocol is open to a possible dictionary attack
on “shared secret” passwords. Discovery of these can be
used to spoof “Access-Accept” packets, with the result of
“free service” being granted to the attacker. While this
security hole is only possible if the attacker is able to “sniff”
channels are used, no further bandwidth, or limited band
communications between the RADIUS server and client,
width, may be available for other providers.
[0009] In the U.S. and most of Europe, only 3 non
overlapping channels are available using 802.11 Direct
wireless networks make this type of unauthorized access
even more likely.
[0014] However, the most glaring issue associated with
using a common authentication/accounting system is that
Spread (802.11 DS) (Direct Sequence Spread Spectrum)
APPENDIX AB
US 2004/021.4572 A1
any approach that ties the authentication and accounting
systems of a set of WSPs together does nothing to solve
problems related to “ESSIDs”, described below.
[0015] As noted above, the IEEE 802.11 specification is a
wireless LAN standard developed by the IEEE (Institute of
Electrical and Electronic Engineering) committee in order to
specify an “over the air” interface between a wireless client
and a base station or Access Point, as well as among wireless
clients. First conceived in 1990, the standard has evolved
from various Draft versions (Drafts 1 through 6), with
approval of the final draft on Jun. 26, 1997.
[0016] The 802.11 MAC layer, supported by an underly
ing PHY layer, is concerned primarily with rules for access
ing the wireless medium. Two network architectures are
defined: the Infrastructure Network and the Ad Hoc Net
work. The Infrastructure Network is a network architecture
for providing communication between wireless clients and
wired network resources. The transmission of data from the
wireless to the wired medium is via an Access Point (AP).
The coverage area is defined by an AP and its associated
wireless clients, and together all the devices form a Basic
Service Set (BSS).
[0017] The IEEE 802.11 protocol also defines an ESSID
(Extended Service Set ID) that is essentially a network
Oct. 28, 2004
active (such as Denial of Service) and passive (e.g. Snooping
or sniffing) would be possible.
[0022] Second, to rely on coordination of ESSIDs among
a potentially large number of WSPs seems questionable at
best. As new providers enter the market, each must choose
to configure its APs such that roaming by other providers’
subscribers is permitted. In fact, the case can be made that
every WSP who chooses to participate in any roaming
network would need to configure ALL of its APs to support
this as yet undefined ESSID.
[0023] Even if these steps are taken, once every WSP has
chosen to use the same ESSID, a new problem occurs.
Unless roaming agreements are global, and every provider
agrees to allow each other provider to roam on its APs, the
user of any given service cannot know that his/her WSP(s)
provide service in any given area. The user of such a service
is left to “guess” at service availability.
[0024] Further, global coordination around a single ESSID
(combined with a common authentication system) does not
solve the problem. An increasing number of enterprises
(large and small) are installing 802.11-compliant network
infrastructures, and equipping the employees of these com
name. The ESSID is used to select an associated wireless
panies with wireless Network Interface Cards (NICs). Each
of these enterprises will likely define its own ESSID, and
possibly an associated WEP (Wired Equivalent Privacy) key.
LAN infrastructure. Two or more BSSs configured with the
Further still, inexpensive 802.11-compliant APs are now
same ESSID attached to a common distribution system (for
instance, an Ethernet LAN) form an ESS (Extended Service
Set.)
[0018] With multiple access points, clients (PCDs) are free
ESSIDS.
to move seamlessly between access points, as long as the
ESSID matches. This feature is built into the 802.11 speci
fication. When a client (PCD) starts losing the signal with its
associated access point, it begins to search the area for a
closer access point. Once a new access point is found, the
client initiates an association with the new access point and
a disassociation from the old one.
[0019] In public-access networks the ESSID has been
commonly used to choose the WSP infrastructure with
which to associate. However, this creates a problem: Each
AP can only support one ESS and one associated ESSID.
Thus, in order for multiple service providers to share a
common space, N sets of APs are needed, where N is the
number of service providers. This leads to co-interference,
over-subscription of the RF environment and resultant lack
of available bandwidth, as described above.
[0020] The commonly suggested solution to this problem
is that all WSPs who wish to allow roaming agree on a
common ESSID for their wireless networks. While initially
this may appear to solve the problem, it also requires not
only a common authentication system, but also a common
network infrastructure which connects to the Internet and
other services. The issues with a common authentication
system have been outlined above. There are also numerous
issues associated with using a common ESSID to support
multiple WSPs in a common network infrastructure.
[0021] First, a common network infrastructure with a
shared ESSID would result in insufficient network security.
Since all devices would necessarily be associated with the
same network infrastructure, all manner of attacks, both
available for the home market (witness the Apple Airport),
and these wireless networks will likely have their own
[0025] Thus, even if all WSPs select and co-ordinate on a
single ESSID, enterprises (including airlines) and other
users of 802.11-compliant NICs will need to reconfigure
their equipment in order to use any common-ESSID network
provided by these WSPs. This would likely be too incon
venient for most users.
[0026] Finally, given a common infrastructure, only one
broadcast domain is possible. For an IP-based network (such
as must be supplied to provide connectivity to the Internet),
this implies that only one IP address space (and by exten
sion, one Dynamic Host Configuration Protocol (DHCP)
server) is possible for each location. This implies that the
WSP who owns the infrastructure (and supplies the connec
tivity) in each location has an advantage in that the network
connectivity for that WSP’s customers will experience better
connectivity. Also implied is that any resource located on the
network (such as file or video servers, voice gateways, and
otherwise secured facilities of other airport tenants) is avail
able to all users of the wireless infrastructure, and thus no
service differentiation is possible.
[0027] Therefore, it would be desirable to provide a sys
tem and method which enables a common wireless network
infrastructure (and especially an IEEE 802.11 wireless net
work infrastructure) to be used by two or more wireless
service providers (WSPs). This would allow a plurality of
service providers to utilize a common set of access points to
provide service to a potentially overlapping set of custom
ers. This would also provide subscribers or users with the
ability to more fully utilize the existing network infrastruc
ture. It would further be desirable to provide a distributed
wireless network system which can selectively provide
different access levels to users of the system.
APPENDIX AB
US 2004/021.4572 A1
SUMMARY OF THE INVENTION
[0028] One embodiment of the present invention com
prises a system and method for enabling multiple wireless
service providers (WSPs) to use or provide services on a
common wireless network infrastructure. The system and
method can thus provide access and/or roaming features on
a distributed wireless network system.
[0029] The network system includes a plurality of access
points (APs) coupled to a network. The network access
points include wireless access points, and may also include
wired access points. Access points for the network may be
widely distributed in various facilities, such as airports,
mass-transit stations, hotels, and various businesses, such as
business offices, restaurants, and stores. The network may
couple to a wide area network, such as the Internet. A
plurality of wireless service providers (WSPs) or network
providers may provide network services, such as Internet
access, over the network infrastructure.
[0030] In one embodiment, a user, also referred to as a
subscriber, may access the network system through a por
table computing device (PCD) using, for example, a wireless
network interface card (NIC). When in sufficiently close
range to an access point, the PCD may wirelessly commu
nicate with the AP in the network system. In one embodi
ment, the APs are arranged at known geographic locations
and may provide geographic location information regarding
the geographic location of the AP or the mobile user.
[0031] Each PCD may store identification information
which may uniquely indicate at least one wireless service
provider of a plurality of possible wireless service providers.
The identification information thus may designate the wire
less service provider (or providers) to which the user of the
PCD is a subscriber. The identification information may take
various forms, such as a System ID (SID), MACID, or other
identification which may be used to identify the wireless
service provider to which the user has subscribed. As used
herein, the SID may comprise an SSID (Service Set ID) or
an ESSID (Extended Service Set ID). When the PCD
becomes close to an access point, the PCD may provide the
identification information to the access point.
[0032] In one embodiment, each of the access points is
operable to “listen for’’ or detect identification information,
e.g., System IDs, associated with numerous different pro
viders, contained in “probes” broadcast by PCDs. Alterna
tively, each of the access points may be operable to broad
cast requests for identification information, e.g., broadcast
recognized System IDs to the PCDs, wherein the PCDs may
respond to this broadcast by providing the identification
information. Such broadcasts by APs are known as “bea
Oct. 28, 2004
[0034] In one embodiment, the network system may
include a memory medium which stores a list of identifica
tion information that maps to a corresponding list of the
plurality of possible wireless service providers. The memory
medium may be comprised in one or more of, or all of, the
access points, or may be comprised in one or more other
devices connected to the network, such as a computer
system. In this embodiment, determining the wireless ser
vice provider for the portable computing device includes
accessing the memory medium and using the received
identification information to determine the wireless service
provider. For example, the access point or other device may
use the received System ID to index into a table to determine
the appropriate WSP.
[0035] The memory medium may also store associated
access information. For each of the wireless service provid
ers, the access information may include access methods for
providing user data to the respective wireless service pro
vider, such as a destination IP address of the WSP. The
appropriate access method may be used based on the iden
tification information and/or the determined WSP. Thus, the
identification information may be used to determine the
appropriate WSP as well as to automatically route network
packets or data between that PCD and the appropriate
provider.
[0036] The access information stored in the memory
medium may also include an access level which indicates
the user’s access rights or privilege level. Thus, the local
network or the WSP may provide various local resources
which are available to all users regardless of access level,
and users with a higher access level may additionally be
entitled to Internet access. In other environments, all users
may receive Internet access, and users with a lower access
level may not be entitled to view or utilize certain or all local
network resources on the network. Thus, depending on the
access level, the user may be provided solely with external
Internet access, or only local network access, or may be
provided with no network services. The access level may
also possibly depend on the known geographic location of
the AP or the user. For example, the access level for each
user may vary depending on the known geographic location
of the AP to which the user is currently associated, or may
depend on the approximate geographic location of the user,
e.g., may depend on whether the user is in a certain store or
in a secure area.
[0033] When an access point receives the identification
information from a PCD of a user, the access point may
determine the appropriate wireless service provider for the
portable computing device using the identification informa
tion. Thus, the network system is able to recognize and
process identification information which identifies any of the
plurality of possible wireless service providers. In one
embodiment, the APs answer all queries from all PCDs,
[0037] In one embodiment, one or more of the wireless
service provider ID and the access information may be
provided by the PCD of the user. Thus, an access point or
other device on the network may not be required to perform
a look-up to determine this information, but rather this
information may be provided by the PCD.
[0038] When the portable computing device communi
cates with the access point, network access may be provided
to the portable computing device through the determined
WSP. For example, the access point may provide the com
municated data to a destination based on or specified by the
determined WSP, e.g., may provide or route the data to the
determined wireless service provider’s site, e.g., to equip
ment provided by the WSP. The WSP may then provide
even if the identification information from the PCD does not
Internet access and/or other network services. The WSP will
match the information available to that particular AP, e.g.,
also typically charge a fee for this service. The access point
preferably provides the data to the destination in a secure
cons”.
even if an unknown SID is received.
APPENDIX AB
US 2004/021.4572 A1
manner to prevent the data from being unintentionally
provided to third parties, such as other providers.
[0039] Thus the wireless network system is useable by
subscribers of each of the plurality of possible wireless
service providers, thereby enabling subscribers to “roam” on
various networks, including networks maintained by other
providers. For example, the plurality of access points may be
maintained by a first WSP, and a subscriber of a second WSP
may be recognized and allowed use of the network. Alter
natively, the plurality of access points may be maintained by
an independent third party, and subscribers of any of various
WSPs may be recognized and allowed use of the network.
Wireless service providers may charge subscribers for
access regardless of who operates or maintains the network.
In addition, the network system may selectively provide
users different access levels to network resources depending
on the access or privilege level of the user. This allows
WSPs to offer different levels of access to customers,
possibly based on different service fee levels. This also
allows visitors or non-members of a network system to be
allowed certain network services, such as Internet access,
without compromising other private network resources.
[0040] In one embodiment, the system includes at least
one AP with software which is executable to provide access
point functionality for each of a plurality of WSPs. The
software may implement a “super access point” which
maintains associations between the plurality of WSPs and a
corresponding plurality of SIDs, such as MAC IDs, ESSIDs,
etc. The AP may be capable of broadcasting or recognizing
any of the plurality of SIDS, behaving appropriately for
different SIDS that are received from PCDs of users, and
providing network services to each user through that user’s
corresponding WSP. Thus an AP may be operable to appear
as any one of a plurality of different WSPAPs, meaning that
a single AP may “pretend to be” or behave as an access point
dedicated to a particular WSP for each of a plurality of
different WSPs.
[0041] In one embodiment, the system provides a plurality
of virtual APs, where a virtual AP may comprise access point
functionality implemented in software that appears as a
physical AP to a PCD. The plurality of virtual APs or
“software” APs may be implemented on one or more physi
cal APs, e.g., on a common set of physical APs. For
example, each physical AP may implement a plurality of
virtual APs. Each instance of a virtual AP executes a
complete 802.11 protocol stack, and may be indistinguish
able from a hardware AP to any wireless network client(s).
Each virtual AP or “software” AP may include its own
ESSID and may be uniquely associated with a correspond
ing WSP. Thus, each WSP that uses a virtual AP solution
would enjoy the illusion that there was a complete wireless
infrastructure available for its exclusive use. In one embodi
ment, the System ID of each virtual AP may be a variant of
the SID of the physical AP hosting the virtual APs.
[0042] Each of the APs may connect to a “wired” LAN. In
one embodiment, the “wired” LAN supports a VLAN (Vir
tual LAN) protocol. In order to partition the network, the
network system may maintain a binding between the ESSID
and IEEE 802.1(q) VLAN tags or their equivalent. This
allows a common wired backbone (using VLAN-capable
Ethernet switches) to supply a secured “virtual LAN” to
each WSP. In order to provide service differentiation and
Oct. 28, 2004
quality of service (QoS) to each user of the network, the
network system may further enable 802.1(p) in these tags.
This allows the proprietor of the network system to provide
service level agreements to its customers, including both
other WSPs and, for example, airport tenants. The network
architecture described herein can scale to support hundreds
of these network customers, and thousands of simultaneous
users in each location.
[0043] In order to support users who arrive at the wireless
network location (e.g., an airport) with an ESSID that does
not match the ESSID of any WSP, the network system also
allows for a “default” mapping. Users who arrive with a
different ESSID, e.g., the ESSID used at their home or
enterprise, would have their network data passed to a default
or selected provider. This provider may present the user with
the opportunity to use the network on a one-time basis, or
may present the user with the opportunity to register with the
provider, perhaps by requesting credit card information from
the user.
[0044] The wireless network system described herein
enjoys several advantages over the approach of tying the
authentication system of each subscriber to a roaming
“clearing house”. The wireless network system described
herein leverages the 802.11 protocol, and is agnostic as to
which PHY technology is used. The present system can
support all of the following 802.11 technologies:
[0045] 802.11 FH (Frequency Hopping Spread Spec
trum (a 1-2 Mbps in 2.4 Ghz)
[0046] 802.11 DS (Direct Sequencing Spread Spec
trum (a 1-2 Mbps in 2.4 Ghz)
[0047] 802.11 (b) (High-rate (11 Mbps) DSSS in 2.4
Ghz)
[0048] 802.11(a) (High-rate (50 Mbps) FHSS in 5.7
Ghz)
[0049] Bluetooth (FHSS (a)-1 Mbps in 2.4 Ghz) (via
similar virtualization of the SDP)
[0050] In one embodiment, the physical AP may comprise
two radios, one Direct Spread Coding radio, and one Fre
quency Hopping radio, thus providing multiple PHY layers
on one physical AP. Using the present system, one set of APS
(for a given PHY technology) can maximize the coverage in
a given space with a minimum of co-interference. A group
of providers can share this “footprint”, enabling maximum
coverage for the superset of the subscribers to each service.
Each wireless service provider can leverage their expertise
in attracting members and providing value-added services or
COntent.
[0051] In addition, each location authority, (e.g., an airport
authority) can deal with one “master concession”, who is
responsible for building and maintaining the RF infrastruc
ture, manages the RF environment, and sub-leases this
infrastructure to the other providers. In fact, the location
authority can act as the “master concession”, should it so
desire.
[0052] The present system is also transparent to authenti
cation technology used by any provider. Due to the issues
raised above, the wireless subscriber technology described
herein is not based on RADIUS or TACACS4. Instead, the
present subscriber technology may use a “single sign-on”
APPENDIX AB
US 2004/021.4572 A1
technology based on X.509 certificates. Similar technology
is used to secure nearly every WWW transaction that
requires protection.
[0053] The present system is also transparent to the net
work protocols in-use. While other provider’s approaches
assume that IPv4 is the only protocol in-use, the present
system allows other protocols (IPX, IPv6, NetBIOS, ARP,
etc) to be used in the network as they normally would, with
the singular exception that these flows take place within the
virtual LAN provided by the APs and the network backbone.
[0054] Thus the wireless network system described herein
enables a common infrastructure to be used by a plurality of
wireless service providers, and provides a number of advan
tages over the prior art.
BRIEF DESCRIPTION OF THE DRAWINGS
[0055] Other objects and advantages of the invention will
become apparent upon reading the following detailed
description and upon reference to the accompanying draw
ings in which:
[0056] FIG. 1 is a block diagram of one embodiment of a
wireless network system;
[0057] FIG. 2 is a more detailed block diagram of one
embodiment of the wireless network system of FIG. 1;
[0058] FIG. 3 is a block diagram of another embodiment
of the wireless network system of FIG. 1;
[0059] FIG. 4 is a flowchart diagram illustrating operation
of allowing access to a wireless network system using a
multiple subscriber model;
[0060] FIG. 5 illustrates an example of a data structure
which stores wireless service provider and access informa
tion;
[0061] FIG. 6 illustrates selectively allowing access to a
wireless network system using various access levels;
[0062] FIG. 7 is a flowchart of initial communication
between a PCD and an access point;
[0063] FIG. 8 is a flowchart of communications between
a PCD and an access point; and
[0064] FIG. 9 is a flowchart of the process of packets
arriving from a wired medium to the AP which are destined
for a PCD.
[0065] While the invention is susceptible to various modi
fications and alternative forms, specific embodiments
thereof are shown by way of example in the drawings and
will herein be described in detail. It should be understood,
however, that the drawings and detailed description thereto
are not intended to limit the invention to the particular form
disclosed, but on the contrary, the intention is to cover all
modifications, equivalents and alternatives falling within the
spirit and scope of the present invention as defined by the
appended claims.
Oct. 28, 2004
Enables Multiple Network Providers to Use a Common
Distributed Network Infrastructure” and filed on Apr. 18,
2000, whose inventors are Brett B. Stewart, James W.
Thompson and Kathleen E. McClelland is hereby incorpo
rated by reference in its entirety as though fully and com
pletely set forth herein.
[0068] U.S. Pat. No. 5,835,061 titled “Method and Appa
ratus for Geographic-Based Communications Service”,
whose inventor is Brett B. Stewart, is hereby incorporated
by reference in its entirety as though fully and completely set
forth herein.
[0069] U.S. Pat. No. 5,969,678 titled “System for Hybrid
Wired and Wireless Geographic-Based Communications
Service”, whose inventor is Brett B. Stewart, is hereby
incorporated by reference in its entirety as though fully and
completely set forth herein.
[0070] U.S. patent application Ser. No. 09/433,817 titled
“Geographic Based Communications Service” and filed on
Nov. 3, 1999, whose inventors are Brett B. Stewart and
James Thompson, is hereby incorporated by reference in its
entirety as though fully and completely set forth herein.
[0071] U.S. patent application Ser. No. 09/433,818 titled
“A Network Communications Service with an Improved
Subscriber Model Using Digital Certificates” and filed on
Nov. 3, 1999, whose inventors are Brett B. Stewart and
James Thompson, is hereby incorporated by reference in its
entirety as though fully and completely set forth herein.
[0072] U.S. patent application Ser. No. 09/551,309 titled
“System and Method for Managing User Demographic
Information Using Digital Certificates” and filed on Apr. 18,
2000, whose inventors are Brett B. Stewart and James
Thompson, is hereby incorporated by reference in its
entirety as though fully and completely set forth herein.
[0073] FIG. 1—Network Communication System
[0074] FIG. 1 shows one embodiment of a distributed
network communication system 100. The network system
100 may include one or more access points 120, preferably
a plurality of access points 120. At least a subset of the
access points 120 are wireless access points (APs) 120
which communicate with a portable computing device
(PCD) 110 in a wireless fashion. Each wireless access point
(AP) 120 may have a wireless connection or transceiver
(e.g., an antenna) and may operate according to various
wireless standards, such as wireless Ethernet (IEEE 802.11),
Bluetooth, etc. One or more of the access points 120 may
also be wired access points which communicate with a
portable computing device 110 in a wired fashion.
[0075] Each AP120 may be coupled to a network 130. The
network 130 may comprise a wired network, a wireless
network or a combination of wired and wireless networks.
For example, the network 130 may be a standard “wired”
Ethernet network which connects each of the wireless (and
wired) access points 120 together. The network 130 may
also be a wireless network based on IEEE 802.11. The
DETAILED DESCRIPTION OF THE
EMBODIMENTS
network 130 may form part of the Internet 170, or may
couple to other networks, e.g., other local or wide area
[0066] Incorporation by Reference
[0067] U.S. patent application Ser. No. 09/551,291 titled
“A Distributed Network Communication System which
[0076] The network 130 may also include or be coupled to
other types of communications networks, (e.g., networks
other than those comprised in the Internet) such as the public
networks, such as the Internet 170.
APPENDIX AB
US 2004/021.4572 A1
switched telephone network (PSTN), whereby a user using
PCD 110 may send and receive information from/to the
PSTN or other communication network through a wireless
service provider. The network 130 may also include, or be
coupled to, another wide area network 130, such as a
proprietary WAN. The network 130 thus may be, or be
coupled to, any of various wide area networks (WANs) or
local area networks (WANs), including the Internet 170.
[0077] The access points (APs) 120 may be widely dis
tributed in various facilities, such as airports, mass-transit
stations, hotels, shopping malls, restaurants and other busi
nesses, such as business offices, law firm offices, retail
stores, etc. For example, where the access points 120 are
distributed in an airport, one or more access points 120 may
be distributed throughout various terminals in the airport, in
an airline club, and in coffee shops, restaurants or rental car
counters at the respective airport. The access points 120 may
thus be primarily designed to service mobile users, wherein
it may not be known ahead of time which mobile users will
be accessing the network from which locations. Thus the
network system 100 is preferably a distributed network
system, with access points placed in locations to service
mobile users. This differs from a conventional fixed LAN,
where it is generally pre-configured as to which pre-deter
mined users will be using which nodes in the fixed LAN on
a day-to-day basis, and the relative access levels that these
pre-determined users have is also pre-configured.
[0078] Each access point 120 may comprise information
used to identify or select a wireless service provider (also
called a network provider) for a particular user, as well as
related access information to enable the wireless service
provider to provide access. Each access point 120 may
comprise information used to enable network access through
a wireless service provider of a plurality of possible wireless
service providers. Thus each access point 120 may support
a plurality of different wireless service providers. When in
sufficiently close range to an access point 120, or when the
PCD 110 is directly coupled to an access point 120 in a wired
fashion, the PCD 110 may access the network utilizing a
particular wireless service provider, as discussed further
below.
[0079] A user operating a portable computing device
(PCD) 110 may communicate with one of the access points
120 to gain access to network services, such as Internet
access. The portable computing device (PCD) 110 may have
a wireless communication device, e.g., a wireless Ethernet
card, Bluetooth wireless interface, etc., for communicating
with a wireless access point 120. The portable computing
device (PCD) 110 may instead have a wired communication
device, e.g., an Ethernet card, for communicating with a
wired access point 125.
[0080] The portable computing device 110 may be any of
various types of devices, including a computer system, such
as a portable computer, a personal digital assistant (PDA), an
Internet appliance, a communications device or telephony
device, or other wired or wireless device. The PCD may
include various wireless or wired communication devices,
such as a wireless Ethernet (IEEE 802.11) card, Bluetooth
logic, paging logic, RF communication logic (such as cel
lular phone logic), a wired Ethernet card, a modem, a DSL
device, an ISDN device, an ATM device, a parallel or serial
port bus interface, or other type of communication device.
Oct. 28, 2004
[0081] The PCD 110 preferably includes a memory
medium which stores identification information indicating a
wireless service provider to which the user has subscribed.
The indicated wireless service provider may be one of a
plurality of possible wireless service providers that provide
Internet access or other network services in a network
system such as that shown in FIG. 1. The identification
information may be a System ID (an 802.11 System ID), a
MAC ID of a wireless Ethernet device comprised in the PCD
110, the name of the wireless service provider, or other type
of information that uniquely identifies one (or more) wire
less service providers. Where the wireless network is IEEE
802.11 wireless Ethernet, the identification information or
System ID may be a SSID (Service Set ID), an ESSID
(Extended Service Set ID) or possibly a BSSID (Basic
Service Set ID). Where the wireless network is Bluetooth,
the identification information may be an IP address. The
identification information may be contained in a digital
certificate, which may be stored in a web browser or other
location of the personal computing device 110.
[0082] Where the access point 120 is a wireless access
point 120, the wireless communication may be accom
plished in a number of ways. In one embodiment, PCD 110
and wireless AP 120 are both equipped with an appropriate
transmitter and receiver compatible in power and frequency
range (e.g., 2.4 GHz) to establish a wireless communication
link. Wireless communication may also be accomplished
through cellular, digital, or infrared communication tech
nologies, among others. To provide user identification and/
or ensure security, the PCD 110 may use any of various
security mechanisms, such as WEP (Wired Equivalent Pri
vacy).
[0083] Where the access point 120 is a wired access point
120, the wired connection may be accomplished through a
variety of different ports, connectors, and transmission
mediums. For example, the PCD 110 may be connected
through an Ethernet, USB, serial, or parallel transmission
cables, among others. The PCD 110 may also include
various communication devices for connecting to the AP
120, such as wired Ethernet cards, modems, DSL adapters,
ATM adapters, IDSN devices, or other communication
devices. For example, a hotel may have Ethernet connec
tions in the restaurants, shops, and guest rooms. An airline
club, e.g., an airport Admiral’s Club, may also have both
wireless and wired connections for mobile users. A user may
connect to a wired access point 120 through the use of a
laptop computer (PCD 110), an Ethernet network card, and
a network cable. This connection may have the same impact
as a connection made to a wireless AP 120 as discussed
above. In other words, a user using a wired PCD 110 is able
to “roam” on various network infrastructures in the same
manner as a user using a wireless PCD 110.
[0084] One or more wireless service providers may each
have an associated network device 160 coupled to the
network 130. For example, FIG. 1 illustrates network
devices 160 associated with three different wireless service
providers. The network devices 160 may take any of various
forms, such as a computer system, router, bridge, etc. It is
noted that wireless service providers may provide network
services at a network location without being required to
locate any equipment or bandwidth at the network location.
For example, a wireless service provider may combine
APPENDIX AB
US 2004/021.4572 A1
VLANs and IP tunneling to avoid having to locate any
equipment or bandwidth at a particular network location.
[0085] A user operating a portable computing device 110
will typically have previously subscribed with one (or more)
Wireless Service Providers (WSPs), also called network
providers. Examples of wireless service providers include
Wayport, MobileStar and Softnet, among others. As dis
cussed further below, when the PCD 110 of a user commu
nicates with an AP 120, the respective wireless service
provider to which the user is subscribed is determined. If no
previous affiliation with a wireless service provider is
detected, a default wireless service provider may be
selected. After the wireless service provider is determined or
selected, network access or services may be provided
through that wireless service provider. For example, data or
packets from the respective PCD 110 may be routed to a
destination designated by the respective wireless service
provider, such as the respective provider’s network device
160. This effectively allows a plurality of wireless service
providers to each offer access on a common network infra
structure, i.e., on common access points. Thus a single
access point can support multiple different wireless service
providers, i.e., can support subscribers of multiple different
wireless service providers. This also allows subscribers of
various wireless service providers to “roam” on other net
works, such as networks installed and/or maintained by
other providers, or networks maintained by independent
third parties.
[0086] The network system 100 may also include a man
agement information base (MIB) 150. The MIB 150 may be
a mechanism, such as a memory, which may allow the
persistent storage and management of information needed
by network 130 to operate. For example, in one embodiment
of the invention, the MIB 150 may store a data structure,
such as a table comprising a list of identification information
and a corresponding list of the plurality of possible wireless
service providers. The data structure may also store access
information, which may comprise associated methods for
providing data to the respective plurality of possible wireless
service providers. The access information may further com
prise access level or privilege level information. Thus, the
data structure may comprise a table having a plurality of
tuples, with each tuple having the identification information,
e.g., a System ID, the corresponding wireless service pro
vider, and access information containing a method of access
to the provider, possibly including a destination IP address
or other methodology for accessing the provider’s site. In an
alternate embodiment, as noted above, the data structures
which store this information may be comprised in each of
the access points 120, or may be provided in various other
locations. Each tuple may further include wired transport
information, such as a VLAN tag, Generalized Routing
Encapsulation (GRE), or other wired transport information,
indicating a channel to be used on the wired network to
which the AP 120 is coupled.
[0087] As discussed further below, when a portable com
munication device 110 of a user begins communication with
an access point 120, the portable communication device 110
may transmit wireless service provider ID information, and
the wireless service provider for the portable computing
device 110 may be determined using this data structure. The
memory medium containing the data structure may be
accessed, and received wireless service provider identifica
Oct. 28, 2004
tion information from the respective portable computing
device 110 may be used to index into the data structure or
table to determine the wireless service provider. The appro
priate access method may also be accessed and used for
enabling the wireless service provider to provide network
services, e.g., the access method may be used for providing
the data from the respective portable computing device 110
to the determined wireless service provider. For example,
wired transport information may also be used to determine
how to transfer packets on the wired network. Access level
information may also be retrieved and used to determine a
user’s access to local network resources or Internet access.
[0088] The MIB 150 may store other information, such as
a directory of all the elements (e.g., APs, PCDs, etc) in the
network, the topology of the network, characteristics of
individual network elements, characteristics of connection
links, performance and trend statistics, and any information
which is of interest in the operation of the network 130. For
example, the MIB may store the precise longitude, latitude,
altitude and other geographic information pinpointing the
location of each access point.
[0089] One or more service providers 140 may also be
coupled to the network 130 or other networks to which the
network 130 is coupled, such as the Internet 170. As used
herein, the term “service provider” is intended to include
various types of service and information providers which
may be connected to the network 130. The service provider
140 may take any of various forms and may provide any of
various services or information. Each service provider 140
may include one or more computers or computer systems
configured to provide goods, information, and/or services as
appropriate for the service provider. The one or more service
providers 140 may couple to the network in a wired or
wireless fashion. The service providers 140 may include
“network access” providers which typically charge fees for
network access. The service providers 140 may also include
other types of providers which may provide a service at the
location where the APs are located. For example, in an
airport, example service providers may include an airline
server or airline personnel (which may operate as clients of
APs) which provides flight information and/or helps direct
passengers to flights. In a hotel, example service providers
may include housekeeping, engineering, and other typical
hotel services which may utilize particular WSPs for their
respective network services. For example, maid carts in a
hotel may be configured with PCDs to answer requests from
users that are staying in the hotel. Thus, the plurality of
WSPs may include fee-based network access providers for
serving customers, as well as operational service providers
for serving the needs of employees.
[0090] The network communication system 100 may be
geographic-based. In other words, the network communica
tion system 100 may provide information and/or services to
the user based at least partly on the known geographic
location of the user, e.g., as indicated by the access points
120 or as indicated by geographic information (e.g., GPS
information) provided from the PCD 110. In one embodi
ment, the APS 120 are arranged at known geographic loca
tions and may provide geographic location information
regarding the geographic location of the user or the PCD
110. In another embodiment, the PCD 110 may provide
geographic location information of the PCD 110 through the
AP 120 to the network 130. For example, the PCD 110 may
APPENDIX AB
US 2004/021.4572 A1
include GPS (Global Positioning System) equipment to
enable the PCD 110 to provide its geographic location
through the AP 120 to the network 130, such as to a service
provider 140 coupled to the network 130.
[0091] In one embodiment, the network communication
system 100 may provide information and/or services to the
user based on both the known geographic location of the
user and an access level of the user. For example, a bank
official may have an access level which allows access to
security codes regarding electronic or physical access to
funds. The access level may only be operational when the
employee (or the employee’s PCD) is in a secure area of the
bank, thereby preventing unauthorized or unintended access
to sensitive information, such as due to coercion or theft of
the user’s PCD.
[0092] Memory Medium and Carrier Medium
[0093] One or more of the systems described above, such
as PCD 110, access points 120, MIB 150, and wireless
service providers 160 may include a memory medium on
which computer programs or data according to the present
invention may be stored. For example, each of the access
points 120 and/or the MIB 150 may store a data structure as
described above comprising information regarding identifi
cation information, corresponding wireless service provid
ers 160 and access information such as associated data
routing methods. Each of the access points 120 and/or the
MIB 150 may further store a software program for accessing
these data structures and using the information therein to
properly provide or route data between users (subscribers)
and their corresponding wireless service providers, or to
selectively provide or route data depending on the access
information.
[0094] One or more of the access points 120 and/or the
MIB 150 may include software that enables the AP 120 to
accommodate or service subscribers of a plurality of differ
ent WSPs. Thus an AP 120 may be operable to appear as any
one of a plurality of different WSPAPs, meaning that a
single AP may “pretend to be” or behave as an access point
dedicated to a particular WSP for each of a plurality of
different WSPs. In contrast, prior art APs are only able to
provide access point services for a single WSP. In other
words, according to one embodiment of the invention, an AP
120 may execute one or more software programs that allow
it to act as an AP for each of a plurality of WSPs. Thus, each
AP 120 may be capable of broadcasting or recognizing any
of a plurality of SIDS, and maintaining associations between
the SIDS and the subscribers of the respective WSPs. The
physical AP may further behave appropriately for different
SIDS that are received from PCDs of users, providing
network services to each user through that user’s corre
sponding WSP.
[0095] In one embodiment, at least one of the APs 120
may include software that enables the single physical AP
120 to implement a plurality of virtual APs, where a virtual
AP may comprise access point functionality implemented in
software that appears as a physical AP to a PCD. The
plurality of virtual APs or “software” APs may be imple
mented on one or more physical APs, e.g., on a common set
of physical APs. Each instance of a virtual AP executes a
complete 802.11 protocol stack, and is indistinguishable
from a hardware AP to any wireless network client(s). Each
virtual AP or “software” AP may include its own ESSID
Oct. 28, 2004
(e.g., an ESSID as specified in IEEE 802.11) and may be
uniquely associated with a corresponding WSP. Thus, each
WSP that uses a virtual AP solution would enjoy the illusion
that there was a complete wireless infrastructure available
for its exclusive use.
[0096] In another embodiment, at least one of the APs 120
may include software that enables the single physical AP
120 to behave appropriately for each of a plurality of WSPs.
For example, instead of implementing a plurality of virtual
APs, i.e., instead of storing and executing a plurality of
virtual AP software program instantiations, a single software
instantiation may enable this operation. In the embodiment
above, each virtual AP may entail one or more software
programs, and each instantiation of a virtual AP may utilize
a separate instantiation or replication of these one or more
software programs. In this “super access point” embodi
ment, a single instantiation of one or more software pro
grams may enable the physical AP 120 to behave appropri
ately for each of a plurality of WSPs. These one or more
software programs may execute to cause the AP 120 to:
broadcast and recognize a plurality of different SIDs corre
sponding to each of a plurality of different WSPs, maintain
associations between SIDs and WSPs, maintain SID and
VLAN tag mappings, and perform other operations neces
sary to enable the single physical AP 120 to behave appro
priately for each of a plurality of WSPs.
[0097] In the virtual AP embodiment described above, as
noted, for one or more of the access points 120, each
physical access point 120 may include a plurality of virtual
APs implemented in software that are comprised on the
single physical access point 120. As described above, each
of these virtual APS may be used for servicing a respective
WSP, i.e., for providing network access services to a respec
tive WSP. According to the current IEEE 802.11 standard,
each physical AP has a BSSID (Basis Service Set ID). The
BSSID is typically the MAC ID of the network interface
device comprised in the physical AP 120.
[0098] However, when multiple virtual APs are comprised
on or implemented on a single physical AP, it may not be
possible to use the same MAC ID of the physical AP as the
BSSID of each of the virtual APs on that physical AP In
other words, using this approach, each of the virtual APS
may not receive a unique BSSID, as they each would have
the MAC ID of the physical AP. If it is desired or required
for each of the virtual APs to have a unique BSSID, then
various alternative methods may be used. In one embodi
ment of the invention, the MAC ID of the single physical AP
is simply used for all virtual APs, i.e., is used as the BSSID
for all virtual APs on that physical AP. Thus, in this
embodiment, each of the virtual APs on a single physical AP
has the same BSSID. It is currently not believed that this will
impact the operation of each of the virtual APs in any way.
In an alternate embodiment, where it is desired that each of
the virtual APs has a different respective BSSID, then the
“local to network” MAC ID address bits which are defined
by IEEE are adjusted for each of the respective virtual APs
to produce a unique MAC ID for each of the virtual APs.
[0099] In yet another alternate embodiment, the physical
AP is initially assigned a pool of MAC ID addresses and
each of the virtual APs is assigned a unique MAC ID from
this pool, thus providing each virtual AP with a unique MAC
ID address, i.e., a unique BSSID. One drawback to this
APPENDIX AB
US 2004/021.4572 A1
Oct. 28, 2004
implementation is the need for a larger number of MAC ID
addresses than the methods previously described.
[0100] In one embodiment, a single physical AP may
couple to respective routers 160, labeled router A, router B
and router C, which are provided by wireless service pro
viders A, B and C respectively. These routers in turn couple
support both Infrastructure Network mode (BSS) and Ad
Hoc Network mode (Independent BSS, or IBSS). In Ad Hoc
lers, e.g., computer systems configured to determine or
control network service access, may be provided for each of
the wireless service providers. The access controllers oper
ate to verify user or subscriber access to the respective
provider’s network. FIG. 2 illustrates access controller A,
mode, each AP is just another peer on the network. This may
be accomplished by configuring one or more virtual APs for
BSS, as described above, and one or more other virtual APs
(also on the same physical AP) for IBSS, or Ad Hoc Network
mode.
[0101] The term “memory medium” is intended to include
various types of memory or storage, including an installation
medium, e.g., a CD-ROM, or floppy disks 104, a random
access memory or computer system memory such as
DRAM, SRAM, EDO RAM, Rambus RAM, EPROM,
EEPROM, flash memory etc., or a non-volatile memory
such as a magnetic media, e.g., a hard drive, or optical
storage. The memory medium may comprise other types of
memory as well, or combinations thereof. In addition, the
memory medium may be located in a first computer in which
the programs are executed, or may be located in a second
different computer which connects to the first computer over
a network. In the latter instance, the second computer
provides the program instructions to the first computer for
execution. The memory medium may also be a distributed
memory medium, e.g., for security reasons, where a portion
of the data is stored on one memory medium and the
remaining portion of the data may be stored on a different
memory medium. Also, the memory medium may be one of
the networks to which the current network is coupled, e.g.,
a SAN (Storage Area Network).
[0102] Also, each of the systems described above may
take various forms, including a personal computer system,
mainframe computer system, workstation, network appli
ance, Internet appliance, personal digital assistant (PDA),
television system or other device. In general, the term
“computer system” can be broadly defined to encompass any
device having a processor which executes instructions from
a memory medium.
[0103] The memory medium in one or more of the above
systems thus may store a software program or data for
performing or enabling roaming or selective network
resource access within a network system 100. A CPU or
processing unit in one or more of the above systems execut
ing code and data from a memory medium comprises a
means for executing the software program according to the
methods or flowcharts described below.
[0104] Various embodiments further include receiving or
storing instructions and/or data implemented in accordance
with the present description upon a carrier medium. Suitable
carrier media include memory media as described above, as
well as signals such as electrical, electromagnetic, or other
forms of analog or digital signals, conveyed via a commu
nication medium such as networks and/or a wireless link.
[0105] FIGS. 2 and 3: Block Diagrams Of The System Of
to the Internet 170. As shown, one or more access control
access controller B and access controller C. As shown,
access controllers A and B are coupled to router A and router
B respectively. However, the access controller may be
located outside of the local network 130, e.g., may be
comprised on any of various locations on the Internet, as
shown with respect to access controller C.
[0107] In this embodiment, the data structure may store an
identification information/VLAN tag mapping, e.g., an SID/
VLAN tag mapping, which operates to map the user to the
appropriate VLAN of the user’s wireless service provider.
Thus, on the wired network to which the access points 120
are connected, the use of a different VLAN for each wireless
service provider operates to separate data traffic on the wired
network for each of the wireless service providers. It should
be noted that one or more of the access points 120 may
include software which implements a plurality of virtual
access points, described above, each of which may corre
spond to a particular wireless service provider or VLAN.
[0108] As shown, each of VLAN1, VLAN2 and VLAN3
may be supported by one or more Ethernet switches which
support tagged VLANs (IEEE 802.1q). In addition, each
switch may also support IEEE 802.1p, which provides for
various quality of service (QoS) metrics. This enables the
switches to enforce certain predefined quality of service
metrics for any given port or virtual port contained within
the network. As shown in FIG.3, it is also noted that a router
may be present on more than one VLAN. As shown, FIG.
3 includes an 802.1q switch which couples to three access
points referred to as access point 1 (AP1), access point 2
(AP2), and access point 3 (AP3). As shown, a router labeled
Router C may be coupled to two or more VLANs as shown.
[0109] Using VLANs, each access point 120 preferably
has the ability to transmit/receive on one or more VLAN IPs
to one or more wireless service providers. This permits, but
does not require, that each wireless service provider use its
own network numbering plan. At most, each wireless service
provider may have an access controller and a router at each
coverage location. As shown in FIGS. 2 and 3, the access
controller is not required to be physically located at the
coverage location, but rather may be located anywhere.
[0110] FIG. 4—Multiple WSP Network Access
[0111] FIG. 4 is a flowchart diagram illustrating a method
of allowing roaming access and/or selective access to a
wireless network system. In one embodiment, as described
above, the PCD 110 includes wireless service provider
identification information (called “identification informa
tion” herein), preferably comprising a System ID, stored in
FIG. 1
the memory of the PCD 110. The identification information
[0106] FIG. 2 is a more detailed block diagram illustrating
a portion of the wireless network system of FIG. 1. FIG. 2
illustrates an embodiment having three access points 120
(A-C) which couple to respective VLANs, labeled VLAN1,
wireless service providers to which the user of PCD 110 is
a subscriber. As noted above, the System ID may be an IEEE
VLAN2 and VLAN3. VLAN1, VLAN2 and VLAN3 in turn
wireless network.
may include information which identifies one (or more)
802.11 SSID or ESSID. The wireless service identification
information may also be an IP address in a Bluetooth
APPENDIX AB
US 2004/021.4572 A1
[0112] The network access method of the present inven
tion may be operable to receive and use the identification
information to facilitate roaming, e.g., to allow a particular
wireless service of a plurality of possible wireless services
to be selected and used for a user operating on the network.
As discussed further below, the identification information
may also store access level information which may be used
to indicate a network access or privilege level. This stored
access level information may be used to selectively allow
user access to different parts of the network.
[0113] As shown, in step 402 the user connects to the
network (e.g., to an access point of the network). For
example, the user may be walking in an airport with a
portable computing device and may connect in a wireless
fashion to an access point located at the airport. In another
scenario, the user may enter a hotel room and connect in a
wireless fashion to an Ethernet port in his/her room which is
connected to the network. In another scenario, the user may
enter an office of a business, such as a law firm or corpo
ration, and may connect in a wireless fashion to an access
point located in that office. Thus, the user may connect to the
network or an access point of the network in any of various
locations in a wireless fashion.
[0114] In step 404 the personal computing device (PCD)
110 of the user may transmit wireless service provider
(WSP) identification information (ID information) to an
access point (AP) 120 of the network. The identification
information may take any of various forms. In one embodi
ment, the identification information comprises a System ID
(SID), e.g., an ESSID, according to IEEE 802.11. As dis
cussed above, IEEE 802.11 (wireless Ethernet) is designed
to support multiple overlapping wireless LANs in a given
coverage area. IEEE 802.11 uses the System ID (SID), or
ESSID, to “select” which LAN to use, and thus the access
point with which to associate. In this embodiment each
System ID may be uniquely associated with a respective
wireless service provider, and thus the user may configure
the System ID on his/her PCD 110 to uniquely identify the
wireless service provider which the user has selected or to
which the user has subscribed. The identification informa
tion may also or instead be a MAC (media access controller)
ID which is comprised on a wireless Ethernet card of the
personal computing device used by the user. The MAC ID
may perform a similar purpose in selecting the wireless
service provider. As noted above, the identification infor
mation may take various forms. For example, the identifi
cation information may simply comprise the name of the
respective provider and the appropriate access information,
which may be contained in a digital certificate. In various
embodiments, the identification information may comprise
other types of wireless service provider identification as
desired.
[0115] In prior art systems, access points are only able to
“listen for’’ one System ID which corresponds to one wire
less service provider. According to one embodiment of the
invention, each access point 120 may be operable to “listen
for’’ or “detect” a plurality of different sets of identification
information, e.g., a plurality of different System IDs, which
may correspond to a plurality of different possible wireless
service providers, or which may correspond to unknown
wireless service providers. Thus, each AP may be set up to
“listen” for all types of identification information, e.g., listen
for all SIDs, and to answer all queries from PCDs 110, even
Oct. 28, 2004
if the identification information or SID is not recognized by
the particular AP 120. Alternatively, each of the access
points may be operable to broadcast requests for identifica
tion information. For example, each of the access points may
periodically broadcast requests for SIDs. Alternatively, each
of the access points may periodically broadcast recognized
System IDs to the PCDs, i.e., broadcast the sets of SIDs the
access point supports, wherein the PCDs may respond to this
broadcast by providing the identification information.
[0116] In step 406 the access point 120 to which the user
has connected may transmit known geographic location
information to the network (e.g., to a wireless service
provider on the network). This known geographic location
information may originate from the AP 120 or from the PCD
110 of the user. As discussed further below, this known
geographic location information may be used in various
ways. For example, the geographic location information
may be used in selecting among two or more possible
wireless service providers to which the user has previously
subscribed, or may be used in selecting the default provider.
[0117] The geographic location information may also be
used in determining the network services or access privi
leges of the user, or used in determining charging aspects of
the use. For example, this known geographic location infor
mation may be used to determine whether a third party pays
for the network access of the user. As one example, an
employer of the user (employee) may have previously
directed that the employer will pay for network access of the
employee if the employee is located in an airport or hotel,
but not if the employee is located, for example, in a bar. The
known geographic location may also be used to determine a
charge rate, based on various incentive or sponsorship
programs of which the user is a member. For example, the
user may receive a discount if he/she uses network access
from certain locations, such as a certain business, a certain
airport club, etc. The known geographic location informa
tion may also be used to selectively provide different access
or privilege levels based on the geographic location, e.g., a
user may have greater privilege/access levels at a first
geographic location than from a second different geographic
location. This known geographic location information may
further be used to provide services to the user which are
dependent upon the geographic location of the user. For
more information on the use of geographic location infor
mation for providing geographic based services, please see
U.S. Pat. No. 5,835,061, referenced above.
[0118] In step 412 the wireless service provider may
examine the received identification information, e.g., the
System ID, or other identification information and determine
whether the received identification information is known or
recognized. In step 412 the method may also determine if
other id information is valid. If the identification information
is determined to not be known, e.g., the System ID is
unknown, then in step 422 the method may perform pro
cessing to account for the unknown identification informa
tion. Step 422 may also involve performing processing for
an unknown or incorrect digital certificate or other unknown
information.
[0119). In step 422, where the identification information is
determined to not be known or recognized, the method may
select a default wireless service provider for the user for
network access. The default wireless service provider may
APPENDIX AB
US 2004/021.4572 A1
be the provider who maintains the wireless network system
being used, or may be a randomly selected provider. In step
423 the user may be required to register with this provider
to gain network access. This provider may then arrange for
ad hoc billing of the user, such as by credit card. For
example, the provider may present a web page on the user’s
PCD 110 requesting the user to enter credit card information
for access to the network. Operation then proceeds to step
432.
[0120] Also, if the identification information is determined
to not be known, the access or privilege level of the user may
be set to the lowest possible level. This, for example, may
allow the user to only have access to certain limited local
resources, but no external access, e.g., to the Internet. Thus,
for example, where the APs 120 are located in an airport, the
user having a low access level, e.g., the user whose identi
fication information is not known, may be granted access to
certain local resources, such as coffee shops, bookstores, and
advertising on the local LAN at the airport, but may not be
provided with Internet access. Access to local resources may
be allowed since this does not require the use of external
facilities and hence does not consume off-property band
width, and thus is relatively inexpensive to provide. Alter
natively, if the identification information of a user is deter
mined to not be known, the system may provide some form
of external access, which may be billed separately by an
external Internet provider, without the user being able to
view or use any local network resources.
[0121] If known identification information is determined
to be received in step 412, then in step 416 the method may
determine the wireless service provider which corresponds
to the identification information (e.g., the System ID). In the
preferred embodiment, a data structure comprising wireless
service provider information is stored in each of the access
points 120. In this embodiment, the respective access point
with which the user is communicating receives the identi
fication information and uses the identification information
to obtain the appropriate or corresponding wireless service
provider to which the user of the PCD 110 is subscribed. In
step 418 the respective access point 120 may also access the
data structure to determine the appropriate access method or
access level for providing data or packets to the respective
wireless service provider. For example, the respective access
point 120 may access the data structure to analyze the
respective SID/VLAN tag to determine the VLAN tag to use
for the respective wireless service provider. In one embodi
ment, the respective access point 120 may instead access this
information from a separate data structure stored in MIB
150.
[0122] In an alternate embodiment, the PCD 110 of the
user may provide all of this information to the access point
120. In this embodiment, the data structure containing the
wireless service provider data and access information may
not be required to be stored in the access points 120 or on
the network. Alternatively, data may be stored on the net
work 130, e.g., in the access points 120 or in the MIB 150,
which is used only to validate this information received from
the user.
[0123] As discussed above, the data structure is preferably
a table comprising a plurality of three-tuples wherein each
tuple stores a set of identification information, the corre
sponding wireless service provider associated with that
Oct. 28, 2004
identification information, and access information associ
ated with that wireless service provider and/or the user. An
example of this data structure is shown in FIG. 5. The data
structure shown in FIG. 5 includes five different sets of
three-tuples. It is noted that the data structure may take any
of various forms.
[012.4] The access information may include an access
method, possibly including a destination address, or other
method by which data packets are routed to/from the respec
tive site of the wireless service provider, or other method
which directs that network access be provided by that
wireless service provider. The access information may also
include a SID/wired transport mechanism mapping, such as
a SID/VLAN tag mapping. The access information may also
include an access level or privilege level that indicates
which network resources that the user may access, e.g.,
whether the user is only allowed access to resources on the
local network 130, or is only or in addition allowed external
access, such as Internet access.
[0125] Thus, when the access point 120 receives the
identification information, the access point may simply use
the identification information to index into a table containing
this information to determine the appropriate wireless ser
vice provider and the respective access method and/or
access level.
[0126] It is noted that each of steps 412,416 and 418, and
422 may be performed as one action or a series of related
actions. In other words, when the access point 120 receives
the identification information, if the identification informa
tion does not index into any of the entries in the data
structure or table, then the identification information or
System ID is determined to be unknown or not associated
with a respective wireless service provider as determined in
step 412. In this case, the default provider and default access
level may be selected as performed in step 422. If the
identification information does index properly into an entry
of the table, but the corresponding wireless service provider
does not have the necessary equipment to accommodate the
user, then this may also be treated as unknown identification
information, where another provider or the default provider
may be selected as performed in step 422.
[0127] If the identification information properly indexes
into the table, then in steps 416 and 418 information from the
respective entry of the table is accessed and used to deter
mine a corresponding wireless service provider which can
accommodate the user’s network access, as well as the
associated method and access level for providing network
access using the wireless service provider.
[0128] After the wireless service provider and associated
access method/level have been determined in each of steps
416 and 418, then in step 432 network access or network
services may be provided to the portable computing device
110 through the determined wireless service provider. For
example, in step 432 the access point 120 with which the
user is communicating may operate to provide data to/from
a destination specified by the determined wireless service
provider using the method specified by the determined
wireless service provider, e.g., the method comprised in the
table or data structure. In one embodiment, the access point
120 may operate simply as a bridge or router which operates
to forward or route packets to the appropriate destination,
e.g., to the wireless service provider’s network device 160 or
APPENDIX AB
US 2004/021.4572 A1
to the provider’s site. As noted above, the wireless service
provider may provide a network device 160 such as a router,
which operates to route packets to the provider’s site or
otherwise simply allow Internet access to the user. Thus in
step 432 the method allows the personal computing device
of the user access to the network using the user’s provider.
[0129] In another embodiment, the access point 120 itself
operates as a router to route packets to the determined
wireless service provider’s site, which may be located on the
Internet. Thus, in this embodiment, the wireless service
provider may not be required to provide any type of network
device 160 to enable network access for its respective
subscribers. Rather, data packets from the PCD 110 of the
user may be routed to the wireless service provider’s site on
the Internet, which may be located in any location.
[0130] In step 432 data is communicated between the PCD
110 and the respective destination specified by the wireless
service provider preferably using a secured technique.
Examples of possible secured techniques include Layer 2
forwarding; various tunneling protocols such as PPTP,
IPSEC, GRE, and IP-in-IP; and tagged VLANs (IEEE
802.1q), among others.
[0131] In one embodiment, in step 432 the access point
120 operates to direct PCDs 110 to an available communi
cation channel, e.g., an available RF channel or other
wireless channel, possibly based on information received
from the PCD 110. Thus the access point 120, not the PCD
110, may assign channels for communication. For example,
the access point 120 may operate to direct a PCD 110 to an
available communication channel (e.g., an RF channel)
based on the identification information, e.g., the SID,
received from the PCD 110. The access point 120 may also
operate to direct the PCD 110 to an available communication
channel based on other types of identification or authenti
cation information, or on the determined access level of the
PCD. This allows an access point 120 to separate the
communication traffic onto different channels based on the
wireless service provider being used, or based on the access
or privilege level of the PCD 110. For example, the access
point 120 may assign a PCD 110 a communication channel
based on whether the PCD 110 has access to private portions
of the network.
[0132] In step 434 the selected wireless service provider
may record charges for the network access. In one embodi
ment, each of the wireless service provider’s respective
devices 160 may maintain separate charge/billing informa
tion for each of their respective subscribers. Thus, the
network device 160 of the selected wireless service provider
may record charges for the network access of the user.
Alternatively, a computer system coupled to the network
130, such as the MIB 150, or another computer system, may
receive information from the wireless access point 120 as to
the determined wireless service provider, and the computer
system may maintain billing/charging information for each
of a subset or all of the wireless service providers. In one
embodiment, billing information for the user may be stored
on the PCD 110 and may be provided to the AP 120.
[0133] As noted above, network charging information
may also be based on known geographic information, as
well as, for example, sponsorship or demographic informa
tion of the user, which may be provided to the access point
in a digital certificate.
Oct. 28, 2004
[0134] As noted above, the data structure or table con
taining wireless service provider information may be stored
in each of the access points 120. Alternatively, the data
structure may be stored in a separate computer system, such
as the MIB 150. In this latter instance, each of the access
points 120 may operate to forward the identification infor
mation to the MIB or other computer system 150, and this
computer system may perform steps 412, 416 and 418 of
determining the appropriate wireless service provider and
corresponding access method, or selecting the default pro
vider. Once the wireless service provider and access method
have been determined in this embodiment, this information
may be forwarded to the respective access point 120 for
proper routing, or the respective access point 120 may
forward data received from the PCD 110 of the user to the
MIB 150 or an associated router for proper routing to the
respective wireless service provider’s device 160 or to the
appropriate site on the Internet.
[0135] Thus, in step 432 the PCD 110 of the user is
allowed to obtain network access through his previously
chosen wireless service provider, i.e., through the wireless
service provider to which the user has previously sub
scribed. As noted above, the wireless service provider, may
operate to maintain billing/charging information through its
equipment 160, at its site, or through a shared resource such
as MIB 150. As also noted above, the billing information
may be stored on the PCD 110 of the user, e.g., in the user’s
digital certificate. In this case, if the AP 120 answers the
query of the PCD 110 and allows access after confirming the
identification information, the system allows for roaming
and billing. This effectively allows users to roam on various
network infrastructures, e.g., allows a user who is a sub
scriber of wireless service provider A to roam on a network
infrastructure operated and maintained by wireless service
provider B. Alternatively, certain portions of the network
infrastructure may be built and maintained by a third party
who is not a wireless service provider, and subscribers of
each of the various wireless service providers may be able
to roam onto this network, perhaps with a small fee being
paid to the manager of the network infrastructure in addition
to the fee normally paid to the wireless service provider for
network access. Further, users who have never previously
subscribed to a wireless service provider may be allowed to
communicate with an AP 120 and select a wireless service
provider, or be assigned the default wireless service pro
vider, for network access.
[0136] Different Access Levels
[0137] As noted above, in one embodiment, the data
structure or table may store one or more different access
methods depending upon an access level received within the
identification information. Thus, referring back to FIG. 1,
the network 130 may provide certain local network
resources as well as external Internet access which may both
be available to users having a first access level. Users with
a second, lower, access level may not be entitled to external
access, but may be simply able to view or utilize certain
local network resources on network 130. Users may also be
selectively allowed to make 802.11 voice calls using the
network, depending on access level.
[0138] For example, in an airport scenario, a non-recog
nized user, or a user paying a lower fee, may have an
access/privilege level that only allows him/her access to
APPENDIX AB
US 2004/021.4572 A1
Oct. 28, 2004
local content such as various airport advertising, airport
information such as the layout of the airport, including
where the restrooms, restaurants, etc. are located, flight
information, etc., but does not allow the non-recognized user
external access, e.g., access to the Internet. A non-recog
nized user would of course also not have any access to
private corporate LANs maintained on this network, such as
the corporate LANs of airlines located at the airport.
[0139] If the wireless network system provides a mecha
nism for the user to register or subscribe to a wireless service
provider, then the user may do so and receive Internet access
through that selected provider. As another alternative, the
network system may provide a mechanism for the user to
register or subscribe to an external wireless service provider,
e.g., an external ISP, perhaps with a small referral fee paid
to the maintainer of the network system.
[0140] Alternatively, the network 130 may provide vari
the business who is physically present in the office and
desires Internet access may utilize his PCD 110 to gain
access to the Internet through the local network of the office
130, without the visitor or customer being able to view any
of the computing resources, file servers, etc., of that local
network 130. In addition, if the user’s corporate intranet is
web-based, the user may be allowed access to his own LAN
computing resources remotely. This allows a business to
provide customers and visitors with Internet access through
its network 130 without compromising the security of the
ous local resources as well as external Internet access which
points 120 are comprised in an airport, a user may have a
greater access level and hence access to more network
resources from, for example, an airline club such as an
Admiral’s club, and the same user may have a lesser access
may both be available to users having a first access level, and
users with a second access level may not be entitled to view
or utilize these local network resources on network 130, but
may be simply provided some form of external access, such
as external telephone access using Voice over Internet Pro
tocol (VoIP) or possibly a pathway to the Internet.
[0141] For example, where the network 130 and one or
more wireless access points 120 are comprised in an airport,
one or more airlines may maintain various computing
resources on the local network 130 which are usable solely
by airline employees and personnel. In this embodiment,
PCDs 110 of airline employees may comprise identification
information which indicates an access level that allows them
access to the various computing resources on the network
130. Thus, employees of a first airline such as American
Airlines may have first access level information stored on
network 130.
[0143] As noted above, in one embodiment, the known
geographic location information may also be used to selec
tively provide different access or privilege levels based on
the geographic location, e.g., a user may have greater
privilege/access levels at a first geographic location than
from a second different geographic location. For example,
where the network 130 and one or more wireless access
level and hence access to fewer network resources from an
airline gate. Thus the access level of a user may be based at
least partly on the geographic location of the user. This may
possibly be based on various agreements negotiated by
service providers to “reward” users who are present at their
geographic location. In a similar manner, the network charge
rate may also be based on the geographic location of the
|USè?.
[0144] Thus, in step 418, where the method determines an
access method for the wireless service provider, the method
may also determine one or more access levels or privilege
levels contained within the identification information to
Airline computing resources on the network 130, whereas
employees of Delta Airlines may have second, different,
determine whether the user should be provided with Internet
access or should only have access to local resources on the
network. The method may also determine the known geo
graphic location of the user to aid in determining the access
access level information stored on their PCDs 110 which
level as described above.
their PCD 110 that entitles them to utilize certain American
enables use of only Delta Airlines computing resources
located on the network 130, etc. Those users who are not
airline employees or personnel may have access information
stored on their PCDs 110 which only allows them external
access to the Internet and use of certain non-private local
resources, but does not allow them to view or use any of the
private computing resources on the network 130. Thus,
PCDs 110 of users may store various access level informa
tion comprised within the identification information which
selectively allows access to certain resources on the local
network 130. This effectively facilitates private and public
portions of the network 130.
[0142] As another example, consider an office, such as a
law firm office or business which maintains one or more
wireless or wired access points 120. Employees of the office
may have first access level information (possibly of varying
degrees) stored on their PCDs 110 which grants them access
to selected resources or all resources on this network 130.
However, visitors to this office which do not have this
privilege or access level may be detected by a wireless or
wired access point and not be allowed to view or use any of
the resources on the local network 130, but rather may
simply be provided a port for complimentary (or billable)
external access to the Internet. Thus, a visitor or customer of
[0145] In step 432 the access point 120 or MIB 150 or
other device operates to provide or route data depending
upon this access level. Thus, users with the appropriate
access level may have Internet access as well as be able to
view and use resources on the network 130, while users
lacking this necessary access level may simply be provided
with certain local network resources and not have any
Internet access. Alternatively, users having a lower access or
privilege level may be provided some form of external
access, such as local telephone access using VoIP. 802.11
voice calls, or possibly complimentary Internet access, with
out being able to view or use certain private network
?eSOUITCeS.
[0146] FIG. 6: Selective Access To A Wireless Service
Provider
[0147] FIG. 6 illustrates one exemplary embodiment,
where a PCD 110A of a first user comprises identification
information including an access level which indicates that
the user has access only to the computing resources on the
local network 130. In this instance, once this access level has
been verified, such as by a lookup in the table or data
structure, data or packets from the PCD 110A may be routed
to various computing resources on the local network as
APPENDIX AB
US 2004/021.4572 A1
shown by the arrows designated “1”. For example, packets
from PCD 110A may be routed to virtual access point 602B
which is associated with local network 130. In contrast, PCD
110B of a second user comprises identification information
which includes a higher access level which encompasses
accessing local resources on network 130 as well as Internet
access. In this instance, in addition to local network access,
data or packets may also be routed from the PCD 110B
through the access point 120 and directly out to an external
access port for Internet access. Thus, the user who does not
have the appropriate access or privilege level is able to view
or use any computing resources on the network 130, but
cannot gain Internet access through the network 130. As
noted above, the system can also be configured whereby the
user who does not have the appropriate access or privilege
level is only allowed Internet access, and users with higher
privilege levels are able to view or use computing resources
on the network 130.
[0148] Thus, the present invention enables two or more
wireless service providers to utilize a common set of wire
less or wired access points to provide their respective
services to a potentially overlapping set of customers. This
allows use of a single network infrastructure, which mini
mally impacts the wireless spectrum available at a location
while allowing the maximum possible number of wireless
service providers to offer their network access services. In
addition, the system and method described herein allows
subscribers of a wireless service provider A to be able to use
the network access service provided by wireless service
provider B in a location otherwise not serviced by provider
A without necessarily requiring any relationship with pro
vider B and vice versa. This allows a confederation of
wireless service providers to offer network access to a larger
footprint of locations, which offers more value to each of
their respective subscribers.
[0149] The system may thus allow network access from
multiple different providers. For example, one communica
tion service may be referred to as a Wayport network
(Wayport is a Registered Trademark of Wayport, Inc. of
Austin, Tex.). A Wayport network may be compatible with
other types of similar networks maintained by other com
panies. For example, if Wayport networks are installed in the
Austin-Bergstrom International airport and similar ‘XYZ’
networks are installed in a hotel in downtown Austin, a user
that has subscribed to Wayport networks may be able to use
the services offered at the downtown hotel by XYZ. More
specifically, a user that has registered with a Wayport
network (e.g., has entered demographic data and agreed to
pay transaction costs) may not need to register with XYZ.
The user may use other wireless service providers (e.g.,
XYZ networks) and still only be billed from one company
(e.g., the provider of the Wayport network with which the
user is registered). This may be accomplished through
agreements established between different wireless service
providers.
[0150] In one example, a Wayport network-registered user
attempts to connect to the XYZ network in the downtown
hotel. In the embodiment described herein, the access point
120 maintained by the XYZ network still answers or com
municates with the PCD 110, even though the PCD 110
provides identification information that is different from,
and possibly not even recognized by, the access point 120.
In this example, assume the XYZ network notices from the
Oct. 28, 2004
PCD ID information that the user is not registered on the
XYZ network, but is registered on the Wayport network. The
XYZ network may perform a verification of the PCD ID by
querying a database of registered PCD IDs on the Wayport
network. The XYZ network may acquire demographic infor
mation from, or using, the credentials of the user. If the
credentials of the user are not acceptable, access to the XYZ
network may be denied. If the credentials are acceptable, the
XYZ network may grant the user access to various goods,
information and/or service providers. The XYZ network
may inform the user (via a message on the user’s PCD) that
there is an additional cost for accessing the XYZ network as
a non-registered user. The user may then have the choice of
paying the additional fees for the services or disconnecting.
In addition, the user may have the option of registering with
the XYZ network to avoid paying “roaming’ fees.
[0151] Wireless AP Usage of Multiple Channels
[0152] A wireless access point 120 can use one of a
plurality of different RF (radio frequency) channels for
communication with portable computing devices of users.
For example, a wireless access point 120 can use one of RF
channels 1 through 11. As is well known, RF channels 1, 6
and 11 are non-overlapping, with the remainder of these
channels being partially overlapping with other channels.
[0153] According to one embodiment of the present inven
tion, each wireless access point can communicate on one or
more, e.g. a plurality of or all of, the available wireless
channels, e.g., the available RF channels. Furthermore, each
access point 120 can control which channel the portable
computing device 110 of a client is able to use. In one
embodiment, each portable computing device may scan each
of the RF channels until it detects a wireless access point 120
on one of the channels.
[0154] In one embodiment, one or more of the wireless
access points may each utilize a plurality of the RF channels,
e.g., may use each of the non-overlapping channels 1, 6 and
11 to effectively provide up to three times the normal
channel capacity. Thus, the wireless access point 120 may be
able to control allocations of a plurality or all of the
respective RF channels to selectively obtain higher band
width when appropriate, or to simply accommodate a greater
number of subscribers. Thus, if a wireless access point using
only one RF channel could only handle fifty PCDs 110 on
that respective channel, the wireless access point may oper
ate to use all three non-overlapping RF channels to effec
tively triple this capacity to a total of 150 simultaneous
PCDs 110.
[0155] As another example, if the wireless access point
120 is only communicating with one portable computing
device 110, then the wireless access point 120 may option
ally or selectively use each of the three non-overlapping RF
channels to produce effectively three times the bandwidth
for this communication. As additional portable computer
devices engage in communication with the respective wire
less access point, 120, the wireless access point 120 may
selectively allocate different channels to different ones of
these PCDs as needed. Further, if more than three PCDs are
communicating with the respective wireless access point,
the wireless access point 120 may partition one or more of
the respective channels for the respective users, such as by
using wireless Ethernet Collision Sense Multiple Access/
Collision Detection (CSMA/CD) or other multiple access
schemes such as TDMA, FDMA, or CDMA, among others.
APPENDIX AB
US 2004/021.4572 A1
[0156] In one embodiment, as described above with
respect to step 432, the access point 120 operates to direct
PCDs 110 to an available channel, possibly based on infor
mation received from the PCD 110. Thus the access point
120, not the PCD 110, may assign channels for communi
cation. For example, the access point 120 may operate to
direct a PCD 110 to an available communication channel
(e.g., an RF channel) based on the identification information,
e.g., the SID, received from the PCD 110. The access point
120 may also operate to direct the PCD 110 to an available
communication channel based on other types of identifica
tion or authentication information, or on the determined
access level of the PCD. This allows the access point 120 to
separate the communication traffic onto different channels
based on the wireless service provider being used, or based
on the access or privilege level of the PCD 110. For
example, the access point 120 may assign a PCD 110 a
communication channel based on whether the PCD 110 has
access to private portions of the network.
[0157] FIG. 7: Initial PCD Communication with AP
[0158] FIG. 7 is a flowchart diagram illustrating operation
of initial communication of a user’s PCD with an access
point in a wireless distributed network system, according to
one embodiment of the invention. Here it is presumed that
a user having a PCD comes within proximity of an AP and
begins wireless communication with the AP As shown in
step 702 the AP detects the PCD. Here it is noted that several
different mechanisms may be used to initiate communication
between an AP and a PCD. In one implementation, the PCD
may transmit a “probe” signal to the AP containing an SID,
e.g., an ESSID as specified in IEEE 802.11, indicating a
particular WSP. Here it is presumed that the PCD stores the
SID, e.g., the ESSID, corresponding to a pre-selected WSP
to which the user of the PCD has previously subscribed. The
AP may then respond to the probe by transmitting connec
tion information corresponding to this ESSID. In this imple
mentation, the PCD simply transmits the ESSID to the AP to
indicate to the AP the selected WSP of the PCD. In a second
implementation, the AP may “beacon” or provide continu
ously a list of ESSIDs corresponding to all of the WSPs that
are supported by that AP. As noted above, each supported
WSP has a corresponding ESSID and also has a correspond
ing virtual AP, i.e., virtual AP software comprised on the
physical AP that implements or presents a virtual AP that is
used for that WSP. In this implementation, the AP continu
ously broadcasts or beacons the list of possible ESSIDs. The
PCD receives this beacon, analyzes the possible ESSIDs,
and selects an ESSID to provide back to the AP For
example, if the PCD has previously registered with or
subscribed to a chosen WSP, and the PCD detects that the
ESSID of this previously selected WSP is included in the
beacon, then the PCD typically will select the WSP and
transmit the ESSID corresponding to the previously selected
WSP. If the PCD has previously subscribed with a WSP that
is not present in the list of beaconed ESSIDs that are
beaconed by the AP, then the PCD may use some secondary
choice or algorithm to select a WSP that is supported by this
AP, even though the PCD may not have previously sub
scribed with or have a relationship with this WSP. For
example, the PCD may simply select a default WSP from the
list of available WSPs if the preferred WSP is not supported
by that AP Alternatively, the PCD may analyze signal
strength or may utilize billing/charging information in
Oct. 28, 2004
evaluating which WSP to select based on the list of available
WSPs as indicated by the list of ESSIDs transmitted by the
AP.
[0159] In step 704 the PCD then transmits the ESSID to
the AP in a data packet. As noted above, the transmitted
ESSID may be the ESSID that is stored on the PCD which
corresponds to the WSP previously selected by the PCD, i.e.,
to which the PCD has previously subscribed. Alternatively,
the PCD may transmit an ESSID that is selected from a list
of possible ESSIDs beaconed by the AP
[0160] In step 706 the software executing on the AP (or
device coupled to the AP) operates to extract user ID
information from the packet received from the PCD. In one
embodiment, the user identification information may com
prise a MAC ID of the network interface card (NIC)
comprised on the PCD. Alternatively, the user ID informa
tion may comprise any other information that is suitable for
particularly identifying either the user or the PCD of the
user. The user ID information is preferably comprised in
each packet transmitted by the PCD to enable each packet to
be properly routed to a corresponding virtual AP and wired
transport mechanism as discussed below.
[0161] In step 708 the software executing on the AP stores
the user ID information, e.g., the MAC ID, into a table
corresponding to the ESSID transmitted by the PCD in step
704. Thus, in step 708 the user ID information is associated
with the ESSID and hence with the selected WSP. As
discussed further below, this table can later be accessed on
receipt of subsequent packets to associate the user ID
information contained in received packets with the corre
sponding ESSID and hence with the chosen WSP and
corresponding wired transport mechanism, e.g., VLAN tag.
[0162] In step 710 the AP determines the wired transport
mechanism, e.g., the VLAN tag based on the ESSID.
[0163] Finally, in step 712 the virtual AP software corre
sponding to the determined ESSID executes and operates to
transmit the packet into the wired network (VLAN) using
the wired transport mechanism, e.g., using the VLAN tag
that corresponds to the ESSID,
[0164] FIG. 8: PCD Communication with AP
[0165] FIG. 8 is a flowchart diagram illustrating operation
of PCD communication with an AP after an association
event has occurred, i.e., after the method described in FIG.
7 has been executed to create an entry in the table of the AP
associating the user ID information of the PCD with a
corresponding ESSID and hence with a selected WSP.
[0166] As shown, in step 802 the AP receives a packet
from the PCD. Each packet provided from the PCD com
prises or includes user ID information which identifies the
source or the PCD from which the packet originates.
[0167] In step 804 the AP determines the user ID infor
mation comprised within the packet. In one embodiment, the
user ID information is a MAC ID as discussed above.
However, the user ID information may comprise other types
of identification, such as an IP address as specified in the
Blue Tooth wireless communication standard.
[0168] In step 806 the AP accesses the table comprised
within the AP to determine the corresponding ESSID and
wired transport mechanism based on the user ID informa
APPENDIX AB
US 2004/021.4572 A1
tion. In other words, when the association event occurs
Oct. 28, 2004
to utilize a common set of access points to provide service
to a potentially overlapping set of customers, thus providing
subscribers or users with the ability to more fully utilize the
existing network infrastructure. The system and method
further provide a distributed wireless network system which
can selectively provide different access levels to users of the
initially between the PCD and the AP, the table entry is
created as described above in step 708; this table is then
accessed on receipt of subsequent packets transmitted by the
PCD to determine the ESSID and wired transport mecha
nism, e.g., VLAN tag, based on the user ID information.
Thus, the table association created in step 708 is accessed in
step 806 for each subsequent packet.
[0169] In step 808 the virtual AP software corresponding
to the determined ESSID transmits the packet received from
the PCD onto the wired network using the determined wired
transport mechanism. For example, the virtual AP may
transmit the packet onto a LAN using the VLAN tag
determined in step 806.
[0170] FIG. 9: Packets Arriving from Wired Medium to
[0178] While the present invention has been described
with reference to particular embodiments, it will be under
the AP Destined for a PCD
What is claimed:
[0171] FIG. 9 is a flowchart diagram illustrating operation
when incoming packets arrive at the AP from the wired
1. An access point for providing network access to a
plurality of computing devices, wherein the access point is
operable to couple to a network, the access point compris
medium which are destined for one of the PCDs in com
munication with the AP
[0172] As shown, in step 902 the AP receives a packet
from the wired medium that is intended for one or more
PCDs that are in communication with the AP
[0173] In step 904 the AP operates to parse the packet to
determine the VLAN tag associated with the arriving packet,
i.e., or comprised within the arriving packet, and also to
determine the destination user ID information contained
within the incoming packet. Incoming packets received from
the wired medium may include user ID information corre
sponding to the destination PCD. For example, in IEEE
802.11 wireless Ethernet, the incoming packet may include
a MAC ID corresponding to the destination network inter
face card (NIC) of the PCD. This user ID information is
extracted or obtained from the packet in step 904.
[0174] In step 906 the AP may optionally ensure that the
arriving packet arrived on a VLAN corresponding to the
VLAN tag determined in step 904 as a security mechanism.
In general, the incoming packet should arrive on the VLAN
corresponding to the VLAN tag contained or comprised
within the packet. If this is determined to not be the case in
step 906, than the packet may be a spurious packet or present
a security issue, and the packet may simply be dropped.
[0175] In step 908 the AP software accesses its table(s) to
determine the virtual AP associated with the user ID infor
mation obtained in step 904. Thus, in step 908 the user ID
information may be used in conjunction with the table to
determine the virtual AP corresponding to the user ID
information. As noted above, there is preferably a 1 to 1
correspondence between an ESSID, a corresponding wire
less service provider, and a corresponding virtual AP.
[0176] In step 910 the virtual AP software executes on the
physical AP to wirelessly transmit the packet received from
the wired medium to the PCD as a wireless transmission.
[0177] Therefore, FIGS. 7, 8 and 9 disclose one embodi
ment of a system and method operating in a distributed
wireless network system based on IEEE 802.11 wireless
Ethernet which operates to allow multiple wireless service
providers to use a common network infrastructure. Addi
tionally, the system and method described above with ref
erence to FIGS. 1-9 allows a plurality of service providers
system.
stood that the embodiments are illustrative and that the
invention scope is not so limited. Any variations, modifica
tions, additions, and improvements to the embodiments
described are possible. These variations, modifications,
additions, and improvements may fall within the scope of
the inventions as detailed within the following claims.
Ing:
a processor;
a memory medium coupled to the processor, wherein the
memory medium comprises program instructions
executable by the processor, wherein the program
instructions are executable to:
receive a plurality of System IDs (SIDs), wherein at
least two of the plurality of SIDs are used for
providing wireless Ethernet; and
concurrently utilize the at least two of the plurality of
SIDs to communicate with the plurality of comput
ing devices, wherein, in communicating with the
plurality of computing devices, the program instruc
tions are further executable to use wireless Ethernet.
2. The access point of claim 1,
wherein the memory medium further comprises a plural
ity of SIDs for broadcasting;
wherein the program instructions are further executable
to:
retrieve at least two SIDs of the plurality of SIDs for
broadcasting from the memory medium; and
broadcast the at least two SIDs of the plurality of SIDs
for broadcasting.
3. The access point of claim 2,
wherein the broadcast comprises a beacon format.
4. The access point of claim 2,
wherein the program instructions are further executable
to:
implement a wireless protocol stack.
5. The access point of claim 4, wherein the wireless
protocol stack comprises an IEEE 802.11 protocol stack.
6. The access point of claim 1, wherein the plurality of
SIDs comprise a plurality of IEEE 802.11 System IDs.
7. The access point of claim 1, wherein the plurality of
SIDs comprise a plurality of IEEE 802.11 Service Set IDs
(SSIDs).
8. The access point of claim 1, wherein the plurality of
SIDs comprise a plurality of IEEE 802.11 Extended Service
Set IDs (ESSIDs).
APPENDIX AB
US 2004/021.4572 A1
9. The access point of claim 1, wherein the plurality of
SIDs comprise a plurality of IEEE 802.11 Basic Service Set
IDs (BSSIDs).
10. The access point of claim 9,
wherein the plurality of BSSIDs comprise at least one
media access control (MAC) ID.
11. The access point of claim 9,
wherein the plurality of BSSIDs comprise a plurality of
media access control (MAC) IDs; and
wherein a first MAC ID of the plurality of MAC IDs is
different from a second MAC ID of the plurality of
MAC IDS.
12. The access point of claim 1,
wherein the memory medium further comprises a data
structure comprising a list of SID entries each indicat
ing at least one wireless service provider of a plurality
of possible wireless service providers;
wherein the program instructions are further executable
to:
determine if a received SID of the plurality of SIDs is
comprised in the list of SID entries, wherein, in
determining if the received SID of the plurality of
SIDs is comprised in the list of SID entries, the
program instructions are further executable to access
the memory medium and use the received SID; and
if the received SID of the plurality of SIDs is comprised
in the list of SID entries, determine a wireless service
provider indicated by the received SID and provide
data from a computing device of the plurality of
computing devices using the received SID to the
determined wireless service provider.
13. The access point of claim 12, wherein at least a subset
of the SID entries each indicate at least one VLAN.
14. The access point of claim 13,
wherein each VLAN specifies a wireless service provider.
15. The access point of claim 14,
wherein, in providing data from the computing device to
the determined wireless service provider, the program
instructions are further executable to use the at least
one VLAN indicated by the SID.
16. The method of claim 12,
wherein the program instructions are further executable
to:
if the received SID is not included in the SID entries,
provide data from a computing device of the plural
ity of computing devices using the received SID to a
default wireless service provider.
17. The access point of claim 16,
wherein, in providing data from the computing device to
the default wireless service provider, the program
instructions are further executable to use a default
VLAN.
18. The access point of claim 16,
wherein the memory medium further comprises a default
VLAN tag; and
Oct. 28, 2004
wherein, in providing data from the computing device to
the default wireless service provider, the program
instructions are further executable to use the default
VLAN tag.
19. The access point of claim 16,
wherein the memory medium further comprises a default
tunneling protocol; and
wherein, in providing data from the computing device to
the default wireless service provider, the program
instructions are further executable to use the default
tunneling protocol.
20. The access point of claim 12, wherein at least a subset
of the SID entries each indicate at least one VLAN tag.
21. The access point of claim 20,
wherein each VLAN tag specifies a wireless service
provider.
22. The access point of claim 21,
wherein, in providing data from the computing device to
the determined wireless service provider, the program
instructions are further executable to use the at least
one VLAN tag indicated by the SID.
23. The access point of claim 12, wherein at least a subset
of the SID entries each indicate at least one tunneling
protocol.
24. The access point of claim 23,
wherein, in providing data from the computing device to
the determined wireless service provider, the program
instructions are further executable to use the at least
one tunneling protocol indicated by the SID.
24. The access point of claim 24,
wherein the at least one tunneling protocol indicated by
the SID comprises PPTP.
25. The access point of claim 24,
wherein the at least one tunneling protocol indicated by
the SID comprises IPSEC.
26. The access point of claim 24,
wherein the at least one tunneling protocol indicated by
the SID comprises Generalized Routing Encapsulation
(GRE).
27. The access point of claim 24,
wherein the at least one tunneling protocol indicated by
the SID comprises IP-in-IP
28. The access point of claim 1,
wherein the memory medium further comprises a data
structure comprising a list of SID entries each indicat
ing at least one media access control (MAC) ID of a
plurality of possible MAC IDs;
wherein the program instructions further executable to:
determine if a received SID of the plurality of SIDs is
comprised in the list of SID entries;
wherein, in determining if the received SID of the plu
rality of SIDs is comprised in the list of SID entries, the
program instructions are further executable to access
the memory medium and use the received SID to
determine if the received SID of the plurality of SIDs
is comprised in the list of SID entries; and
APPENDIX AB
US 2004/021.4572 A1
Oct. 28, 2004
18
wherein the program instructions further executable to:
if the received SID of the plurality of SIDs is comprised
in the list of SID entries, determine a MAC ID
indicated by the received SID and communicate with
a computing device of the plurality of computing
devices using the received SID and the determined
MAC ID.
29. The access point of claim 28,
wherein a first MAC ID of the plurality of MAC IDs is
different from a second MAC ID of the plurality of
MAC IDS.
30. The access point of claim 1,
wherein a subset of the plurality of computing devices are
portable computing devices.
31. The access point of claim 1,
wherein the memory medium further comprises a data
structure comprising a list of VLAN tag entries each
indicating at least one SID of the plurality of SIDs;
wherein the program instructions are further executable
to:
receive information from the network, wherein the
information from the network comprises a VLAN
tag, an identification of a computing device of the
plurality of computing devices, and data for the
computing device;
determine if the received VLAN tag is comprised in the
list of VLAN tag entries;
wherein, in determining if the received VLAN tag of the
plurality of VLAN tags is comprised in the list of
VLAN tag entries, the program instructions are further
executable to access the memory medium and use the
received VLAN tag to determine if the received VLAN
tag is comprised in the list of VLAN tag entries; and
wherein the program instructions are further executable
to:
if the received VLAN tag is comprised in the list of SID
entries, determine a SID indicated by the received
VLAN tag, determine the identification of the com
puting device from the received information, and
transmit the data to the computing device;
wherein, in transmitting the data to the computing device,
the program instructions are further executable to use
the determined SID and the identification of the com
puting device.
32. The access point of claim 31,
wherein the identification information of the computing
device comprises a media access control (MAC) ID.
33. The access point of claim 31,
wherein the identification information of the computing
device comprises an internet protocol (IP) address.
34. An access point operable to concurrently communi
cate with a plurality of computing devices, wherein the
access point is further operable to utilize a first wireless
network service System ID to communicate with a first
subset of the plurality of computing devices, wherein the
access point is further operable to utilize a second wireless
network service System ID to communicate with a second
subset of the plurality of computing devices, wherein the
access point is further operable to be coupled to a network,
wherein the access point is further operable to provide
wireless network service to the plurality of computing
devices;
wherein the access point is further operable to provide
data from the first subset of the plurality of computing
devices to a first wireless network service provider; and
wherein the access point is further operable to provide
data from the second subset of the plurality of com
puting devices to a second wireless network service
provider.
35. An access point operable to concurrently communi
cate with a plurality of computing devices, wherein the
access point is further operable to utilize a plurality of
wireless network service System IDs to communicate with
the plurality of computing devices;
wherein the access point comprises a memory medium
operable for storing a data structure, wherein the data
structure includes a list which comprises a plurality of
wireless network service System IDs and an associated
list of a plurality wireless network providers, wherein
each wireless network service System ID indicates a
wireless network service provider of a plurality of
possible wireless network service providers;
wherein a first computing device of the plurality of
computing devices communicates with the access point
using a first wireless network service System ID of the
plurality of wireless network service System IDs and
the access point is further operable to provide wireless
network service of a wireless network provider indi
cated by the first wireless network service System ID.
36. The access point of claim 35,
wherein the plurality of wireless network service System
IDs comprises a plurality of IEEE 802.11 System IDs.
37. The access point of claim 35,
wherein the plurality of wireless network service System
IDs comprise a plurality of IEEE 802.11 Service Set
IDs (SSIDs).
38. The access point of claim 35,
wherein the plurality of wireless network service System
IDs comprise a plurality of IEEE 802.11 Extended
Service Set IDs (ESSIDs).
39. The access point of claim 35,
wherein the plurality of wireless network service System
IDs comprise a plurality of IEEE 802.11 Basic Service
Set IDs (BSSIDs).
40. The access point of claim 35, wherein the access point
is further operable to concurrently broadcast a plurality of
wireless network services System IDs for broadcasting.
41. The access point of claim 40,
wherein the plurality of wireless network service System
IDs for broadcasting comprise a plurality of IEEE
802.11 System IDs.
42. The access point of claim 40,
wherein the plurality of wireless network service System
IDs for broadcasting comprise a plurality of IEEE
802.11 Service Set IDs (SSIDs).
APPENDIX AB
US 2004/021.4572 A1
Oct. 28, 2004
19
43. The access point of claim 40,
wherein the plurality of wireless network service System
IDs for broadcasting comprise a plurality of IEEE
802.11 Extended Service Set IDs (ESSIDs).
44. The access point of claim 40,
wherein the plurality of wireless network service System
IDs for broadcasting are a plurality of IEEE 802.11
Basic Service Set IDs (BSSIDs).
receive a plurality of System IDs (SIDs), wherein at least
two of the plurality of SIDs are used for providing
wireless Ethernet (IEEE 802.11) to the plurality of
computing devices; and
concurrently utilize the at least two of the plurality of
SIDs for communicating with the plurality of comput
ing devices, wherein said communicating uses wireless
Ethernet.
54. The carrier medium of claim 53,
45. The access point of claim 35,
wherein the data structure further comprises method
information for providing data from the plurality of
computing devices to the plurality of wireless network
service providers, wherein each wireless network ser
vice System ID is associated with a wireless network
service provider of the plurality of possible wireless
network service providers and method information for
providing data from a computing device of the plurality
of computing devices to a wireless network service
provider of the plurality of wireless network service
providers;
wherein the access point is further operable to access the
wherein the plurality of SIDs comprise one or more IEEE
data structure and determine method information asso
wherein each MAC ID is different from another MAC ID.
ciated with a wireless network service System ID;
wherein the access point is further operable to provide
data from the computing device to the wireless network
service provider in accordance with the determined
method information indicated by the wireless network
service System ID.
46. The access point of claim 45,
wherein the method information includes a use of a
VLAN.
47. The access point of claim 45,
wherein the method information includes a VLAN tag.
48. The access point of claim 35, wherein the wireless
access point is further operable to concurrently use a plu
rality of radio frequency (RF) channels for communicating
with the plurality of computing devices.
49. The access point of claim 48, wherein the wireless
access point is further operable to communicate using a first
RF channel with a first subset of the plurality of computing
devices, wherein the wireless access point is further operable
to communicate using a second RF channel with a second
subset of the plurality of computing devices.
50. The access point of claim 49, wherein the wireless
access point is further operable to communicate using an
Nth RF channel with an Nth subset of the plurality of
computing devices.
51. The wireless access point of claim 49, wherein the first
RF channel and the second RF are non-overlapping RF
channels.
52. The access point of claim 35,
wherein the access point communicates with the plurality
of computing devices using Bluetooth.
53. A carrier medium comprising program instructions for
providing network access to a plurality of computing
devices communicating with an access point, wherein the
program instructions are computer-executable to:
802.11 Service Set IDs (SSIDs).
55. The carrier medium of claim 53,
wherein the plurality of SIDs comprise one or more IEEE
802.11 Extended Service Set IDs (ESSIDs).
56. The carrier medium of claim 53,
wherein the plurality of SIDs comprise one or more IEEE
802.11 Basic Service Set IDs (BSSIDs).
57. The carrier medium of claim 56,
wherein the Basic Service Set IDs comprises one or more
media access control (MAC) IDs.
58. The carrier medium of claim 57,
59. The carrier medium of claim 53, wherein the program
instructions are further computer-executable to implement a
wireless protocol stack for each SID of the plurality of SIDs.
60. The carrier medium of claim 59,
wherein the wireless protocol stack is an IEEE 802.11
protocol stack.
61. The carrier medium claim of 53, wherein the program
instructions are further computer-executable to:
retrieve a plurality of SIDs for broadcasting from a
memory medium; and
broadcast at least two SIDs of the plurality of SIDs for
broadcasting.
62. The carrier medium of claim 61,
wherein, in broadcasting the at least two SIDs, the pro
gram instructions are further computer-executable to
use a beacon format.
63. The carrier medium of claim 62,
wherein a subset of the plurality of SIDs for broadcasting
comprise IEEE 802.11 System IDs.
64. The carrier medium of claim 62,
wherein a subset of the plurality of SIDs for broadcasting
comprise IEEE 802.11 Service Set IDs (SSIDs).
65. The carrier medium of claim 62,
wherein a subset of the plurality of SIDs for broadcasting
comprise IEEE 802.11 Extended Service Set IDs
(ESSIDs).
66. The carrier medium of claim 62,
wherein a subset of the plurality of SIDs for broadcasting
comprise IEEE 802.11 Basic Service Set IDs
(BSSIDs).
67. The carrier medium of claim 66,
wherein the BSSIDs comprise media access control
(MAC) IDs.
APPENDIX AB
US 2004/021.4572 A1
Oct. 28, 2004
20
68. The carrier medium of claim 67,
wherein each BSSID is different from another BSSID.
instructions are further computer-executable to use the
at least one VLAN tag indicated by the received SID.
79. The carrier medium of claim 77,
69. The carrier medium of claim 53, wherein the program
instructions are further computer-executable to:
access a data structure comprised in a memory medium,
wherein the data structure comprises a list of SID
entries each indicating a wireless service provider of a
possible plurality of wireless service providers;
wherein, in determining the at least one VLAN tag, the
program instructions are further computer-executable
to index into the data structure using the received SID
to determine the at least one VLAN tag.
determine if a received SID is included in the list of SID
wherein at least a subset of the SID entries each indicate
80. The carrier medium of claim 69,
entries;
if the received SID is included in the list of SID entries,
at least one tunneling protocol;
wherein the program instructions are further computer
determine a wireless services provider and provide
network access to a computing device associated with
the received SID through the determined wireless ser
vice provider.
if the received SID is included in the list of SID entries,
70. The carrier medium of claim 69, wherein at least a
subset of the SID entries indicate respective VLANs.
71. The carrier medium of claim 70,
wherein each VLAN specifies a wireless service provider.
72. The carrier medium of claim 71,
wherein, in determining the wireless service provider, the
program instructions are further computer-executable
to determine a VLAN specified by the received SID.
wherein, in providing network access, the program
instructions are further executable to use the deter
mined VLAN.
73. The carrier medium of claim 69,
wherein, in determining the wireless service provider, the
program instructions are further computer-executable
to index into the data structure using the received SID
to determine the wireless service provider stored in the
data structure corresponding to the received SID.
74. The carrier medium of claim 69, wherein the program
instructions are further computer-executable to:
if the received SID is not included in the list of SID
entries, provide network access to a computing device
associated with the received SID through a default
wireless service provider.
executable to:
determine the at least one tunneling protocol;
wherein, in providing network access to the computing
device associated with the received SID through the
determined wireless service provider, the program
instructions are further computer-executable to use the
determined at least one tunneling protocol.
81. The carrier medium of claim 80,
wherein the at least a subset of the SID entries each
indicate at least one tunneling protocol and at least one
destination;
wherein, in determining the at least one tunneling proto
col, the program instructions are further computer
executable to determine the at least one destination;
wherein, in using the determined at least one tunneling
protocol, the program instructions are further com
puter-executable to use the determined at least one
destination.
82. The carrier medium of claim 81,
wherein the at least one destination is specified by a
wireless service provider indicated by the received
SID.
83. The carrier medium of claim 80,
wherein the at least one tunneling protocol comprises
PPTP.
75. The carrier medium of claim 74,
84. The carrier medium of claim 80,
wherein, in providing network access to the computing
device associated with the received SID through the
default wireless service provider, the program instruc
tions are further computer-executable to use a default
wherein the at least one tunneling protocol comprises
VLAN.
76. The carrier medium of claim 69,
wherein at least a subset of the SID entries each indicate
at least one VLAN tag;
wherein the program instructions are further computer
executable to:
if the received SID is included in the list of SID entries,
determine the at least one VLAN tag.
77. The carrier medium of claim 76,
wherein each VLAN tag specifies a wireless service
provider.
78. The carrier medium of claim 77,
wherein, in providing network access to the computing
device associated with the received SID through the
determined wireless service provider, the program
IPSEC.
85. The carrier medium of claim 80,
wherein the at least one tunneling protocol comprises
Generalized Routing Encapsulation (GRE).
86. The carrier medium of claim 80,
wherein the at least one tunneling protocol comprises
IP-in-IP.
87. The carrier medium of claim 53,
wherein each SID of a subset of the plurality of SIDs is
associated with a media access control (MAC) ID for
communicating with a computing device, wherein the
MAC ID is not a MAC ID of a computing device;
wherein the program instructions are further computer
executable to:
determine if a received SID is in the subset;
if the received SID is in the subset, determine a MAC
ID associated with the received SID and communi
APPENDIX AB
US 2004/021.4572 A1
cate with the computing device associated with the
received SID, wherein, in communicating the com
puting device associated with the received SID, the
program instructions are further computer-execut
able to use the determined MAC ID.
88. The carrier medium of claim 87,
wherein each MAC ID associated with each SID of the
subset is different from another MAC ID associated
with each SID of the subset.
89. The carrier medium of claim 53, wherein the program
instructions are further computer-executable to:
receive information from a network, wherein the infor
mation from the network, comprises a VLAN tag, an
identification of a computing device of the plurality of
computing devices, and data for the computing device;
access a memory medium which comprises a data struc
ture which comprises a list of VLAN tag entries each
indicating at least one identification of a computing
device of the plurality of computing devices and at least
one SID of the plurality of SIDs;
determine if the received VLAN tag is comprised in the
list of VLAN tag entries;
wherein, in determining if the received VLAN tag is
comprised in the list of VLAN tag entries, the program
instructions are further computer-executable to access
the memory medium and use the received VLAN tag to
determine if the received VLAN tag is comprised in the
list of VLAN tag entries; and
wherein the program instructions are further computer
executable to:
if the received VLAN tag is comprised in the list of SID
entries, determine a SID indicated by the received
VLAN tag, determine the identification of the com
puting device from the received information, and
transmit the data to the computing device;
wherein, in transmitting the data to the computing device,
the program instructions are further computer-execut
Oct. 28, 2004
concurrently communicating with a plurality of comput
ing devices, wherein said communicating utilizes the at
least two SIDs.
94. The method of claim 93, further comprising:
providing network service of a first wireless service
provider coupled to the network to a first computing
device of the plurality of computing devices, wherein
the access point and the first computing device com
municate using a first SID of the at least two SIDs; and
providing network service of a second wireless service
provider coupled to the network to a second computing
device of the plurality of computing devices, wherein
the access point and the second computing device
communicate using a second SID of the at least two
SIDS.
95. The method of claim 94,
wherein the first SID indicates the first wireless service
provider.
96. The method of claim 94,
wherein the second SID indicates the second wireless
service provider.
97. The method of claim 94,
wherein the second wireless service provider comprises a
default wireless service provider.
98. The method of claim 93, further comprising:
broadcasting a plurality of SIDs.
99. The method of claim 98,
wherein said broadcasting comprises a beacon format.
100. The method of claim 98,
wherein the plurality of SIDs comprises a plurality of
IEEE 802.11 Service Set IDs (SSIDs).
101. The method of claim 98,
wherein the plurality of SIDs comprises a plurality of
IEEE 802.11 basic Service Set IDs (BSSIDs).
102. The method of claim 101,
wherein the plurality of BSSIDs comprise at least one
media access control (MAC) ID.
able to use the indicated SID and the identification of
103. The method of claim 101,
the computing device.
wherein the plurality of BSSIDs comprise a plurality of
90. The carrier medium of claim 89,
media access control (MAC) IDs; and
wherein the identification information of the computing
wherein a first MAC ID of the plurality of MAC IDs is
different from a second MAC ID of the plurality of
device comprises a media access control (MAC) ID of
the computing device.
MAC IDS.
91. The carrier medium of claim 89,
104. The method of claim 101,
wherein the identification information of the computing
wherein a first BSSID of the plurality of BSSIDs is
different from a second BSSID of the plurality of
device comprises an internet protocol (IP) address of
the computing device.
92. The carrier medium of claim 53,
wherein a subset of the plurality of computing devices are
portable computing devices.
93. A method for operating an access point, wherein the
access point is operable to be coupled to a network, the
method comprising:
receiving a plurality of System IDs (SIDs), wherein at
least two of the plurality of SIDs are used for providing
wireless Ethernet;
BSSIDS.
105. The method of claim 98,
wherein the plurality of SIDs comprises a plurality of
IEEE 802.11 Extended Service Set IDs (ESSIDs).
106. The method of claim 93, further comprising:
implementing a wireless protocol stack for each SID of
the plurality of SIDs.
107. The method of claim 106,
wherein at least one wireless protocol stack is an IEEE
802.11 protocol stack.
APPENDIX AB
US 2004/021.4572 A1
Oct. 28, 2004
22
108. The method of claim 93, further comprising:
receiving information from the network, wherein the
information from the network comprises a VLAN tag,
an identification of a computing device, and data for the
computing device;
accessing a memory medium which comprises a data
structure which comprises a list of VLAN tag entries
each indicating at least one SID of the plurality of SIDs;
determining if the received VLAN tag is comprised in the
list of VLAN tag entries, wherein said determining if
the received VLAN tag is comprised in the list of
VLAN tag entries includes accessing the memory
medium and using the received VLAN tag;
if the received VLAN tag is comprised in the list of SID
entries, determining a SID indicated by the received
VLAN tag, determining the identification of the com
puting device from the received information, and trans
mitting the data to the computing device;
wherein said transmitting the data to the computing
device includes using the indicated SID and the iden
tification of the computing device.
the wireless access point receiving data from the first
portable computing device;
the wireless access point receiving data from the second
portable computing device;
providing wireless network access to the first portable
computing device through the first wireless service
provider determined in said determining the first wire
less service provider;
providing wireless network access to the second portable
computing device through the second wireless service
provider determined in said determining the second
wireless service provider;
wherein said providing wireless network access to the first
portable computing device and said providing wireless
network access to the second portable computing
device are performed concurrently.
109. The method of claim 108,
wherein the access point comprises the memory medium.
wherein a portion of the first identification information is
a portion of the second identification information.
110. The method of claim 108,
114. The method of claim 111,
wherein a management information base (MIB) coupled
wherein the first identification information includes an
to the network comprises the memory medium.
111. A method for providing wireless network access to a
plurality of computing devices, the method comprising:
a wireless access point receiving first identification infor
mation from a first portable computing device, wherein
the first identification information indicates a first wire
less service provider of a plurality of possible wireless
service providers, wherein the wireless access point
includes a memory medium which stores a data struc
ture comprising a list of identification information
entries each indicating at least one wireless service
provider of the plurality of possible wireless service
providers;
the wireless access point receiving second identification
information from a second portable computing device,
wherein the second identification information indicates
a second wireless service provider of the plurality of
possible wireless service providers;
determining the first wireless service provider for the first
portable computing device after receiving the first
identification information, wherein said determining
the first wireless service provider for the first portable
computing device includes accessing the memory
medium and using the received first identification infor
mation to determine the first wireless provider;
determining the second wireless service provider for the
second portable computing device after receiving the
second identification information, wherein said deter
mining the second wireless service provider for the
second portable computing device includes accessing
the memory medium and using the received second
identification information to determine the second
wireless provider;
112. The method of claim 111,
wherein the first wireless service provider is the second
wireless service provider.
113. The method of claim 112,
IEEE 802.11 System ID; and
wherein the second identification information includes an
IEEE 802.11 System ID.
115. A method for providing wireless network access to a
plurality of computing devices, the method comprising:
a wireless access point receiving first identification infor
mation from a first portable computing device, wherein
the first identification information indicates a first wire
less service provider of a plurality of possible wireless
service providers, wherein the wireless access point is
operable to access a memory medium which stores a
data structure comprising a list of identification infor
mation entries each indicating at least one wireless
service provider of the plurality of possible wireless
service providers;
the wireless access point receiving second identification
information from a second portable computing device,
wherein the second identification information indicates
a second wireless service provider of the plurality of
possible wireless service providers;
determining the first wireless service provider for the first
portable computing device after receiving the first
identification information, wherein said determining
the first wireless service provider for the first portable
computing device includes accessing the memory
medium and using the received first identification infor
mation to determine the first wireless provider;
determining the second wireless service provider for the
second portable computing device after receiving the
second identification information, wherein said deter
mining the second wireless service provider for the
second portable computing device includes accessing
APPENDIX AB
US 2004/021.4572 A1
Oct. 28, 2004
23
the memory medium and using the received second
identification information to determine the second
wireless provider;
the wireless access point receiving data from the first
portable computing device;
the wireless access point receiving data from the second
portable computing device;
providing wireless network access to the first portable
computing device through the first wireless service
provider determined in said determining the first wire
less service provider;
providing wireless network access to the second portable
computing device through the second wireless service
provider determined in said determining the second
wireless service provider;
wherein said providing wireless network access to the first
portable computing device and said providing wireless
network access to the second portable computing
device are performed concurrently.
116. The method of claim 115,
wherein the wireless access point is coupled to a man
agement information base (MIB); and
wherein the MIB comprises the memory medium.
117. The method of claim 115,
wherein the first wireless service provider is the second
wireless service provider.
118. The method of claim 115,
wherein the first identification information includes an
IEEE 802.11 System ID; and
wherein the second identification information includes an
IEEE 802.11 System ID.
APPENDIX AC
US007860978B2
(12) United States Patent
(10) Patent No.:
Oba et al.
(54) ESTABLISHING ASECURE TUNNEL TO
FOREIGN PATENT DOCUMENTS
(75) Inventors: Yoshihiro Oba, Torrance, CA (US);
Shinichi Baba, Irvine, CA (US)
Piscataway, NJ (US); Telcordia
Technologies, Inc., Piscataway, NJ (US)
-
-
-
-
patent is extended or adjusted under 35
U.S.C. 154(b) by 0 days
y
2001-016255 A
1/2001
2001-237892 A
8/2001
P2002-044076 A
ys.
-
;*
;
JP
P2003-167805 A
6/2003
OTHER PUBLICATIONS
Godber et al. “Secure Wireless Gateway.” 2002. ACM Proceedings
on Wireless Security, pp. 41-46.”
“Multi-Link Technology White Paper.” Oct. 2001. www.Stonesoft.
com White Papers. pp. 1-15.”
(21) Appl. No.: 10/761,347
(22) Filed
Jan.
22. 2004
1IeCl.
&Il.
L. Mamakos, et al., “A Method for Transmitting PPP Over Ethernet
(PPPoE).” RFC 2516, Feb. 1999, pp. 1-20, USA.
s
(65)
2/2002
..
-
Subject to any disclaimer, the term of this
-- - *--> -
JP
JP
JP
(73) Assignees: Toshiba America Research, Inc.,
(*) Notice:
Dec. 28, 2010
2005/0108386 A1* 5/2005 Acharya et al. ............. 709/224
ACCESS ROUTER
-
US 7,860,978 B2
(45) Date of Patent:
(Continued)
Prior Publication Data
|US 2005/01 65953 A1
Jul. 28, 2005
Primary Examiner–Larry Donaghue
Assistant Examiner—Nicholas Taylor
(74) Attorney, Agent, or Firm—Watchstone P&D, PLLC
(51) Int. Cl.
G{}6F 15/16
(2006.01)
(57)
(52) U.S. Cl. ....................... 709/227; 709/200; 709/225;
709/228
(58) Field of Classification Search ................. 709/225,
709/200, 227 28
S
lication file f
let
h history.
ee application IIIe Ior complete searcn n1story
(56)
References Cited
In some illustrative embodiments, an IP-layer based network
selection and multihoming method is provided that enables a
flexible and secure dynamic selection of one or more serving
networks for use by a client node. The method is independent
of any link-layer technology. A serving network can be an ISP
network, a NAP network exchange facility, a VLAN, or the
like. Network information is advertised to a client node, the
|U.S. PATENT DOCUMENTS
client node is authenticated and authorized for use of an
6,636,898 B1 * 10/2003 Ludovici et al. ............ 709/250
2002/0069278
2002/0196.802
2003/0145104
2004/00 19664
2004/0236855
ABSTRACT
A1* 6/2002 Forslow ......................
A1* 12/2002 Sakov et al. ................
A1* 7/2003 Boden et al. ................
A1* 1/2004 Le et al. .....................
A1 * 1 1/2004 Peles ..........................
709/225
370/432
709/238
709/220
709/227
access router, and a secure tunnel is established between the
client node and the access router. The method can be imple
mented by using standard protocols, and can work over any
existing or future link-layer technologies that are able to carry
IP datagrams, without any modification.
26 Claims, 8 Drawing Sheets
Serving
Serving
Serving
Network N1
Network N2
Network N3
*::=
Logical IPsec
101
Tunnel Interface Li
Physical
Interface P
103
Client Node
203
APPENDIX AC
US 7,860,978 B2
Page 2
OTHER PUBLICATIONS
W. Simpson, “The Point-to-Point Protocol (PPP).” RFC 1661, Jul.
1994, USA.
S. Cheshire, “Dynamic Configuration of Link-Local IPv4
Addresses.” Internet Draft, Jan. 2004, p. 1-32, USA.
S.Thomson, “IPv6 Stateless Address Autoconfiguration.” RFC 2462,
Dec. 1998, p. 1-24, USA.
J. Arkko, “SEcure Neighbor Discovery (SEND).” Internet Draft,
Aug. 2003, p. 1-51, USA.
R. Droms, “Dynamic Host Configuration Protocol.” RFC 2131, Mar.
1997, p. 1-43, USA.
R. Droms, “Dynamic Host Configuration Protocol for IPv6
(DHCPv6).” RFC 3315, Jul. 2003, p. 1-100, USA.
B. Aboba, “Virtual Access Points.” IEEE 802.11-03/154r1, May
2003, p. 1-13, USA.
D. Forsberg, “Protocol for Carrying Authentication for Network
Access (PANA).” Internet Draft, Jun. 2003, p. 1-49, USA.
S. Deering, “ICMP Router Discovery Messages.” RFC 1256, Sep.
1991, p. 1-18, USA.
T. Narten, “Neighbor Discovery for IPVersion 6 (IPv6).” RFC 2461,
Dec. 1998, p. 1-87, USA.
D. Harkins, “The Internet Key Exchange (IKE).” RFC 2409, Nov.
1998, p. 1-39, USA.
C. Kaufman, “Internet Key Exchange (IKEv2) Protocol”, Internet
Draft, Oct. 2003, p. 1-108, USA.
L. Blunk, “PPP Extensible Authentication Protocol (EAP).” RFC
2284, Mar 1998, p. 1-15, USA.
B. Aboba, “EAP Key Management Framework.” Internet Draft, Oct.
2003, p. 1-55, USA.
M. Parthasarathy, “PANA enabling IPsec based Access Control.”
Internet Draft, Oct. 2003, p. 1-11, USA.
O. Troan, “IPv6 Prefix Options for DHCPv6.” Internet Draft, Oct.
2003, p. 1-20, USA.
C. Perkins, “IP Mobility Support for IPv4,” RFC 3344, Aug. 2002, p.
1-98, USA.
D. Johnson, “Mobility Supportin IPv6.” Internet Draft, Jun. 2004, p.
1-163, USA.
Satoshi Uda, ‘Proposal of Multi-homing Architecture of Miltiple
Routing Type’. A new multi-homing architecture based on overlay
network, Technical Reports of Information Processing Society, vol.
2003, No. 101, APAJ SIG Technical Reports, Japan, Information
Processing Society of Japan (Oct. 8, 2003).
Dan Forsberg, Jarno Rajahalme, Secure Network Access Authenti
cation (SeNAA), “draft-forsberg-pana-secure-network-access-auth
01.fxt-[online], Finland, Internet Engineering Task Force, (Sep.
2002), The internet ‘http://tools.ietforg/html/draft-forsberg-pana
secure-network-access-auth-01× [searched Apr. 2, 2009].
Yasuhiro Katsube, ‘Frontiers of Research & Development’, Toshiba
Review, vol. 58, No. 5, Toshiba Review, Japan, Kabushiki Kaisha
Toshiba, Toshiba Corporation, (May 1, 2003) (relating to authenti
cation using the PANA protocol).
Office Action related to corresponding PCT application, Japanese
patent application 2006-551325.
Japanese Office Action dated Jun. 16, 2009, issued in corresponding
Japanese patent application No. 2006-551325.
Yasuhiro Katsube, “Comfortable Radio IP Communication Is Real
ized Based on Mobility, Security and Quality Technologies”, Fron
tiers of Research & Development, Toshiba Review, vol. 58, No. 5,
Toshiba Review, Japan, Kabushiki Kaisha Toshiba, Toshiba Corpo
ration, (May 1, 2003) (relating to authentication using the PANA
protocol).
* cited by examiner
APPENDIX AC
APPENDIX AC
APPENDIX AC
U.S. Patent
Dec. 28, 2010
Sheet 3 of 8
US 7,860,978 B2
;
APPENDIX AC
U.S. Patent
Dec. 28, 2010
3Zu?NAJVOSI
Sheet 4 of 8
US 7,860,978 B2
APPENDIX AC
U.S. Patent
Dec. 28, 2010
?£uNVAJIOS
3ZuN?VAJIOS
Sheet 5 of 8
US 7,860,978 B2
APPENDIX AC
APPENDIX AC
U.S. Patent
Dec. 28, 2010
Sheet 7 of 8
US 7,860,978 B2
APPENDIX AC
U.S. Patent
US 7,860,978 B2
APPENDIX AC
US 7,860,978 B2
1
2
the access routers, the simple solution is difficult to imple
ment where a client node with a single physical interface is
ESTABLISHING A SECURE TUNNEL TO
ACCESS ROUTER
allowed to connect to two or more ISPs or VLANs simulta
neously. Ingress filtering is a technique for preventing attack
ers from injecting packets with a forged source IP address as
if they were generated in a different network than the access
BACKGROUND
1. Field of the Invention
The present invention relates generally to network commu
nications and preferred embodiments relate more particularly
to communication network service provider selection at a
single client location from among a number of different avail
able providers. In accordance with some preferred embodi
ments, the invention relates to Internet Service Provider (ISP)
selection and multihoming by a user at a client node on an
network to which the access router attaches. In an access
10
access network.
2. Background Discussion
Multihoming is the technique of connecting to the Internet
via two or more ISPs, either simultaneously or dynamically.
Multihoming has a number of advantages, including provid
ing an essential back-up connection to the public Internet if
one ISP fails, improved regional and local connectivity,
increased bandwidth, and availability of load-sharing which
can improve performance. Currently, there are many situa
tions where multiple ISPs are available at a single user loca
tion. For example, home users can choose one ISP via a
dial-up connection and another ISP via a cable or DSL (Digi
tal Subscriber Line) modem connection.
DSL providers that use PPPoE (Point-to-Point Protocol
over Ethernet) for IP encapsulation can allow subscribers to
choose one of a number of connected ISPs, either statically
during the initial sign-up, or dynamically by using NAIs
(Network Access Identifiers) provided by the subscribers dur
ing the PPP authentication phase or by carrying ISP informa
tion in the PPPoE discovery stage.
In IEEE 802 LANs (Local Area Networks), a VLAN (Vir
tual LAN) is used to partition a LAN into multiple smaller
LANs. A VLAN is a network of computers that behave as if
they are connected to the same wire even though they actually
may be physically located on different segments of a LAN.
VLANs can be configured through software rather than hard
ware, which makes them extremely flexible. When a client
node is connected to a VLAN through a wired Ethernet con
nection, the mapping between the Ethernet port of the client
node and the VLAN is statically configured in most cases. In
public wireless LAN environments, the IEEE 802.11 SSID
(Service Set IDentifier) advertised by access points can con
tain service provider information. SSID also is used for
dynamically selecting a VLAN by creating a static mapping
15
the case where simultaneous connection to different ISPs or
VLANs is enabled.
20
Consequently, there exists a need in the art for, among other
things, a solution that prevents any information leakage to
occur and also that protects against IP address spoofing
attacks.
SUMMARY OF THE INVENTION
25
The preferred embodiments of the present invention can
significantly improve upon existing methods and/or appara
tuses. In some embodiments, the present invention provides
substantial improvements over the above-mentioned meth
ods.
30
35
40
45
between SSID and VLAN, so that stations that are associated
with an access point by specifying a particular SSID are
connected to a particular VLAN mapped to that SSID.
The current methods for selecting an ISP or a VLAN are
closely tied to particular link-layer technologies (i.e., PPP and
IEEE 802.11) and therefore are difficult to apply across all
link-layer technologies. As such, in an environment where
access networks are heterogeneous or more flexibility in
VLAN assignment to client nodes is needed, it would be
desirable to have an IP (Internet Protocol) layer solution that
is independent of any link-layer technology.
As a simple IP-layer solution, it is possible to place mul
tiple access routers in an access network where each access
router is connected to a particular ISP or a VLAN, such that a
client node on the access network can select a particular
access router to send and receive data packets. However, the
simple solution has two problems. First, information leakage
could occur in the access network among multiple ISPs or
VLANs, especially when the access network uses multi-ac
cess technologies. Second, if ingress filtering is performed at
network where ingress filtering is employed, a packet gener
ated in the access network can pass through an access router
only when it has a source address with a network prefix that is
assigned by the router to the network interface where the
packet was received. However, most host implementations do
not provide any method to choose an appropriate source
address when multiple routable IP addresses with different
network prefixes are assigned to a given interface, as would be
50
55
According to one aspect of the invention, a new IP-layer
based model for network selection and multihoming is pro
vided that enables a flexible and secure dynamic selection of
one or more serving networks to use, where a serving network
is an ISP network, a NAP (Network Access Point) network
exchange facility, a VLAN, etc. The IP-layer based model
according to one preferred embodiment consists of three
phases. Network information is advertised to a client node in
the first phase, the client node is authenticated and authorized
for use of an access router in the second phase, and a secure
tunnel is established between the client node and the access
router in the third phase. The inventive model can be imple
mented by using standard protocols, and can work over any
existing or future link-layer technologies that are able to carry
IP datagrams, without any modification.
In particular, according to one preferred embodiment, the
present invention provides a method of dynamically connect
ing a client node to a serving network, including the steps of
providing an access network to which a client node has a
network connection; providing at least one access router hav
ing a network connection to the access network and having a
network connection to at least one serving network; sending
serving network provideradvertising information to the client
node in response to a request message from the client node:
receiving from the client node serving network provider
information specifying a serving network to which the client
node desires access; and establishing a secure communica
tion tunnel between the client node and the access router
60
65
through the access network, such that the client node is able to
send and receive data packets to and from the serving network
specified by the client node within the secure communication
tunnel through the access network.
According to a second aspect, the invention provides a
method of connecting a client node to multiple Internet ser
vice providers, including the steps of providing an access
network through which the client node may communicate
with the multiple Internet service providers; and establishing
a separate secure communication tunnel within the access
APPENDIX AC
US 7,860,978 B2
4
3
network for each of the multiple Internet service providers,
includes access routers AR1 and AR2 and a client node 103.
Additional nodes on the access network are not shown for
such that the client node is able to send and receive data
purposes of simplification. Access routerAR1 is connected to
serving network N1, and access router AR2 is connected to
serving networks N2 and N3. In the IP access network 101,
packets to and from each of the Internet service providers
within the separate secure communication tunnels through
the access network.
According to a third aspect, the invention provides a
method of connecting a client node to a serving network,
including the steps of providing an access router having a
network connection to at least two serving networks; receiv
ing from the client node serving network information speci
fying a serving network to which the client node desires to
have access; establishing a secure communication tunnel
between the client node and the access router through the
client node 103 can communicate with the access routers as
well as other nodes (not shown), by using a routable or non
routable IP address that is valid for communication within the
access network. When the client node 103 needs to send or
10
access network, such that the client node is able to send and
receive data packets to and from the serving network specified
by the client node within the secure communication tunnel
through the access network; and binding the secure commu
nication tunnel to the specified serving network by using
serving network information of the specified serving network
as a security association identifier of the secure communica
15
20
tion tunnel.
The above and/or other aspects, features and/or advantages
of various embodiments will be further appreciated in view of
the following description in conjunction with the accompa
nying figures. Various embodiments can include and/or
exclude different aspects, features and/or advantages where
applicable. In addition, various embodiments can combine
one or more aspect or feature of other embodiments where
applicable. The descriptions of aspects, features and/or
advantages of particular embodiments should not be con
strued as limiting other embodiments or the claims.
25
30
DESCRIPTION OF THE DRAWINGS
The preferred embodiments of the present invention are
shown by a way of example, and not limitation, in the accom
panying figures, in which:
FIG. 1 is a diagram of a physical network topology accord
ing to one preferred embodiment of the invention;
FIG. 2 is a diagram of a logical network topology accord
ing to one preferred embodiment of the invention overlaying
the topology of FIG. 1;
FIG. 3 is a diagram of a network topology according to one
preferred embodiment of the invention using ISPs and NAPs;
FIGS. 4 and 5 are diagrams of a network topology accord
ing to one preferred embodiment of the invention using
access VLANS and serving VLANS:
FIGS. 6 and 7 are diagrams of a network topology accord
ing to one preferred embodiment of the invention using vir
tual access points; and
FIG. 8 is a diagram of a network topology according to one
preferred embodiment of the invention using a remote net
35
node 103 has three IPSec tunnels 201, 202 and 203, each
40
202 and 203 corresponding to logical interfaces L2 and L3 are
45
terminated at access router AR2.
50
The interface address of each logical interface L1, L2 and
L3 of the client node 103 is assigned from the address block
of the corresponding serving network. In the example as
shown, the client node 103 can send and receive data packets
through any of the three serving networks N1, and N2 and N3.
Of course, it is also possible for the client node to establish
connectivity to only one or two of the serving networks
instead of all three serving networks. A client node that has
on-link connectivity to the access network can be a worksta
55
other nodes in the access network 101. A non-routable
different forms, a number of illustrative embodiments are
60
is illustrated in FIG. 1. As shown, an IP access network 101
address is not allowed to be forwarded by a router while a
routable address can be forwarded by a router. An example of
non-routable address is an IPv4 link-local address or an IPv6
link-local address, for which the client node 103 can autono
described herein and/or illustrated herein.
An example physical topology of the proposed IP-layer
model according to a preferred embodiment of the invention
tion or a router.
The client node 103 can use an IP address that is a routable
address or a non-routable address for communicating with
While the present invention may be embodied in many
described herein with the understanding that the present dis
closure is to be considered as providing examples of the
principles of the invention and that such examples are not
intended to limit the invention to preferred embodiments
associated with a distinct logical interface L1, L2 or L3. The
logical interfaces L1, L2 and L3 are used for sending and
receiving data packets through particular serving networks
N1, N2 and N3, respectively. The serving networks N1, N2
and N3 can be ISPs, NAPs, VLANS, or similar serving net
works. The IPSec tunnel 201 corresponding to logical inter
face L1 is terminated at access router AR1. The IPSec tunnels
work.
DESCRIPTION OF THE PREFERRED
EMBODIMENTS
receive data packets through a serving network, it establishes
a secure tunnel (logical interface) using IP Security protocol
(IPSec tunnel) to the access router of that serving network
through the IP access network. Tunneling allows one network
to send its data through another network’s connections, and
works by encapsulating a network protocol within packets
carried by the second network. For example, PPTP (Point-to
Point Tunneling Protocol) technology enables organizations
to use the Internet to transmit data across a VPN (Virtual
Private Network). It does this by embedding its own network
protocol within the TCP/IP packets carried by the Internet.
The established IPSec tunnel is a secure logical interface
that provides confidentiality, integrity and replay protection
for packets passing through the access router, which also
prevents the packets from being leaked to other serving net
works. Additionally, the IPSec tunnel establishes a logical
tunnel interface overlaying the physical interface of the node.
This guarantees that a particular interface address (i.e., the
address assigned to a particular logical tunnel interface) is
used as the source address of packets forwarded to the corre
sponding access router. Access routers that employ ingress
filtering will neverdrop packets having such a source address,
since it will contain the network prefix assigned to the logical
interface by the access router.
An example logical topology that overlays the physical
topology of FIG. 1 is illustrated in FIG.2. As shown, the client
65
mously generate the address. Especially when an IPv6 link
local address is used, SEND (SEcure Neighbor Discovery)
can be used for protecting IPv6 Neighbor Discovery
exchanges. When a routable address is used, it can be either
statically configured or dynamically configured, using any
APPENDIX AC
US 7,860,978 B2
5
method including DHCP (Dynamic Host Configuration Pro
tocol), DHCPv6 or IPv6 address auto-configuration.
It is not necessary to use the IPSec key management pro
tocol to establish a tunnel if security is not crucial for the
serving network providing the service, such as for a public
service access network. In such case, other IP tunneling
schemes may be used, such as for example IP-in-IP or GRE
(Generic Routing Encapsulation).
Serving Network Information Advertising
Many wireless LAN hotspot service providers currently
6
router. When a PAA is not co-located with an access router, it
uses another protocol such as SNMP (Simple Network Man
agement Protocol) or Diameter to send authorization infor
mation on authorized clients to some or all of the access
routers connected to the serving network(s) to be advertised
by the PAA.
The advertising sequence can be performed as follows:
1. A Pac sends a PANA-PAA-Discover message that may
be multicast within the access network or unicast to a
10
particular PAA.
use 802.11 SSID that is included in a broadcast beacon frame
2. Each PAA that received the PANA-PAA-Discover mes
to advertise service provider information to wireless clients.
A technique called virtual access point (VAP) can extend this
usage so that a single physical access point can be divided into
multiple virtual access points, each of which acts as if it were
a distinct physical access point, by advertising a distinct SSID
for each VLAN. A disadvantage of VAP is that it is closely
tied with a particular access technology and is difficult to
apply to other access technologies. Another disadvantage is
that more bandwidth is occupied by beacon frames and thus
the total data traffic throughput will decrease. For example, if
there are 10 virtual access points and each virtual access point
generates a beacon frame every 100 msec, a station will
receive a beacon frame every 10 msec, in which case more
sage sends a PANA-Start-Request message back to the
PaC. The PANA-Start-Request message contains the
information on the serving network(s) associated with
than 30% of the link bandwidth of IEEE 802.11b will be
15
20
25
occupied by beacon frames.
According to the present invention in contrast, network
layer protocols are used for advertising serving network
information to the client nodes on the access network 101.
When the routable networks are ISP or NAP networks, a
provide identifier and provider name data pair may be adver
tised per each service provider, where the provider identifier
is a unique identifier that is used to identify the provider and
the provider name is a character string that represents the
name of the provider. When the serving networks are VLANs,
a VLAN identifier and VLAN name may be advertised per
VLAN, where the VLAN identifier is a unique identifier that
is used to identify the VLAN and the VLAN name is a char
acter string that represents the name of the VLAN. The VLAN
advertising information may be sent over IP when the access
30
2. Each router that receives the Router Solicitation mes
35
40
45
When PANA is used for advertising the information on the
serving networks, it also can be used for its original purpose,
i.e., authenticating and authorizing the clients. IKE (Internet
Key Exchange) can also be used for authenticating the clients.
When IKE is used for client authentication, the client node
50
can immediately establish a secure tunnel. IKE is a key man
agement protocol standard that is used in conjunction with the
IPSec standard. IPSec is an IP security feature that provides
robust authentication and encryption of IP packets.
On the other hand, when a PAA is not co-located with an
access router, PANA is always used for authenticating the
client. When PANA is used for client authentication, the
55
authentication procedure continues from Step 3 in the previ
ous section:
60
access network.
PANA is a client-server type protocol where the client and
server are referred to as a Pac (PANA Client) and a PAA
(PANA Authentication Agent), respectively. In the invention,
client node 103 is a PaC. A PAA is placed in the access
network and may or may not be co-located with an access
message(s) extracts the serving network information
from the received message.
Authentication
tocols that are in use at the site. It also allows such interactions
to take place without a link-layer specific mechanism. PANA
is applicable to both multi-access and point-to-point links.
The present invention makes use of the PANA protocols to
provide serving network information to client nodes on the
sage sends a Router Advertisement message back to the
client node. The Router Advertisement message con
tains information on the serving network(s) connected to
the router.
3. The client node that receives the Router Advertisement
network is not also a VLAN.
According to one preferred embodiment of the invention,
information concerning the serving networks is advertised by
using PANA (Protocol for carrying Authentication informa
tion for Network Access). In some scenarios, an IP-based
device is required to authenticate itself to the network prior to
being authorized to use it. This authentication usually
requires a protocol that can support various authentication
methods. In the absence of such an authentication protocol on
most of the link-layers, architectures have resorted to using a
number of inadequate authentication methods. PANA defines
a protocol that allows clients to authenticate themselves to the
access network using IP protocols that allow a client to inter
act with a site’s back-end AAA (Authentication, Authoriza
tion, and Accounting) infrastructure to gain access without
needing to understand the particular AAA infrastructure pro
the PAA.
3. The Pac that receives the PANA-Start-Request message
(s) extracts the serving network information from the
received message.
It is noted that a PaC may not need to configure an IP
address when it uses an unspecified IP address for receiving
serving network information using PANA. In such case, the
PAA will send information encapsulated in an IP packet to the
PaC by using a Layer 2-specific packet delivery mechanism
and bypassing the regular IP stack implementation
According to an alternate embodiment of the invention,
serving network information may be advertised to clients by
using the Router Discovery mechanism of IPv4 or IPv6. A
client node needs to configure an IP address to obtain serving
network information using Router Discovery. The advertis
ing sequence can be performed as follows:
1. A client node sends a Router Solicitation message that
may be multicast within the access network or unicast to
a particular router.
65
4. The Pac sends a PANA-Start-Answer message to a PAA
in response to a PANA-Start-Request message. The Pac
may specify one or more serving network it wishes to
access, by inserting the information on the desired serv
ing network(s) in the PANA-Start-Answer message.
5. The PAA then sends a PANA-Auth-Request message,
carrying an EAP (Extensible Authentication Protocol)
message and a PANA session identifier. The PANA
Auth-Request message may contain the information on
the serving network that is associated with the ongoing
authentication. EAP is a general protocol for authenti
APPENDIX AC
US 7,860,978 B2
8
7
cation that also supports multiple authentication meth
ods, such as token cards, one-time passwords, certifi
cates, public key authentication and smart cards. The
object of authentication is to confirm the identity of the
use the PANA session identifier or a valid IP address in the
access network as the ISAKMP Security Association
(ISAMKPSA) identifier in IKEv1 or the IKE_SA identifier
in IKEv2. When an IP address is used as the ISAKMP SA
client or user.
identifier in IKEv1, the IKEv1 Main Mode needs to be used.
6. The Pac returns a PANA-Auth-Answer message in
response to the PANA-Auth-Request message, carrying
an EAP message.
7. Steps 5 and 6 are repeated as necessary until the EAP
authentication process completes.
8. When the EAP authentication process completes, the
PAA sends a PANA-Bind-Request message to the Pac,
containing an EAP Success/Failure message. If the EAP
authentication completes successfully, a list of IP
10
addresses of the access routers associated with the PAA
15
dure is used.
is additionally contained in the message. If the PAA is
not co-located with an access router, a list of access
router names associated with the PAA and connected to
the serving network(s) is additionally contained in the
message. The PANA-Bind-Request may contain the
information on the serving network the PAA authorizes
20
access to the PaC. If the client authentication fails, the
client node will be denied access to any serving network.
9. The Pac returns a PANA-Bind-Answer message to the
PAA.
10. When EAP authentication is needed for more than one
serving network, Steps 5 to 9 are repeated for each
serving network.
In the above sequence, it is assumed that at least one EAP
authentication method that is capable of deriving an EAP
Master Session Key (MSK) is used. The derived MSK is
shared between the Pac and the PAA. Upon successful
completion of an EAP authentication process with a derived
MSK, the PAA sends at least the following information to
each access router associated with the PAA and connected to
access network, single PANA authentication and identifier for
each access router, or single PANA authentication and iden
tifier for each serving network. Where there is authentication
for each serving network, the PANA session identifier may be
used as an identifier for IKE, but in other cases the client has
30
35
network:
PANA session identifier.
40
45
which access router associated with the PAA is connected to
which serving network(s). The client then can perform IKE
with any access router to establish an IPSec tunnel.
IKE is a hybrid protocol which implements the Oakley key
exchange and Skeme key exchange inside the Internet Secu
rity Association and Key Management Protocol (ISAKMP)
framework. (ISAKMP Oakley, and Skeme are security pro
tocols implemented by IKE.) IPSec is a framework of open
standards that provides data confidentiality, data integrity,
and data authentication between participating peers. IPSec
provides these security services at the IP layer; it uses IKE to
handle negotiation of protocols and algorithms based on local
policy, and to generate the encryption and authentication keys
to be used by IPSec. IPSec can be used to protect one or more
data flows between a pair of hosts, between a pair of security
gateways, or between a security gateway and a host.
If authentication was performed before entering the secure
tunnel establishment phase, the IKE pre-shared key that was
derived in the authentication procedure is used for IKE to
authenticate the IKE end-points (thus no other client authen
tication is performed within IKE negotiation). The client can
When an access router is connected to multiple serving
networks (such as access router AR2 in FIG. 1), a mechanism
for binding an IPSec tunnel to a specific serving network is
needed so that the access router can (1) assign an IPSec tunnel
inner address from the address block of the serving network
and (2) forward packets between the client and the serving
network. The binding can be created in the IKE negotiation by
using the information on the serving network as the IPSec SA
identifier credential. In this way, it is possible to establish
multiple IPSec tunnels between a client node and an access
router, each bound to a distinct serving network, as shown in
FIG. 2. Multiple schemes can be employed, such as single
PANA authentication and session identifier for an entire
25
the serving network(s) that are specified by the Pac in Step 4,
so as to authorize the Pac to have access to the serving
IKE pre-shared secret data which is derived from the MSK.
Establishing S Cure Tunnel to Access Router
Upon successful completion of reception of serving net
work advertising information and client node authentication
(in the case of using PANA for advertising and authentica
tion) or of receiving serving network advertising information
(in the case of using Router Discovery), the client knows
Otherwise, if client authentication was not performed
before entering the secure tunnel establishment phase, an
authentication procedure other than using an IKE pre-shared
key must be performed within the IKE negotiation. In this
case, an identifier that is specific to the authentication proce
50
55
60
65
to use/generate a unique identifier for IKE for a specific
serving network or other information/identifier exchange/ne
gotiation may be required during IKE
When IKEv2 is used for establishing an IPSec tunnel, it is
also possible to establish multiple IPSec tunnels between a
client node and an access router, each bound to a serving
network. When an access router is connected to only one
serving network, there is only one binding and other identi
fiers may be used.
The inner address of an IPSec tunnel SA may be assigned
during IKE negotiation by the access router that terminates
the tunnel. For example, IKEv2 defines a Configuration Pay
load exchange to assign an IPSec tunnel inner address. When
an inner address is notassigned in the IKE negotiation, DHCP
may be performed through the established IPSec tunnel. In
any case, the assigned IPSec inner address must be valid for
the serving network bound to the IPSec SA. Other configu
ration information such as a subnet prefix (or a netmask), a
DNS (Domain Name System) server address, or a DHCP
server address also may be assigned in the IKE negotiation. In
addition, when the client node is an IPv6 router, an IPv6 prefix
delegated from the serving network also can be assigned by
running DHCPv6 with prefix delegation option through the
established IPSec tunnel. In this case, the delegated prefix can
be shared among other client nodes for which the client router
serves as the client-side gateway to the serving network.
An access router can perform Quality of Service (QoS)
control on the IPSec tunnels it terminates, to provide differ
entiated services among IPSec tunnels from different client
nodes and/or among IPSec tunnels from the same client
nodes. The advertising information on the serving network
can also contain the QoS information so that a client node can
specify QoS information during IPSec SA negotiation in IKE.
The present invention also allows multiple access routers
on the same access network to connect to the same serving
network. Thus, load balancing among access routers is pos
sible. When PANA is used in serving network advertising and
authentication, a list of access routers contained in a PANA
APPENDIX AC
US 7,860,978 B2
Bind-Request message during the authentication phase can
be used for identifying which access router is connected to
which serving network.
Broadcast and/or multicast traffic also may be transmitted
through an IPSec tunnel. An access router may have a con
figuration option for allowing and prohibiting transmission of
broadcast/multicast traffic through an IPSec tunnel.
5
A client node that has an IPSec tunnel to an access router
may not use the IPSec tunnel to send or receive packets to
other nodes in the access network. Such packets include
application traffic such as printing data to a local printer in the
10
However, the wireless client will not be able to connect to
access network.
Usage Scenarios
When the present invention is used in DSL or Wireless
LAN hotspots, a serving network can be an ISP network or a
NAP exchange network. The access network is typically
owned by a single NAP, but it is also possible for multiple
NAPs to share the same access network. An example physical
topology when a single NAP 301 owns the access network
101 is shown in FIG. 3.
In this example, the client node 103 is able to selectively
establish connectivity to one, some or all of the serving net
works owned by ISP1, ISP2 ISP3 or NAP 301. When PANA
is used to authenticate the client node, it is possible to perform
two EAP authentications in a single PANA session, one for
the ISP and the other for the NAP possibly with using differ
15
25
30
rations also can be combined.
provider advertising information. This is because neither the
access routers nor the PAA can broadcast provider informa
tion to the remote network.
When the client node is connected to the internal network
from an external network through a firewall in the DMZ
(DeMilitarized Zone, which is a computer or small subnet
35
work that sits between a trusted internal network, such as a
corporate private LAN, and an untrusted external network,
such as the public Internet), the following scenarios are pre
sented:
40
network information.
It is also possible for the access network to be composed of
multipleAccess VLANs 501 and 502 as shown in FIG.5. This
configuration is useful for partitioning traffic in the access
network (as a legacy VLAN network does) such that client
node 103 may establish connections to the Serving VLANs
402-404 through Access VLAN 501, and client node 104 may
establish connections to the Serving VLANs 402-404 through
Access VLAN 502, while still allowing the client nodes to
create dynamic binding to Serving VLANs.
It will now be explained with reference to FIGS. 6 and 7
how the present invention can be used with a layer-2 Dynamic
VLAN model based on a Virtual Access Point (VAP). A
Virtual Access Point is a logical entity that exists within a
physical Access Point (AP). When a single physical AP sup
ports multiple Virtual APs, each Virtual AP appears to client
stations to be an independent physical AP even though only a
single physical AP is present. For example, multiple Virtual
APs might exist within a single physical AP, each advertising
a distinct SSID and capability set. It is assumed that IEEE
802.11 SSID is used as the information to identify a VLAN.
There are two alternate configurations for the present inven
tion as applied to VAPs, as explained below. The two configu
As shown in FIG. 8, client node 103 may want to connect
to the Serving VLANs 402-404 from a remote network site
801. The present invention can support such a situation pro
vided that the client node 103 knows the IP address of the
PAA or the access routers AR1 or AR2 so as to receive service
VLAN 401 is used as the access network for the client node
103. The Serving VLANs 402-404 are VLANs that are used
as the serving networks. Connectivity to the Serving VLANs
is made only through IPSec tunnels established between the
client node 103 and access routers AR1 and AR2 (the access
routers may be virtual routers where the VLANS are config
ured in the same physical network). For each Serving VLAN,
the identifier and name of the VLAN is used as the serving
103 (104) first connects to an Access VLAN 501 (502)
through a Virtual AP 701 (702), and then uses the present
invention to establish connectivity to the Serving VLANs
402–404.
information.
Example physical topologies for VLAN usage are shown in
FIGS. 4-8. VLAN topologies are used mainly for enterprise
network configurations. In the example shown in FIG.4, there
are four VLANs configured in the network. The Access
multiple Serving VLANs at the same time unless it has mul
tiple wireless LAN cards (or supports some sort of “virtual
station” interface on a single physical layer).
If an AP supports dynamic VLAN functionality but does
not support a secure access mechanism as strong as IPsec, the
network administrator will not allow the AP to be directly
connected to a Serving VLAN, but it may be connected to the
Access VLANs as shown in FIG. 7. In this case, a client node
20
ent client identifiers. When the client node 103 creates mul
tiple IPSec tunnels to different ISPs, multihoming is
achieved. Foreach provider (either ISP or NAP), the identifier
and name of the provider may be used as the serving network
10
If an AP supports both a secure access mechanism as strong
as IPSec (or IEEE 802.11i) and dynamic VLAN functionality
(i.e. the ability to handle multiple VLANs), it is possible to
directly (virtually) connect the AP to the Serving VLANs
where a distinct SSID is associated with each Serving VLAN
as shown in FIG. 6. Client node 103 uses the present invention
through a wired Ethernet connection 601 to connect to the
Serving VLANs 1-3, while wireless client node 104 (which
supports IEEE 802.11i) can connect directly to a Serving
VLAN through a wireless connection 602 to Virtual AP 3.
45
50
Where internal network management policy mandates that
all access from the external network is to be protected
with IPSec through an IPSec gateway in the DMZ (such
as where an access router of a Serving VLAN is placed
in the internal network)—In this case, packets transmit
ted through an IPSec tunnel established between the
client node and an access router of a Serving VLAN will
be protected with another IPSec tunnel established
between the client node and the IPSec VPN gateway
(double IPsec).
Where internal network management policy mandates that
all access from the external network is to be protected
with IPsec, but the IPsec gateway does not have to be in
the DMZ–In this case, an additional IPsec tunnel is not
needed.
55
60
The present invention also can be used with Mobile IP
(such as MIPv4) in the following ways. First, since the
present invention allows a client node to dynamically switch
from one serving network to another, a stable IP address is
needed for an application that needs a persistent connectivity
to its corresponding node when switching occurs (it will be
noted that the switching can occur on a mobile client node that
does not physically move). By using Mobile IP, a home
address can be used as such a stable IP address.
65
Second, a mobile client node that is connected to a serving
network may physically move from an area covered by one
access network to an area covered by another access network,
where the access network may be an access network of a
serving network oran access networkina remote network. By
APPENDIX AC
US 7,860,978 B2
11
using Mobile IP the client node can seamlessly move among
different access networks without losing application connec
12
security association identifier of said secure communi
cation tunnel, such that said client node is able to send
and receive data packets to and from the serving network
specified by said client node within said secure commu
nication tunnel through said access network.
2. A method as set forth in claim 1, further comprising the
step of authenticating said client node prior to establishing
tion.
In both cases, the IP header that contains the home address
in a packet appears inside the IPSec tunnel header. In the case
where the client node is connected from an external site to an
internal serving network through a DMZ, an additional
Mobile IP may be used to support external mobility.
said secure communication tunnel.
In VLAN scenarios, if a mobile client node establishes
connectivity to multiple Serving VLANs and each Serving
VLAN uses its own home agent, the client node may run dual
Mobile IP in parallel using multiple home addresses. The
above discussion applies also to the case where Mobile IPv6
10
is used instead of Mobile IP
Broad Scope of the Invention
15
While illustrative embodiments of the invention have been
described herein, the present invention is not limited to the
various preferred embodiments described herein, but
includes any and all embodiments having modifications,
omissions, combinations (e.g., of aspects across various
embodiments), adaptations and/or alterations as would be
appreciated by those in the art based on the present disclosure.
The limitations in the claims are to be interpreted broadly
based on the language employed in the claims and not limited
to examples described in the present specification or during
the prosecution of the application, which examples are to be
construed as non-exclusive. For example, in the present dis
closure, the term “preferably” is non-exclusive and means
“preferably, but not limited to.” Means-plus-function or step
plus-function limitations will only be employed where for a
specific claim limitation all of the following conditions are
present in that limitation: a) “means for’’ or “stepfor” (i.e., not
step on is expressly recited; b) a corresponding function is
expressly recited; and c) structure, material or acts that sup
port that structure are not recited. In this disclosure and during
the prosecution of this application, the terminology “present
invention” or “invention” may be used as a reference to one or
more aspect within the present disclosure. The language
present invention orinvention should not be improperly inter
preted as an identification of criticality, should not be improp
erly interpreted as applying across all aspects or embodi
ments (i.e., it should be understood that the present invention
has a number of aspects and embodiments), and should not be
improperly interpreted as limiting the scope of the application
or claims. In this disclosure and during the prosecution of this
application, the terminology “embodiment” can be used to
describe any aspect, feature, process or step, any combination
thereof, and/or any portion thereof, etc. In some examples,
various embodiments may include overlapping features.
What is claimed is:
network connection;
20
to said client node;
25
client node desires access; and
establishing a communication tunnel between said client
node and said access router through said access network,
such that said client node is able to send and receive data
packets to and from the serving network specified by
30
35
said client node within said communication tunnel
through said access network;
further comprising the step of providing a second access
router having a network connection to said access net
work and having network connections to at least two
serving networks;
wherein when a serving network specified by said client
node is associated with said second access router, said
40
establishing step further comprises the step of binding
said communication tunnel to said specified serving net
work associated with said second access router by using
serving network information of said specified serving
network as a security association identifier of said com
munication tunnel.
5. A method as set forth in claim 1, wherein said access
45
50
router has network connections to at least two serving net
works, said method further comprising the step of establish
ing a second secure communication tunnel between said cli
ent node and said access router through said access network,
such that said client node is able to selectively send and
receive data packets to and from each of said two serving
networks.
6. A method of dynamically connecting a client node to a
serving network, comprising the steps of:
providing an access network to which a client node has a
network connection;
55
60
network connection;
providing at least one access router having a network con
nection to said access network and having a network
connection to at least one serving network;
sending serving network provider advertising information
to said client node;
receiving from said client node serving network provider
information specifying a serving network to which said
client node desires access; and
client node desires access; and
establishing a secure communication tunnel between said
client node and said access router through said access
network using information of said serving network as a
providing at least one access router having a network con
nection to said access network and having a network
connection to at least one serving network;
sending serving network provider advertising information
receiving from said client node serving network provider
information specifying a serving network to which said
1. A method of dynamically connecting a client node to a
serving network, comprising the steps of:
providing an access network to which a client node has a
providing at least one access router having a network con
nection to said access network and having a network
connection to at least one serving network;
sending serving network provider advertising information
to said client node, said network provider advertising
information including a provider identifier advertised
per each service provider;
receiving from said client node serving network provider
information specifying a serving network to which said
3. A method as set forth in claim 1, further comprising the
step of providing a second access router having a network
connection to said access network and having network con
nections to at least two serving networks.
4. A method of dynamically connecting a client node to a
serving network, comprising the steps of:
providing an access network to which a client node has a
65
establishing a communication tunnel between said client
node and said access router through said access network,
such that said client node is able to send and receive data
packets to and from the serving network specified by
APPENDIX AC
US 7,860,978 B2
13
said client node within said communication tunnel
through said access network;
further comprising the step of providing a second access
router having a network connection to said access net
work and a network connection to at least one serving
network, said method further comprising the step of
establishing a second communication tunnel between
said client node and said second access router through
5
fier of said secure communication tunnel.
said access network, such that said client node is able to
selectively send and receive data packets to and from
each of said serving networks associated with said
access routers through said communication tunnels.
7. A method as set forth in claim 1, wherein said step of
sending serving network provider advertising information
comprises the step of using a PANA protocol.
8. A method as set forth in claim 1, wherein said step of
sending serving network provider advertising information
comprises the step of using a Router Discovery mechanism.
10
15
21. A method as set forth in claim 20, further comprising
the step of establishing said secure communication tunnel
using an IPSec key management protocol.
22. A method of connecting a client node to a serving
network, comprising the steps of:
providing an access router having a network connection to
at least two serving networks;
sending serving network provider advertising information
to said client node;
receiving from said client node serving network informa
tion specifying a serving network to which said client
9. A method as set forth in claim 1, wherein said at leastone
serving network comprises an Internet Service Provider net
14
20. A method as set forth in claim 1, wherein said step of
sending serving network provider advertising information is
performed using network layer protocols, and wherein said
establishing step further comprises the step of binding said
secure communication tunnel to a specified serving network
associated with an access router by using a PANA session
identifier or an IP address as said security association identi
20
node desires to have access;
10. A method as set forth in claim 1, wherein said at least
establishing a secure communication tunnel between said
client node and said access router through said access
one serving network comprises a Network Access Provider
network, such that said client node is able to send and
work.
network.
11. A method as set forth in claim 1, wherein said at least
one serving network comprises a VLAN network.
12. A method as set forth in claim 11, further comprising
the step of providing a virtual access point in said VLAN
serving network, through which a client node may connect
directly to said VLAN serving network.
25
30
13. A method as set forth in claim 1, wherein said access
network comprises an IP access network.
14. A method as set forth in claim 1, wherein said access
network comprises a VLAN access network.
15. A method as set forth in claim 14, wherein said VLAN
35
access network is partitioned into multiple VLAN access
sub-networks.
16. A method as set forth in claim 14, further comprising
the step of providing a virtual access point in said VLAN
access network, through which a client node may connect to
receive data packets to and from the serving network
specified by said client node within said secure commu
nication tunnel through said access network; and
binding said secure communication tunnel to said specified
serving network by using serving network information
of said specified serving network as a security associa
tion identifier of said secure communication tunnel.
23. A method as set forth in claim 22, wherein said step of
sending serving network provider advertising information is
performed using network layer protocols, and wherein said
establishing step further comprises the step of binding said
secure communication tunnel to a specified serving network
associated with an access router by using a PANA session
identifier or an IP address as said security association identi
fier of said secure communication tunnel.
24. A method as set forth in claim 23, further comprising
the step of establishing said secure communication tunnel
using an IPSec key management protocol.
said VLAN access network.
25. The method of claim 1, wherein said advertising infor
17. A method as set forth in claim 1, wherein said client
mation includes said provider identifier being a unique iden
node connects to said access network via a remote network.
identifies a provider and a provider name character
18. A method as set forth in claim 1, wherein the step of tifier that
that represents the name of the provider.
establishing said secure communication tunnel comprises the 5 string
26. The method of claim 25, wherein said advertising infor
step of using an IPSec key management protocol.
mation
is advertised using protocol for carrying authentica
19. A method as set forth in claim 1, wherein said client
tion
information
for network access (PANA).
node is a mobile node, and said network connection of said
client node to said access network is a wireless connection.
40
APPENDIX AD
Network Working Group
Request for Comments: 2401
Obsoletes: 1825
Category: Standards Track
S. Kent
BBN Corp
R. Atkinson
@Home Network
November 1998
Security Architecture for the Internet Protocol
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998).
All Rights Reserved.
Table of Contents
1. Introduction........................................................3
1.1 Summary of Contents of Document..................................3
1.2 Audience.........................................................3
1.3 Related Documents................................................4
2. Design Objectives...................................................4
2.1 Goals/Objectives/Requirements/Problem Description................4
2.2 Caveats and Assumptions..........................................5
3. System Overview.....................................................5
3.1 What IPsec Does..................................................6
3.2 How IPsec Works..................................................6
3.3 Where IPsec May Be Implemented...................................7
4. Security Associations...............................................8
4.1 Definition and Scope.............................................8
4.2 Security Association Functionality..............................10
4.3 Combining Security Associations.................................11
4.4 Security Association Databases..................................13
4.4.1 The Security Policy Database (SPD).........................14
4.4.2 Selectors..................................................17
4.4.3 Security Association Database (SAD)........................21
4.5 Basic Combinations of Security Associations.....................24
4.6 SA and Key Management...........................................26
4.6.1 Manual Techniques..........................................27
4.6.2 Automated SA and Key Management............................27
4.6.3 Locating a Security Gateway................................28
4.7 Security Associations and Multicast.............................29
Kent & Atkinson
Standards Track
[Page 1]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
5. IP Traffic Processing..............................................30
5.1 Outbound IP Traffic Processing..................................30
5.1.1 Selecting and Using an SA or SA Bundle.....................30
5.1.2 Header Construction for Tunnel Mode........................31
5.1.2.1 IPv4 -- Header Construction for Tunnel Mode...........31
5.1.2.2 IPv6 -- Header Construction for Tunnel Mode...........32
5.2 Processing Inbound IP Traffic...................................33
5.2.1 Selecting and Using an SA or SA Bundle.....................33
5.2.2 Handling of AH and ESP tunnels.............................34
6. ICMP Processing (relevant to IPsec)................................35
6.1 PMTU/DF Processing..............................................36
6.1.1 DF Bit.....................................................36
6.1.2 Path MTU Discovery (PMTU)..................................36
6.1.2.1 Propagation of PMTU...................................36
6.1.2.2 Calculation of PMTU...................................37
6.1.2.3 Granularity of PMTU Processing........................37
6.1.2.4 PMTU Aging............................................38
7. Auditing...........................................................39
8. Use in Systems Supporting Information Flow Security................39
8.1 Relationship Between Security Associations and Data Sensitivity.40
8.2 Sensitivity Consistency Checking................................40
8.3 Additional MLS Attributes for Security Association Databases....41
8.4 Additional Inbound Processing Steps for MLS Networking..........41
8.5 Additional Outbound Processing Steps for MLS Networking.........41
8.6 Additional MLS Processing for Security Gateways.................42
9. Performance Issues.................................................42
10. Conformance Requirements..........................................43
11. Security Considerations...........................................43
12. Differences from RFC 1825.........................................43
Acknowledgements......................................................44
Appendix A -- Glossary................................................45
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues.....48
B.1 DF bit..........................................................48
B.2 Fragmentation...................................................48
B.3 Path MTU Discovery..............................................52
B.3.1 Identifying the Originating Host(s)........................53
B.3.2 Calculation of PMTU........................................55
B.3.3 Granularity of Maintaining PMTU Data.......................56
B.3.4 Per Socket Maintenance of PMTU Data........................57
B.3.5 Delivery of PMTU Data to the Transport Layer...............57
B.3.6 Aging of PMTU Data.........................................57
Appendix C -- Sequence Space Window Code Example......................58
Appendix D -- Categorization of ICMP messages.........................60
References............................................................63
Disclaimer............................................................64
Author Information....................................................65
Full Copyright Statement..............................................66
Kent & Atkinson
Standards Track
[Page 2]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
1. Introduction
1.1 Summary of Contents of Document
This memo specifies the base architecture for IPsec compliant
systems. The goal of the architecture is to provide various security
services for traffic at the IP layer, in both the IPv4 and IPv6
environments. This document describes the goals of such systems,
their components and how they fit together with each other and into
the IP environment. It also describes the security services offered
by the IPsec protocols, and how these services can be employed in the
IP environment. This document does not address all aspects of IPsec
architecture. Subsequent documents will address additional
architectural details of a more advanced nature, e.g., use of IPsec
in NAT environments and more complete support for IP multicast. The
following fundamental components of the IPsec security architecture
are discussed in terms of their underlying, required functionality.
Additional RFCs (see Section 1.3 for pointers to other documents)
define the protocols in (a), (c), and (d).
a. Security Protocols -- Authentication Header (AH) and
Encapsulating Security Payload (ESP)
b. Security Associations -- what they are and how they work,
how they are managed, associated processing
c. Key Management -- manual and automatic (The Internet Key
Exchange (IKE))
d. Algorithms for authentication and encryption
This document is not an overall Security Architecture for the
Internet; it addresses security only at the IP layer, provided
through the use of a combination of cryptographic and protocol
security mechanisms.
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 RFC 2119 [Bra97].
1.2 Audience
The target audience for this document includes implementers of this
IP security technology and others interested in gaining a general
background understanding of this system. In particular, prospective
users of this technology (end users or system administrators) are
part of the target audience. A glossary is provided as an appendix
Kent & Atkinson
Standards Track
[Page 3]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
to help fill in gaps in background/vocabulary. This document assumes
that the reader is familiar with the Internet Protocol, related
networking technology, and general security terms and concepts.
1.3 Related Documents
As mentioned above, other documents provide detailed definitions of
some of the components of IPsec and of their inter-relationship.
They include RFCs on the following topics:
a. "IP Security Document Roadmap" [TDG97] -- a document
providing guidelines for specifications describing encryption
and authentication algorithms used in this system.
b. security protocols -- RFCs describing the Authentication
Header (AH) [KA98a] and Encapsulating Security Payload (ESP)
[KA98b] protocols.
c. algorithms for authentication and encryption -- a separate
RFC for each algorithm.
d. automatic key management -- RFCs on "The Internet Key
Exchange (IKE)" [HC98], "Internet Security Association and
Key Management Protocol (ISAKMP)" [MSST97],"The OAKLEY Key
Determination Protocol" [Orm97], and "The Internet IP
Security Domain of Interpretation for ISAKMP" [Pip98].
2. Design Objectives
2.1 Goals/Objectives/Requirements/Problem Description
IPsec is designed to provide interoperable, high quality,
cryptographically-based security for IPv4 and IPv6. The set of
security services offered includes access control, connectionless
integrity, data origin authentication, protection against replays (a
form of partial sequence integrity), confidentiality (encryption),
and limited traffic flow confidentiality. These services are
provided at the IP layer, offering protection for IP and/or upper
layer protocols.
These objectives are met through the use of two traffic security
protocols, the Authentication Header (AH) and the Encapsulating
Security Payload (ESP), and through the use of cryptographic key
management procedures and protocols. The set of IPsec protocols
employed in any context, and the ways in which they are employed,
will be determined by the security and system requirements of users,
applications, and/or sites/organizations.
When these mechanisms are correctly implemented and deployed, they
ought not to adversely affect users, hosts, and other Internet
components that do not employ these security mechanisms for
Kent & Atkinson
Standards Track
[Page 4]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
protection of their traffic. These mechanisms also are designed to
be algorithm-independent. This modularity permits selection of
different sets of algorithms without affecting the other parts of the
implementation. For example, different user communities may select
different sets of algorithms (creating cliques) if required.
A standard set of default algorithms is specified to facilitate
interoperability in the global Internet. The use of these
algorithms, in conjunction with IPsec traffic protection and key
management protocols, is intended to permit system and application
developers to deploy high quality, Internet layer, cryptographic
security technology.
2.2 Caveats and Assumptions
The suite of IPsec protocols and associated default algorithms are
designed to provide high quality security for Internet traffic.
However, the security offered by use of these protocols ultimately
depends on the quality of the their implementation, which is outside
the scope of this set of standards. Moreover, the security of a
computer system or network is a function of many factors, including
personnel, physical, procedural, compromising emanations, and
computer security practices. Thus IPsec is only one part of an
overall system security architecture.
Finally, the security afforded by the use of IPsec is critically
dependent on many aspects of the operating environment in which the
IPsec implementation executes. For example, defects in OS security,
poor quality of random number sources, sloppy system management
protocols and practices, etc. can all degrade the security provided
by IPsec. As above, none of these environmental attributes are
within the scope of this or other IPsec standards.
3. System Overview
This section provides a high level description of how IPsec works,
the components of the system, and how they fit together to provide
the security services noted above. The goal of this description is
to enable the reader to "picture" the overall process/system, see how
it fits into the IP environment, and to provide context for later
sections of this document, which describe each of the components in
more detail.
An IPsec implementation operates in a host or a security gateway
environment, affording protection to IP traffic. The protection
offered is based on requirements defined by a Security Policy
Database (SPD) established and maintained by a user or system
administrator, or by an application operating within constraints
Kent & Atkinson
Standards Track
[Page 5]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
established by either of the above. In general, packets are selected
for one of three processing modes based on IP and transport layer
header information (Selectors, Section 4.4.2) matched against entries
in the database (SPD). Each packet is either afforded IPsec security
services, discarded, or allowed to bypass IPsec, based on the
applicable database policies identified by the Selectors.
3.1 What IPsec Does
IPsec provides security services at the IP layer by enabling a system
to select required security protocols, determine the algorithm(s) to
use for the service(s), and put in place any cryptographic keys
required to provide the requested services. IPsec can be used to
protect one or more "paths" between a pair of hosts, between a pair
of security gateways, or between a security gateway and a host. (The
term "security gateway" is used throughout the IPsec documents to
refer to an intermediate system that implements IPsec protocols. For
example, a router or a firewall implementing IPsec is a security
gateway.)
The set of security services that IPsec can provide includes access
control, connectionless integrity, data origin authentication,
rejection of replayed packets (a form of partial sequence integrity),
confidentiality (encryption), and limited traffic flow
confidentiality. Because these services are provided at the IP
layer, they can be used by any higher layer protocol, e.g., TCP, UDP,
ICMP, BGP, etc.
The IPsec DOI also supports negotiation of IP compression [SMPT98],
motivated in part by the observation that when encryption is employed
within IPsec, it prevents effective compression by lower protocol
layers.
3.2 How IPsec Works
IPsec uses two protocols to provide traffic security -Authentication Header (AH) and Encapsulating Security Payload (ESP).
Both protocols are described in more detail in their respective RFCs
[KA98a, KA98b].
o The IP Authentication Header (AH) [KA98a] provides
connectionless integrity, data origin authentication, and an
optional anti-replay service.
o The Encapsulating Security Payload (ESP) protocol [KA98b] may
provide confidentiality (encryption), and limited traffic flow
confidentiality. It also may provide connectionless
Kent & Atkinson
Standards Track
[Page 6]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
integrity, data origin authentication, and an anti-replay
service. (One or the other set of these security services
must be applied whenever ESP is invoked.)
o Both AH and ESP are vehicles for access control, based on the
distribution of cryptographic keys and the management of
traffic flows relative to these security protocols.
These protocols may be applied alone or in combination with each
other to provide a desired set of security services in IPv4 and IPv6.
Each protocol supports two modes of use: transport mode and tunnel
mode. In transport mode the protocols provide protection primarily
for upper layer protocols; in tunnel mode, the protocols are applied
to tunneled IP packets. The differences between the two modes are
discussed in Section 4.
IPsec allows the user (or system administrator) to control the
granularity at which a security service is offered. For example, one
can create a single encrypted tunnel to carry all the traffic between
two security gateways or a separate encrypted tunnel can be created
for each TCP connection between each pair of hosts communicating
across these gateways. IPsec management must incorporate facilities
for specifying:
o which security services to use and in what combinations
o the granularity at which a given security protection should be
applied
o the algorithms used to effect cryptographic-based security
Because these security services use shared secret values
(cryptographic keys), IPsec relies on a separate set of mechanisms
for putting these keys in place. (The keys are used for
authentication/integrity and encryption services.) This document
requires support for both manual and automatic distribution of keys.
It specifies a specific public-key based approach (IKE -- [MSST97,
Orm97, HC98]) for automatic key management, but other automated key
distribution techniques MAY be used. For example, KDC-based systems
such as Kerberos and other public-key systems such as SKIP could be
employed.
3.3 Where IPsec May Be Implemented
There are several ways in which IPsec may be implemented in a host or
in conjunction with a router or firewall (to create a security
gateway). Several common examples are provided below:
a. Integration of IPsec into the native IP implementation. This
requires access to the IP source code and is applicable to
both hosts and security gateways.
Kent & Atkinson
Standards Track
[Page 7]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
b. "Bump-in-the-stack" (BITS) implementations, where IPsec is
implemented "underneath" an existing implementation of an IP
protocol stack, between the native IP and the local network
drivers. Source code access for the IP stack is not required
in this context, making this implementation approach
appropriate for use with legacy systems. This approach, when
it is adopted, is usually employed in hosts.
c. The use of an outboard crypto processor is a common design
feature of network security systems used by the military, and
of some commercial systems as well. It is sometimes referred
to as a "Bump-in-the-wire" (BITW) implementation. Such
implementations may be designed to serve either a host or a
gateway (or both). Usually the BITW device is IP
addressable. When supporting a single host, it may be quite
analogous to a BITS implementation, but in supporting a
router or firewall, it must operate like a security gateway.
4. Security Associations
This section defines Security Association management requirements for
all IPv6 implementations and for those IPv4 implementations that
implement AH, ESP, or both. The concept of a "Security Association"
(SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a
major function of IKE is the establishment and maintenance of
Security Associations. All implementations of AH or ESP MUST support
the concept of a Security Association as described below. The
remainder of this section describes various aspects of Security
Association management, defining required characteristics for SA
policy management, traffic processing, and SA management techniques.
4.1 Definition and Scope
A Security Association (SA) is a simplex "connection" that affords
security services to the traffic carried by it. Security services
are afforded to an SA by the use of AH, or ESP, but not both. If
both AH and ESP protection is applied to a traffic stream, then two
(or more) SAs are created to afford protection to the traffic stream.
To secure typical, bi-directional communication between two hosts, or
between two security gateways, two Security Associations (one in each
direction) are required.
A security association is uniquely identified by a triple consisting
of a Security Parameter Index (SPI), an IP Destination Address, and a
security protocol (AH or ESP) identifier. In principle, the
Destination Address may be a unicast address, an IP broadcast
address, or a multicast group address. However, IPsec SA management
mechanisms currently are defined only for unicast SAs. Hence, in the
Kent & Atkinson
Standards Track
[Page 8]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
discussions that follow, SAs will be described in the context of
point-to-point communication, even though the concept is applicable
in the point-to-multipoint case as well.
As noted above, two types of SAs are defined: transport mode and
tunnel mode. A transport mode SA is a security association between
two hosts. In IPv4, a transport mode security protocol header
appears immediately after the IP header and any options, and before
any higher layer protocols (e.g., TCP or UDP). In IPv6, the security
protocol header appears after the base IP header and extensions, but
may appear before or after destination options, and before higher
layer protocols. In the case of ESP, a transport mode SA provides
security services only for these higher layer protocols, not for the
IP header or any extension headers preceding the ESP header. In the
case of AH, the protection is also extended to selected portions of
the IP header, selected portions of extension headers, and selected
options (contained in the IPv4 header, IPv6 Hop-by-Hop extension
header, or IPv6 Destination extension headers). For more details on
the coverage afforded by AH, see the AH specification [KA98a].
A tunnel mode SA is essentially an SA applied to an IP tunnel.
Whenever either end of a security association is a security gateway,
the SA MUST be tunnel mode. Thus an SA between two security gateways
is always a tunnel mode SA, as is an SA between a host and a security
gateway. Note that for the case where traffic is destined for a
security gateway, e.g., SNMP commands, the security gateway is acting
as a host and transport mode is allowed. But in that case, the
security gateway is not acting as a gateway, i.e., not transiting
traffic. Two hosts MAY establish a tunnel mode SA between
themselves. The requirement for any (transit traffic) SA involving a
security gateway to be a tunnel SA arises due to the need to avoid
potential problems with regard to fragmentation and reassembly of
IPsec packets, and in circumstances where multiple paths (e.g., via
different security gateways) exist to the same destination behind the
security gateways.
For a tunnel mode SA, there is an "outer" IP header that specifies
the IPsec processing destination, plus an "inner" IP header that
specifies the (apparently) ultimate destination for the packet. The
security protocol header appears after the outer IP header, and
before the inner IP header. If AH is employed in tunnel mode,
portions of the outer IP header are afforded protection (as above),
as well as all of the tunneled IP packet (i.e., all of the inner IP
header is protected, as well as higher layer protocols). If ESP is
employed, the protection is afforded only to the tunneled packet, not
to the outer header.
Kent & Atkinson
Standards Track
[Page 9]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
In summary,
a) A host MUST support both transport and tunnel mode.
b) A security gateway is required to support only tunnel
mode. If it supports transport mode, that should be used
only when the security gateway is acting as a host, e.g.,
for network management.
4.2 Security Association Functionality
The set of security services offered by an SA depends on the security
protocol selected, the SA mode, the endpoints of the SA, and on the
election of optional services within the protocol. For example, AH
provides data origin authentication and connectionless integrity for
IP datagrams (hereafter referred to as just "authentication"). The
"precision" of the authentication service is a function of the
granularity of the security association with which AH is employed, as
discussed in Section 4.4.2, "Selectors".
AH also offers an anti-replay (partial sequence integrity) service at
the discretion of the receiver, to help counter denial of service
attacks. AH is an appropriate protocol to employ when
confidentiality is not required (or is not permitted, e.g , due to
government restrictions on use of encryption). AH also provides
authentication for selected portions of the IP header, which may be
necessary in some contexts. For example, if the integrity of an IPv4
option or IPv6 extension header must be protected en route between
sender and receiver, AH can provide this service (except for the
non-predictable but mutable parts of the IP header.)
ESP optionally provides confidentiality for traffic. (The strength
of the confidentiality service depends in part, on the encryption
algorithm employed.) ESP also may optionally provide authentication
(as defined above). If authentication is negotiated for an ESP SA,
the receiver also may elect to enforce an anti-replay service with
the same features as the AH anti-replay service. The scope of the
authentication offered by ESP is narrower than for AH, i.e., the IP
header(s) "outside" the ESP header is(are) not protected. If only
the upper layer protocols need to be authenticated, then ESP
authentication is an appropriate choice and is more space efficient
than use of AH encapsulating ESP. Note that although both
confidentiality and authentication are optional, they cannot both be
omitted. At least one of them MUST be selected.
If confidentiality service is selected, then an ESP (tunnel mode) SA
between two security gateways can offer partial traffic flow
confidentiality. The use of tunnel mode allows the inner IP headers
to be encrypted, concealing the identities of the (ultimate) traffic
source and destination. Moreover, ESP payload padding also can be
Kent & Atkinson
Standards Track
[Page 10]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
invoked to hide the size of the packets, further concealing the
external characteristics of the traffic. Similar traffic flow
confidentiality services may be offered when a mobile user is
assigned a dynamic IP address in a dialup context, and establishes a
(tunnel mode) ESP SA to a corporate firewall (acting as a security
gateway). Note that fine granularity SAs generally are more
vulnerable to traffic analysis than coarse granularity ones which are
carrying traffic from many subscribers.
4.3 Combining Security Associations
The IP datagrams transmitted over an individual SA are afforded
protection by exactly one security protocol, either AH or ESP, but
not both. Sometimes a security policy may call for a combination of
services for a particular traffic flow that is not achievable with a
single SA. In such instances it will be necessary to employ multiple
SAs to implement the required security policy. The term "security
association bundle" or "SA bundle" is applied to a sequence of SAs
through which traffic must be processed to satisfy a security policy.
The order of the sequence is defined by the policy. (Note that the
SAs that comprise a bundle may terminate at different endpoints. For
example, one SA may extend between a mobile host and a security
gateway and a second, nested SA may extend to a host behind the
gateway.)
Security associations may be combined into bundles in two ways:
transport adjacency and iterated tunneling.
o Transport adjacency refers to applying more than one
security protocol to the same IP datagram, without invoking
tunneling. This approach to combining AH and ESP allows
for only one level of combination; further nesting yields
no added benefit (assuming use of adequately strong
algorithms in each protocol) since the processing is
performed at one IPsec instance at the (ultimate)
destination.
Host 1 --- Security ---- Internet -- Security --- Host 2
| |
Gwy 1
Gwy 2
| |
| |
| |
| -----Security Association 1 (ESP transport)------- |
|
|
-------Security Association 2 (AH transport)---------o Iterated tunneling refers to the application of multiple
layers of security protocols effected through IP tunneling.
This approach allows for multiple levels of nesting, since
each tunnel can originate or terminate at a different IPsec
Kent & Atkinson
Standards Track
[Page 11]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
site along the path. No special treatment is expected for
ISAKMP traffic at intermediate security gateways other than
what can be specified through appropriate SPD entries (See
Case 3 in Section 4.5)
There are 3 basic cases of iterated tunneling -- support is
required only for cases 2 and 3.:
1. both endpoints for the SAs are the same -- The inner and
outer tunnels could each be either AH or ESP, though it
is unlikely that Host 1 would specify both to be the
same, i.e., AH inside of AH or ESP inside of ESP.
Host 1 --- Security ---- Internet -- Security --- Host 2
| |
Gwy 1
Gwy 2
| |
| |
| |
| -------Security Association 1 (tunnel)---------- | |
|
|
---------Security Association 2 (tunnel)-------------2. one endpoint of the SAs is the same -- The inner and
uter tunnels could each be either AH or ESP.
Host 1 --- Security ---- Internet -- Security --- Host 2
| |
Gwy 1
Gwy 2
|
| |
|
|
| ----Security Association 1 (tunnel)---|
|
|
---------Security Association 2 (tunnel)------------3. neither endpoint is the same -- The inner and outer
tunnels could each be either AH or ESP.
Host 1 --- Security ---- Internet -- Security --- Host 2
|
Gwy 1
Gwy 2
|
|
|
|
|
|
--Security Assoc 1 (tunnel)|
|
|
-----------Security Association 2 (tunnel)----------These two approaches also can be combined, e.g., an SA bundle could
be constructed from one tunnel mode SA and one or two transport mode
SAs, applied in sequence. (See Section 4.5 "Basic Combinations of
Security Associations.") Note that nested tunnels can also occur
where neither the source nor the destination endpoints of any of the
tunnels are the same. In that case, there would be no host or
security gateway with a bundle corresponding to the nested tunnels.
Kent & Atkinson
Standards Track
[Page 12]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
For transport mode SAs, only one ordering of security protocols seems
appropriate. AH is applied to both the upper layer protocols and
(parts of) the IP header. Thus if AH is used in a transport mode, in
conjunction with ESP, AH SHOULD appear as the first header after IP,
prior to the appearance of ESP. In that context, AH is applied to
the ciphertext output of ESP. In contrast, for tunnel mode SAs, one
can imagine uses for various orderings of AH and ESP. The required
set of SA bundle types that MUST be supported by a compliant IPsec
implementation is described in Section 4.5.
4.4 Security Association Databases
Many of the details associated with processing IP traffic in an IPsec
implementation are largely a local matter, not subject to
standardization. However, some external aspects of the processing
must be standardized, to ensure interoperability and to provide a
minimum management capability that is essential for productive use of
IPsec. This section describes a general model for processing IP
traffic relative to security associations, in support of these
interoperability and functionality goals. The model described below
is nominal; compliant implementations need not match details of this
model as presented, but the external behavior of such implementations
must be mappable to the externally observable characteristics of this
model.
There are two nominal databases in this model: the Security Policy
Database and the Security Association Database. The former specifies
the policies that determine the disposition of all IP traffic inbound
or outbound from a host, security gateway, or BITS or BITW IPsec
implementation. The latter database contains parameters that are
associated with each (active) security association. This section
also defines the concept of a Selector, a set of IP and upper layer
protocol field values that is used by the Security Policy Database to
map traffic to a policy, i.e., an SA (or SA bundle).
Each interface for which IPsec is enabled requires nominally separate
inbound vs. outbound databases (SAD and SPD), because of the
directionality of many of the fields that are used as selectors.
Typically there is just one such interface, for a host or security
gateway (SG). Note that an SG would always have at least 2
interfaces, but the "internal" one to the corporate net, usually
would not have IPsec enabled and so only one pair of SADs and one
pair of SPDs would be needed. On the other hand, if a host had
multiple interfaces or an SG had multiple external interfaces, it
might be necessary to have separate SAD and SPD pairs for each
interface.
Kent & Atkinson
Standards Track
[Page 13]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
4.4.1 The Security Policy Database (SPD)
Ultimately, a security association is a management construct used to
enforce a security policy in the IPsec environment. Thus an
essential element of SA processing is an underlying Security Policy
Database (SPD) that specifies what services are to be offered to IP
datagrams and in what fashion. The form of the database and its
interface are outside the scope of this specification. However, this
section does specify certain minimum management functionality that
must be provided, to allow a user or system administrator to control
how IPsec is applied to traffic transmitted or received by a host or
transiting a security gateway.
The SPD must be consulted during the processing of all traffic
(INBOUND and OUTBOUND), including non-IPsec traffic. In order to
support this, the SPD requires distinct entries for inbound and
outbound traffic. One can think of this as separate SPDs (inbound
vs. outbound). In addition, a nominally separate SPD must be
provided for each IPsec-enabled interface.
An SPD must discriminate among traffic that is afforded IPsec
protection and traffic that is allowed to bypass IPsec. This applies
to the IPsec protection to be applied by a sender and to the IPsec
protection that must be present at the receiver. For any outbound or
inbound datagram, three processing choices are possible: discard,
bypass IPsec, or apply IPsec. The first choice refers to traffic
that is not allowed to exit the host, traverse the security gateway,
or be delivered to an application at all. The second choice refers
to traffic that is allowed to pass without additional IPsec
protection. The third choice refers to traffic that is afforded
IPsec protection, and for such traffic the SPD must specify the
security services to be provided, protocols to be employed,
algorithms to be used, etc.
For every IPsec implementation, there MUST be an administrative
interface that allows a user or system administrator to manage the
SPD. Specifically, every inbound or outbound packet is subject to
processing by IPsec and the SPD must specify what action will be
taken in each case. Thus the administrative interface must allow the
user (or system administrator) to specify the security processing to
be applied to any packet entering or exiting the system, on a packet
by packet basis. (In a host IPsec implementation making use of a
socket interface, the SPD may not need to be consulted on a per
packet basis, but the effect is still the same.) The management
interface for the SPD MUST allow creation of entries consistent with
the selectors defined in Section 4.4.2, and MUST support (total)
ordering of these entries. It is expected that through the use of
wildcards in various selector fields, and because all packets on a
Kent & Atkinson
Standards Track
[Page 14]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
single UDP or TCP connection will tend to match a single SPD entry,
this requirement will not impose an unreasonably detailed level of
SPD specification. The selectors are analogous to what are found in
a stateless firewall or filtering router and which are currently
manageable this way.
In host systems, applications MAY be allowed to select what security
processing is to be applied to the traffic they generate and consume.
(Means of signalling such requests to the IPsec implementation are
outside the scope of this standard.) However, the system
administrator MUST be able to specify whether or not a user or
application can override (default) system policies. Note that
application specified policies may satisfy system requirements, so
that the system may not need to do additional IPsec processing beyond
that needed to meet an application’s requirements. The form of the
management interface is not specified by this document and may differ
for hosts vs. security gateways, and within hosts the interface may
differ for socket-based vs. BITS implementations. However, this
document does specify a standard set of SPD elements that all IPsec
implementations MUST support.
The SPD contains an ordered list of policy entries. Each policy
entry is keyed by one or more selectors that define the set of IP
traffic encompassed by this policy entry. (The required selector
types are defined in Section 4.4.2.) These define the granularity of
policies or SAs. Each entry includes an indication of whether
traffic matching this policy will be bypassed, discarded, or subject
to IPsec processing. If IPsec processing is to be applied, the entry
includes an SA (or SA bundle) specification, listing the IPsec
protocols, modes, and algorithms to be employed, including any
nesting requirements. For example, an entry may call for all
matching traffic to be protected by ESP in transport mode using
3DES-CBC with an explicit IV, nested inside of AH in tunnel mode
using HMAC/SHA-1. For each selector, the policy entry specifies how
to derive the corresponding values for a new Security Association
Database (SAD, see Section 4.4.3) entry from those in the SPD and the
packet (Note that at present, ranges are only supported for IP
addresses; but wildcarding can be expressed for all selectors):
a. use the value in the packet itself -- This will limit use
of the SA to those packets which have this packet’s value
for the selector even if the selector for the policy entry
has a range of allowed values or a wildcard for this
selector.
b. use the value associated with the policy entry -- If this
were to be just a single value, then there would be no
difference between (b) and (a). However, if the allowed
values for the selector are a range (for IP addresses) or
Kent & Atkinson
Standards Track
[Page 15]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
wildcard, then in the case of a range,(b) would enable use
of the SA by any packet with a selector value within the
range not just by packets with the selector value of the
packet that triggered the creation of the SA. In the case
of a wildcard, (b) would allow use of the SA by packets
with any value for this selector.
For example, suppose there is an SPD entry where the allowed value
for source address is any of a range of hosts (192.168.2.1 to
192.168.2.10). And suppose that a packet is to be sent that has a
source address of 192.168.2.3. The value to be used for the SA could
be any of the sample values below depending on what the policy entry
for this selector says is the source of the selector value:
source for the
value to be
used in the SA
--------------a. packet
b. SPD entry
example of
new SAD
selector value
-----------192.168.2.3 (one host)
192.168.2.1 to 192.168.2.10 (range of hosts)
Note that if the SPD entry had an allowed value of wildcard for the
source address, then the SAD selector value could be wildcard (any
host). Case (a) can be used to prohibit sharing, even among packets
that match the same SPD entry.
As described below in Section 4.4.3, selectors may include "wildcard"
entries and hence the selectors for two entries may overlap. (This
is analogous to the overlap that arises with ACLs or filter entries
in routers or packet filtering firewalls.) Thus, to ensure
consistent, predictable processing, SPD entries MUST be ordered and
the SPD MUST always be searched in the same order, so that the first
matching entry is consistently selected. (This requirement is
necessary as the effect of processing traffic against SPD entries
must be deterministic, but there is no way to canonicalize SPD
entries given the use of wildcards for some selectors.) More detail
on matching of packets against SPD entries is provided in Section 5.
Note that if ESP is specified, either (but not both) authentication
or encryption can be omitted. So it MUST be possible to configure
the SPD value for the authentication or encryption algorithms to be
"NULL". However, at least one of these services MUST be selected,
i.e., it MUST NOT be possible to configure both of them as "NULL".
The SPD can be used to map traffic to specific SAs or SA bundles.
Thus it can function both as the reference database for security
policy and as the map to existing SAs (or SA bundles). (To
accommodate the bypass and discard policies cited above, the SPD also
Kent & Atkinson
Standards Track
[Page 16]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
MUST provide a means of mapping traffic to these functions, even
though they are not, per se, IPsec processing.) The way in which the
SPD operates is different for inbound vs. outbound traffic and it
also may differ for host vs. security gateway, BITS, and BITW
implementations. Sections 5.1 and 5.2 describe the use of the SPD
for outbound and inbound processing, respectively.
Because a security policy may require that more than one SA be
applied to a specified set of traffic, in a specific order, the
policy entry in the SPD must preserve these ordering requirements,
when present. Thus, it must be possible for an IPsec implementation
to determine that an outbound or inbound packet must be processed
thorough a sequence of SAs. Conceptually, for outbound processing,
one might imagine links (to the SAD) from an SPD entry for which
there are active SAs, and each entry would consist of either a single
SA or an ordered list of SAs that comprise an SA bundle. When a
packet is matched against an SPD entry and there is an existing SA or
SA bundle that can be used to carry the traffic, the processing of
the packet is controlled by the SA or SA bundle entry on the list.
For an inbound IPsec packet for which multiple IPsec SAs are to be
applied, the lookup based on destination address, IPsec protocol, and
SPI should identify a single SA.
The SPD is used to control the flow of ALL traffic through an IPsec
system, including security and key management traffic (e.g., ISAKMP)
from/to entities behind a security gateway. This means that ISAKMP
traffic must be explicitly accounted for in the SPD, else it will be
discarded. Note that a security gateway could prohibit traversal of
encrypted packets in various ways, e.g., having a DISCARD entry in
the SPD for ESP packets or providing proxy key exchange. In the
latter case, the traffic would be internally routed to the key
management module in the security gateway.
4.4.2
Selectors
An SA (or SA bundle) may be fine-grained or coarse-grained, depending
on the selectors used to define the set of traffic for the SA. For
example, all traffic between two hosts may be carried via a single
SA, and afforded a uniform set of security services. Alternatively,
traffic between a pair of hosts might be spread over multiple SAs,
depending on the applications being used (as defined by the Next
Protocol and Port fields), with different security services offered
by different SAs. Similarly, all traffic between a pair of security
gateways could be carried on a single SA, or one SA could be assigned
for each communicating host pair. The following selector parameters
MUST be supported for SA management to facilitate control of SA
granularity. Note that in the case of receipt of a packet with an
ESP header, e.g., at an encapsulating security gateway or BITW
Kent & Atkinson
Standards Track
[Page 17]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
implementation, the transport layer protocol, source/destination
ports, and Name (if present) may be "OPAQUE", i.e., inaccessible
because of encryption or fragmentation. Note also that both Source
and Destination addresses should either be IPv4 or IPv6.
- Destination IP Address (IPv4 or IPv6): this may be a single IP
address (unicast, anycast, broadcast (IPv4 only), or multicast
group), a range of addresses (high and low values (inclusive),
address + mask, or a wildcard address. The last three are used
to support more than one destination system sharing the same SA
(e.g., behind a security gateway). Note that this selector is
conceptually different from the "Destination IP Address" field
in the <Destination IP Address, IPsec Protocol, SPI> tuple used
to uniquely identify an SA. When a tunneled packet arrives at
the tunnel endpoint, its SPI/Destination address/Protocol are
used to look up the SA for this packet in the SAD. This
destination address comes from the encapsulating IP header.
Once the packet has been processed according to the tunnel SA
and has come out of the tunnel, its selectors are "looked up" in
the Inbound SPD. The Inbound SPD has a selector called
destination address. This IP destination address is the one in
the inner (encapsulated) IP header. In the case of a
transport’d packet, there will be only one IP header and this
ambiguity does not exist. [REQUIRED for all implementations]
- Source IP Address(es) (IPv4 or IPv6): this may be a single IP
address (unicast, anycast, broadcast (IPv4 only), or multicast
group), range of addresses (high and low values inclusive),
address + mask, or a wildcard address. The last three are used
to support more than one source system sharing the same SA
(e.g., behind a security gateway or in a multihomed host).
[REQUIRED for all implementations]
- Name: There are 2 cases (Note that these name forms are
supported in the IPsec DOI.)
1. User ID
a. a fully qualified user name string (DNS), e.g.,
mozart@foo.bar.com
b. X.500 distinguished name, e.g., C = US, SP = MA,
O = GTE Internetworking, CN = Stephen T. Kent.
2. System name (host, security gateway, etc.)
a. a fully qualified DNS name, e.g., foo.bar.com
b. X.500 distinguished name
c. X.500 general name
NOTE: One of the possible values of this selector is "OPAQUE".
Kent & Atkinson
Standards Track
[Page 18]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
[REQUIRED for the following cases. Note that support for name
forms other than addresses is not required for manually keyed
SAs.
o User ID
- native host implementations
- BITW and BITS implementations acting as HOSTS
with only one user
- security gateway implementations for INBOUND
processing.
o System names -- all implementations]
- Data sensitivity level: (IPSO/CIPSO labels)
[REQUIRED for all systems providing information flow security as
per Section 8, OPTIONAL for all other systems.]
- Transport Layer Protocol: Obtained from the IPv4 "Protocol" or
the IPv6 "Next Header" fields. This may be an individual
protocol number. These packet fields may not contain the
Transport Protocol due to the presence of IP extension headers,
e.g., a Routing Header, AH, ESP, Fragmentation Header,
Destination Options, Hop-by-hop options, etc. Note that the
Transport Protocol may not be available in the case of receipt
of a packet with an ESP header, thus a value of "OPAQUE" SHOULD
be supported.
[REQUIRED for all implementations]
NOTE: To locate the transport protocol, a system has to chain
through the packet headers checking the "Protocol" or "Next
Header" field until it encounters either one it recognizes as a
transport protocol, or until it reaches one that isn’t on its
list of extension headers, or until it encounters an ESP header
that renders the transport protocol opaque.
- Source and Destination (e.g., TCP/UDP) Ports: These may be
individual UDP or TCP port values or a wildcard port. (The use
of the Next Protocol field and the Source and/or Destination
Port fields (in conjunction with the Source and/or Destination
Address fields), as an SA selector is sometimes referred to as
"session-oriented keying."). Note that the source and
destination ports may not be available in the case of receipt of
a packet with an ESP header, thus a value of "OPAQUE" SHOULD be
supported.
The following table summarizes the relationship between the
"Next Header" value in the packet and SPD and the derived Port
Selector value for the SPD and SAD.
Kent & Atkinson
Standards Track
[Page 19]
APPENDIX AD
RFC 2401
Security Architecture for IP
Next Hdr
in Packet
-------ESP
-don’t carespecific value
fragment
specific value
not fragment
November 1998
Transport Layer
Protocol in SPD
--------------ESP or ANY
ANY
specific value
Derived Port Selector Field
Value in SPD and SAD
--------------------------ANY (i.e., don’t look at it)
ANY (i.e., don’t look at it)
NOT ANY (i.e., drop packet)
specific value
actual port selector field
If the packet has been fragmented, then the port information may
not be available in the current fragment. If so, discard the
fragment. An ICMP PMTU should be sent for the first fragment,
which will have the port information. [MAY be supported]
The IPsec implementation context determines how selectors are used.
For example, a host implementation integrated into the stack may make
use of a socket interface. When a new connection is established the
SPD can be consulted and an SA (or SA bundle) bound to the socket.
Thus traffic sent via that socket need not result in additional
lookups to the SPD/SAD. In contrast, a BITS, BITW, or security
gateway implementation needs to look at each packet and perform an
SPD/SAD lookup based on the selectors. The allowable values for the
selector fields differ between the traffic flow, the security
association, and the security policy.
The following table summarizes the kinds of entries that one needs to
be able to express in the SPD and SAD. It shows how they relate to
the fields in data traffic being subjected to IPsec screening.
(Note: the "wild" or "wildcard" entry for src and dst addresses
includes a mask, range, etc.)
Field
-------src addr
dst addr
xpt protocol*
src port*
dst port*
user id*
sec. labels
Traffic Value
------------single IP addr
single IP addr
xpt protocol
single src port
single dst port
single user id
single value
SAD Entry
---------------single,range,wild
single,range,wild
single,wildcard
single,wildcard
single,wildcard
single,wildcard
single,wildcard
SPD Entry
-------------------single,range,wildcard
single,range,wildcard
single,wildcard
single,wildcard
single,wildcard
single,wildcard
single,wildcard
* The SAD and SPD entries for these fields could be "OPAQUE"
because the traffic value is encrypted.
NOTE: In principle, one could have selectors and/or selector values
in the SPD which cannot be negotiated for an SA or SA bundle.
Examples might include selector values used to select traffic for
Kent & Atkinson
Standards Track
[Page 20]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
discarding or enumerated lists which cause a separate SA to be
created for each item on the list. For now, this is left for future
versions of this document and the list of required selectors and
selector values is the same for the SPD and the SAD. However, it is
acceptable to have an administrative interface that supports use of
selector values which cannot be negotiated provided that it does not
mislead the user into believing it is creating an SA with these
selector values. For example, the interface may allow the user to
specify an enumerated list of values but would result in the creation
of a separate policy and SA for each item on the list. A vendor
might support such an interface to make it easier for its customers
to specify clear and concise policy specifications.
4.4.3 Security Association Database (SAD)
In each IPsec implementation there is a nominal Security Association
Database, in which each entry defines the parameters associated with
one SA. Each SA has an entry in the SAD. For outbound processing,
entries are pointed to by entries in the SPD. Note that if an SPD
entry does not currently point to an SA that is appropriate for the
packet, the implementation creates an appropriate SA (or SA Bundle)
and links the SPD entry to the SAD entry (see Section 5.1.1). For
inbound processing, each entry in the SAD is indexed by a destination
IP address, IPsec protocol type, and SPI. The following parameters
are associated with each entry in the SAD. This description does not
purport to be a MIB, but only a specification of the minimal data
items required to support an SA in an IPsec implementation.
For inbound processing: The following packet fields are used to look
up the SA in the SAD:
o Outer Header’s Destination IP address: the IPv4 or IPv6
Destination address.
[REQUIRED for all implementations]
o IPsec Protocol: AH or ESP, used as an index for SA lookup
in this database. Specifies the IPsec protocol to be
applied to the traffic on this SA.
[REQUIRED for all implementations]
o SPI: the 32-bit value used to distinguish among different
SAs terminating at the same destination and using the same
IPsec protocol.
[REQUIRED for all implementations]
For each of the selectors defined in Section 4.4.2, the SA entry in
the SAD MUST contain the value or values which were negotiated at the
time the SA was created. For the sender, these values are used to
decide whether a given SA is appropriate for use with an outbound
packet. This is part of checking to see if there is an existing SA
Kent & Atkinson
Standards Track
[Page 21]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
that can be used. For the receiver, these values are used to check
that the selector values in an inbound packet match those for the SA
(and thus indirectly those for the matching policy). For the
receiver, this is part of verifying that the SA was appropriate for
this packet. (See Section 6 for rules for ICMP messages.) These
fields can have the form of specific values, ranges, wildcards, or
"OPAQUE" as described in section 4.4.2, "Selectors". Note that for
an ESP SA, the encryption algorithm or the authentication algorithm
could be "NULL". However they MUST not both be "NULL".
The following SAD fields are used in doing IPsec processing:
o Sequence Number Counter: a 32-bit value used to generate the
Sequence Number field in AH or ESP headers.
[REQUIRED for all implementations, but used only for outbound
traffic.]
o Sequence Counter Overflow: a flag indicating whether overflow
of the Sequence Number Counter should generate an auditable
event and prevent transmission of additional packets on the
SA.
[REQUIRED for all implementations, but used only for outbound
traffic.]
o Anti-Replay Window: a 32-bit counter and a bit-map (or
equivalent) used to determine whether an inbound AH or ESP
packet is a replay.
[REQUIRED for all implementations but used only for inbound
traffic. NOTE: If anti-replay has been disabled by the
receiver, e.g., in the case of a manually keyed SA, then the
Anti-Replay Window is not used.]
o AH Authentication algorithm, keys, etc.
[REQUIRED for AH implementations]
o ESP Encryption algorithm, keys, IV mode, IV, etc.
[REQUIRED for ESP implementations]
o ESP authentication algorithm, keys, etc. If the
authentication service is not selected, this field will be
null.
[REQUIRED for ESP implementations]
o Lifetime of this Security Association: a time interval after
which an SA must be replaced with a new SA (and new SPI) or
terminated, plus an indication of which of these actions
should occur. This may be expressed as a time or byte count,
or a simultaneous use of both, the first lifetime to expire
taking precedence. A compliant implementation MUST support
both types of lifetimes, and must support a simultaneous use
of both. If time is employed, and if IKE employs X.509
certificates for SA establishment, the SA lifetime must be
constrained by the validity intervals of the certificates,
and the NextIssueDate of the CRLs used in the IKE exchange
Kent & Atkinson
Standards Track
[Page 22]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
for the SA. Both initiator and responder are responsible for
constraining SA lifetime in this fashion.
[REQUIRED for all implementations]
NOTE: The details of how to handle the refreshing of keys
when SAs expire is a local matter. However, one reasonable
approach is:
(a) If byte count is used, then the implementation
SHOULD count the number of bytes to which the IPsec
algorithm is applied. For ESP, this is the encryption
algorithm (including Null encryption) and for AH,
this is the authentication algorithm. This includes
pad bytes, etc. Note that implementations SHOULD be
able to handle having the counters at the ends of an
SA get out of synch, e.g., because of packet loss or
because the implementations at each end of the SA
aren’t doing things the same way.
(b) There SHOULD be two kinds of lifetime -- a soft
lifetime which warns the implementation to initiate
action such as setting up a replacement SA and a
hard lifetime when the current SA ends.
(c) If the entire packet does not get delivered during
the SAs lifetime, the packet SHOULD be discarded.
o IPsec protocol mode: tunnel, transport or wildcard.
Indicates which mode of AH or ESP is applied to traffic on
this SA. Note that if this field is "wildcard" at the
sending end of the SA, then the application has to specify
the mode to the IPsec implementation. This use of wildcard
allows the same SA to be used for either tunnel or transport
mode traffic on a per packet basis, e.g., by different
sockets. The receiver does not need to know the mode in
order to properly process the packet’s IPsec headers.
[REQUIRED as follows, unless implicitly defined by context:
- host implementations must support all modes
- gateway implementations must support tunnel mode]
NOTE: The use of wildcard for the protocol mode of an inbound
SA may add complexity to the situation in the receiver (host
only). Since the packets on such an SA could be delivered in
either tunnel or transport mode, the security of an incoming
packet could depend in part on which mode had been used to
deliver it. If, as a result, an application cared about the
SA mode of a given packet, then the application would need a
mechanism to obtain this mode information.
Kent & Atkinson
Standards Track
[Page 23]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
o Path MTU: any observed path MTU and aging variables. See
Section 6.1.2.4
[REQUIRED for all implementations but used only for outbound
traffic]
4.5 Basic Combinations of Security Associations
This section describes four examples of combinations of security
associations that MUST be supported by compliant IPsec hosts or
security gateways. Additional combinations of AH and/or ESP in
tunnel and/or transport modes MAY be supported at the discretion of
the implementor. Compliant implementations MUST be capable of
generating these four combinations and on receipt, of processing
them, but SHOULD be able to receive and process any combination. The
diagrams and text below describe the basic cases. The legend for the
diagrams is:
==== = one or more security associations (AH or ESP, transport
or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
Hx
= host x
SGx = security gateway x
X*
= X supports IPsec
NOTE: The security associations below can be either AH or ESP. The
mode (tunnel vs transport) is determined by the nature of the
endpoints. For host-to-host SAs, the mode can be either transport or
tunnel.
Case 1. The case of providing end-to-end security between 2 hosts
across the Internet (or an Intranet).
====================================
|
|
H1* ------ (Inter/Intranet) ------ H2*
Note that either transport or tunnel mode can be selected by the
hosts. So the headers in a packet between H1 and H2 could look
like any of the following:
Transport
----------------1. [IP1][AH][upper]
2. [IP1][ESP][upper]
3. [IP1][AH][ESP][upper]
Kent & Atkinson
Tunnel
--------------------4. [IP2][AH][IP1][upper]
5. [IP2][ESP][IP1][upper]
Standards Track
[Page 24]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
Note that there is no requirement to support general nesting,
but in transport mode, both AH and ESP can be applied to the
packet. In this event, the SA establishment procedure MUST
ensure that first ESP, then AH are applied to the packet.
Case 2. This case illustrates simple virtual private networks
support.
===========================
|
|
---------------------|------|----------------------|
|
|
| |
|
| H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 |
|
Intranet)
|
|
Intranet)
|
---------------------------------------------------admin. boundary
admin. boundary
Only tunnel mode is required here. So the headers in a packet
between SG1 and SG2 could look like either of the following:
Tunnel
--------------------4. [IP2][AH][IP1][upper]
5. [IP2][ESP][IP1][upper]
Case 3. This case combines cases 1 and 2, adding end-to-end security
between the sending and receiving hosts. It imposes no new
requirements on the hosts or security gateways, other than a
requirement for a security gateway to be configurable to pass
IPsec traffic (including ISAKMP traffic) for hosts behind it.
===============================================================
|
|
|
=========================
|
|
|
|
|
---|-----------------|------|-------------------|--| |
|
|
| |
| |
| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
|
Intranet)
|
|
Intranet)
|
---------------------------------------------------admin. boundary
admin. boundary
Case 4. This covers the situation where a remote host (H1) uses the
Internet to reach an organization’s firewall (SG2) and to then
gain access to some server or other machine (H2). The remote
host could be a mobile host (H1) dialing up to a local PPP/ARA
server (not shown) on the Internet and then crossing the
Internet to the home organization’s firewall (SG2), etc. The
Kent & Atkinson
Standards Track
[Page 25]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
details of support for this case, (how H1 locates SG2,
authenticates it, and verifies its authorization to represent
H2) are discussed in Section 4.6.3, "Locating a Security
Gateway".
======================================================
|
|
|==============================
|
||
|
|
||
---|----------------------|--||
| |
| |
H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
^
|
Intranet)
|
|
-----------------------------could be dialup
admin. boundary (optional)
to PPP/ARA server
Only tunnel mode is required between H1 and SG2. So the choices
for the SA between H1 and SG2 would be one of the ones in case
2. The choices for the SA between H1 and H2 would be one of the
ones in case 1.
Note that in this case, the sender MUST apply the transport
header before the tunnel header. Therefore the management
interface to the IPsec implementation MUST support configuration
of the SPD and SAD to ensure this ordering of IPsec header
application.
As noted above, support for additional combinations of AH and ESP is
optional. Use of other, optional combinations may adversely affect
interoperability.
4.6 SA and Key Management
IPsec mandates support for both manual and automated SA and
cryptographic key management. The IPsec protocols, AH and ESP, are
largely independent of the associated SA management techniques,
although the techniques involved do affect some of the security
services offered by the protocols. For example, the optional antireplay services available for AH and ESP require automated SA
management. Moreover, the granularity of key distribution employed
with IPsec determines the granularity of authentication provided.
(See also a discussion of this issue in Section 4.7.) In general,
data origin authentication in AH and ESP is limited by the extent to
which secrets used with the authentication algorithm (or with a key
management protocol that creates such secrets) are shared among
multiple possible sources.
Kent & Atkinson
Standards Track
[Page 26]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
The following text describes the minimum requirements for both types
of SA management.
4.6.1 Manual Techniques
The simplest form of management is manual management, in which a
person manually configures each system with keying material and
security association management data relevant to secure communication
with other systems. Manual techniques are practical in small, static
environments but they do not scale well. For example, a company
could create a Virtual Private Network (VPN) using IPsec in security
gateways at several sites. If the number of sites is small, and
since all the sites come under the purview of a single administrative
domain, this is likely to be a feasible context for manual management
techniques. In this case, the security gateway might selectively
protect traffic to and from other sites within the organization using
a manually configured key, while not protecting traffic for other
destinations. It also might be appropriate when only selected
communications need to be secured. A similar argument might apply to
use of IPsec entirely within an organization for a small number of
hosts and/or gateways. Manual management techniques often employ
statically configured, symmetric keys, though other options also
exist.
4.6.2 Automated SA and Key Management
Widespread deployment and use of IPsec requires an Internet-standard,
scalable, automated, SA management protocol. Such support is
required to facilitate use of the anti-replay features of AH and ESP,
and to accommodate on-demand creation of SAs, e.g., for user- and
session-oriented keying. (Note that the notion of "rekeying" an SA
actually implies creation of a new SA with a new SPI, a process that
generally implies use of an automated SA/key management protocol.)
The default automated key management protocol selected for use with
IPsec is IKE [MSST97, Orm97, HC98] under the IPsec domain of
interpretation [Pip98]. Other automated SA management protocols MAY
be employed.
When an automated SA/key management protocol is employed, the output
from this protocol may be used to generate multiple keys, e.g., for a
single ESP SA. This may arise because:
o the encryption algorithm uses multiple keys (e.g., triple DES)
o the authentication algorithm uses multiple keys
o both encryption and authentication algorithms are employed
Kent & Atkinson
Standards Track
[Page 27]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
The Key Management System may provide a separate string of bits for
each key or it may generate one string of bits from which all of them
are extracted. If a single string of bits is provided, care needs to
be taken to ensure that the parts of the system that map the string
of bits to the required keys do so in the same fashion at both ends
of the SA. To ensure that the IPsec implementations at each end of
the SA use the same bits for the same keys, and irrespective of which
part of the system divides the string of bits into individual keys,
the encryption key(s) MUST be taken from the first (left-most, highorder) bits and the authentication key(s) MUST be taken from the
remaining bits. The number of bits for each key is defined in the
relevant algorithm specification RFC. In the case of multiple
encryption keys or multiple authentication keys, the specification
for the algorithm must specify the order in which they are to be
selected from a single string of bits provided to the algorithm.
4.6.3 Locating a Security Gateway
This section discusses issues relating to how a host learns about the
existence of relevant security gateways and once a host has contacted
these security gateways, how it knows that these are the correct
security gateways. The details of where the required information is
stored is a local matter.
Consider a situation in which a remote host (H1) is using the
Internet to gain access to a server or other machine (H2) and there
is a security gateway (SG2), e.g., a firewall, through which H1’s
traffic must pass. An example of this situation would be a mobile
host (Road Warrior) crossing the Internet to the home organization’s
firewall (SG2). (See Case 4 in the section 4.5 Basic Combinations of
Security Associations.) This situation raises several issues:
1. How does H1 know/learn about the existence of the security
gateway SG2?
2. How does it authenticate SG2, and once it has authenticated
SG2, how does it confirm that SG2 has been authorized to
represent H2?
3. How does SG2 authenticate H1 and verify that H1 is authorized
to contact H2?
4. How does H1 know/learn about backup gateways which provide
alternate paths to H2?
To address these problems, a host or security gateway MUST have an
administrative interface that allows the user/administrator to
configure the address of a security gateway for any sets of
destination addresses that require its use. This includes the ability
to configure:
Kent & Atkinson
Standards Track
[Page 28]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
o the requisite information for locating and authenticating the
security gateway and verifying its authorization to represent
the destination host.
o the requisite information for locating and authenticating any
backup gateways and verifying their authorization to represent
the destination host.
It is assumed that the SPD is also configured with policy information
that covers any other IPsec requirements for the path to the security
gateway and the destination host.
This document does not address the issue of how to automate the
discovery/verification of security gateways.
4.7 Security Associations and Multicast
The receiver-orientation of the Security Association implies that, in
the case of unicast traffic, the destination system will normally
select the SPI value. By having the destination select the SPI
value, there is no potential for manually configured Security
Associations to conflict with automatically configured (e.g., via a
key management protocol) Security Associations or for Security
Associations from multiple sources to conflict with each other. For
multicast traffic, there are multiple destination systems per
multicast group. So some system or person will need to coordinate
among all multicast groups to select an SPI or SPIs on behalf of each
multicast group and then communicate the group’s IPsec information to
all of the legitimate members of that multicast group via mechanisms
not defined here.
Multiple senders to a multicast group SHOULD use a single Security
Association (and hence Security Parameter Index) for all traffic to
that group when a symmetric key encryption or authentication
algorithm is employed. In such circumstances, the receiver knows only
that the message came from a system possessing the key for that
multicast group. In such circumstances, a receiver generally will
not be able to authenticate which system sent the multicast traffic.
Specifications for other, more general multicast cases are deferred
to later IPsec documents.
At the time this specification was published, automated protocols for
multicast key distribution were not considered adequately mature for
standardization. For multicast groups having relatively few members,
manual key distribution or multiple use of existing unicast key
distribution algorithms such as modified Diffie-Hellman appears
feasible. For very large groups, new scalable techniques will be
needed. An example of current work in this area is the Group Key
Management Protocol (GKMP) [HM97].
Kent & Atkinson
Standards Track
[Page 29]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
5. IP Traffic Processing
As mentioned in Section 4.4.1 "The Security Policy Database (SPD)",
the SPD must be consulted during the processing of all traffic
(INBOUND and OUTBOUND), including non-IPsec traffic. If no policy is
found in the SPD that matches the packet (for either inbound or
outbound traffic), the packet MUST be discarded.
NOTE: All of the cryptographic algorithms used in IPsec expect their
input in canonical network byte order (see Appendix in RFC 791) and
generate their output in canonical network byte order. IP packets
are also transmitted in network byte order.
5.1 Outbound IP Traffic Processing
5.1.1 Selecting and Using an SA or SA Bundle
In a security gateway or BITW implementation (and in many BITS
implementations), each outbound packet is compared against the SPD to
determine what processing is required for the packet. If the packet
is to be discarded, this is an auditable event. If the traffic is
allowed to bypass IPsec processing, the packet continues through
"normal" processing for the environment in which the IPsec processing
is taking place. If IPsec processing is required, the packet is
either mapped to an existing SA (or SA bundle), or a new SA (or SA
bundle) is created for the packet. Since a packet’s selectors might
match multiple policies or multiple extant SAs and since the SPD is
ordered, but the SAD is not, IPsec MUST:
1. Match the packet’s selector fields against the outbound
policies in the SPD to locate the first appropriate
policy, which will point to zero or more SA bundles in the
SAD.
2. Match the packet’s selector fields against those in the SA
bundles found in (1) to locate the first SA bundle that
matches. If no SAs were found or none match, create an
appropriate SA bundle and link the SPD entry to the SAD
entry. If no key management entity is found, drop the
packet.
3. Use the SA bundle found/created in (2) to do the required
IPsec processing, e.g., authenticate and encrypt.
In a host IPsec implementation based on sockets, the SPD will be
consulted whenever a new socket is created, to determine what, if
any, IPsec processing will be applied to the traffic that will flow
on that socket.
Kent & Atkinson
Standards Track
[Page 30]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
NOTE: A compliant implementation MUST not allow instantiation of an
ESP SA that employs both a NULL encryption and a NULL authentication
algorithm. An attempt to negotiate such an SA is an auditable event.
5.1.2 Header Construction for Tunnel Mode
This section describes the handling of the inner and outer IP
headers, extension headers, and options for AH and ESP tunnels. This
includes how to construct the encapsulating (outer) IP header, how to
handle fields in the inner IP header, and what other actions should
be taken. The general idea is modeled after the one used in RFC
2003, "IP Encapsulation with IP":
o The outer IP header Source Address and Destination Address
identify the "endpoints" of the tunnel (the encapsulator and
decapsulator). The inner IP header Source Address and
Destination Addresses identify the original sender and
recipient of the datagram, (from the perspective of this
tunnel), respectively. (see footnote 3 after the table in
5.1.2.1 for more details on the encapsulating source IP
address.)
o The inner IP header is not changed except to decrement the TTL
as noted below, and remains unchanged during its delivery to
the tunnel exit point.
o No change to IP options or extension headers in the inner
header occurs during delivery of the encapsulated datagram
through the tunnel.
o If need be, other protocol headers such as the IP
Authentication header may be inserted between the outer IP
header and the inner IP header.
The tables in the following sub-sections show the handling for the
different header/option fields (constructed = the value in the outer
field is constructed independently of the value in the inner).
5.1.2.1 IPv4 -- Header Construction for Tunnel Mode
IPv4
Header fields:
version
header length
TOS
total length
ID
flags (DF,MF)
fragmt offset
Kent & Atkinson
<-- How Outer Hdr Relates to Inner Hdr -->
Outer Hdr at
Inner Hdr at
Encapsulator
Decapsulator
------------------------------4 (1)
no change
constructed
no change
copied from inner hdr (5)
no change
constructed
no change
constructed
no change
constructed, DF (4)
no change
constructed
no change
Standards Track
[Page 31]
APPENDIX AD
RFC 2401
Security Architecture for IP
TTL
protocol
checksum
src address
dest address
Options
constructed (2)
AH, ESP, routing hdr
constructed
constructed (3)
constructed (3)
never copied
November 1998
decrement (2)
no change
constructed (2)
no change
no change
no change
1. The IP version in the encapsulating header can be different
from the value in the inner header.
2. The TTL in the inner header is decremented by the
encapsulator prior to forwarding and by the decapsulator if
it forwards the packet. (The checksum changes when the TTL
changes.)
Note: The decrementing of the TTL is one of the usual actions
that takes place when forwarding a packet. Packets
originating from the same node as the encapsulator do not
have their TTL’s decremented, as the sending node is
originating the packet rather than forwarding it.
3. src and dest addresses depend on the SA, which is used to
determine the dest address which in turn determines which src
address (net interface) is used to forward the packet.
NOTE: In principle, the encapsulating IP source address can
be any of the encapsulator’s interface addresses or even an
address different from any of the encapsulator’s IP
addresses, (e.g., if it’s acting as a NAT box) so long as the
address is reachable through the encapsulator from the
environment into which the packet is sent. This does not
cause a problem because IPsec does not currently have any
INBOUND processing requirement that involves the Source
Address of the encapsulating IP header. So while the
receiving tunnel endpoint looks at the Destination Address in
the encapsulating IP header, it only looks at the Source
Address in the inner (encapsulated) IP header.
4. configuration determines whether to copy from the inner
header (IPv4 only), clear or set the DF.
5. If Inner Hdr is IPv4 (Protocol = 4), copy the TOS.
Hdr is IPv6 (Protocol = 41), map the Class to TOS.
If Inner
5.1.2.2 IPv6 -- Header Construction for Tunnel Mode
See previous section 5.1.2 for notes 1-5 indicated by (footnote
number).
Kent & Atkinson
Standards Track
[Page 32]
APPENDIX AD
RFC 2401
Security Architecture for IP
IPv6
Header fields:
version
class
flow id
len
next header
hop limit
src address
dest address
Extension headers
November 1998
<-- How Outer Hdr Relates Inner Hdr --->
Outer Hdr at
Inner Hdr at
Encapsulator
Decapsulator
------------------------------6 (1)
no change
copied or configured (6)
no change
copied or configured
no change
constructed
no change
AH,ESP,routing hdr
no change
constructed (2)
decrement (2)
constructed (3)
no change
constructed (3)
no change
never copied
no change
6. If Inner Hdr is IPv6 (Next Header = 41), copy the Class. If
Inner Hdr is IPv4 (Next Header = 4), map the TOS to Class.
5.2 Processing Inbound IP Traffic
Prior to performing AH or ESP processing, any IP fragments are
reassembled. Each inbound IP datagram to which IPsec processing will
be applied is identified by the appearance of the AH or ESP values in
the IP Next Protocol field (or of AH or ESP as an extension header in
the IPv6 context).
Note: Appendix C contains sample code for a bitmask check for a 32
packet window that can be used for implementing anti-replay service.
5.2.1 Selecting and Using an SA or SA Bundle
Mapping the IP datagram to the appropriate SA is simplified because
of the presence of the SPI in the AH or ESP header. Note that the
selector checks are made on the inner headers not the outer (tunnel)
headers. The steps followed are:
1. Use the packet’s destination address (outer IP header),
IPsec protocol, and SPI to look up the SA in the SAD. If
the SA lookup fails, drop the packet and log/report the
error.
2. Use the SA found in (1) to do the IPsec processing, e.g.,
authenticate and decrypt. This step includes matching the
packet’s (Inner Header if tunneled) selectors to the
selectors in the SA. Local policy determines the
specificity of the SA selectors (single value, list,
range, wildcard). In general, a packet’s source address
MUST match the SA selector value. However, an ICMP packet
received on a tunnel mode SA may have a source address
Kent & Atkinson
Standards Track
[Page 33]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
other than that bound to the SA and thus such packets
should be permitted as exceptions to this check. For an
ICMP packet, the selectors from the enclosed problem
packet (the source and destination addresses and ports
should be swapped) should be checked against the selectors
for the SA. Note that some or all of these selectors may
be inaccessible because of limitations on how many bits of
the problem packet the ICMP packet is allowed to carry or
due to encryption. See Section 6.
Do (1) and (2) for every IPsec header until a Transport
Protocol Header or an IP header that is NOT for this
system is encountered. Keep track of what SAs have been
used and their order of application.
3. Find an incoming policy in the SPD that matches the
packet. This could be done, for example, by use of
backpointers from the SAs to the SPD or by matching the
packet’s selectors (Inner Header if tunneled) against
those of the policy entries in the SPD.
4. Check whether the required IPsec processing has been
applied, i.e., verify that the SA’s found in (1) and (2)
match the kind and order of SAs required by the policy
found in (3).
NOTE: The correct "matching" policy will not necessarily
be the first inbound policy found. If the check in (4)
fails, steps (3) and (4) are repeated until all policy
entries have been checked or until the check succeeds.
At the end of these steps, pass the resulting packet to the Transport
Layer or forward the packet. Note that any IPsec headers processed
in these steps may have been removed, but that this information,
i.e., what SAs were used and the order of their application, may be
needed for subsequent IPsec or firewall processing.
Note that in the case of a security gateway, if forwarding causes a
packet to exit via an IPsec-enabled interface, then additional IPsec
processing may be applied.
5.2.2 Handling of AH and ESP tunnels
The handling of the inner and outer IP headers, extension headers,
and options for AH and ESP tunnels should be performed as described
in the tables in Section 5.1.
Kent & Atkinson
Standards Track
[Page 34]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
6. ICMP Processing (relevant to IPsec)
The focus of this section is on the handling of ICMP error messages.
Other ICMP traffic, e.g., Echo/Reply, should be treated like other
traffic and can be protected on an end-to-end basis using SAs in the
usual fashion.
An ICMP error message protected by AH or ESP and generated by a
router SHOULD be processed and forwarded in a tunnel mode SA. Local
policy determines whether or not it is subjected to source address
checks by the router at the destination end of the tunnel. Note that
if the router at the originating end of the tunnel is forwarding an
ICMP error message from another router, the source address check
would fail. An ICMP message protected by AH or ESP and generated by
a router MUST NOT be forwarded on a transport mode SA (unless the SA
has been established to the router acting as a host, e.g., a Telnet
connection used to manage a router). An ICMP message generated by a
host SHOULD be checked against the source IP address selectors bound
to the SA in which the message arrives. Note that even if the source
of an ICMP error message is authenticated, the returned IP header
could be invalid. Accordingly, the selector values in the IP header
SHOULD also be checked to be sure that they are consistent with the
selectors for the SA over which the ICMP message was received.
The table in Appendix D characterize ICMP messages as being either
host generated, router generated, both, unknown/unassigned. ICMP
messages falling into the last two categories should be handled as
determined by the receiver’s policy.
An ICMP message not protected by AH or ESP is unauthenticated and its
processing and/or forwarding may result in denial of service. This
suggests that, in general, it would be desirable to ignore such
messages. However, it is expected that many routers (vs. security
gateways) will not implement IPsec for transit traffic and thus
strict adherence to this rule would cause many ICMP messages to be
discarded. The result is that some critical IP functions would be
lost, e.g., redirection and PMTU processing. Thus it MUST be
possible to configure an IPsec implementation to accept or reject
(router) ICMP traffic as per local security policy.
The remainder of this section addresses how PMTU processing MUST be
performed at hosts and security gateways. It addresses processing of
both authenticated and unauthenticated ICMP PMTU messages. However,
as noted above, unauthenticated ICMP messages MAY be discarded based
on local policy.
Kent & Atkinson
Standards Track
[Page 35]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
6.1 PMTU/DF Processing
6.1.1 DF Bit
In cases where a system (host or gateway) adds an encapsulating
header (ESP tunnel or AH tunnel), it MUST support the option of
copying the DF bit from the original packet to the encapsulating
header (and processing ICMP PMTU messages). This means that it MUST
be possible to configure the system’s treatment of the DF bit (set,
clear, copy from encapsulated header) for each interface. (See
Appendix B for rationale.)
6.1.2 Path MTU Discovery (PMTU)
This section discusses IPsec handling for Path MTU Discovery
messages. ICMP PMTU is used here to refer to an ICMP message for:
IPv4 (RFC
-
792):
Type = 3 (Destination Unreachable)
Code = 4 (Fragmentation needed and DF set)
Next-Hop MTU in the low-order 16 bits of the second
word of the ICMP header (labelled "unused" in RFC
792), with high-order 16 bits set to zero
IPv6 (RFC
-
1885):
Type = 2 (Packet Too Big)
Code = 0 (Fragmentation needed)
Next-Hop MTU in the 32 bit MTU field of the ICMP6
message
6.1.2.1 Propagation of PMTU
The amount of information returned with the ICMP PMTU message (IPv4
or IPv6) is limited and this affects what selectors are available for
use in further propagating the PMTU information. (See Appendix B for
more detailed discussion of this topic.)
o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU
message contains only 64 bits of the IPsec header (minimum for
IPv4), then a security gateway MUST support the following options
on a per SPI/SA basis:
a. if the originating host can be determined (or the possible
sources narrowed down to a manageable number), send the PM
information to all the possible originating hosts.
b. if the originating host cannot be determined, store the PMTU
with the SA and wait until the next packet(s) arrive from the
originating host for the relevant security association. If
Kent & Atkinson
Standards Track
[Page 36]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
the packet(s) are bigger than the PMTU, drop the packet(s),
and compose ICMP PMTU message(s) with the new packet(s) and
the updated PMTU, and send the ICMP message(s) about the
problem to the originating host. Retain the PMTU information
for any message that might arrive subsequently (see Section
6.1.2.4, "PMTU Aging").
o PMTU message with >64 bits of IPsec header -- If the ICMP message
contains more information from the original packet then there may
be enough non-opaque information to immediately determine to which
host to propagate the ICMP/PMTU message and to provide that system
with the 5 fields (source address, destination address, source
port, destination port, transport protocol) needed to determine
where to store/update the PMTU. Under such circumstances, a
security gateway MUST generate an ICMP PMTU message immediately
upon receipt of an ICMP PMTU from further down the path.
o Distributing the PMTU to the Transport Layer -- The host mechanism
for getting the updated PMTU to the transport layer is unchanged,
as specified in RFC 1191 (Path MTU Discovery).
6.1.2.2 Calculation of PMTU
The calculation of PMTU from an ICMP PMTU MUST take into account the
addition of any IPsec header -- AH transport, ESP transport, AH/ESP
transport, ESP tunnel, AH tunnel. (See Appendix B for discussion of
implementation issues.)
Note: In some situations the addition of IPsec headers could result
in an effective PMTU (as seen by the host or application) that is
unacceptably small. To avoid this problem, the implementation may
establish a threshold below which it will not report a reduced PMTU.
In such cases, the implementation would apply IPsec and then fragment
the resulting packet according to the PMTU. This would result in a
more efficient use of the available bandwidth.
6.1.2.3 Granularity of PMTU Processing
In hosts, the granularity with which ICMP PMTU processing can be done
differs depending on the implementation situation. Looking at a
host, there are 3 situations that are of interest with respect to
PMTU issues (See Appendix B for additional details on this topic.):
a. Integration of IPsec into the native IP implementation
b. Bump-in-the-stack implementations, where IPsec is implemented
"underneath" an existing implementation of a TCP/IP protocol
stack, between the native IP and the local network drivers
Kent & Atkinson
Standards Track
[Page 37]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
c. No IPsec implementation -- This case is included because it
is relevant in cases where a security gateway is sending PMTU
information back to a host.
Only in case (a) can the PMTU data be maintained at the same
granularity as communication associations. In (b) and (c), the IP
layer will only be able to maintain PMTU data at the granularity of
source and destination IP addresses (and optionally TOS), as
described in RFC 1191. This is an important difference, because more
than one communication association may map to the same source and
destination IP addresses, and each communication association may have
a different amount of IPsec header overhead (e.g., due to use of
different transforms or different algorithms).
Implementation of the calculation of PMTU and support for PMTUs at
the granularity of individual communication associations is a local
matter. However, a socket-based implementation of IPsec in a host
SHOULD maintain the information on a per socket basis. Bump in the
stack systems MUST pass an ICMP PMTU to the host IP implementation,
after adjusting it for any IPsec header overhead added by these
systems. The calculation of the overhead SHOULD be determined by
analysis of the SPI and any other selector information present in a
returned ICMP PMTU message.
6.1.2.4 PMTU Aging
In all systems (host or gateway) implementing IPsec and maintaining
PMTU information, the PMTU associated with a security association
(transport or tunnel) MUST be "aged" and some mechanism put in place
for updating the PMTU in a timely manner, especially for discovering
if the PMTU is smaller than it needs to be. A given PMTU has to
remain in place long enough for a packet to get from the source end
of the security association to the system at the other end of the
security association and propagate back an ICMP error message if the
current PMTU is too big. Note that if there are nested tunnels,
multiple packets and round trip times might be required to get an
ICMP message back to an encapsulator or originating host.
Systems SHOULD use the approach described in the Path MTU Discovery
document (RFC 1191, Section 6.3), which suggests periodically
resetting the PMTU to the first-hop data-link MTU and then letting
the normal PMTU Discovery processes update the PMTU as necessary.
The period SHOULD be configurable.
Kent & Atkinson
Standards Track
[Page 38]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
7. Auditing
Not all systems that implement IPsec will implement auditing. For
the most part, the granularity of auditing is a local matter.
However, several auditable events are identified in the AH and ESP
specifications and for each of these events a minimum set of
information that SHOULD be included in an audit log is defined.
Additional information also MAY be included in the audit log for each
of these events, and additional events, not explicitly called out in
this specification, also MAY result in audit log entries. There is
no requirement for the receiver to transmit any message to the
purported transmitter in response to the detection of an auditable
event, because of the potential to induce denial of service via such
action.
8. Use in Systems Supporting Information Flow Security
Information of various sensitivity levels may be carried over a
single network. Information labels (e.g., Unclassified, Company
Proprietary, Secret) [DoD85, DoD87] are often employed to distinguish
such information. The use of labels facilitates segregation of
information, in support of information flow security models, e.g.,
the Bell-LaPadula model [BL73]. Such models, and corresponding
supporting technology, are designed to prevent the unauthorized flow
of sensitive information, even in the face of Trojan Horse attacks.
Conventional, discretionary access control (DAC) mechanisms, e.g.,
based on access control lists, generally are not sufficient to
support such policies, and thus facilities such as the SPD do not
suffice in such environments.
In the military context, technology that supports such models is
often referred to as multi-level security (MLS). Computers and
networks often are designated "multi-level secure" if they support
the separation of labelled data in conjunction with information flow
security policies. Although such technology is more broadly
applicable than just military applications, this document uses the
acronym "MLS" to designate the technology, consistent with much
extant literature.
IPsec mechanisms can easily support MLS networking. MLS networking
requires the use of strong Mandatory Access Controls (MAC), which
unprivileged users or unprivileged processes are incapable of
controlling or violating. This section pertains only to the use of
these IP security mechanisms in MLS (information flow security
policy) environments. Nothing in this section applies to systems not
claiming to provide MLS.
Kent & Atkinson
Standards Track
[Page 39]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
As used in this section, "sensitivity information" might include
implementation-defined hierarchic levels, categories, and/or
releasability information.
AH can be used to provide strong authentication in support of
mandatory access control decisions in MLS environments. If explicit
IP sensitivity information (e.g., IPSO [Ken91]) is used and
confidentiality is not considered necessary within the particular
operational environment, AH can be used to authenticate the binding
between sensitivity labels in the IP header and the IP payload
(including user data). This is a significant improvement over
labeled IPv4 networks where the sensitivity information is trusted
even though there is no authentication or cryptographic binding of
the information to the IP header and user data. IPv4 networks might
or might not use explicit labelling. IPv6 will normally use implicit
sensitivity information that is part of the IPsec Security
Association but not transmitted with each packet instead of using
explicit sensitivity information. All explicit IP sensitivity
information MUST be authenticated using either ESP, AH, or both.
Encryption is useful and can be desirable even when all of the hosts
are within a protected environment, for example, behind a firewall or
disjoint from any external connectivity. ESP can be used, in
conjunction with appropriate key management and encryption
algorithms, in support of both DAC and MAC. (The choice of
encryption and authentication algorithms, and the assurance level of
an IPsec implementation will determine the environments in which an
implementation may be deemed sufficient to satisfy MLS requirements.)
Key management can make use of sensitivity information to provide
MAC. IPsec implementations on systems claiming to provide MLS SHOULD
be capable of using IPsec to provide MAC for IP-based communications.
8.1 Relationship Between Security Associations and Data Sensitivity
Both the Encapsulating Security Payload and the Authentication Header
can be combined with appropriate Security Association policies to
provide multi-level secure networking. In this case each SA (or SA
bundle) is normally used for only a single instance of sensitivity
information. For example, "PROPRIETARY - Internet Engineering" must
be associated with a different SA (or SA bundle) from "PROPRIETARY Finance".
8.2 Sensitivity Consistency Checking
An MLS implementation (both host and router) MAY associate
sensitivity information, or a range of sensitivity information with
an interface, or a configured IP address with its associated prefix
(the latter is sometimes referred to as a logical interface, or an
Kent & Atkinson
Standards Track
[Page 40]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
interface alias). If such properties exist, an implementation SHOULD
compare the sensitivity information associated with the packet
against the sensitivity information associated with the interface or
address/prefix from which the packet arrived, or through which the
packet will depart. This check will either verify that the
sensitivities match, or that the packet’s sensitivity falls within
the range of the interface or address/prefix.
The checking SHOULD be done on both inbound and outbound processing.
8.3 Additional MLS Attributes for Security Association Databases
Section 4.4 discussed two Security Association databases (the
Security Policy Database (SPD) and the Security Association Database
(SAD)) and the associated policy selectors and SA attributes. MLS
networking introduces an additional selector/attribute:
- Sensitivity information.
The Sensitivity information aids in selecting the appropriate
algorithms and key strength, so that the traffic gets a level of
protection appropriate to its importance or sensitivity as described
in section 8.1. The exact syntax of the sensitivity information is
implementation defined.
8.4 Additional Inbound Processing Steps for MLS Networking
After an inbound packet has passed through IPsec processing, an MLS
implementation SHOULD first check the packet’s sensitivity (as
defined by the SA (or SA bundle) used for the packet) with the
interface or address/prefix as described in section 8.2 before
delivering the datagram to an upper-layer protocol or forwarding it.
The MLS system MUST retain the binding between the data received in
an IPsec protected packet and the sensitivity information in the SA
or SAs used for processing, so appropriate policy decisions can be
made when delivering the datagram to an application or forwarding
engine. The means for maintaining this binding are implementation
specific.
8.5 Additional Outbound Processing Steps for MLS Networking
An MLS implementation of IPsec MUST perform two additional checks
besides the normal steps detailed in section 5.1.1. When consulting
the SPD or the SAD to find an outbound security association, the MLS
implementation MUST use the sensitivity of the data to select an
Kent & Atkinson
Standards Track
[Page 41]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
appropriate outbound SA or SA bundle. The second check comes before
forwarding the packet out to its destination, and is the sensitivity
consistency checking described in section 8.2.
8.6 Additional MLS Processing for Security Gateways
An MLS security gateway MUST follow the previously mentioned inbound
and outbound processing rules as well as perform some additional
processing specific to the intermediate protection of packets in an
MLS environment.
A security gateway MAY act as an outbound proxy, creating SAs for MLS
systems that originate packets forwarded by the gateway. These MLS
systems may explicitly label the packets to be forwarded, or the
whole originating network may have sensitivity characteristics
associated with it. The security gateway MUST create and use
appropriate SAs for AH, ESP, or both, to protect such traffic it
forwards.
Similarly such a gateway SHOULD accept and process inbound AH and/or
ESP packets and forward appropriately, using explicit packet
labeling, or relying on the sensitivity characteristics of the
destination network.
9. Performance Issues
The use of IPsec imposes computational performance costs on the hosts
or security gateways that implement these protocols. These costs are
associated with the memory needed for IPsec code and data structures,
and the computation of integrity check values, encryption and
decryption, and added per-packet handling. The per-packet
computational costs will be manifested by increased latency and,
possibly, reduced throughout. Use of SA/key management protocols,
especially ones that employ public key cryptography, also adds
computational performance costs to use of IPsec. These perassociation computational costs will be manifested in terms of
increased latency in association establishment. For many hosts, it
is anticipated that software-based cryptography will not appreciably
reduce throughput, but hardware may be required for security gateways
(since they represent aggregation points), and for some hosts.
The use of IPsec also imposes bandwidth utilization costs on
transmission, switching, and routing components of the Internet
infrastructure, components not implementing IPsec. This is due to
the increase in the packet size resulting from the addition of AH
and/or ESP headers, AH and ESP tunneling (which adds a second IP
header), and the increased packet traffic associated with key
management protocols. It is anticipated that, in most instances,
Kent & Atkinson
Standards Track
[Page 42]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
this increased bandwidth demand will not noticeably affect the
Internet infrastructure. However, in some instances, the effects may
be significant, e.g., transmission of ESP encrypted traffic over a
dialup link that otherwise would have compressed the traffic.
Note: The initial SA establishment overhead will be felt in the first
packet. This delay could impact the transport layer and application.
For example, it could cause TCP to retransmit the SYN before the
ISAKMP exchange is done. The effect of the delay would be different
on UDP than TCP because TCP shouldn’t transmit anything other than
the SYN until the connection is set up whereas UDP will go ahead and
transmit data beyond the first packet.
Note: As discussed earlier, compression can still be employed at
layers above IP. There is an IETF working group (IP Payload
Compression Protocol (ippcp)) working on "protocol specifications
that make it possible to perform lossless compression on individual
payloads before the payload is processed by a protocol that encrypts
it. These specifications will allow for compression operations to be
performed prior to the encryption of a payload by IPsec protocols."
10. Conformance Requirements
All IPv4 systems that claim to implement IPsec MUST comply with all
requirements of the Security Architecture document. All IPv6 systems
MUST comply with all requirements of the Security Architecture
document.
11. Security Considerations
The focus of this document is security; hence security considerations
permeate this specification.
12. Differences from RFC 1825
This architecture document differs substantially from RFC 1825 in
detail and in organization, but the fundamental notions are
unchanged. This document provides considerable additional detail in
terms of compliance specifications. It introduces the SPD and SAD,
and the notion of SA selectors. It is aligned with the new versions
of AH and ESP, which also differ from their predecessors. Specific
requirements for supported combinations of AH and ESP are newly
added, as are details of PMTU management.
Kent & Atkinson
Standards Track
[Page 43]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
Acknowledgements
Many of the concepts embodied in this specification were derived from
or influenced by the US Government’s SP3 security protocol, ISO/IEC’s
NLSP, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93],
and the work done for SNMP Security and SNMPv2 Security.
For over 3 years (although it sometimes seems *much* longer), this
document has evolved through multiple versions and iterations.
During this time, many people have contributed significant ideas and
energy to the process and the documents themselves. The authors
would like to thank Karen Seo for providing extensive help in the
review, editing, background research, and coordination for this
version of the specification. The authors would also like to thank
the members of the IPsec and IPng working groups, with special
mention of the efforts of (in alphabetic order): Steve Bellovin,
Steve Deering, James Hughes, Phil Karn, Frank Kastenholz, Perry
Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William
Simpson, Harry Varnis, and Nina Yuan.
Kent & Atkinson
Standards Track
[Page 44]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
Appendix A -- Glossary
This section provides definitions for several key terms that are
employed in this document. Other documents provide additional
definitions and background information relevant to this technology,
e.g., [VK83, HA94]. Included in this glossary are generic security
service and security mechanism terms, plus IPsec-specific terms.
Access Control
Access control is a security service that prevents unauthorized
use of a resource, including the prevention of use of a resource
in an unauthorized manner. In the IPsec context, the resource
to which access is being controlled is often:
o for a host, computing cycles or data
o for a security gateway, a network behind the gateway
or
bandwidth on that network.
Anti-replay
[See "Integrity" below]
Authentication
This term is used informally to refer to the combination of two
nominally distinct security services, data origin authentication
and connectionless integrity. See the definitions below for
each of these services.
Availability
Availability, when viewed as a security service, addresses the
security concerns engendered by attacks against networks that
deny or degrade service. For example, in the IPsec context, the
use of anti-replay mechanisms in AH and ESP support
availability.
Confidentiality
Confidentiality is the security service that protects data from
unauthorized disclosure. The primary confidentiality concern in
most instances is unauthorized disclosure of application level
data, but disclosure of the external characteristics of
communication also can be a concern in some circumstances.
Traffic flow confidentiality is the service that addresses this
latter concern by concealing source and destination addresses,
message length, or frequency of communication. In the IPsec
context, using ESP in tunnel mode, especially at a security
gateway, can provide some level of traffic flow confidentiality.
(See also traffic analysis, below.)
Kent & Atkinson
Standards Track
[Page 45]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
Encryption
Encryption is a security mechanism used to transform data from
an intelligible form (plaintext) into an unintelligible form
(ciphertext), to provide confidentiality. The inverse
transformation process is designated "decryption". Oftimes the
term "encryption" is used to generically refer to both
processes.
Data Origin Authentication
Data origin authentication is a security service that verifies
the identity of the claimed source of data. This service is
usually bundled with connectionless integrity service.
Integrity
Integrity is a security service that ensures that modifications
to data are detectable. Integrity comes in various flavors to
match application requirements. IPsec supports two forms of
integrity: connectionless and a form of partial sequence
integrity. Connectionless integrity is a service that detects
modification of an individual IP datagram, without regard to the
ordering of the datagram in a stream of traffic. The form of
partial sequence integrity offered in IPsec is referred to as
anti-replay integrity, and it detects arrival of duplicate IP
datagrams (within a constrained window). This is in contrast to
connection-oriented integrity, which imposes more stringent
sequencing requirements on traffic, e.g., to be able to detect
lost or re-ordered messages. Although authentication and
integrity services often are cited separately, in practice they
are intimately connected and almost always offered in tandem.
Security Association (SA)
A simplex (uni-directional) logical connection, created for
security purposes. All traffic traversing an SA is provided the
same security processing. In IPsec, an SA is an internet layer
abstraction implemented through the use of AH or ESP.
Security Gateway
A security gateway is an intermediate system that acts as the
communications interface between two networks. The set of hosts
(and networks) on the external side of the security gateway is
viewed as untrusted (or less trusted), while the networks and
hosts and on the internal side are viewed as trusted (or more
trusted). The internal subnets and hosts served by a security
gateway are presumed to be trusted by virtue of sharing a
common, local, security administration. (See "Trusted
Subnetwork" below.) In the IPsec context, a security gateway is
a point at which AH and/or ESP is implemented in order to serve
Kent & Atkinson
Standards Track
[Page 46]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
a set of internal hosts, providing security services for these
hosts when they communicate with external hosts also employing
IPsec (either directly or via another security gateway).
SPI
Acronym for "Security Parameters Index". The combination of a
destination address, a security protocol, and an SPI uniquely
identifies a security association (SA, see above). The SPI is
carried in AH and ESP protocols to enable the receiving system
to select the SA under which a received packet will be
processed. An SPI has only local significance, as defined by
the creator of the SA (usually the receiver of the packet
carrying the SPI); thus an SPI is generally viewed as an opaque
bit string. However, the creator of an SA may choose to
interpret the bits in an SPI to facilitate local processing.
Traffic Analysis
The analysis of network traffic flow for the purpose of deducing
information that is useful to an adversary. Examples of such
information are frequency of transmission, the identities of the
conversing parties, sizes of packets, flow identifiers, etc.
[Section 8.6">Sch94]
Trusted Subnetwork
A subnetwork containing hosts and routers that trust each other
not to engage in active or passive attacks. There also is an
assumption that the underlying communications channel (e.g., a
LAN or CAN) isn’t being attacked by other means.
Kent & Atkinson
Standards Track
[Page 47]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues
B.1 DF bit
In cases where a system (host or gateway) adds an encapsulating
header (e.g., ESP tunnel), should/must the DF bit in the original
packet be copied to the encapsulating header?
Fragmenting seems correct for some situations, e.g., it might be
appropriate to fragment packets over a network with a very small MTU,
e.g., a packet radio network, or a cellular phone hop to mobile node,
rather than propagate back a very small PMTU for use over the rest of
the path. In other situations, it might be appropriate to set the DF
bit in order to get feedback from later routers about PMTU
constraints which require fragmentation. The existence of both of
these situations argues for enabling a system to decide whether or
not to fragment over a particular network "link", i.e., for requiring
an implementation to be able to copy the DF bit (and to process ICMP
PMTU messages), but making it an option to be selected on a per
interface basis. In other words, an administrator should be able to
configure the router’s treatment of the DF bit (set, clear, copy from
encapsulated header) for each interface.
Note: If a bump-in-the-stack implementation of IPsec attempts to
apply different IPsec algorithms based on source/destination ports,
it will be difficult to apply Path MTU adjustments.
B.2 Fragmentation
If required, IP fragmentation occurs after IPsec processing within an
IPsec implementation. Thus, transport mode AH or ESP is applied only
to whole IP datagrams (not to IP fragments). An IP packet to which
AH or ESP has been applied may itself be fragmented by routers en
route, and such fragments MUST be reassembled prior to IPsec
processing at a receiver. In tunnel mode, AH or ESP is applied to an
IP packet, the payload of which may be a fragmented IP packet. For
example, a security gateway, "bump-in-the-stack" (BITS), or "bumpin-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to
such fragments. Note that BITS or BITW implementations are examples
of where a host IPsec implementation might receive fragments to which
tunnel mode is to be applied. However, if transport mode is to be
applied, then these implementations MUST reassemble the fragments
prior to applying IPsec.
Kent & Atkinson
Standards Track
[Page 48]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
NOTE: IPsec always has to figure out what the encapsulating IP header
fields are. This is independent of where you insert IPsec and is
intrinsic to the definition of IPsec. Therefore any IPsec
implementation that is not integrated into an IP implementation must
include code to construct the necessary IP headers (e.g., IP2):
o AH-tunnel --> IP2-AH-IP1-Transport-Data
o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer
*********************************************************************
Overall, the fragmentation/reassembly approach described above works
for all cases examined.
AH Xport
Implementation approach
IPv4 IPv6
-------------------------- ---Hosts (integr w/ IP stack)
Y
Y
Hosts (betw/ IP and drivers)
Y
Y
S. Gwy (integr w/ IP stack)
Outboard crypto processor *
AH Tunnel
IPv4 IPv6
---- ---Y
Y
Y
Y
Y
Y
ESP Xport
IPv4 IPv6
---- ---Y
Y
Y
Y
ESP Tunnel
IPv4 IPv6
---- ---Y
Y
Y
Y
Y
Y
* If the crypto processor system has its own IP address, then it
is covered by the security gateway case. This box receives
the packet from the host and performs IPsec processing. It
has to be able to handle the same AH, ESP, and related
IPv4/IPv6 tunnel processing that a security gateway would have
to handle. If it doesn’t have it’s own address, then it is
similar to the bump-in-the stack implementation between IP and
the network drivers.
The following analysis assumes that:
1. There is only one IPsec module in a given system’s stack.
There isn’t an IPsec module A (adding ESP/encryption and
thus) hiding the transport protocol, SRC port, and DEST port
from IPsec module B.
2. There are several places where IPsec could be implemented (as
shown in the table above).
a. Hosts with integration of IPsec into the native IP
implementation. Implementer has access to the source
for the stack.
b. Hosts with bump-in-the-stack implementations, where
IPsec is implemented between IP and the local network
drivers. Source access for stack is not available;
but there are well-defined interfaces that allows the
IPsec code to be incorporated into the system.
Kent & Atkinson
Standards Track
[Page 49]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
c. Security gateways and outboard crypto processors with
integration of IPsec into the stack.
3. Not all of the above approaches are feasible in all hosts.
But it was assumed that for each approach, there are some
hosts for whom the approach is feasible.
For each of the above 3 categories, there are IPv4 and IPv6, AH
transport and tunnel modes, and ESP transport and tunnel modes -- for
a total of 24 cases (3 x 2 x 4).
Some header fields and interface fields are listed here for ease of
reference -- they’re not in the header order, but instead listed to
allow comparison between the columns. (* = not covered by AH
authentication. ESP authentication doesn’t cover any headers that
precede it.)
IPv4
---Version = 4
Header Len
*TOS
Packet Len
ID
*Flags
*Offset
*TTL
Protocol
*Checksum
Src Address
Dst Address
Options?
IPv6
---Version = 6
IP/Transport Interface
(RFC 1122 -- Sec 3.4)
----------------------
Class,Flow Lbl
Payload Len
TOS
Len
ID (optional)
DF
*Hop Limit
Next Header
TTL
Src Address
Dst Address
Options?
Src Address
Dst Address
Opt
? = AH covers Option-Type and Option-Length, but
might not cover Option-Data.
The results for each of the 20 cases is shown below ("works" = will
work if system fragments after outbound IPsec processing, reassembles
before inbound IPsec processing). Notes indicate implementation
issues.
a. Hosts (integrated into IP stack)
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
Kent & Atkinson
Standards Track
[Page 50]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and
network drivers. In this case, the IPsec module would have to do
something like one of the following for fragmentation and
reassembly.
- do the fragmentation/reassembly work itself and
send/receive the packet directly to/from the network
layer. In AH or ESP transport mode, this is fine. In AH
or ESP tunnel mode where the tunnel end is at the ultimate
destination, this is fine. But in AH or ESP tunnel modes
where the tunnel end is different from the ultimate
destination and where the source host is multi-homed, this
approach could result in sub-optimal routing because the
IPsec module may be unable to obtain the information
needed (LAN interface and next-hop gateway) to direct the
packet to the appropriate network interface. This is not
a problem if the interface and next-hop gateway are the
same for the ultimate destination and for the tunnel end.
But if they are different, then IPsec would need to know
the LAN interface and the next-hop gateway for the tunnel
end. (Note: The tunnel end (security gateway) is highly
likely to be on the regular path to the ultimate
destination. But there could also be more than one path
to the destination, e.g., the host could be at an
organization with 2 firewalls. And the path being used
could involve the less commonly chosen firewall.) OR
- pass the IPsec’d packet back to the IP layer where an
extra IP header would end up being pre-pended and the
IPsec module would have to check and let IPsec’d fragments
go by.
OR
- pass the packet contents to the IP layer in a form such
that the IP layer recreates an appropriate IP header
At the network layer, the IPsec module will have access to the
following selectors from the packet -- SRC address, DST address,
Next Protocol, and if there’s a transport layer header --> SRC
port and DST port. One cannot assume IPsec has access to the
Name. It is assumed that the available selector information is
sufficient to figure out the relevant Security Policy entry and
Security Association(s).
Kent & Atkinson
Standards Track
[Page 51]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
c. Security gateways -- integrate IPsec into the IP stack
NOTE: The IPsec module will have access to the following
selectors from the packet -- SRC address, DST address, Next
Protocol, and if there’s a transport layer header --> SRC port
and DST port. It won’t have access to the User ID (only Hosts
have access to User ID information.) Unlike some Bump-in-thestack implementations, security gateways may be able to look up
the Source Address in the DNS to provide a System Name, e.g., in
situations involving use of dynamically assigned IP addresses in
conjunction with dynamically updated DNS entries. It also won’t
have access to the transport layer information if there is an ESP
header, or if it’s not the first fragment of a fragmented
message. It is assumed that the available selector information
is sufficient to figure out the relevant Security Policy entry
and Security Association(s).
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
**********************************************************************
B.3 Path MTU Discovery
As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for
Path MTU Discovery.
The legend for the diagrams below in B.3.1 and B.3.3 (but not B.3.2)
is:
==== = security association (AH or ESP, transport or tunnel)
Kent & Atkinson
Standards Track
[Page 52]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
---- = connectivity (or if so labelled, administrative boundary)
.... = ICMP message (hereafter referred to as ICMP PMTU) for
IPv4:
- Type = 3 (Destination Unreachable)
- Code = 4 (Fragmentation needed and DF set)
- Next-Hop MTU in the low-order 16 bits of the second
word of the ICMP header (labelled unused in RFC 792),
with high-order 16 bits set to zero
IPv6 (RFC 1885):
- Type = 2 (Packet Too Big)
- Code = 0 (Fragmentation needed and DF set)
- Next-Hop MTU in the 32 bit MTU field of the ICMP6
Hx
Rx
SGx
X*
=
=
=
=
host x
router x
security gateway x
X supports IPsec
B.3.1 Identifying the Originating Host(s)
The amount of information returned with the ICMP message is limited
and this affects what selectors are available to identify security
associations, originating hosts, etc. for use in further propagating
the PMTU information.
In brief... An ICMP message must contain the following information
from the "offending" packet:
- IPv4 (RFC 792) -- IP header plus a minimum of 64 bits
Accordingly, in the IPv4 context, an ICMP PMTU may identify only the
first (outermost) security association. This is because the ICMP
PMTU may contain only 64 bits of the "offending" packet beyond the IP
header, which would capture only the first SPI from AH or ESP. In
the IPv6 context, an ICMP PMTU will probably provide all the SPIs and
the selectors in the IP header, but maybe not the SRC/DST ports (in
the transport header) or the encapsulated (TCP, UDP, etc.) protocol.
Moreover, if ESP is used, the transport ports and protocol selectors
may be encrypted.
Looking at the diagram below of a security gateway tunnel (as
mentioned elsewhere, security gateways do not use transport mode)...
Kent & Atkinson
Standards Track
[Page 53]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
H1
===================
H3
\ |
|
/
H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5
/ ^
|
\
H2
|........|
H4
Suppose that the security policy for SG1 is to use a single SA to SG2
for all the traffic between hosts H0, H1, and H2 and hosts H3, H4,
and H5. And suppose H0 sends a data packet to H5 which causes R1 to
send an ICMP PMTU message to SG1. If the PMTU message has only the
SPI, SG1 will be able to look up the SA and find the list of possible
hosts (H0, H1, H2, wildcard); but SG1 will have no way to figure out
that H0 sent the traffic that triggered the ICMP PMTU message.
original
packet
--------
IP-1 header
TCP header
TCP data
after IPsec
processing
-----------
IP-2 header
ESP header
IP-1 header
TCP header
TCP data
ESP trailer
ICMP
packet
-----IP-3 header (S = R1, D = SG1)
ICMP header (includes PMTU)
IP-2 header (S = SG1, D = SG2)
minimum of 64 bits of ESP hdr (*)
(*) The 64 bits will include enough of the ESP (or AH) header to
include the SPI.
- ESP -- SPI (32 bits), Seq number (32 bits)
- AH -- Next header (8 bits), Payload Len (8 bits),
Reserved (16 bits), SPI (32 bits)
This limitation on the amount of information returned with an ICMP
message creates a problem in identifying the originating hosts for
the packet (so as to know where to further propagate the ICMP PMTU
information). If the ICMP message contains only 64 bits of the IPsec
header (minimum for IPv4), then the IPsec selectors (e.g., Source and
Destination addresses, Next Protocol, Source and Destination ports,
etc.) will have been lost. But the ICMP error message will still
provide SG1 with the SPI, the PMTU information and the source and
destination gateways for the relevant security association.
The destination security gateway and SPI uniquely define a security
association which in turn defines a set of possible originating
hosts. At this point, SG1 could:
Kent & Atkinson
Standards Track
[Page 54]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
a. send the PMTU information to all the possible originating hosts.
This would not work well if the host list is a wild card or if
many/most of the hosts weren’t sending to SG1; but it might work
if the SPI/destination/etc mapped to just one or a small number of
hosts.
b. store the PMTU with the SPI/etc and wait until the next packet(s)
arrive from the originating host(s) for the relevant security
association. If it/they are bigger than the PMTU, drop the
packet(s), and compose ICMP PMTU message(s) with the new packet(s)
and the updated PMTU, and send the originating host(s) the ICMP
message(s) about the problem. This involves a delay in notifying
the originating host(s), but avoids the problems of (a).
Since only the latter approach is feasible in all instances, a
security gateway MUST provide such support, as an option. However,
if the ICMP message contains more information from the original
packet, then there may be enough information to immediately determine
to which host to propagate the ICMP/PMTU message and to provide that
system with the 5 fields (source address, destination address, source
port, destination port, and transport protocol) needed to determine
where to store/update the PMTU. Under such circumstances, a security
gateway MUST generate an ICMP PMTU message immediately upon receipt
of an ICMP PMTU from further down the path. NOTE: The Next Protocol
field may not be contained in the ICMP message and the use of ESP
encryption may hide the selector fields that have been encrypted.
B.3.2 Calculation of PMTU
The calculation of PMTU from an ICMP PMTU has to take into account
the addition of any IPsec header by H1 -- AH and/or ESP transport, or
ESP or AH tunnel. Within a single host, multiple applications may
share an SPI and nesting of security associations may occur. (See
Section 4.5 Basic Combinations of Security Associations for
description of the combinations that MUST be supported). The diagram
below illustrates an example of security associations between a pair
of hosts (as viewed from the perspective of one of the hosts.) (ESPx
or AHx = transport mode)
Socket 1 -------------------------|
|
Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet
In order to figure out the PMTU for each socket that maps to SPI-B,
it will be necessary to have backpointers from SPI-B to each of the 2
paths that lead to it -- Socket 1 and Socket 2/SPI-A.
Kent & Atkinson
Standards Track
[Page 55]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
B.3.3 Granularity of Maintaining PMTU Data
In hosts, the granularity with which PMTU ICMP processing can be done
differs depending on the implementation situation. Looking at a
host, there are three situations that are of interest with respect to
PMTU issues:
a. Integration of IPsec into the native IP implementation
b. Bump-in-the-stack implementations, where IPsec is implemented
"underneath" an existing implementation of a TCP/IP protocol
stack, between the native IP and the local network drivers
c. No IPsec implementation -- This case is included because it is
relevant in cases where a security gateway is sending PMTU
information back to a host.
Only in case (a) can the PMTU data be maintained at the same
granularity as communication associations. In the other cases, the
IP layer will maintain PMTU data at the granularity of Source and
Destination IP addresses (and optionally TOS/Class), as described in
RFC 1191. This is an important difference, because more than one
communication association may map to the same source and destination
IP addresses, and each communication association may have a different
amount of IPsec header overhead (e.g., due to use of different
transforms or different algorithms). The examples below illustrate
this.
In cases (a) and (b)... Suppose you have the following situation.
H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds
the PMTU of the network hop between them.
==================================
|
|
H1* --- R1 ----- R2 ---- R3 ---- H2*
^
|
|.......|
If R1 is configured to not fragment subscriber traffic, then R1 sends
an ICMP PMTU message with the appropriate PMTU to H1. H1’s
processing would vary with the nature of the implementation. In case
(a) (native IP), the security services are bound to sockets or the
equivalent. Here the IP/IPsec implementation in H1 can store/update
the PMTU for the associated socket. In case (b), the IP layer in H1
can store/update the PMTU but only at the granularity of Source and
Destination addresses and possibly TOS/Class, as noted above. So the
result may be sub-optimal, since the PMTU for a given
SRC/DST/TOS/Class will be the subtraction of the largest amount of
IPsec header used for any communication association between a given
source and destination.
Kent & Atkinson
Standards Track
[Page 56]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
In case (c), there has to be a security gateway to have any IPsec
processing. So suppose you have the following situation. H1 is
sending to H2 and the packet to be sent from SG1 to R exceeds the
PMTU of the network hop between them.
================
|
|
H1 ---- SG1* --- R --- SG2* ---- H2
^
|
|.......|
As described above for case (b), the IP layer in H1 can store/update
the PMTU but only at the granularity of Source and Destination
addresses, and possibly TOS/Class. So the result may be sub-optimal,
since the PMTU for a given SRC/DST/TOS/Class will be the subtraction
of the largest amount of IPsec header used for any communication
association between a given source and destination.
B.3.4 Per Socket Maintenance of PMTU Data
Implementation of the calculation of PMTU (Section B.3.2) and support
for PMTUs at the granularity of individual "communication
associations" (Section B.3.3) is a local matter. However, a socketbased implementation of IPsec in a host SHOULD maintain the
information on a per socket basis. Bump in the stack systems MUST
pass an ICMP PMTU to the host IP implementation, after adjusting it
for any IPsec header overhead added by these systems. The
determination of the overhead SHOULD be determined by analysis of the
SPI and any other selector information present in a returned ICMP
PMTU message.
B.3.5 Delivery of PMTU Data to the Transport Layer
The host mechanism for getting the updated PMTU to the transport
layer is unchanged, as specified in RFC 1191 (Path MTU Discovery).
B.3.6 Aging of PMTU Data
This topic is covered in Section 6.1.2.4.
Kent & Atkinson
Standards Track
[Page 57]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
Appendix C -- Sequence Space Window Code Example
This appendix contains a routine that implements a bitmask check for
a 32 packet window. It was provided by James Hughes
(jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com)
and is intended as an implementation example. Note that this code
both checks for a replay and updates the window. Thus the algorithm,
as shown, should only be called AFTER the packet has been
authenticated. Implementers might wish to consider splitting the
code to do the check for replays before computing the ICV. If the
packet is not a replay, the code would then compute the ICV, (discard
any bad packets), and if the packet is OK, update the window.
#include <stdio.h>
#include <stdlib.h>
typedef unsigned long u_long;
enum {
ReplayWindowSize = 32
};
u_long bitmap = 0;
u_long lastSeq = 0;
/* session state - must be 32 bits */
/* session state */
/* Returns 0 if packet disallowed, 1 if packet permitted */
int ChkReplayWindow(u_long seq);
int ChkReplayWindow(u_long seq) {
u_long diff;
if (seq == 0) return 0;
/* first == 0 or wrapped */
if (seq > lastSeq) {
/* new larger sequence number */
diff = seq - lastSeq;
if (diff < ReplayWindowSize) { /* In window */
bitmap <<= diff;
bitmap |= 1;
/* set bit for this packet */
} else bitmap = 1;
/* This packet has a "way larger" */
lastSeq = seq;
return 1;
/* larger is good */
}
diff = lastSeq - seq;
if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
if (bitmap & ((u_long)1 << diff)) return 0; /* already seen */
bitmap |= ((u_long)1 << diff);
/* mark as seen */
return 1;
/* out of order but good */
}
char string_buffer[512];
Kent & Atkinson
Standards Track
[Page 58]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
#define STRING_BUFFER_SIZE sizeof(string_buffer)
int main() {
int result;
u_long last, current, bits;
printf("Input initial state (bits in hex, last msgnum):\n");
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
sscanf(string_buffer, "%lx %lu", &bits, &last);
if (last != 0)
bits |= 1;
bitmap = bits;
lastSeq = last;
printf("bits:%08lx last:%lu\n", bitmap, lastSeq);
printf("Input value to test (current):\n");
while (1) {
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
sscanf(string_buffer, "%lu", &current);
result = ChkReplayWindow(current);
printf("%-3s", result ? "OK" : "BAD");
printf(" bits:%08lx last:%lu\n", bitmap, lastSeq);
}
return 0;
}
Kent & Atkinson
Standards Track
[Page 59]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
Appendix D -- Categorization of ICMP messages
The tables below characterize ICMP messages as being either host
generated, router generated, both, unassigned/unknown. The first set
are IPv4. The second set are IPv6.
IPv4
Type
Name/Codes
Reference
========================================================================
HOST GENERATED:
3
Destination Unreachable
2 Protocol Unreachable
[RFC792]
3 Port Unreachable
[RFC792]
8 Source Host Isolated
[RFC792]
14 Host Precedence Violation
[RFC1812]
10
Router Selection
[RFC1256]
Type
Name/Codes
Reference
========================================================================
ROUTER GENERATED:
3
Destination Unreachable
0 Net Unreachable
[RFC792]
4 Fragmentation Needed, Don’t Fragment was Set
[RFC792]
5 Source Route Failed
[RFC792]
6 Destination Network Unknown
[RFC792]
7 Destination Host Unknown
[RFC792]
9 Comm. w/Dest. Net. is Administratively Prohibited [RFC792]
11 Destination Network Unreachable for Type of Service[RFC792]
5
Redirect
0 Redirect Datagram for the Network (or subnet)
[RFC792]
2 Redirect Datagram for the Type of Service & Network[RFC792]
9
Router Advertisement
[RFC1256]
18
Address Mask Reply
[RFC950]
Kent & Atkinson
Standards Track
[Page 60]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
IPv4
Type
Name/Codes
Reference
========================================================================
BOTH ROUTER AND HOST GENERATED:
0
Echo Reply
[RFC792]
3
Destination Unreachable
1 Host Unreachable
[RFC792]
10 Comm. w/Dest. Host is Administratively Prohibited [RFC792]
12 Destination Host Unreachable for Type of Service
[RFC792]
13 Communication Administratively Prohibited
[RFC1812]
15 Precedence cutoff in effect
[RFC1812]
4
Source Quench
[RFC792]
5
Redirect
1 Redirect Datagram for the Host
[RFC792]
3 Redirect Datagram for the Type of Service and Host [RFC792]
6
Alternate Host Address
[JBP]
8
Echo
[RFC792]
11
Time Exceeded
[RFC792]
12
Parameter Problem
[RFC792,RFC1108]
13
Timestamp
[RFC792]
14
Timestamp Reply
[RFC792]
15
Information Request
[RFC792]
16
Information Reply
[RFC792]
17
Address Mask Request
[RFC950]
30
Traceroute
[RFC1393]
31
Datagram Conversion Error
[RFC1475]
32
Mobile Host Redirect
[Johnson]
39
SKIP
[Markson]
40
Photuris
[Simpson]
Type
Name/Codes
Reference
========================================================================
UNASSIGNED TYPE OR UNKNOWN GENERATOR:
1
Unassigned
[JBP]
2
Unassigned
[JBP]
7
Unassigned
[JBP]
19
Reserved (for Security)
[Solo]
20-29 Reserved (for Robustness Experiment)
[ZSu]
33
IPv6 Where-Are-You
[Simpson]
34
IPv6 I-Am-Here
[Simpson]
35
Mobile Registration Request
[Simpson]
36
Mobile Registration Reply
[Simpson]
37
Domain Name Request
[Simpson]
38
Domain Name Reply
[Simpson]
41-255 Reserved
[JBP]
Kent & Atkinson
Standards Track
[Page 61]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
IPv6
Type
Name/Codes
Reference
========================================================================
HOST GENERATED:
1
Destination Unreachable
[RFC 1885]
4 Port Unreachable
Type
Name/Codes
Reference
========================================================================
ROUTER GENERATED:
1
Destination Unreachable
[RFC1885]
0 No Route to Destination
1 Comm. w/Destination is Administratively Prohibited
2 Not a Neighbor
3 Address Unreachable
2
Packet Too Big
[RFC1885]
0
3
Time Exceeded
[RFC1885]
0 Hop Limit Exceeded in Transit
1 Fragment reassembly time exceeded
Type
Name/Codes
Reference
========================================================================
BOTH ROUTER AND HOST GENERATED:
4
Parameter Problem
[RFC1885]
0 Erroneous Header Field Encountered
1 Unrecognized Next Header Type Encountered
2 Unrecognized IPv6 Option Encountered
Kent & Atkinson
Standards Track
[Page 62]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
References
[BL73]
Bell, D.E. & LaPadula, L.J., "Secure Computer Systems:
Mathematical Foundations and Model", Technical Report M74244, The MITRE Corporation, Bedford, MA, May 1973.
[Bra97]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[DoD85]
US National Computer Security Center, "Department of
Defense Trusted Computer System Evaluation Criteria", DoD
5200.28-STD, US Department of Defense, Ft. Meade, MD.,
December 1985.
[DoD87]
US National Computer Security Center, "Trusted Network
Interpretation of the Trusted Computer System Evaluation
Criteria", NCSC-TG-005, Version 1, US Department of
Defense, Ft. Meade, MD., 31 July 1987.
[HA94]
Haller, N., and R. Atkinson, "On Internet Authentication",
RFC 1704, October 1994.
[HC98]
Harkins, D., and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[HM97]
Harney, H., and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094, July 1997.
[ISO]
ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
DIS 11577, International Standards Organisation, Geneva,
Switzerland, 29 November 1992.
[IB93]
John Ioannidis and Matt Blaze, "Architecture and
Implementation of Network-layer Security Under Unix",
Proceedings of USENIX Security Symposium, Santa Clara, CA,
October 1993.
[IBK93]
John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: NetworkLayer Security for IP", presentation at the Spring 1993
IETF Meeting, Columbus, Ohio
[KA98a]
Kent, S., and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[KA98b]
Kent, S., and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
Kent & Atkinson
Standards Track
[Page 63]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
[Ken91]
Kent, S., "US DoD Security Options for the Internet
Protocol", RFC 1108, November 1991.
[MSST97]
Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[Orm97]
Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[Pip98]
Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[Sch94]
Bruce Schneier, Applied Cryptography, Section 8.6, John
Wiley & Sons, New York, NY, 1994.
[SDNS]
SDNS Secure Data Network System, Security Protocol 3, SP3,
Document SDN.301, Revision 1.5, 15 May 1989, published in
NIST Publication NIST-IR-90-4250, February 1990.
[SMPT98]
Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 2393, August
1998.
[TDG97]
Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[VK83]
V.L. Voydock & S.T. Kent, "Security Mechanisms in Highlevel Networks", ACM Computing Surveys, Vol. 15, No. 2,
June 1983.
Disclaimer
The views and specification expressed in this document are those of
the authors and are not necessarily those of their employers. The
authors and their employers specifically disclaim responsibility for
any problems arising from correct or incorrect implementation or use
of this design.
Kent & Atkinson
Standards Track
[Page 64]
APPENDIX AD
RFC 2401
Security Architecture for IP
November 1998
Author Information
Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Randall Atkinson
@Home Network
425 Broadway
Redwood City, CA 94063
USA
Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
Kent & Atkinson
Standards Track
[Page 65]
APPENDIX AD
RFC 2401
Security Architecture for IP
Copyright (C) The Internet Society (1998).
November 1998
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.
Kent & Atkinson
Standards Track
[Page 66]
APPENDIX AE
Network Working Group
Request for Comments: 1825
Category: Standards Track
R. Atkinson
Naval Research Laboratory
August 1995
Security Architecture for the Internet Protocol
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
1. INTRODUCTION
This memo describes the security mechanisms for IP version 4 (IPv4)
and IP version 6 (IPv6) and the services that they provide. Each
security mechanism is specified in a separate document. This
document also describes key management requirements for systems
implementing those security mechanisms. This document is not an
overall Security Architecture for the Internet and is instead focused
on IP-layer security.
1.1 Technical Definitions
This section provides a few basic definitions that are applicable to
this document. Other documents provide more definitions and
background information [VK83, HA94].
Authentication
The property of knowing that the data received is the same as
the data that was sent and that the claimed sender is in fact
the actual sender.
Integrity
The property of ensuring that data is transmitted from source
to destination without undetected alteration.
Confidentiality
The property of communicating such that the intended
recipients know what was being sent but unintended
parties cannot determine what was sent.
Encryption
A mechanism commonly used to provide confidentiality.
Atkinson
RFC 1825
Standards Track
[Page 1]
Security Architecture for IP
August 1995
Non-repudiation
The property of a receiver being able to prove that the sender
of some data did in fact send the data even though the sender
might later desire to deny ever having sent that data.
SPI
Acronym for "Security Parameters Index". An unstructured
opaque index which is used in conjunction with the
Destination Address to identify a particular Security
Association.
Security Association
The set of security information relating to a given network
connection or set of connections. This is described in
detail below.
Traffic Analysis
The analysis of network traffic flow for the purpose of
deducing information that is useful to an adversary.
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
Examples of such information are frequency of transmission,
the identities of the conversing parties, sizes of packets,
Flow Identifiers used, etc. [Sch94].
1.2 Requirements Terminology
In this document, the words that are used to define the significance
of each particular requirement are usually capitalised. These words
are:
- MUST
This word or the adjective "REQUIRED" means that the item is an
absolute requirement of the specification.
- SHOULD
This word or the adjective "RECOMMENDED" means that there might
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case
carefully weighed before taking a different course.
- MAY
This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor might choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit the
same item.
Atkinson
RFC 1825
Standards Track
[Page 2]
Security Architecture for IP
August 1995
1.3 Typical Use
There are two specific headers that are used to provide security
services in IPv4 and IPv6. These headers are the "IP Authentication
Header (AH)" [Atk95a] and the "IP Encapsulating Security Payload
(ESP)" [Atk95b] header. There are a number of ways in which these IP
security mechanisms might be used. This section describes some of
the more likely uses. These descriptions are not complete or
exhaustive. Other uses can also be envisioned.
The IP Authentication Header is designed to provide integrity and
authentication without confidentiality to IP datagrams. The lack of
confidentiality ensures that implementations of the Authentication
Header will be widely available on the Internet, even in locations
where the export, import, or use of encryption to provide
confidentiality is regulated. The Authentication Header supports
security between two or more hosts implementing AH, between two or
more gateways implementing AH, and between a host or gateway
implementing AH and a set of hosts or gateways. A security gateway
is a system which acts as the communications gateway between external
untrusted systems and trusted hosts on their own subnetwork. It also
provides security services for the trusted hosts when they
communicate with the external untrusted systems. A trusted
subnetwork contains hosts and routers that trust each other not to
engage in active or passive attacks and trust that the underlying
communications channel (e.g., an Ethernet) isn't being attacked.
In the case where a security gateway is providing services on behalf
of one or more hosts on a trusted subnet, the security gateway is
responsible for establishing the security association on behalf of
its trusted host and for providing security services between the
security gateway and the external system(s). In this case, only the
gateway need implement AH, while all of the systems behind the
gateway on the trusted subnet may take advantage of AH services
between the gateway and external systems.
A security gateway which receives a datagram containing a recognised
sensitivity label, for example IPSO [Ken91], from a trusted host
should take that label's value into consideration when
creating/selecting an Security Association for use with AH between
the gateway and the external destination. In such an environment, a
gateway which receives a IP packet containing the IP Encapsulating
Security Payload (ESP) should add appropriate authentication,
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
APPENDIX AE
including implicit (i.e., contained in the Security Association used)
or explicit label information (e.g., IPSO), for the decrypted packet
that it forwards to the trusted host that is the ultimate
destination. The IP Authentication Header should always be used on
packets containing explicit sensitivity labels to ensure end-to-end
Atkinson
RFC 1825
Standards Track
[Page 3]
Security Architecture for IP
August 1995
label integrity. In environments using security gateways, those
gateways MUST perform address-based IP packet filtering on
unauthenticated packets purporting to be from a system known to be
using IP security.
The IP Encapsulating Security Payload (ESP) is designed to provide
integrity, authentication, and confidentiality to IP datagrams
[Atk95b]. The ESP supports security between two or more hosts
implementing ESP, between two or more gateways implementing ESP, and
between a host or gateway implementing ESP and a set of hosts and/or
gateways. A security gateway is a system which acts as the
communications gateway between external untrusted systems and trusted
hosts on their own subnetwork and provides security services for the
trusted hosts when they communicate with external untrusted systems.
A trusted subnetwork contains hosts and routers that trust each other
not to engage in active or passive attacks and trust that the
underlying communications channel (e.g., an Ethernet) isn't being
attacked. Trusted systems always should be trustworthy, but in
practice they often are not trustworthy.
Gateway-to-gateway encryption is most valuable for building private
virtual networks across an untrusted backbone such as the Internet.
It does this by excluding outsiders. As such, it is often not a
substitute for host-to-host encryption, and indeed the two can be and
often should be used together.
In the case where a security gateway is providing services on behalf
of one or more hosts on a trusted subnet, the security gateway is
responsible for establishing the security association on behalf of
its trusted host and for providing security services between the
security gateway and the external system(s). In this case, only the
gateway need implement ESP, while all of the systems behind the
gateway on the trusted subnet may take advantage of ESP services
between the gateway and external systems.
A gateway which receives a datagram containing a recognised
sensitivity label from a trusted host should take that label's value
into consideration when creating/selecting a Security Association for
use with ESP between the gateway and the external destination. In
such an environment, a gateway which receives a IP packet containing
the ESP should appropriately label the decrypted packet that it
forwards to the trusted host that is the ultimate destination. The
IP Authentication Header should always be used on packets containing
explicit sensitivity labels to ensure end-to-end label integrity.
Atkinson
RFC 1825
Standards Track
[Page 4]
Security Architecture for IP
August 1995
If there are no security gateways present in the connection, then two
end systems that implement ESP may also use it to encrypt only the
user data (e.g., TCP or UDP) being carried between the two systems.
ESP is designed to provide maximum flexibility so that users may
select and use only the security that they desire and need.
Routing headers for which integrity has not been cryptographically
protected SHOULD be ignored by the receiver. If this rule is not
strictly adhered to, then the system will be vulnerable to various
kinds of attacks, including source routing attacks [Bel89] [CB94]
[CERT95].
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
APPENDIX AE
While these documents do not specifically discuss IPv4 broadcast,
these IP security mechanisms MAY be used with such packets. Key
distribution and Security Association management are not trivial for
broadcast applications. Also, if symmetric key algorithms are used
the value of using cryptography with a broadcast packet is limited
because the receiver can only know that the received packet came from
one of many systems knowing the correct key to use.
1.4 Security Associations
The concept of a "Security Association" is fundamental to both the IP
Encapsulating Security Payload and the IP Authentication Header. The
combination of a given Security Parameter Index (SPI) and Destination
Address uniquely identifies a particular "Security Association". An
implementation of the Authentication Header or the Encapsulating
Security Payload MUST support this concept of a Security Association.
An implementation MAY also support other parameters as part of a
Security Association. A Security Association normally includes the
parameters listed below, but might include additional parameters as
well:
- Authentication algorithm and algorithm mode being used with
the IP Authentication Header [REQUIRED for AH implementations].
- Key(s) used with the authentication algorithm in use with
the Authentication Header [REQUIRED for AH implementations].
- Encryption algorithm, algorithm mode, and transform being
used with the IP Encapsulating Security Payload [REQUIRED for
ESP implementations].
- Key(s) used with the encryption algorithm in use with the
Encapsulating Security Payload [REQUIRED for ESP implementations].
Atkinson
RFC 1825
Standards Track
[Page 5]
Security Architecture for IP
August 1995
- Presence/absence and size of a cryptographic synchronisation or
initialisation vector field for the encryption algorithm [REQUIRED
for ESP implementations].
- Authentication algorithm and mode used with the ESP transform
(if any is in use) [RECOMMENDED for ESP implementations].
- Authentication key(s) used with the authentication algorithm
that is part of the ESP transform (if any) [RECOMMENDED for
ESP implementations].
- Lifetime of the key or time when key change should occur
[RECOMMENDED for all implementations].
- Lifetime of this Security Association [RECOMMENDED for all
implementations].
- Source Address(es) of the Security Association, might be a
wildcard address if more than one sending system shares the
same Security Association with the destination [RECOMMENDED
for all implementations].
- Sensitivity level (for example, Secret or Unclassified)
of the protected data [REQUIRED for all systems claiming
to provide multi-level security, RECOMMENDED for all other systems].
The sending host uses the sending userid and Destination Address to
select an appropriate Security Association (and hence SPI value).
The receiving host uses the combination of SPI value and Destination
Address to distinguish the correct association. Hence, an AH
implementation will always be able to use the SPI in combination with
the Destination Address to determine the security association and
related security configuration data for all valid incoming packets.
When a formerly valid Security Association becomes invalid, the
destination system(s) SHOULD NOT immediately reuse that SPI value and
instead SHOULD let that SPI value become stale before reusing it for
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
APPENDIX AE
APPENDIX AE
some other Security Association.
A security association is normally one-way. An authenticated
communications session between two hosts will normally have two
Security Parameter Indexes in use (one in each direction). The
combination of a particular Security Parameter Index and a particular
Destination Address uniquely identifies the Security Association.
The Destination Address may be a unicast address or a multicast group
address.
Atkinson
RFC 1825
Standards Track
[Page 6]
Security Architecture for IP
August 1995
The receiver-orientation of the Security Association implies that, in
the case of unicast traffic, the destination system will normally
select the SPI value. By having the destination select the SPI
value, there is no potential for manually configured Security
Associations that conflict with automatically configured (e.g., via a
key management protocol) Security Associations. For multicast
traffic, there are multiple destination systems but a single
destination multicast group, so some system or person will need to
select SPIs on behalf of that multicast group and then communicate
the information to all of the legitimate members of that multicast
group via mechanisms not defined here.
Multiple senders to a multicast group MAY use a single Security
Association (and hence Security Parameter Index) for all traffic to
that group. In that case, the receiver only knows that the message
came from a system knowing the security association data for that
multicast group. A receiver cannot generally authenticate which
system sent the multicast traffic when symmetric algorithms (e.g.,
DES, IDEA) are in use. Multicast traffic MAY also use a separate
Security Association (and hence SPI) for each sender to the multicast
group . If each sender has its own Security Association and
asymmetric algorithms are used, then data origin authentication is
also a provided service.
2. DESIGN OBJECTIVES
This section describes some of the design objectives of this security
architecture and its component mechanisms. The primary objective of
this work is to ensure that IPv4 and IPv6 will have solid
cryptographic security mechanisms available to users who desire
security.
These mechanisms are designed to avoid adverse impacts on Internet
users who do not employ these security mechanisms for their traffic.
These mechanisms are intended to be algorithm-independent so that the
cryptographic algorithms can be altered without affecting the other
parts of the implementation. These security mechanisms should be
useful in enforcing a variety of security policies.
Standard default algorithms (keyed MD5, DES CBC) are specified to
ensure interoperability in the global Internet. The selected default
algorithms are the same as the standard default algorithms used in
SNMPv2 [GM93].
Atkinson
RFC 1825
Standards Track
[Page 7]
Security Architecture for IP
August 1995
3. IP-LAYER SECURITY MECHANISMS
There are two cryptographic security mechanisms for IP. The first is
the Authentication Header which provides integrity and authentication
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
without confidentiality [Atk95a]. The second is the Encapsulating
Security Payload which always provides confidentiality, and
(depending on algorithm and mode) might also provide integrity and
authentication [Atk95b]. The two IP security mechanisms may be used
together or separately.
These IP-layer mechanisms do not provide security against a number of
traffic analysis attacks. However, there are several techniques
outside the scope of this specification (e.g., bulk link encryption)
that might be used to provide protection against traffic analysis
[VK83].
3.1 AUTHENTICATION HEADER
The IP Authentication Header holds authentication information for its
IP datagram [Atk95a]. It does this by computing a cryptographic
authentication function over the IP datagram and using a secret
authentication key in the computation. The sender computes the
authentication data prior to sending the authenticated IP packet.
Fragmentation occurs after the Authentication Header processing for
outbound packets and prior to Authentication Header processing for
inbound packets. The receiver verifies the correctness of the
authentication data upon reception. Certain fields which must change
in transit, such as the "TTL" (IPv4) or "Hop Limit" (IPv6) field,
which is decremented on each hop, are omitted from the authentication
calculation. However the omission of the Hop Limit field does not
adversely impact the security provided. Non-repudiation might be
provided by some authentication algorithms (e.g., asymmetric
algorithms when both sender and receiver keys are used in the
authentication calculation) used with the Authentication Header, but
it is not necessarily provided by all authentication algorithms that
might be used with the Authentication Header. The default
authentication algorithm is keyed MD5, which, like all symmetric
algorithms, cannot provide non-repudiation by itself.
Confidentiality and traffic analysis protection are not provided by
the Authentication Header.
Use of the Authentication Header will increase the IP protocol
processing costs in participating systems and will also increase the
communications latency. The increased latency is primarily due to
the calculation of the authentication data by the sender and the
calculation and comparison of the authentication data by each
receiver for each IP datagram containing an Authentication Header
(AH).
Atkinson
RFC 1825
Standards Track
[Page 8]
Security Architecture for IP
August 1995
The Authentication Header provides much stronger security than exists
in most of the current Internet and should not affect exportability
or significantly increase implementation cost. While the
Authentication Header might be implemented by a security gateway on
behalf of hosts on a trusted network behind that security gateway,
this mode of operation is not encouraged. Instead, the
Authentication Header should be used from origin to final
destination.
All IPv6-capable hosts MUST implement the IP Authentication Header
with at least the MD5 algorithm using a 128-bit key. IPv4-systems
claiming to implement the Authentication Header MUST implement the IP
Authentication Header with at least the MD5 algorithm using a 128-bit
key [MS95]. An implementation MAY support other authentication
algorithms in addition to keyed MD5.
3.2 ENCAPSULATING SECURITY PAYLOAD
The IP Encapsulating Security Payload (ESP) is designed to provide
integrity, authentication, and confidentiality to IP datagrams
[Atk95b]. It does this by encapsulating either an entire IP datagram
or only the upper-layer protocol (e.g., TCP, UDP, ICMP) data inside
the ESP, encrypting most of the ESP contents, and then appending a
new cleartext IP header to the now encrypted Encapsulating Security
Payload. This cleartext IP header is used to carry the protected
data through the internetwork.
3.2.1 Description of the ESP Modes
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
APPENDIX AE
There are two modes within ESP. The first mode, which is known as
Tunnel-mode, encapsulates an entire IP datagram within the ESP
header. The second mode, which is known as Transport-mode,
encapsulates an upper-layer protocol (for example UDP or TCP) inside
ESP and then prepends a cleartext IP header.
3.2.2 Usage of ESP
ESP works between hosts, between a host and a security gateway, or
between security gateways. This support for security gateways permits
trustworthy networks behind a security gateway to omit encryption and
thereby avoid the performance and monetary costs of encryption, while
still providing confidentiality for traffic transiting untrustworthy
network segments. When both hosts directly implement ESP and there
is no intervening security gateway, then they may use the Transportmode (where only the upper layer protocol data (e.g., TCP or UDP) is
encrypted and there is no encrypted IP header). This mode reduces
both the bandwidth consumed and the protocol processing costs for
users that don't need to keep the entire IP datagram confidential.
Atkinson
RFC 1825
Standards Track
[Page 9]
Security Architecture for IP
August 1995
ESP works with both unicast and multicast traffic.
3.2.3 Performance Impacts of ESP
The encapsulating security approach used by ESP can noticeably impact
network performance in participating systems, but use of ESP should
not adversely impact routers or other intermediate systems that are
not participating in the particular ESP association. Protocol
processing in participating systems will be more complex when
encapsulating security is used, requiring both more time and more
processing power. Use of encryption will also increase the
communications latency. The increased latency is primarily due to
the encryption and decryption required for each IP datagram
containing an Encapsulating Security Payload. The precise cost of
ESP will vary with the specifics of the implementation, including the
encryption algorithm, key size, and other factors. Hardware
implementations of the encryption algorithm are recommended when high
throughput is desired.
For interoperability throughout the worldwide Internet, all
conforming implementations of the IP Encapsulating Security Payload
MUST support the use of the Data Encryption Standard (DES) in
Cipher-Block Chaining (CBC) Mode as detailed in the ESP
specification. Other confidentiality algorithms and modes may also
be implemented in addition to this mandatory algorithm and mode.
Export and use of encryption are regulated in some countries [OTA94].
3.3 COMBINING SECURITY MECHANISMS
In some cases the IP Authentication Header might be combined with the
IP Encapsulating Security Protocol to obtain the desired security
properties. The Authentication Header always provides integrity and
authentication and can provide non-repudiation if used with certain
authentication algorithms (e.g., RSA). The Encapsulating Security
Payload always provides integrity and confidentiality and can also
provide authentication if used with certain authenticating encryption
algorithms. Adding the Authentication Header to a IP datagram prior
to encapsulating that datagram using the Encapsulating Security
Protocol might be desirable for users wishing to have strong
integrity, authentication, confidentiality, and perhaps also for
users who require strong non-repudiation. When the two mechanisms
are combined, the placement of the IP Authentication Header makes
clear which part of the data is being authenticated. Details on
combining the two mechanisms are provided in the IP Encapsulating
Security Payload specification [At94b].
Atkinson
Standards Track
[Page 10]
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
APPENDIX AE
RFC 1825
Security Architecture for IP
August 1995
3.4 OTHER SECURITY MECHANISMS
Protection from traffic analysis is not provided by any of the
security mechanisms described above. It is unclear whether
meaningful protection from traffic analysis can be provided
economically at the Internet Layer and it appears that few Internet
users are concerned about traffic analysis. One traditional method
for protection against traffic analysis is the use of bulk link
encryption. Another technique is to send false traffic in order to
increase the noise in the data provided by traffic analysis.
Reference [VK83] discusses traffic analysis issues in more detail.
4. KEY MANAGEMENT
The Key Management protocol that will be used with IP layer security
is not specified in this document. However, because the key
management protocol is coupled to AH and ESP only via the Security
Parameters Index (SPI), we can meaningfully define AH and ESP without
having to fully specify how key management is performed. We envision
that several key management systems will be usable with these
specifications, including manual key configuration. Work is ongoing
within the IETF to specify an Internet Standard key management
protocol.
Support for key management methods where the key management data is
carried within the IP layer is not a design objective for these IPlayer security mechanisms. Instead these IP-layer security
mechanisms will primarily use key management methods where the key
management data will be carried by an upper layer protocol, such as
UDP or TCP, on some specific port number or where the key management
data will be distributed manually.
This design permits clear decoupling of the key management mechanism
from the other security mechanisms, and thereby permits one to
substitute new and improved key management methods without having to
modify the implementations of the other security mechanisms. This
separation of mechanism is clearly wise given the long history of
subtle flaws in published key management protocols [NS78, NS81].
What follows in this section is a brief discussion of a few
alternative approaches to key management. Mutually consenting
systems may additionally use other key management approaches by
private prior agreement.
4.1 Manual Key Distribution
The simplest form of key management is manual key management, where a
person manually configures each system with its own key and also with
the keys of other communicating systems. This is quite practical in
Atkinson
RFC 1825
Standards Track
[Page 11]
Security Architecture for IP
August 1995
small, static environments but does not scale. It is not a viable
medium-term or long-term approach, but might be appropriate and
useful in many environments in the near-term. For example, within a
small LAN it is entirely practical to manually configure keys for
each system. Within a single administrative domain it is practical
to configure keys for each router so that the routing data can be
protected and to reduce the risk of an intruder breaking into a
router. Another case is where an organisation has an encrypting
firewall between the internal network and the Internet at each of its
sites and it connects two or more sites via the Internet. In this
case, the encrypting firewall might selectively encrypt traffic for
other sites within the organisation using a manually configured key,
while not encrypting traffic for other destinations. It also might
be appropriate when only selected communications need to be secured.
4.2 Some Existing Key Management Techniques
There are a number of key management algorithms that have been
described in the public literature. Needham & Schroeder have
proposed a key management algorithm which relies on a centralised key
distribution system [NS78, NS81]. This algorithm is used in the
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
APPENDIX AE
Kerberos Authentication System developed at MIT under Project Athena
[KB93]. Diffie and Hellman have devised an algorithm which does not
require a centralised key distribution system [DH76]. Unfortunately,
the original Diffie-Hellman technique is vulnerable to an active "man
in the middle" attack [Sch93, p. 43-44]. However, this vulnerability
can be mitigated by using signed keys to authentically bootstrap into
the Diffie-Hellman exchange [Sch93, p. 45].
4.3 Automated Key Distribution
Widespread deployment and use of IP security will require an
Internet-standard scalable key management protocol. Ideally such a
protocol would support a number of protocols in the Internet protocol
suite, not just IP security. There is work underway within the IETF
to add signed host keys to the Domain Name System [EK94] The DNS keys
enable the originating party to authenticate key management messages
with the other key management party using an asymmetric algorithm.
The two parties would then have an authenticatible communications
channel that could be used to create a shared session key using
Diffie-Hellman or other means [DH76] [Sch93].
4.4 Keying Approaches for IP
There are two keying approaches for IP. The first approach, called
host-oriented keying, has all users on host 1 share the same key for
use on traffic destined for all users on host 2. The second
approach, called user-oriented keying, lets user A on host 1 have one
Atkinson
RFC 1825
Standards Track
[Page 12]
Security Architecture for IP
August 1995
or more unique session keys for its traffic destined for host 2; such
session keys are not shared with other users on host1. For example,
user A's ftp session might use a different key than user A's telnet
session. In systems claiming to provide multi-level security, user A
will typically have at least one key per sensitivity level in use
(e.g., one key for UNCLASSIFIED traffic, a second key for SECRET
traffic, and a third key for TOP SECRET traffic). Similarly, with
user-oriented keying one might use separate keys for information sent
to a multicast group and control messages sent to the same multicast
group.
In many cases, a single computer system will have at least two
mutually suspicious users A and B that do not trust each other. When
host-oriented keying is used and mutually suspicious users exist, it
is sometimes possible for user A to determine the host-oriented key
via well known methods, such as a Chosen Plaintext attack. Once user
A has improperly obtained the key in use, user A can then either read
user B's encrypted traffic or forge traffic from user B. When useroriented keying is used, certain kinds of attack from one user onto
another user's traffic are not possible.
IP Security is intended to be able to provide Authentication,
Integrity, and Confidentiality for applications operating on
connected end systems when appropriate algorithms are in use.
Integrity and Confidentiality can be provided by host-oriented keying
when appropriate dynamic key management techniques and appropriate
algorithms are in use. However, authentication of principals using
applications on end-systems requires that processes running
applications be able to request and use their own Security
Associations. In this manner, applications can make use of key
distribution facilities that provide authentication.
Hence, support for user-oriented keying SHOULD be present in all IP
implementations, as is described in the "IP Key Management
Requirements" section below.
4.5 Multicast Key Distribution
Multicast key distribution is an active research area in the
published literature as of this writing. For multicast groups having
relatively few members, manual key distribution or multiple use of
existing unicast key distribution algorithms such as modified
Diffie-Hellman appears feasible. For very large groups, new scalable
techniques will be needed. The use of Core-Based Trees (CBT) to
provide session key management as well as multicast routing might be
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
APPENDIX AE
APPENDIX AE
an approach used in the future [BFC93].
Atkinson
RFC 1825
Standards Track
[Page 13]
Security Architecture for IP
August 1995
4.6 IP Key Management Requirements
This section defines key management requirements for all IPv6
implementations and for those IPv4 implementations that implement the
IP Authentication Header, the IP Encapsulating Security Payload, or
both. It applies equally to the IP Authentication Header and the IP
Encapsulating Security Payload.
All such implementations MUST support manual configuration of
Security Associations.
All such implementations SHOULD support an Internet standard Security
Association establishment protocol (e.g., IKMP, Photuris) once such a
protocol is published as an Internet standards-track RFC.
Implementations MAY also support other methods of configuring
Security Associations.
Given two endpoints, it MUST be possible to have more than one
concurrent Security Association for communications between them.
Implementations on multi-user hosts SHOULD support user granularity
(i.e., "user-oriented") Security Associations.
All such implementations MUST permit the configuration of hostoriented keying.
A device that encrypts or authenticates IP packets originated other
systems, for example a dedicated IP encryptor or an encrypting
gateway, cannot generally provide user-oriented keying for traffic
originating on other systems. Such systems MAY additionally
implement support for user-oriented keying for traffic originating on
other systems.
The method by which keys are configured on a particular system is
implementation-defined. A flat file containing security association
identifiers and the security parameters, including the key(s), is an
example of one possible method for manual key distribution. An IP
system MUST take reasonable steps to protect the keys and other
security association information from unauthorised examination or
modification because all of the security lies in the keys.
5. USAGE
This section describes the possible use of the security mechanisms
provided by IP in several different environments and applications in
order to give the implementer and user a better idea of how these
mechanisms can be used to reduce security risks.
Atkinson
RFC 1825
Standards Track
[Page 14]
Security Architecture for IP
August 1995
5.1 USE WITH FIREWALLS
Firewalls are not uncommon in the current Internet [CB94]. While
many dislike their presence because they restrict connectivity, they
are unlikely to disappear in the near future. Both of these IP
mechanisms can be used to increase the security provided by
firewalls.
Firewalls used with IP often need to be able to parse the headers and
options to determine the transport protocol (e.g., UDP or TCP) in use
and the port number for that protocol. Firewalls can be used with
the Authentication Header regardless of whether that firewall is
party to the appropriate Security Assocation, but a firewall that is
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
not party to the applicable Security Association will not normally be
able to decrypt an encrypted upper-layer protocol to view the
protocol or port number needed to perform per-packet filtering OR to
verify that the data (e.g., source, destination, transport protocol,
port number) being used for access control decisions is correct and
authentic. Hence, authentication might be performed not only within
an organisation or campus but also end to end with remote systems
across the Internet. This use of the Authentication Header with IP
provides much more assurance that the data being used for access
control decisions is authentic.
Organisations with two or more sites that are interconnected using
commercial IP service might wish to use a selectively encrypting
firewall. If an encrypting firewall were placed between each site of
a company and the commercial IP service provider, the firewall could
provide an encrypted IP tunnel among all the company's sites. It
could also encrypt traffic between the company and its suppliers,
customers, and other affiliates. Traffic with the Network
Information Center, with public Internet archives, or some other
organisations might not be encrypted because of the unavailability of
a standard key management protocol or as a deliberate choice to
facilitate better communications, improved network performance, and
increased connectivity. Such a practice could easily protect the
company's sensitive traffic from eavesdropping and modification.
Some organisations (e.g., governments) might wish to use a fully
encrypting firewall to provide a protected virtual network over
commercial IP service. The difference between that and a bulk IP
encryption device is that a fully encrypting firewall would provide
filtering of the decrypted traffic as well as providing encryption of
IP packets.
Atkinson
RFC 1825
Standards Track
[Page 15]
Security Architecture for IP
August 1995
5.2 USE WITH IP MULTICAST
In the past several years, the Multicast Backbone (MBONE) has grown
rapidly. IETF meetings and other conferences are now regularly
multicast with real-time audio, video, and whiteboards. Many people
are now using teleconferencing applications based on IP Multicast in
the Internet or in private internal networks. Others are using IP
multicasting to support distributed simulation or other applications.
Hence it is important that the security mechanisms in IP be suitable
for use in an environment where multicast is the general case.
The Security Parameters Indexes (SPIs) used in the IP security
mechanisms are receiver-oriented, making them well suited for use in
IP multicast [Atk95a, Atk95b]. Unfortunately, most currently
published multicast key distribution protocols do not scale well.
However, there is active research in this area. As an interim step,
a multicast group could repeatedly use a secure unicast key
distribution protocol to distribute the key to all members or the
group could pre-arrange keys using manual key distribution.
5.3 USE TO PROVIDE QOS PROTECTION
The recent IAB Security Workshop identified Quality of Service
protection as an area of significant interest [BCCH]. The two IP
security mechanisms are intended to provide good support for realtime services as well as multicasting. This section describes one
possible approach to providing such protection.
The Authentication Header might be used, with appropriate key
management, to provide authentication of packets. This
authentication is potentially important in packet classification
within routers. The IPv6 Flow Identifier might act as a Low-Level
Identifier (LLID). Used together, packet classification within
routers becomes straightforward if the router is provided with the
appropriate keying material. For performance reasons the routers
might authenticate only every Nth packet rather than every packet,
but this is still a significant improvement over capabilities in the
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
APPENDIX AE
current Internet. Quality of service provisioning is likely to also
use the Flow ID in conjunction with a resource reservation protocol,
such as RSVP [ZDESZ93]. Thus, the authenticated packet
classification can be used to help ensure that each packet receives
appropriate handling inside routers.
5.4 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS
A multi-level secure (MLS) network is one where a single network is
used to communicate data at different sensitivity levels (e.g.,
Unclassified and Secret) [DoD85] [DoD87]. Many governments have
Atkinson
RFC 1825
Standards Track
[Page 16]
Security Architecture for IP
August 1995
significant interest in MLS networking [DIA]. The IP security
mechanisms have been designed to support MLS networking. MLS
networking requires the use of strong Mandatory Access Controls
(MAC), which ordinary users are incapable of controlling or violating
[BL73]. This section pertains only to the use of these IP security
mechanisms in MLS environments.
The Authentication Header can be used to provide strong
authentication among hosts in a single-level network. The
Authentication Header can also be used to provide strong assurance
for both mandatory access control decisions in multi-level networks
and discretionary access control decisions in all kinds of networks.
If explicit IP sensitivity labels (e.g., IPSO) [Ken91] are used and
confidentiality is not considered necessary within the particular
operational environment, the Authentication Header is used to provide
authentication for the entire packet, including cryptographic binding
of the sensitivity level to the IP header and user data. This is a
significant improvement over labeled IPv4 networks where the label is
trusted even though it is not trustworthy because there is no
authentication or cryptographic binding of the label to the IP header
and user data. IPv6 will normally use implicit sensitivity labels
that are part of the Security Association but not transmitted with
each packet instead of using explicit sensitivity labels. All
explicit IP sensitivity labels MUST be authenticated using either
ESP, AH, or both.
The Encapsulating Security Payload can be combined with appropriate
key policies to provide full multi-level secure networking. In this
case each key must be used only at a single sensitivity level and
compartment. For example, Key "A" might be used only for sensitive
Unclassified packets, while Key "B" is used only for Secret/Nocompartments traffic, and Key "C" is used only for Secret/No-Foreign
traffic. The sensitivity level of the protected traffic MUST NOT
dominate the sensitivity level of the Security Association used with
that traffic. The sensitivity level of the Security Association MUST
NOT dominate the sensitivity level of the key that belongs to that
Security Association. The sensitivity level of the key SHOULD be the
same as the sensitivity level of the Security Association. The
Authentication Header can also have different keys for the same
reasons, with the choice of key depending in part on the sensitivity
level of the packet.
Encryption is very useful and desirable even when all of the hosts
are within a protected environment. The Internet-standard encryption
algorithm could be used, in conjunction with appropriate key
management, to provide strong Discretionary Access Controls (DAC) in
conjunction with either implicit sensitivity labels or explicit
sensitivity labels (such as IPSO provides for IPv4 [Ken91]). Some
Atkinson
RFC 1825
Standards Track
[Page 17]
Security Architecture for IP
August 1995
environments might consider the Internet-standard encryption
algorithm sufficiently strong to provide Mandatory Access Controls
(MAC). Full encryption SHOULD be used for all communications between
multi-level computers or compartmented mode workstations even when
the computing environment is considered to be protected.
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
APPENDIX AE
APPENDIX AE
6. SECURITY CONSIDERATIONS
This entire memo discusses the Security Architecture for the Internet
Protocol. It is not a general security architecture for the
Internet, but is instead focused on the IP layer.
Cryptographic transforms for ESP which use a block-chaining algorithm
and lack a strong integrity mechanism are vulnerable to a cut-andpaste attack described by Bellovin and should not be used unless the
Authentication Header is always present with packets using that ESP
transform [Bel95].
If more than one sender uses shares a Security Association with a
destination, then the receiving system can only authenticate that the
packet was sent from one of those systems and cannot authenticate
which of those systems sent it. Similarly, if the receiving system
does not check that the Security Association used for a packet is
valid for the claimed Source Address of the packet, then the
receiving system cannot authenticate whether the packet's claimed
Source Address is valid. For example, if senders "A" and "B" each
have their own unique Security Association with destination "D" and
"B" uses its valid Security Association with D but forges a Source
Address of "A", then "D" will be fooled into believing the packet
came from "A" unless "D" verifies that the claimed Source Address is
party to the Security Association that was used.
Users need to understand that the quality of the security provided by
the mechanisms provided by these two IP security mechanisms depends
completely on the strength of the implemented cryptographic
algorithms, the strength of the key being used, the correct
implementation of the cryptographic algorithms, the security of the
key management protocol, and the correct implementation of IP and the
several security mechanisms in all of the participating systems. The
security of the implementation is in part related to the security of
the operating system which embodies the security implementations.
For example, if the operating system does not keep the private
cryptologic keys (that is, all symmetric keys and the private
asymmetric keys) confidential, then traffic using those keys will not
be secure. If any of these is incorrect or insufficiently secure,
little or no real security will be provided to the user. Because
different users on the same system might not trust each other, each
user or each session should usually be keyed separately. This will
Atkinson
RFC 1825
Standards Track
[Page 18]
Security Architecture for IP
August 1995
also tend to increase the work required to cryptanalyse the traffic
since not all traffic will use the same key.
Certain security properties (e.g., traffic analysis protection) are
not provided by any of these mechanisms. One possible approach to
traffic analysis protection is appropriate use of link encryption
[VK83]. Users must carefully consider which security properties they
require and take active steps to ensure that their needs are met by
these or other mechanisms.
Certain applications (e.g., electronic mail) probably need to have
application-specific security mechanisms. Application-specific
security mechanisms are out of the scope of this document. Users
interested in electronic mail security should consult the RFCs
describing the Internet's Privacy-Enhanced Mail system. Users
concerned about other application-specific mechanisms should consult
the online RFCs to see if suitable Internet Standard mechanisms
exist.
ACKNOWLEDGEMENTS
Many of the concepts here are derived from or were influenced by the
US Government's SDNS security protocol specifications, the ISO/IEC's
NLSP specification, or from the proposed swIPe security protocol
[SDNS, ISO, IB93, IBK93]. The work done for SNMP Security and SNMPv2
Security influenced the choice of default cryptological algorithms
and modes [GM93]. Steve Bellovin, Steve Deering, Richard Hale,
George Kamis, Phil Karn, Frank Kastenholz, Perry Metzger, Dave
Mihelcic, Hilarie Orman and Bill Simpson provided careful critiques
of early versions of this document.
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
APPENDIX AE
REFERENCES
[Atk95a] Atkinson, R., "IP Authentication Header", RFC 1826, NRL,
August 1995.
[Atk95b] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
NRL, August 1995.
[BCCH94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
of IAB Workshop on Security in the Internet Architecture",
RFC 1636, USC/Information Sciences Institute, MIT, Trusted
Information Systems, INRIA, June 1994.
[Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP
Protocol Suite", ACM Computer Communications Review, Vol. 19,
No. 2, March 1989.
Atkinson
RFC 1825
Standards Track
[Page 19]
Security Architecture for IP
August 1995
[Bel95] Steven M. Bellovin, Presentation at IP Security Working
Group Meeting, Proceedings of the 32nd Internet Engineering
Task Force, March 1995, Internet Engineering Task Force,
Danvers, MA.
[BFC93] A. Ballardie, P. Francis, & J. Crocroft, "Core Based Trees:
An Architecture for Scalable Inter-Domain Multicast Routing",
Proceedings of ACM SIGCOMM 93, ACM Computer Communications
Review, Volume. 23, Number 4, October 1993, pp. 85-95.
[BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems:
Mathematical Foundations and Model", Technical Report
M74-244, The MITRE Corporation, Bedford, MA, May 1973.
[CB94] William R. Cheswick & Steven M. Bellovin, Firewalls &
Internet Security, Addison-Wesley, Reading, MA, 1994.
[DIA] US Defense Intelligence Agency, "Compartmented Mode
Workstation Specification", Technical Report
DDS-2600-6243-87.
[DoD85] US National Computer Security Center, "Department of Defense
Trusted Computer System Evaluation Criteria", DoD
5200.28-STD, US Department of Defense, Ft. Meade, MD.,
December 1985.
[DoD87] US National Computer Security Center, "Trusted Network
Interpretation of the Trusted Computer System Evaluation
Criteria", NCSC-TG-005, Version 1, US Department of Defense,
Ft. Meade, MD., 31 July 1987.
[DH76] W. Diffie & M. Hellman, "New Directions in Cryptography",
IEEE Transactions on Information Theory, Vol. IT-22, No. 6,
November 1976, pp. 644-654.
[EK94] D. Eastlake III & C. Kaufman, "Domain Name System Protocol
Security Extensions", Work in Progress.
[GM93] Galvin J., and K. McCloghrie, "Security Protocols for
version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN
Systems, April 1993.
[HA94] Haller, N., and R. Atkinson, "On Internet Authentication",
RFC 1704, Bell Communications Research, NRL, October 1994.
[Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6)
Specification, Work in Progress, October 1994.
Atkinson
RFC 1825
Standards Track
[Page 20]
Security Architecture for IP
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
August 1995
[ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
DIS 11577, International Standards Organisation, Geneva,
Switzerland, 29 November 1992.
[IB93] John Ioannidis and Matt Blaze, "Architecture and
Implementation of Network-layer Security Under Unix",
Proceedings of USENIX Security Symposium, Santa Clara, CA,
October 1993.
[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer
Security for IP", presentation at the Spring 1993 IETF Meeting,
Columbus, Ohio.
[Ken91] Kent, S., "US DoD Security Options for the Internet Protocol",
RFC 1108, BBN Communications, November 1991.
[Ken93] Kent, S., "Privacy Enhancement for Internet Electronic Mail:
Part II: Certificate-Based Key Management", RFC 1422,
BBN Communications, February 1993.
[KB93] Kohl, J., and B. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, Digital Equipment Corporation,
USC/Information Sciences Institute, September 1993.
[MS95] Metzger, P., and W. Simpson, "IP Authentication with Keyed
MD5", RFC 1828, Piermont, Daydreamer, August 1995.
[KMS95] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC
Transform", RFC 1829, Qualcomm, Inc., Piermont, Daydreamer,
August 1995.
[NS78] R.M. Needham & M.D. Schroeder, "Using Encryption for
Authentication in Large Networks of Computers", Communications
of the ACM, Vol. 21, No. 12, December 1978, pp. 993-999.
[NS81] R.M. Needham & M.D. Schroeder, "Authentication Revisited",
ACM Operating Systems Review, Vol. 21, No. 1., 1981.
[OTA94] US Congress, Office of Technology Assessment, "Information
Security & Privacy in Network Environments", OTA-TCT-606,
Government Printing Office, Washington, DC, September 1994.
[Sch94] Bruce Schneier, Applied Cryptography, Section 8.6,
John Wiley & Sons, New York, NY, 1994.
Atkinson
RFC 1825
Standards Track
[Page 21]
Security Architecture for IP
August 1995
[SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3,
Document SDN.301, Revision 1.5, 15 May 1989, published
in NIST Publication NIST-IR-90-4250, February 1990.
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level
Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
[ZDESZ93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and
D. Zappala, "RSVP: A New Resource ReSerVation Protocol",
IEEE Network magazine, September 1993.
DISCLAIMER
The views expressed in this note are those of the author and are not
necessarily those of his employer. The Naval Research Laboratory has
not passed judgement on the merits, if any, of this work. The author
and his employer specifically disclaim responsibility for any problems
arising from correct or incorrect implementation or use of this
design.
AUTHOR'S ADDRESS
Randall Atkinson
Information Technology Division
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
APPENDIX AE
APPENDIX AE
Naval Research Laboratory
Washington, DC 20375-5320
USA
Phone: (202) 767-2389
Fax: (202) 404-8590
EMail: atkinson@itd.nrl.navy.mil
Atkinson
Standards Track
[Page 22]
https://www.ietf.org/rfc/rfc1825.txt[3/19/2017 2:09:10 PM]
Appendix AF
Intentionally Left Blank
APPENDIX AG
TECHNICAL BRIEF
Configuring a Wireless Distribution System (WDS)
with the 3Com® OfficeConnect® Wireless 11a/b/g Access Point
Overview
This document explains the WDS
(Wireless Distribution System)
features provided by the 3Com®
OfficeConnect® Wireless 11a/b/g
Access Point (3CRWE454A72). These
features allow you to build a completely wireless infrastructure
because the network equipment no
Point-to-Point WDS Link
Point-to-Multipoint WDS Link
longer has to be connected to a wired
LAN. Also, WDS features allow you to
create large wireless networks by
linking several wireless access points
with WDS links. WDS is normally
used in large, open areas where
pulling wires is cost prohibitive,
restricted or physically impossible.
APPENDIX AG
3COM® CONFIGURING A WIRELESS DISTRIBUTION SYSTEM TECHNICAL BRIEF
Figure 1: WDS Configurations
Repeater WDS Link
Wireless Bridge and
Wireless Repeater
As shown in Figure 1, WDS can be
deployed in several configurations. In
this document, we will introduce two
basic WDS configurations: a wireless
bridge and wireless repeater.
Wireless Bridge
The wireless distribution system
shown in Figure 2 is often called a
“wireless bridge” configuration,
because it allows you to connect two
LANs at the link layer. In Figure 2, the
access point (AP) behaves as a standard
bridge that forwards traffic between
WDS links (links that connect to other
AP/wireless bridges) and an Ethernet
port. As a standard bridge, the access
point learns MAC addresses of up to
64 wireless and/or 128 total wired
and wireless network devices, which
are connected to their respective
Ethernet ports to limit the amount of
data to be forwarded. Only data destined for stations which are known to
reside on the peer Ethernet link, multicast data or data with unknown
destinations need to be forwarded to
the peer AP via the WDS link.
Figure 2: Wireless Bridge Configuration
802.3 Ethernet frame
802.11 four-address format frame
WDS link
2
APPENDIX AG
3COM® CONFIGURING A WIRELESS DISTRIBUTION SYSTEM TECHNICAL BRIEF
If, for example, an 802.3 Ethernet
frame is sent from a wired Station 1
(Sta1) to Sta3 in Figure 2, frame translations are required while the frame
forwards through the WDS link
between AP1 and AP2. When AP1
receives the 802.3 frame, the frame is
translated to a IEEE 802.11 standard
four-address format frame before it is
sent to a WDS link. In the fouraddress format frame, the MAC
address of Sta1, MAC address of AP1,
MAC address of AP2 and MAC
address of Sta3 are all included in the
Figure 3: Wireless Repeater Configuration
802.11 frame header, and the frame
data is same as the original Ethernet
frame. Based on information in this
four-address format frame, AP2 will
reconstruct the 802.3 Ethernet frame
when the frame is forwarded to
LAN2. If a security algorithm is configured on the APs, AP1(AP2) will
encrypt(decrypt) this four-address
format frame before frame forwarding. From Sta3’s point of view, the
bridging function is transparent; i.e.,
the received frame is the same as if
Sta1 and Sta3 resided on the same LAN.
802.3 Ethernet frame
802.11 three-address format frame
802.11 four-address format frame
WDS link
Wireless Repeater
In Figure 3, AP2 is used to extend the
range of the wireless infrastructure by
forwarding traffic between associated
wireless stations and another repeater
or AP connected to the wired LAN.
Note that the local Ethernet traffic is
not forwarded in this mode. Traffic
between Sta3 and Sta4 is not forwarded across the WDS link, nor is
traffic between Sta5 and Sta6. As
with a wireless bridge mode, APs
operating in wireless repeater mode
need to translate frames into different
frame formats when forwarding
frames between wireless connections
and WDS links; the 802.11 three-address
frame format is used on wireless links
connected to wireless stations, while
the 802.3 four-address frame format is
used on WDS links connected to
other access points. Encryption/
decryption algorithms are also invoked
if the AP is configured to be secure.
The OfficeConnect Wireless 11a/b/g
Access Point can function as a wireless
repeater or wireless bridge if WDS
links are configured between the connected AP pairs appropriately.
3
APPENDIX AG
3COM® CONFIGURING A WIRELESS DISTRIBUTION SYSTEM TECHNICAL BRIEF
Configuring
WDS Links on
3Com OfficeConnect
Wireless 11a/b/g
Access Points
A WDS link is defined as the MAC
address pair of the connected APs.
To create a WDS link between two
OfficeConnect Wireless 11a/b/g
Access Points, enter the peer AP’s
MAC address on each AP via the
Wireless WDS web page.
In addition, make sure you configure
all WDS APs to work on the same
radio channel. Since WDS links can
operate in 2.4GHZ or 5.4 GHZ radio
channels, using Auto Channel selection is not appropriate.
Below is an example of configuring a WDS.
We will use example AP1 and AP2
with the following MAC addresses
(see these MAC addresses in the status
page):
AP1
LAN MAC Address:
00-70-46-01-23-45
11a WLAN MAC Address:
00-70-46-01-23-46
11b/g WLAN MAC Address:
00-70-46-01-23-47
AP2
LAN MAC Address:
00-70-46-01-33-62
11a WLAN MAC Address:
00-70-46-01-33-63
11b/g WLAN MAC Address:
00-70-46-01-33-64
To add a WDS link between AP1 and
AP2 in 802.11a mode with channel 60
selected:
2. On the WDS page of AP1, enable
WDS and enter AP2 WLAN MAC
address (00-70-46-01-33-63) with
802.11a mode in a WDS entry as
shown in Figure 4.
1. On the wireless page of AP1,enable
802.11a and select channel 60.
4
APPENDIX AG
3COM® CONFIGURING A WIRELESS DISTRIBUTION SYSTEM TECHNICAL BRIEF
Figure 4: Configuring WDS
Links on AP1
3. On the wireless page of AP2,
enable 802.11a standard and
select channel 60.
4. On the WDS page of AP2, enable
WDS and enter AP1 WLAN MAC
address (00-70-46-01-23-46) with
802.11a mode in a WDS entry as
shown in Figure 5.
Figure 5: Configuring WDS
Links on AP2
5
APPENDIX AG
3COM® CONFIGURING A WIRELESS DISTRIBUTION SYSTEM TECHNICAL BRIEF
Pay special attention to avoid the
creation of network loops in the
network topology while configuring
WDS links. If a loop exists in the
network, data could be forwarded
and duplicated endlessly between
APs. This could crash networks.
Several abnormal loops likely created
in a WDS configuration are shown in
Figure 6.
Security
Spanning Tree Algorithm
Currently, the OfficeConnect Wireless
11a/b/g Access Point can support
secured WDS links in WEP mode. In
version 1.01, WEP keys must be the
same for both radios in the AP,
whether WEP or normal access, and
all APs in the system need to have
the same keys.
As the OfficeConnect Wireless
11a/b/g Access Point doesn’t implement the Spanning Tree algorithm,
WDS links should be configured
appropriately to prevent loops in the
network.
Figure 6: Loops in Wireless Networks with WDS links
Warnings
3Com Corporation, Corporate Headquarters, 350 Campus Drive, Marlborough, MA 01752-3064
To learn more about 3Com solutions, visit www.3com.com. 3Com is publicly traded on NASDAQ under the symbol COMS.
Copyright © 2004 3Com Corporation. All rights reserved. 3Com, the 3Com logo, and OfficeConnect are registered trademarks of 3Com Corporation. Possible made practical is a trademark of 3Com Corporation. All other company and product
names may be trademarks of their respective companies. While every effort is made to ensure the information given is
accurate, 3Com does not accept liability for any errors or mistakes which may arise. Specifications and other information
in this document may be subject to change without notice.
Printed in the U.S. on recycled paper
104108-001 05/04
Download PDF
Similar pages