draft-ietf-mobileip-ip4inip4-01.txt   draft-ietf-mobileip-ip4inip4-02.txt 
Internet Engineering Task Force C. Perkins Internet Engineering Task Force C. Perkins
INTERNET DRAFT IBM INTERNET DRAFT IBM
21 October 1995 10 May 1996
IP Encapsulation within IP IP Encapsulation within IP
draft-ietf-mobileip-ip4inip4-01.txt draft-ietf-mobileip-ip4inip4-02.txt
Status of This Memo Status of This Memo
This document is a submission by the Mobile-IP Working Group of the This document is a submission by the Mobile-IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the mobile-ip@tadpole.com mailing list. to the mobile-ip@SmallWorks.com mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet Drafts are working This document is an Internet-Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents months, and may be updated, replaced, or obsoleted by other documents
skipping to change at page 1, line 39 skipping to change at page 1, line 39
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the internet-drafts the ``1id-abstracts.txt'' listing contained in the internet-drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Rim).
Abstract Abstract
This document specifies a method by which an IP datagram may This document specifies a method by which an IP datagram may
be encapsulated (carried as payload) within an IP datagram. be encapsulated (carried as payload) within an IP datagram.
Encapsulation is suggested as a means to effect "re-addressing" Encapsulation is suggested as a means to alter the normal IP routing
datagrams (i.e., delivering them to an intermediate destination for datagrams, by delivering them to an intermediate destination
other than that specified in the IP destination field) for any of a which would not be otherwise selected by the (network part of the)
variety of reasons, but particularly those useful for adherence to IP destination field. This may be done for any of a variety of
the mobile-IP specification. reasons, but is particular useful for adherence to the mobile-IP
specification.
1. Introduction 1. Introduction
This document specifies a method by which an IP datagram may This document specifies a method by which an IP datagram may
be encapsulated (carried as payload) within an IP datagram. be encapsulated (carried as payload) within an IP datagram.
Encapsulation is suggested as a means to effect "re-addressing" Encapsulation is suggested as a means to alter the normal IP routing
datagrams -- that is, delivering them to an intermediate destination for datagrams, by delivering them to an intermediate destination
other than that specified in the IP destination field. The process which would not be otherwise selected based the (network part of the)
of encapsulation and decapsulation a datagram is frequently referred IP destination field. The process of encapsulation and decapsulation
to as "tunneling" the datagram, and the encapsulator and decapsulator a datagram is frequently referred to as "tunneling" the datagram, and
are then considered to be the the "endpoints" of the tunnel. the encapsulator and decapsulator are then considered to be the the
"endpoints" of the tunnel.
In the most general encapsulation case we have In the most general encapsulation case we have
source ----> encapsulator --------> decapsulator ----> destination
source ---> encapsulator --------> decapsulator ---> destination
with these being separate machines. There may in general be multiple with these being separate machines. There may in general be multiple
source-destination pairs using the same tunnel. source-destination pairs using the same tunnel.
2. Motivation 2. Motivation
The mobile-IP working group has specified the use of encapsulation as The mobile-IP working group has specified the use of encapsulation
a way to deliver packets from a mobile host's "home network" to an as a way to deliver datagrams from a mobile host's "home network"
agent which can deliver packets to the mobile host by conventional to an agent which can deliver datagrams to the mobile host by
means [4]. The use of encapsulation may also be desirable whenever conventional means [7]. The use of encapsulation may also be
the source (or an intermediate router) of an IP datagram must desirable whenever the source (or an intermediate router) of an
influence the route by which a datagram is to be delivered to IP datagram must influence the route by which a datagram is to be
its ultimate destination. Other possible applications include delivered to its ultimate destination. Other possible applications
preferential billing, choice of routes with selected security include preferential billing, choice of routes with selected security
attributes, and general policy routing. attributes, and general policy routing.
It is generally true that encapsulation and source routing techniques It is generally true that encapsulation and source routing techniques
can both be used to re-address datagrams whenever that is necessary, can be used in similar ways to affect the routing of a datagram, but
but there are several technical reasons to prefer encapsulation: there are several technical reasons to prefer encapsulation:
- There are unsolved security problems associated with the use of - There are unsolved security problems associated with the use of
source routing. source routing.
- Current internet routers exhibit performance problems when - Current internet routers exhibit performance problems when
forwarding packets which use the IP source routing option. forwarding datagrams which use the IP source routing option.
- Too many internet hosts process source routing options - Too many internet hosts process source routing options
incorrectly. incorrectly.
- Firewalls may exclude source-routed packets. - Firewalls may exclude source-routed datagrams.
- Insertion of an IP source route option may complicate the - Insertion of an IP source route option may complicate the
processing of authentication information by the source and/or processing of authentication information by the source and/or
destination of a datagram, depending on how the authentication is destination of a datagram, depending on how the authentication is
specified to be performed. specified to be performed.
- It is considered impolite for intermediate routers to make - It is considered impolite for intermediate routers to make
modifications to the packets which they did not originate. modifications to datagrams which they did not originate.
These technical advantages must be weighed against the disadvantages These technical advantages must be weighed against the disadvantages
posed by the use of encapsulation: posed by the use of encapsulation:
- Encapsulated packets typically are longer than source routed - Encapsulated datagrams typically are longer than source routed
packets. datagrams.
- Encapsulation cannot be used unless it is known in advance that - Encapsulation cannot be used unless it is known in advance that
the tunnel endpoint for the encapsulated datagram can decapsulate the tunnel endpoint for the encapsulated datagram can decapsulate
the packet. the datagram.
Since the majority of internet hosts today do not perform well Since the majority of internet hosts today do not perform well
when IP loose source route options are used, the second technical when IP loose source route options are used, the second technical
disadvantage of encapsulation is not as serious as it might seem at disadvantage of encapsulation is not as serious as it might seem at
first. first.
3. IP in IP Encapsulation 3. IP in IP Encapsulation
An outer IP header is inserted before the datagram's IP header: An outer IP header is inserted before the datagram's IP header:
skipping to change at page 2, line 45 skipping to change at page 2, line 50
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
The format of the IP header is described in RFC 791[9]. The outer The format of the IP header is described in RFC 791[9]. The outer
IP header source and destination addresses identify the "endpoints" IP header source and destination addresses identify the "endpoints"
of the tunnel. The inner IP header source and destination addresses of the tunnel. The inner IP header source and destination addresses
identify the sender and recipient of the datagram. The inner IP identify the sender and recipient of the datagram. The inner IP
header is not changed by the node which encapsulates it, except header is not changed by the node which encapsulates it, except
to decrement the TTL before delivery. The inner header remains to decrement the TTL before delivery. The inner header remains
unchanged during its delivery to the tunnel endpoint. No change unchanged during its delivery to the tunnel endpoint. No change
to IP options in the inner header occurs during delivery of the to IP options in the inner header occurs during delivery of the
encapsulated packet through the tunnel. 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 (also see
section 6.3).
3.1. IP Header Fields and Handling 3.1. IP Header Fields and Handling
Version Version
4 4
IHL IHL
The Internet Header Length measures the length (in bytes) of The Internet Header Length measures the length (in bytes) of
the outer IP header exclusive of its payload, but including any the outer IP header exclusive of its payload, but including any
options which the encapsulating agent may insert. options which the encapsulating agent may insert.
TOS TOS
The type of service is copied from the inner IP header. The type of service is copied from the inner IP header.
Total Length Total Length
The length measures the length of the outer IP header along The length measures the length of the outer IP header along
with its payload, that is to say the inner IP header and the with its payload, that is to say (typically) the inner IP
original datagram. header and the original datagram.
Identification
Flags
Fragment Offset Identification, Flags, Fragment Offset
These three fields are set in accordance with the procedures These three fields are set in accordance with the procedures
specified in [9]. The "Don't Fragment" bit in the outer IP specified in [9]. The "Don't Fragment" bit in the outer IP
header is copied from the corresponding flag in the inner IP header is copied from the corresponding flag in the inner IP
header. header.
Time to Live Time to Live
The Time To Live (TTL) field in the outer IP header is set to a The Time To Live (TTL) field in the outer IP header is set to a
value appropriate for delivery of the encapsulated datagram to value appropriate for delivery of the encapsulated datagram to
skipping to change at page 4, line 31 skipping to change at page 4, line 31
Options Options
not copied from the inner IP header. However, new options not copied from the inner IP header. However, new options
particular to the path MAY be added. In particular, any particular to the path MAY be added. In particular, any
supported flavors of security options of the inner IP header supported flavors of security options of the inner IP header
MAY affect the choice of security options for the tunnel. It MAY affect the choice of security options for the tunnel. It
is not expected that there be a one-to-one mapping of such is not expected that there be a one-to-one mapping of such
options to the options or security headers selected for the options to the options or security headers selected for the
tunnel. tunnel.
The inner TTL is decremented by one. If the resulting TTL is 0, The inner TTL is decremented by one. If the resulting TTL is
the datagram is not tunneled. An encapsulating agent MUST NOT 0, the datagram is not tunneled. An encapsulating agent MUST
encapsulate a packet with TTL = 0 for delivery to a tunnel endpoint. NOT encapsulate a datagram with TTL = 0 for delivery to a tunnel
The TTL is not changed when decapsulating. If, after decapsulation, endpoint. The TTL is not changed when decapsulating. If, after
the inner packet has TTL zero, a tunnel endpoint MUST discard the decapsulation, the inner datagram has TTL zero, a tunnel endpoint
packet. If the decapsulator forwards the datagram to some network MUST discard the datagram. If the decapsulator forwards the datagram
interface, it will decrement the TTL as a result of doing normal IP to some network interface, it will decrement the TTL as a result of
forwarding. See also subsection 4.4. doing normal IP forwarding. See also subsection 4.4.
The encapsulating agent is free to use any existing IP mechanisms The encapsulating agent is free to use any existing IP mechanisms
appropriate for delivery of the encapsulated payload to the tunnel appropriate for delivery of the encapsulated payload to the tunnel
endpoint. In particular, this means that use of IP options and endpoint. In particular, this means that use of IP options and
fragmentation are allowed, unless the "Don't Fragment" bit is set in fragmentation are allowed, unless the "Don't Fragment" bit is set in
the inner IP header. This is required so that hosts employing Path the inner IP header. This is required so that hosts employing Path
MTU discovery [7] can obtain the information they seek. MTU discovery [6] can obtain the information they seek.
3.2. Routing Failures 3.2. Routing Failures
Routing loops within a tunnel are particularly dangerous when they Routing loops within a tunnel are particularly dangerous when
arrive again at the encapsulator. If the IP Source matches any of they cause datagrams to arrive again at the encapsulator. If the
its interfaces, an implementation MUST NOT further encapsulate. If IP Source matches any of its interfaces, an implementation MUST
the IP Source matches the tunnel destination, an implementation NOT further encapsulate. If the IP Source matches the tunnel
SHOULD NOT further encapsulate. See also subsection 4.4. destination, an implementation SHOULD NOT further encapsulate. See
also subsection 4.4.
4. ICMP messages from within the tunnel 4. ICMP messages from within the tunnel
After an encapsulated datagram has been sent, the encapsulating After an encapsulated datagram has been sent, the encapsulating
agent may receive an ICMP [8] message from any intermediate router agent may receive an ICMP [8] message from any intermediate router
within the tunnel, except for the tunnel endpoint. The action taken within the tunnel, except for the tunnel endpoint. The action taken
by the encapsulating agent depends on the type of ICMP message by the encapsulating agent depends on the type of ICMP message
received. When the received message contains enough information, the received. When the received message contains enough information, the
encapsulating agent may use the incoming message to create a similar encapsulating agent may use the incoming message to create a similar
ICMP message, to be sent to the originator of the inner IP datagram. ICMP message, to be sent to the originator of the inner IP datagram.
skipping to change at page 5, line 38 skipping to change at page 5, line 39
original destination in the unencapsulated datagram is on the same original destination in the unencapsulated datagram is on the same
network as the encapsulating agent, certain Destination Unreachable network as the encapsulating agent, certain Destination Unreachable
codes may be modified to conform to the suggested model. codes may be modified to conform to the suggested model.
Network Unreachable (Code 0) Network Unreachable (Code 0)
A Destination Unreachable message may be returned to A Destination Unreachable message may be returned to
the original sender. If the original destination in the original sender. If the original destination in
the unencapsulated datagram is on the same network as the unencapsulated datagram is on the same network as
the encapsulating agent, the newly generated Destination the encapsulating agent, the newly generated Destination
Unreachable message sent by the encapsulating agent can have Unreachable message sent by the encapsulating agent MAY have
code 1 (Host Unreachable), since presumably the packet arrived code 1 (Host Unreachable), since presumably the datagram
to the correct network and the encapsulating agent is trying to arrived to the correct network and the encapsulating agent is
create the appearance that the original destination is local trying to create the appearance that the original destination
even if it's not. Otherwise, the encapsulating agent must is local even if it's not. Otherwise, the encapsulating agent
return a Destination Unreachable with code 0 message to the must return a Destination Unreachable with code 0 message to
original sender. the original sender.
Host Unreachable (Code 1) Host Unreachable (Code 1)
The encapsulating agent must relay Host Unreachable messages to The encapsulating agent must relay Host Unreachable messages to
the source of the original unencapsulated datagram. the source of the original unencapsulated datagram.
Protocol Unreachable (Code 2) Protocol Unreachable (Code 2)
When the encapsulating agent receives a Protocol Unreachable When the encapsulating agent receives a Protocol Unreachable
ICMP message, it should send a Destination Unreachable message ICMP message, it should send a Destination Unreachable message
skipping to change at page 6, line 34 skipping to change at page 6, line 39
the source of the original unencapsulated datagram. the source of the original unencapsulated datagram.
Source Route Failed (Code 5) Source Route Failed (Code 5)
This code should be treated by the encapsulating agent This code should be treated by the encapsulating agent
itself. It must not be relayed to the source of the original itself. It must not be relayed to the source of the original
unencapsulated datagram. unencapsulated datagram.
4.2. Source Quench (Type 4) 4.2. Source Quench (Type 4)
The encapsulating agent may relay Source Quench messages to the The encapsulating agent SHOULD NOT relay Source Quench messages to
source of the original unencapsulated datagram. the source of the original unencapsulated datagram, but instead
activate whatever congestion control mechanisms it implements to
alleviate the congestion detected within the tunnel.
4.3. Redirect (Type 5) 4.3. Redirect (Type 5)
The encapsulating agent may act on the Redirect message if it is The encapsulating agent may act on the Redirect message if it is
possible, but it should not relay the Redirect back to the source of possible, but it should not relay the Redirect back to the source of
the datagram which was encapsulated. the datagram which was encapsulated.
4.4. Time Exceeded (Type 11) 4.4. Time Exceeded (Type 11)
ICMP Time Exceeded messages report routing loops within the tunnel ICMP Time Exceeded messages report routing loops within the tunnel
itself. Reception of Time Exceeded messages by the encapsulator itself. Reception of Time Exceeded messages by the encapsulator MUST
MUST be reported to the originator as Host Unreachable (Type 3 Code be reported to the originator as Host Unreachable (Type 3 Code 1).
1). Host Unreachable is preferable to Network Unreachable; since the Host Unreachable is preferable to Network Unreachable; since the
packet was handled by the encapsulator, and the encapsulator is often datagram was handled by the encapsulator, and the encapsulator is
considered to be on the same network as the destination address in often considered to be on the same network as the destination address
the original unencapsulated packet, the packet is considered to have in the original unencapsulated datagram, the datagram is considered
reached the correct network, but not the correct destination host to have reached the correct network, but not the correct destination
within that network. host within that network.
4.5. Parameter Problem (Type 12) 4.5. Parameter Problem (Type 12)
If the parameter problem points to a field copied from the original If the parameter problem points to a field copied from the original
unencapsulated datagram, the encapsulating agent may relay the ICMP unencapsulated datagram, the encapsulating agent may relay the ICMP
message to the source; otherwise, if the problem occurs with an IP message to the source; otherwise, if the problem occurs with an IP
option inserted by the encapsulating agent, then the encapsulating option inserted by the encapsulating agent, then the encapsulating
agent must not relay the ICMP message to the source. Note that an agent must not relay the ICMP message to the source. Note that an
encapsulating agent following prevalent current practice will never encapsulating agent following prevalent current practice will never
insert any IP options into the encapsulated datagram, except possibly insert any IP options into the encapsulated datagram, except possibly
skipping to change at page 7, line 32 skipping to change at page 7, line 40
Other ICMP messages are not related to the encapsulation operations Other ICMP messages are not related to the encapsulation operations
described within this protocol specification, and should be acted on described within this protocol specification, and should be acted on
as specified in [8]. as specified in [8].
5. Tunnel Management 5. Tunnel Management
Unfortunately, ICMP only requires IP routers to return 8 bytes (64 Unfortunately, ICMP only requires IP routers to return 8 bytes (64
bits) of the datagram beyond the IP header. This is not enough to bits) of the datagram beyond the IP header. This is not enough to
include the encapsulated header, so it is not always possible for the include the encapsulated header, so it is not always possible for the
home agent to immediately reflect the ICMP message from the interior home agent to immediately reflect the ICMP message from the interior
of a tunnel back to the source host. of a tunnel back to the originating host.
However, by carefully maintaining "soft state" about its tunnels, However, by carefully maintaining "soft state" about its tunnels,
the encapsulating router can return accurate ICMP messages in most the encapsulating router can return accurate ICMP messages in most
cases. The router SHOULD maintain at least the following soft state cases. The router SHOULD maintain at least the following soft state
information about each tunnel: information about each tunnel:
- MTU of the tunnel (subsection 5.1) - MTU of the tunnel (subsection 5.1)
- TTL (path length) of the tunnel - TTL (path length) of the tunnel
- Reachability of the end of the tunnel - Reachability of the end of the tunnel
skipping to change at page 8, line 33 skipping to change at page 8, line 33
would violate the state of the tunnel (such as, the TTL is less than would violate the state of the tunnel (such as, the TTL is less than
the tunnel TTL) the router sends an ICMP error message back to the the tunnel TTL) the router sends an ICMP error message back to the
source, but also forwards the datagram into the tunnel. source, but also forwards the datagram into the tunnel.
Using this technique, the ICMP error messages sent by encapsulating Using this technique, the ICMP error messages sent by encapsulating
routers will not always match up one-to-one with errors encountered routers will not always match up one-to-one with errors encountered
within the tunnel, but they will accurately reflect the state of the within the tunnel, but they will accurately reflect the state of the
network. network.
Tunnel soft state was originally developed for the IP address Tunnel soft state was originally developed for the IP address
encapsulation (IPAE) specification [3]. encapsulation (IPAE) specification [4].
5.1. Tunnel MTU Discovery 5.1. Tunnel MTU Discovery
When the Don't Fragment bit is set by the originator and copied 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 into the outer IP header, the proper MTU of the tunnel will
be learned from ICMP (Type 3 Code 4) "Datagram Too Big" errors be learned from ICMP (Type 3 Code 4) "Datagram Too Big" errors
reported to the encapsulator. To support originating hosts reported to the encapsulator. To support originating hosts
which use this capability, all implementations MUST support Path which use this capability, all implementations MUST support Path
MTU Discovery([6, 7]) within their tunnels. In this particular MTU Discovery [5, 6] within their tunnels. In this particular
application there are several advantages: application there are several advantages:
- As a benefit of Tunnel MTU Discovery, any fragmentation which - As a benefit of Tunnel MTU Discovery, any fragmentation which
occurs because of the size of the encapsulation header is done occurs because of the size of the encapsulation header is
only once after encapsulation. This prevents more than one performed only once after encapsulation. This prevents multiple
fragmentation of a single datagram, which improves processing fragmentation of a single datagram, which improves processing
efficiency of the path routers and tunnel decapsulator. efficiency of the path routers and tunnel decapsulator.
- If the source of the unencapsulated packet is doing MTU discovery - If the source of the unencapsulated datagram is doing MTU
then it is desirable for the encapsulator to know the MTU to the discovery then it is desirable for the encapsulator to know the
decapsulator. If it doesn't know the MTU then it can transfer MTU to the decapsulator. If it doesn't know the MTU then it
the DF bit to the outer packet; however, if that triggers ICMP can transfer the DF bit to the outer datagram; however, if that
Datagram Too Big from within the tunnel (and hence returned triggers ICMP Datagram Too Big from within the tunnel (and hence
to the encapsulator) the encapsulator cannot always return a returned to the encapsulator) the encapsulator cannot always
correct ICMP response to the source unless it has kept state return a correct ICMP response to the source unless it has kept
information about recently sent packets. If the tunnel MTU is state information about recently sent datagrams. If the tunnel
returned to the source by the encapsulator in a Datagram Too Big MTU is returned to the source by the encapsulator in a Datagram
message, the MTU that is conveyed SHOULD be the MTU of the tunnel Too Big message, the MTU that is conveyed SHOULD be the MTU of
minus the size of the encapsulating IP header. This will avoid the tunnel minus the size of the encapsulating IP header. This
fragmentation of the original IP datagram by the encapsulator, will avoid fragmentation of the original IP datagram by the
something that is otherwise certain to occur. encapsulator, something that is otherwise certain to occur.
- If the source is not doing MTU discovery it is still desirable - If the source is not doing MTU discovery it is still desirable
for the encapsulator to know the MTU to the decapsulator. In for the encapsulator to know the MTU to the decapsulator. In
particular it is much better to fragment the inner packet than particular it is much better to fragment the inner datagram than
to allow the outer packet to be fragmented. Fragmenting the to allow the outer datagram to be fragmented. Fragmenting the
inner packet can be done without special buffer requirements and inner datagram can be done without special buffer requirements
without the need to keep state in the decapsulator. By contrast and without the need to keep state in the decapsulator.
if the outer packet is fragmented then the decapsulator needs to By contrast if the outer datagram is fragmented then the
keep state and buffer space on behalf of the destination. decapsulator needs to keep state and buffer space on behalf of
the destination.
The encapsulator SHOULD in normal circumstances do MTU discovery and The encapsulator SHOULD in normal circumstances do MTU discovery
try to send packets with the DF bit set. However there are problems and try to send datagrams with the DF bit set. However there are
with this approach. When the source sets the DF bit it can react problems with this approach. When the source sets the DF bit it can
quickly to resend the information if it gets a ICMP Datagram Too react quickly to resend the information if it gets a ICMP Datagram
Big. When the encapsulator gets a ICMP Datagram Too Big, but the Too Big. When the encapsulator gets a ICMP Datagram Too Big, but the
source had not set the DF bit, then there is nothing sensible that source had not set the DF bit, then there is nothing sensible that
the encapsulator can do to let the source know. The encapsulator the encapsulator can do to let the source know. The encapsulator MAY
MAY keep a copy of the sent packet whenever it tries increasing the keep a copy of the sent datagram whenever it tries increasing the MTU
MTU - this will allow it to resend the packet fragmented if it gets - this will allow it to resend the datagram fragmented if it gets a
a packet too big response. Alternatively the encapsulator MAY be datagram too big response. Alternatively the encapsulator MAY be
configured for certain classes of input to not set the DF bit when configured for certain classes of input to not set the DF bit when
the source has not set the DF bit. the source has not set the DF bit.
5.2. Congestion 5.2. Congestion
Tunnel soft state will collect indications of congestion, such as Tunnel soft state will collect indications of congestion, such as
an ICMP (Type 4) Source Quench or a Congestion Experienced flag in an ICMP (Type 4) Source Quench or a Congestion Experienced flag in
datagrams from the decapsulator (tunnel peer). When forwarding datagrams from the decapsulator (tunnel peer). When forwarding
another datagram into the tunnel, it is appropriate to send Source another datagram into the tunnel, it is appropriate to use approved
Quench messages to the originator. means for controlling congestion [3]; Source Quench messages SHOULD
NOT be sent to the originator.
6. Security Considerations 6. Security Considerations
IP encapsulation potentially reduces the security of the Internet. IP encapsulation potentially reduces the security of the Internet.
For this reason care needs to be taken in the implementation and For this reason care needs to be taken in the implementation and
deployment. deployment.
Assume an organization has good physical control of a secure subset Assume an organization has good physical control of a secure subset
of its network. Assume that the routers connecting that secure of its network. Assume that the routers connecting that secure
network do not allow in packets with source addresses belonging to network do not allow in datagrams with source addresses belonging to
interfaces on that secure network. In that situation it is possible interfaces on that secure network. In that situation it is possible
to safely deploy protocols within that network which depend on the to safely deploy protocols within that network which depend on the
source address of packets for authentication purposes. source address of datagrams for authentication purposes.
Networks with physical security can still be used to run protocols Networks with physical security can still be used to run protocols
which are convenient, but which have implementation or protocol bugs which are convenient, but which have implementation or protocol bugs
which would make them dangerous to use if external sources have which would make them dangerous to use if external sources have
access to the protocol. The external sources can be excluded using access to the protocol. The external sources can be excluded using
router packet filtering. router datagram filtering.
IP encapsulation protocols may allow packets to bypass the checks in IP encapsulation protocols may allow datagrams to bypass the checks
the border routers. There are two cases to consider: in the border routers. There are two cases to consider:
- The case where the people controlling the border routers are - The case where the people controlling the border routers are
trying to protect inner machines from themselves. trying to protect inner machines from themselves.
- The case where the inner machine is looking after its own - The case where the inner machine is looking after its own
defense. defense.
An uncooperative inner machine cannot be protected by the border An uncooperative inner machine cannot be protected by the border
router except by barring all packets to that machine. There is router except by barring all packets to that machine. There is
nothing to stop encapsulated IP coming in to that inner machine nothing to stop encapsulated IP coming in to that inner machine in
in otherwise harmless packets such as port 53 UDP packets (i.e., otherwise harmless datagrams such as port 53 UDP datagrams (i.e.,
apparently DNS packets). So there is a strong case for placing the apparently DNS datagrams). So there is a strong case for placing
security controls at the host rather than the router. However, in the security controls at the host rather than the router. However,
situations where the administrative control of the inner machine is in situations where the administrative control of the inner machine
cooperative but lacks thoroughness or competence, security can be is cooperative but lacks thoroughness or competence, security can be
enhanced by also putting protection in the border routers. enhanced by also putting protection in the border routers.
6.1. Router Considerations 6.1. Router Considerations
Routers need to be aware of IP encapsulation protocols so they can Routers need to be aware of IP encapsulation protocols so they can
correctly filter incoming packets. correctly filter incoming datagrams.
Beyond that it is desirable that filtering be integrated with IP Beyond that it is desirable that filtering be integrated with IP
authentication [1]. In the case of IP encapsulation this can have authentication [1]. In the case of IP encapsulation this can have
2 forms: Encapsulation might be allowed (in some cases) as long 2 forms: Encapsulation might be allowed (in some cases) as long
as the encapsulating packets authentically come from an expected as the encapsulating datagrams authentically come from an expected
encapsulator. Alternatively encapsulation might be allowed if the encapsulator. Alternatively encapsulation might be allowed if the
encapsulated packets have authentication. encapsulated datagrams have authentication.
The next problem is with packets which are encapsulated and Data which is encapsulated and encrypted [2] may also pose a problem.
encrypted [2]. In this case the router can only filter the packet if In this case the router can only filter the datagram if it knows
it knows the security association. To allow this sort of encryption the security association. To allow this sort of encryption in
in environments where all packets need to be filtered (or at least environments where all packets need to be filtered (or at least
accounted for) a mechanism must be in place for the receiving host accounted for) a mechanism must be in place for the receiving host
to securely communicate the association to the border router. This to securely communicate the association to the border router. This
might, more rarely, also apply to the association used for outgoing might, more rarely, also apply to the association used for outgoing
packets. datagrams.
6.2. Host Considerations 6.2. Host Considerations
Receiving IP encapsulation software SHOULD classify incoming packets Receiving IP encapsulation software SHOULD classify incoming
and only allow packets fitting one of the following categories: datagrams and only allow datagrams fitting one of the following
categories:
- The protocol is harmless: source address based authentication is - The protocol is harmless: source address based authentication is
not needed. not needed.
- The packet can be trusted because of trust in the authentically - The datagram can be trusted because of trust in the authentically
identified encapsulating host. That authentic identification identified encapsulating host. That authentic identification
could come from physical security plus border router could come from physical security plus border router
configuration but is more likely to come from AH authentication. configuration but is more likely to come from AH authentication.
- The inner packet has AH authentication. - The inner datagram has AH authentication.
Some or all of this checking could be done in border routers rather Some or all of this checking could be done in border routers rather
than the receiving host but it is better if border router checks are than the receiving host but it is better if border router checks are
used as backup rather than being the only check. used as backup rather than being the only check.
6.3. Using Security Options 6.3. Using Security Options
The security options of the inner IP header MAY affect the choice of The security options of the inner IP header MAY affect the choice of
security options for the encapsulating IP header. security options for the encapsulating IP header.
7. Acknowledgements 7. Acknowledgements
Parts of sections 3 and 5 were taken from the mobile-IP draft [5]. Parts of sections 3 and 5 of this document were taken from sections
Good ideas have also been included from RFC 1853 [10]. "Security (authored by Bill Simpson) of earlier versions of the mobile-IP
Considerations" (section 6) was largely contributed by Bob Smart. Internet Draft [7]. Good ideas have also been included from RFC
Thanks also to Anders Klemets for finding mistakes and suggesting 1853 [10], also authored by Bill Simpson. "Security Considerations"
many improvements to the draft. (section 6) was largely contributed by Bob Smart. Thanks also to
Anders Klemets for finding mistakes and suggesting many improvements
to the draft.
References References
[1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. [1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
[2] R. Atkinson. IP Encapsulating Security Payload. RFC 1827, [2] R. Atkinson. IP Encapsulating Security Payload. RFC 1827,
August 1995. August 1995.
[3] R. Gilligan, E. Nordmark, and B. Hinden. IPAE: The SIPP [3] F. Baker, Editor. Requirements for IP Version 4 Routers. RFC
1812, June 1995.
[4] R. Gilligan, E. Nordmark, and B. Hinden. IPAE: The SIPP
Interoperability and Transition Mechanism. Internet Draft -- Interoperability and Transition Mechanism. Internet Draft --
work in progress, March 1994. work in progress, March 1994.
[4] IETF Mobile-IP Working Group. IPv4 Mobility Support. [5] S. Knowles. IESG Advice from Experience with Path MTU
ietf-draft-mobileip-protocol-12.txt - work in progress,
September 1995.
[5] IETF Mobile-IP Working Group. IPv4 Mobility Support.
ietf-draft-mobileip-protocol-10.txt -- outdated draft, May 1995.
[6] S. Knowles. IESG Advice from Experience with Path MTU
Discovery. RFC 1435, March 1993. Discovery. RFC 1435, March 1993.
[7] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191, [6] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191,
November 1990. November 1990.
[8] J. Postel. Internet Control Message Protocol. RFC 792, [7] C. Perkins, Editor. ietf-draft-mobileip-protocol-16.txt - work
September 1981. in progress. IPv4 Mobility Support, April 1996.
[9] J. Postel. Internet Protocol. RFC 791, September 1981. [8] J. B. Postel, Editor. Internet Control Message Protocol. RFC
792, September 1981.
[9] J. B. Postel, Editor. Internet Protocol. RFC 791, September
1981.
[10] W. Simpson. IP in IP Tunneling. RFC 1853, October 1995. [10] W. Simpson. IP in IP Tunneling. RFC 1853, October 1995.
Author's Address Author's Address
Questions about this memo can also be directed to: Questions about this memo can be directed to:
Charles Perkins Charles Perkins
Room J1-A25 Room H3-D34
T. J. Watson Research Center T. J. Watson Research Center
IBM Corporation IBM Corporation
30 Saw Mill River Rd. 30 Saw Mill River Rd.
Hawthorne, NY 10532 Hawthorne, NY 10532
Work: +1-914-784-7350 Work: +1-914-784-7350
Fax: +1-914-784-7007 Fax: +1-914-784-6205
E-mail: perk@watson.ibm.com E-mail: perk@watson.ibm.com
The working group can be contacted via the current chairs: The working group can be contacted via the current chairs:
Jim Solomon Tony Li Jim Solomon Tony Li
Motorola, Inc. cisco systems Motorola, Inc. cisco systems
1301 E. Algonquin Rd. 170 W. Tasman Dr. 1301 E. Algonquin Rd. 170 W. Tasman Dr.
Schaumburg, IL 60196 San Jose, CA 95134 Schaumburg, IL 60196 San Jose, CA 95134
Work: +1-708-576-2753 Work: +1-408-526-8186 Work: +1-847-576-2753 Work: +1-408-526-8186
E-mail: solomon@comm.mot.com E-mail: tli@cisco.com E-mail: solomon@comm.mot.com E-mail: tli@cisco.com
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/