One document matched: draft-hain-ipv6-fwrh-00.txt
Network Working Group T. Hain
Internet-Draft Cisco Systems
Intended status: Standards Track April 22, 2009
Expires: October 24, 2009
IPv6 Firewall Routing Header
draft-hain-ipv6-fwrh-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 24, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Hain Expires October 24, 2009 [Page 1]
Internet-Draft IPv6 FWRH April 2009
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document specifies a routing header for use by firewalls to
enforce routing symmetry.
The draft is being discussed on the ipv6@ietf.org list.
Legal
This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Hain Expires October 24, 2009 [Page 2]
Internet-Draft IPv6 FWRH April 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Firewall Routing Header Option . . . . . . . . . . . . . . 5
3.2. Routing Header Required ICMP Message . . . . . . . . . . . 7
3.3. ReturnPathForwarding ICMP Error Message . . . . . . . . . 8
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Hain Expires October 24, 2009 [Page 3]
Internet-Draft IPv6 FWRH April 2009
1. Introduction
With the deprecation of RH0 [RFC5095], the ability of a node to avoid
the selection of different firewalls in opposing directions was
eliminated. Operation of stateful firewalls requires path symmetry
at least through that device. The likelihood of asymmetry is
particularly true on the Internet side, but is also a problem when
the exit path changes on the private side during an established
packet exchange. This document targets the specific use case of
symmetric firewall selection, and then defines an IPv6 Firewall
Routing Header and associated IPv6 ICMP error messages. Other use
cases may take advantage of these mechanisms, but are explicitly out
of scope for the development and definition here. While this
Firewall Routing Header mechanism allows for changes in the firewalls
in use during a packet exchange, any mechanisms that would be used to
pass state between disperse firewalls is out of scope here. If those
state passing mechanisms exist, it will be possible for an end-to-end
packet exchange to persist during a routing shift, even over vast
geographic path changes. Since the ability to force routing through
a single intermediary can be used by attackers to receive traffic
they otherwise would not, the ICMP error messages used here may be
signed, and in any event should be dropped if originating outside of
a policy domain. The method that a node would use to verify that
signature is out of scope here.
To deal with the asymmetry issue, a function specific IPv6 routing
header is defined, the Firewall Routing Header (FWRH). This routing
header is used to pass information to a correspondent, so that return
packets are routed through a firewall that is maintaining state for
this transaction. A flag (Origin Flag) will be used to indicate
which instance this is in the case where there are firewalls on each
end (note: this assumes that a firewall would allow an initial
inbound packet, then enforce subsequent packets through itself).
There can be at most 2 (one with each value of the Origin Flag)
FWRH's in any given extension header chain.
An originating node is probably unaware of the presence of a firewall
on its path to any given destination, so it will likely send an
initial packet without the FWRH option. (It may have cached the
value received in a prior ICMP error message for non-local prefixes,
and if so can optimistically minimize the chance for an initial error
by including the cached value in the optional FWRH.) On receipt of
any ICMP Routing Header Required message, the origin node will
extract the return-via address from the ICMP, optionally verify any
signature that may be present, then cache it for use over the
lifetime of the current packet exchange, and optionally for use with
other non-local prefixes. The packet which generated the error is
reconstructed with the appropriate FWRH option, and resent. If the
Hain Expires October 24, 2009 [Page 4]
Internet-Draft IPv6 FWRH April 2009
FWRH option with the appropriate Origin Flag value is missing when a
packet is being sent outbound (from the perspective of the firewall -
private toward public), or if the return-via address in the FWRH
option does not match any address on the firewall that is processing
the packet, an ICMP error (RHR type ???) is returned to the source
address of the packet, indicating the value that is expected to
result in return-path symmetry through an interface on this specific
firewall. That ICMP error SHOULD be signed, and if so the ICMP
packet indicates which signing method was used. Outbound packets
with the matching Origin Flag and return-via address will receive
normal firewall handling before forwarding. If the source address
prefix does not match any prefix that being exchanged in routing
protocols with the next hop, an RPF-error (type ??? +1) ICMP message
should be returned.
The correspondent node will extract the return-via address from a
received FWRH option with an Origin Flag that is opposite the one it
will use when sending, and cache it for use related to this specific
packet exchange. When constructing packets related to this specific
exchange; after all normal processing is complete, the ultimate
destination address will be swapped into the FWRH with the
appropriate Origin Flag, and the previously cached value from any
received FWRH with the opposing Origin Flag will be swapped as the
initial destination address of the packet.
Inbound packets to the public side of a firewall will be addressed
with it as the destination address of the base IPv6 header, and the
FWRH with the Origin flag matching existing state will contain the
address of the ultimate destination. The contents of the FWRH with
the matching Origin flag will be swapped with the destination
addresses in the packet, before normal firewall processing and
forwarding.
2. Terminology
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 RFC 2119 [RFC2119].
3. Mechanisms
3.1. Firewall Routing Header Option
The Firewall Routing header is used by an IPv6 source to list a
single intermediate node to be "visited" by returning packets. The
Firewall Routing header is identified by a Next Header value of 43 in
Hain Expires October 24, 2009 [Page 5]
Internet-Draft IPv6 FWRH April 2009
the immediately preceding header, and has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Address +
| return-via or |
+ ultimate destination +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector.
Identifies the type of header immediately following the
Routing header. Uses the same values as the IPv4 Protocol
field [RFC-1700 et seq.].
Hdr Ext Len 8-bit unsigned integer. Length of the Routing
header in 8-octet units, not including the first 8 octets.
Routing Type 8-bit identifier of this particular Routing
header variant.
Origin Flag The Origin Flag (Flags - bit 0)
is used to indicate the direction that corresponds to
this instance of the FWRH. A value of 1 indicates
that a firewall exists in the initial packet direction
(for TCP this is the SYN), while a value of 0 indicates
that a firewall exists in the response direction
(for TCP this is the SYN-ACK).
Reserved 32-bit reserved field.
Initialized to zero for transmission; ignored on reception.
Address Direction/location dependent address,
where from the origin node toward a correspondent it
contains the address of the firewall to be returned
through and from the correspondent to the intermediate
firewall contains the ultimate destination address
that the firewall will deliver the packet to.
**** Within an enterprise network both FWRH options might contain the
Hain Expires October 24, 2009 [Page 6]
Internet-Draft IPv6 FWRH April 2009
same address if there was an audit function, or traffic engineering
reason to route both directions through the same mid-point.
A FWRH option SHOULD NOT contain an address that matches either the
source or destination addresses of the packet. If there are two FWRH
options present: Their Origin Flag values MUST be different Both
options SHOULD NOT contain the same address
3.2. Routing Header Required ICMP Message
Informing the originating endpoint that it needs to insert a routing
header is accomplished with a specific ICMP error - 'Routing Header
Required' (type ???). This ICMP error may optionally be signed to
mitigate a man-in-the-middle attack vector which could be used to
route all return-path traffic through an attacker's node.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Return-Via IPv6 address |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig-type | Signature-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Signature |
| |
+ +
| |
+ +
IPv6 Fields:
Destination Address
Copied from the Source Address field of the
invoking packet.
ICMPv6 Fields:
Hain Expires October 24, 2009 [Page 7]
Internet-Draft IPv6 FWRH April 2009
Type ???? - 5
Code 0 - unsigned
1 - signed
Reserved 32-bit reserved field. Initialized to zero
for transmission; ignored on reception.
Sig-type 0 - unused
1 - MD5
2 - SHA1
...
Sig-length Length of the signature option
Signature Value of the signature function
The optional signature covers the source and destination address of
this specific packet exchange, plus the FWRH option address.
3.3. ReturnPathForwarding ICMP Error Message
Informing the origin that the source prefix is not appropriate for
the next hop as a symmetric return path.
Hain Expires October 24, 2009 [Page 8]
Internet-Draft IPv6 FWRH April 2009
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Address +
| return-via or |
+ ultimate destination +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of header
immediately following the Routing header. Uses the same
values as the IPv4 Protocol field [RFC-1700 et seq.].
Hdr Ext Len 8-bit unsigned integer.
Length of the Routing header in 8-octet units, not
including the first 8 octets.
Routing Type 8-bit
identifier of this particular Routing header variant.
Origin Flag The Origin Flag (Flags - bit 0)
is used to indicate the direction that corresponds to
this instance of the FWRH. A value of 1 indicates
that a firewall exists in the initial packet direction
(for TCP this is the SYN), while a value of 0 indicates
that a firewall exists in the response direction
(for TCP this is the SYN-ACK).
Reserved 32-bit reserved field.
Initialized to zero for transmission; ignored on reception.
Address Direction/location dependent address,
where from the origin node toward a correspondent it
contains the address of the firewall to be returned
through and from the correspondent to the intermediate
firewall contains the ultimate destination address that
the firewall will deliver the packet to.
The optional signature covers the source and destination address of
this specific packet exchange, plus the source prefix in this option.
4. Examples
Example 1 - Single firewall connecting a private network to the
Hain Expires October 24, 2009 [Page 9]
Internet-Draft IPv6 FWRH April 2009
Internet.
A FW1 B
|__Private__| |__Internet__|
Initial packet exchange sequence -
A ->> DST = B
FW1 ICMP(5) <<- DST = A : SRC = FW1(P) : value - FW1(I)
A ->> DST = B : FWRH(OF=1) = FW1(I)
B <<- DST = FW1(I) : FWRH(OF=1) = A
FW1 <<- DST = A : FWRH(OF=1) = FW1(I)
A ->> DST = B : FWRH(OF=1) = FW1(I)
B <<- DST = FW1(I) : FWRH(OF=1) = A
FW1 <<- DST = A : FWRH(OF=1) = FW1(I)
...
Figure 1
In this case as node A attempts to connect to node B, FW1 rejects the
first attempt with an error message informing that the FWRH is
required. The subsequent packet including the FWRH with Origin Flag
set is forwarded by FW1 toward B. B sends the return packet to FW1,
where the DST is swapped with the locator for A in the FWRH with the
Origin Flag set.
A FW1 B
|__Private__| |__Internet__|
| |
FW2 _ Internet _|
Initial packet exchange sequence -
A ->> DST = B
FW1 ICMP(5) <<- DST = A : SRC = FW1(P) : value - FW1(I)
A ->> DST = B : FWRH(OF=1) = FW1(I)
B <<- DST = FW1(I) : FWRH(OF=1) = A
FW1 <<- DST = A : FWRH(OF=1) = FW1(I)
--- FW1 dies
A ->> DST = B : FWRH(OF=1) = FW1(I)
FW2 ICMP(5) <<- DST = A : SRC = FW2(P) : value - FW2(I)
FW2 ICMP(6) <<- DST = A : SRC = FW2(P) : value - /48 FW2(I)
A ->> DST = B : FWRH(OF=1) = FW2(I)
B <<- DST = FW2(I) : FWRH(OF=1) = A
FW2 <<- DST = A : FWRH(OF=1) = FW1(I)
...
Figure 2
This case is the same as above, except there is an alternate firewall
available to A. At some point after the connection is established,
FW1 dies, and routing redirects packets to B through FW2. FW2 has
Hain Expires October 24, 2009 [Page 10]
Internet-Draft IPv6 FWRH April 2009
acquired state from FW1, so the connection between A & B does not
have to be reset, but FW2 still rejects the next packet with an error
message informing that the FWRH does not have the public address of
FW2. The subsequent packet including the FWRH with Origin Flag set
is forwarded by FW2 toward B. B sends the return packet to FW2, where
the DST is swapped with the locator for A in the FWRH with the Origin
Flag set.
A FW1 FW2 B
|__Private__| |__Internet__| |__Private__|
Initial packet exchange sequence -
A ->> DST = B
FW1 ICMP(5) <<- DST = A : SRC = FW1(P) : value - FW1(I)
A ->> DST = B : FWRH(OF=1) = FW1(I)
FW2 ->> (presumes that FW2 allows initial pkt without state)
B <<- DST = FW1(I) : FWRH(OF=1) = A
FW2 ICMP(5) ->> DST = B : SRC = FW2(P) : value - FW2(I)
B <<- DST = FW1(I) : FWRH(OF=1) = A : FWRH(OF=0) = FW2(I)
FW1 <<- DST = A : FWRH(OF=1) = FW1(I) : FWRH(OF=0) = FW2(I)
A ->> DST= FW2(I) : FWRH(OF=1) = FW1(I) : FWRH(OF=0) = B
FW2 ->> DST = B : FWRH(OF=1) = FW1(I) : FWRH(OF=0) = FW2(I)
...
Figure 3
In this case there are firewalls at each end, and both require a
FWRH. The value of the Origin Flag identifies which FWRH option is
associated with each firewall. Note that before forwarding to the
private side of each firewall, the DST & FWRH(OF=1) was swapped at
FW1, while DST & FWRH(OF=0) was swapped at FW2.
5. IANA Considerations
This specification registers a Routing Header type & two ICMP message
types
6. Security Considerations
A routing header is used to cause packets to traverse a specific
node, and if used maliciously would allow an attacker to see all
packets in an exchange. The risk of this attack is minimized by
filtering out any ICMP Routing Header Required and ICMP RPF-error
messages that originate outside the policy domain, and/or signing &
verifying those ICMP error messages when generated internally.
Hain Expires October 24, 2009 [Page 11]
Internet-Draft IPv6 FWRH April 2009
7. Acknowledgements
The need to resolve routing symmetry for firewalls was initially
championed by William Dixon, and discussed with many attendees at
IETF 74.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[RFC5095] Abley, J., "Deprecation of Type 0 Routing Headers in
IPv6", RFC 5095, December 2007.
Author's Address
Tony Hain
Cisco Systems
500 108th Ave NE
Bellevue, WA 98004
USA
Phone: +1 425 468-1061
Email: alh-ietf@tndh.net
Hain Expires October 24, 2009 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 06:15:18 |