Network Working Group M. Shore
Internet-Draft D. McGrew
Expires: March 11, 2007 Cisco Systems
September 7, 2006
An Authorized IP Firewall Control Application
draft-shore-afwc-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 March 11, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Authorized Firewall Control Protocol provides an interface that
allows network entities to request firewall and NAT services and
resources. It is an instance of a protocol that provides
authorizations and other security servcies, and interworks with other
such instances. AFWC uses its authorization facilities to provide
network administrators more control over network border admissions
decisions than is provided by other firewall pinholing protocols.
Shore & McGrew Expires March 11, 2007 [Page 1]
Internet-Draft AFWC September 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network scenarios . . . . . . . . . . . . . . . . . . . . . . 4
3. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Pinholes . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Firewall pinholes . . . . . . . . . . . . . . . . . . . . 8
4.2. NAT Table mappings . . . . . . . . . . . . . . . . . . . . 8
5. Access Type . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Open Pinhole Exchange . . . . . . . . . . . . . . . . . . 10
6.1.1. Start message . . . . . . . . . . . . . . . . . . . . 10
6.1.2. Offer Message . . . . . . . . . . . . . . . . . . . . 10
6.1.3. Request message . . . . . . . . . . . . . . . . . . . 11
6.1.4. Response message . . . . . . . . . . . . . . . . . . . 12
6.2. Close Pinhole Exchange . . . . . . . . . . . . . . . . . . 13
7. Data formats . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. IPV4_SELECTOR . . . . . . . . . . . . . . . . . . . . . . 15
7.2. IPV6_SELECTOR . . . . . . . . . . . . . . . . . . . . . . 16
7.3. NAT_TUPLE . . . . . . . . . . . . . . . . . . . . . . . . 16
7.4. INFO . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.5. NAT_INFO . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.6. ICMP_MESSAGE . . . . . . . . . . . . . . . . . . . . . . . 19
7.7. PINHOLE_ID . . . . . . . . . . . . . . . . . . . . . . . . 20
7.8. APPLICATION_ID . . . . . . . . . . . . . . . . . . . . . . 21
8. Traffic Flows . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Responder Discovery . . . . . . . . . . . . . . . . . . . . . 24
10. Authorizations . . . . . . . . . . . . . . . . . . . . . . . . 25
11. NAT discussion . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Stand-alone NAT . . . . . . . . . . . . . . . . . . . . . 27
11.2. The NAT is co-resident with the firewall . . . . . . . . . 27
11.3. There is a NAT between the controller and the firewall . . 28
12. NAT call flow examples . . . . . . . . . . . . . . . . . . . . 29
12.1. Calling endpoint is NATted, controls firewall . . . . . . 29
12.2. Calling endpoint is NATted, CCS controls firewall . . . . 30
12.3. Called endpoint NATted . . . . . . . . . . . . . . . . . . 31
13. Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14. Security Considerations . . . . . . . . . . . . . . . . . . . 34
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37
Shore & McGrew Expires March 11, 2007 [Page 2]
Internet-Draft AFWC September 2006
1. Introduction
This specification defines a protocol for establishing and managing
firewall pinholes, and a formal model for evaluating pinhole requests
against a pre-established set of authorizations. The design relies
on a lower layer in the system to provide cryptographic protections,
and to provide the authorizations of the other endpoint.
In this document we refer to a "firewall control application." The
application actually supports requests to both firewalls and NATs,
and while we do not consider NAT to be a type of firewall or to be a
security device in general, we recognize that there are substantial
semantic, topological, and protocol similarities between asking for a
firewall pinhole and asking for a NAT table mapping. For the sake of
convenience we will refer to a firewall control application
throughout this document, acknowledging that in reality the
application includes NAT, a non-firewall function.
Shore & McGrew Expires March 11, 2007 [Page 3]
Internet-Draft AFWC September 2006
2. Network scenarios
Participants in an AFWC dialogue include an initiator, a responder,
and an authenticationserver. In the firewall control application,
the "initiator" is the entity requesting a firewall pinhole or
service, or NAT table mapping. This might be, for example, an IP
telephony call control server, or a network gaming endpoint. The
"responder" is the firewall or NAT, and the authentication server is
the server providing authentication and authorization services to the
initiator and responder.
In this document we will use "initiator" and "responder" to describe
protocol participants.
Firewall control is typically seen as between elements in the same
network, allowing implicit authorization based on topological
considerations such as sharing of address space. For example,
______________ _____________
/ \ / \
/ Local \ / Public \
| network ------ internet |
| _| FW | |
| __--- ------ |
\ CCS---- / \ /
\______________/ \_____________/
In this figure, a VoIP call control server ("CCS") establishes a
request connection to a firewall ("FW").
However, it may be the case in some instances or for some
applications that an external entity, outside of the local network or
address space, may wish to request pinholes or other resources from
the firewall.
______________ _____________
/ \ / \
/ Local \ / Public \
| network ------ internet |
| | FW |-_ |
| ------ -__ |
\ / \ -- CCS /
\______________/ \_____________/
Shore & McGrew Expires March 11, 2007 [Page 4]
Internet-Draft AFWC September 2006
In this scenario the trust relationships will need to be made
explicit, and there may be substantial changes to the security
considerations.
Shore & McGrew Expires March 11, 2007 [Page 5]
Internet-Draft AFWC September 2006
3. Transport
AFWC relies on a cryptographic layer for transport and to provide
authorizations of the other endpoint. The following cryptographic
services MUST be provided by the crypto layer:
o entity authentication of the peer
o confidentiality of all messages sent to and from the peer
o message authentication on all messages sent to and from the peer
o protection from replayed messages
o protection from reflected messages.
In addition, the lower layer MUST establish the authorizations of the
peer in a secure and reliable manner and pass these authorizations to
this protocol.
The messages are framed using the following format. The REQUEST
(Figure 3) and RESPONSE (Figure 4) elements convey arbitrary data in
their Body fields. This data is meant to convey a request or a
response. The Access Type Identifier (ATI) field (Section 5)
indicates the type of access that is being requested. The Body field
is interpreted according to the value of the ATI field. The Request
Identifier field is used to match replies to requests. That field
can be set to any value by the sender of a REQUEST; these values
SHOULD be distinct. The receiver of a REQUEST element MUST set that
field of the corresponding RESPONSE element to the same value.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| Typecode = REQUEST | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Type Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
Shore & McGrew Expires March 11, 2007 [Page 6]
Internet-Draft AFWC September 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| Typecode = RESPONSE | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Type Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
Shore & McGrew Expires March 11, 2007 [Page 7]
Internet-Draft AFWC September 2006
4. Pinholes
4.1. Firewall pinholes
In this specification, a pinhole is a traffic flow that the firewall
permits, which can be very narrowly scoped. For example, a pinhole
can be created that allows VoIP traffic to flow between a phone
behind the firewall and a phone outside the firewall, but which does
not allow traffic from any other hosts outside the firewall to reach
the phone behind the firewall. The definition of a traffic flow used
in this specification appears below.
Each pinhole is associated with a PINHOLE_ID value, which can be used
to uniquely identify the pinhole, and a timer value that indicates
when the pinhole is to expire.
A pinhole corresponds to a "permit" statement, in that it only allows
traffic through the firewall, and cannot cause traffic to be blocked.
There is no equivalent "deny" statement in this specification. This
design decision makes the application simpler and should make
implementations easier to manage. (n.b. this should not in any way be
construed as suggesting that an application cannot request the
closure of a pinhole it created -- see below)
An initiator MAY request a pinhole for which the traffic flow is
already allowed through the responder (firewall), either in part or
in whole. In this case, if the responder rejects the request, it
MUST NOT be construed to indicate that the flow has been blocked.
4.2. NAT Table mappings
A NAT table mapping is the data structure in a NAT providing the
mapping between an external {address, port, protocol} tuple and an
internal, private {address, port, protocol} tuple. In some types of
NAT there may be additional data associated with the mapping. For
example, in a symmetric NAT each mapping is also associated with one
external peer. Those additional data are opaque to the endpoint and
are internal to the NAT.
A NAT table mapping is represented by a PINHOLE_ID value, as well.
Shore & McGrew Expires March 11, 2007 [Page 8]
Internet-Draft AFWC September 2006
5. Access Type
The IP Firewall Control application is identified by an Access Type
Code of ACCESS_TYPE_FW_CTL. The cryptographic and authorization
layers use this code in order to deliver the IP Firewall Control
messages to the appropriate application on each participating device.
The Access Type Code identifies an authorization application in the
same way that a well-known TCP port identifies a service on a host.
Shore & McGrew Expires March 11, 2007 [Page 9]
Internet-Draft AFWC September 2006
6. Message Exchanges
This section defines the IP Firewall application protocol. We use
the notation that T* denotes zero or more instances of the term T, T+
denotes one or more instances of the term T, and T? denotes zero or
one instances of the term T. In this section, I is the initiator, a
device that is making an access control request to the firewall, and
R is the responder, which is the firewall itself. 'I' refers to the
initiator (the entity requesting pinholes) and 'R' refers to the
responder, which in this case is the firewall.
The crypto layer and transport layer operate below the application
layer, and provide the essential security services and reliable data
transport. The application layer contains the "access control
dialog". It contains four messages: Start, Offer, Request, and
Response. These messages are described below along with the data
formats and the semantics used in the IP Firewall Control
application.
6.1. Open Pinhole Exchange
An initiator begins an Open Pinhole exchange in order to cause a
responder to allow a particular traffic flow. The flow is described
by one or more IPV4_SELECTOR or IPV6_SELECTOR TLVs, and is associated
with a particular PINHOLE_ID.
+----------+--------+-----------------------------------------------+
| Message | Flow | Format |
+----------+--------+-----------------------------------------------+
| Start | I -> R | <empty> |
| | | |
| Offer | R -> I | (PINHOLE_ID (IPV4_SELECTOR | IPV6_SELECTOR)* |
| | | ) | INFO |
| | | |
| Request | I -> R | PINHOLE_ID (IPV4_SELECTOR | IPV6_SELECTOR)? | |
| | | NAT_TUPLE? | INFO |
| | | |
| Response | R -> I | PINHOLE_ID INFO? | NAT_INFO? |
+----------+--------+-----------------------------------------------+
6.1.1. Start message
The Start message is sent by the initiator to the responder to
initiate the authorization exchange. The message body is empty.
6.1.2. Offer Message
A responder constructs the Offer message as follows. First, it MUST
Shore & McGrew Expires March 11, 2007 [Page 10]
Internet-Draft AFWC September 2006
check the authorizations of the initiator to make sure that it is
authorized to act as a controller (see the section on
Authorizations). If it is not, then the Offer message MUST contain
an INFO element with Status Code ERROR and Info Code
ACCESS_NOT_ALLOWED, and the session must be terminated. Otherwise,
the responder encodes into the Offer a PINHOLE_ID that is not
currently in use, which will be associated with the pinhole created
by the session, if it completes successfully. The responder MAY send
one or more IPV4_SELECTOR or IPV6_SELECTOR TLV element(s) describing
the traffic that it is willing to allow. The use of these elements
provides basic capability discovery and topology discovery . The
responder indicates to the authorization system the maximum time,
expressed as a number of seconds, that it is willing to allow a
pinhole to remain open. This value is used by the authorization
system, and is also conveyed to the initiator.
A responder that also does NAT, or a stand-alone NAT, MUST include an
INFO element that has a Status Code of CAPABILITIES with the NAT flag
set.
The responder MAY include INFO elements that indicate other
conditions, though the controller MAY ignore them.
An initiator processes an Offer message as follows. First, it MUST
check the authorizations of the responder to make sure that it is
authorized to act as a firewall or NAT (see the section on
Authorizations). If it is not, then the Offer message MUST contain
an INFO element with Status Code ERROR and Info Code
ACCESS_NOT_ALLOWED, and the session must be terminated. If any
IPV4_SELECTOR or IPV6_SELECTOR element(s) appear in the message, the
initiator SHOULD use the information to guide the construction of the
Request.
6.1.3. Request message
The initiator builds the firewall request by including the PINHOLE_ID
element sent in the Offer and zero or more IPV4_SELECTOR or
IPV6_SELECTOR elements that describe the traffic that the initiator
is requesting to be allowed to traverse the firewall. The initiator
indicates to the authorization system the minimum time that it would
like for the pinhole to remain open; this value MUST be no greater
than the duration indicated with the Offer message. The initiator
MAY include INFO elements that indicate other conditions, though the
responder MAY ignore them.
The initiator builds the NAT request by including the PINHOLE_ID
element sent in the Offer and one or more NAT_TUPLE elements that
describe the internal address for which the initiator is requesting a
Shore & McGrew Expires March 11, 2007 [Page 11]
Internet-Draft AFWC September 2006
mapping. The presence of a NAT_TUPLE element implies that a NAT
table mapping is being requested, and, by implication, that a
firewall pinhole request is being requested. There may be cases in
which there are no SELECTOR elements but one or more NAT_TUPLE
elements; in that case the request will be treated as being for both
a NAT table mapping and a firewall pinhole for each NAT_TUPLE
element. Otherwise the construction of the request message is the
same as it is for a firewall pinhole request.
A responder processes a Request message as follows. First, it MUST
check the authorizations of the initiator to make sure that it is
authorized to open the pinhole that it has requested (see the section
on Authorizations). If it is not, then the Offer message MUST
contain an INFO element with Status Code ERROR and Info Code
ACCESS_NOT_ALLOWED, and the session must be terminated. Otherwise,
the responder constructs a Response message. This message serves as
an acknowledgement.
NAT processing of the Request message is the same as firewall
processing of the Request message.
6.1.4. Response message
The Response message contains the PINHOLE_ID that was included in the
Offer and the Request. In the firewall case, if nothing goes wrong,
then this message contains an INFO element with a Status Code of
NOTIFY and an Info Code of OK. If there are any errors or warnings,
then the INFO element must be set appropriately. If the duration
requested by the initiator is greater than the maximum that the
responder is willing to allow, then the responder SHOULD install the
pinhole with the maximum duration to which it consents. In this
case, the firewall SHOULD send an INFO element with Status Code
WARNING and Info Code of DURATION_TOO_LONG. The responder MUST
implement the pinhole before sending the Response. The number of
seconds before the pinhole expires is provided to the authorization
system, which forwards it to the controller.
If the request was for a NAT table mapping, the Response message MUST
also contain a NAT_INFO TLV. The NAT_INFO TLV is used to communicate
the external address back to the controller.
An initiator processes a Response as follows. It uses the PINHOLE_ID
to associate the reply with the request that it made earlier. If an
INFO element with Status Code NOTIFY and Info Code OK appears in the
message, and no element with Status Code ERROR appears in the
message, then the session has concluded successfully. Otherwise, the
controller MUST NOT assume that the pinhole that it has requested has
been implemented by the responder. If an INFO element containing
Shore & McGrew Expires March 11, 2007 [Page 12]
Internet-Draft AFWC September 2006
DURATION_TOO_LONG appears, then the initiator SHOULD be prepared to
make another Open Pinhole request before the pinhole times out and is
removed by the responder. The duration conveyed by the authorization
system indicates the number of seconds that the responder has
committed to keep the pinhole open.
6.2. Close Pinhole Exchange
An initiator initiates a Close Pinhole exchange to close a responder
to a traffic flow that had been previously allowed via an Open
Pinhole exchange. A Close Pinhole exchange causes the responder to
reverse the firewall policy changes that were made in the previous
exchange. The messages for this exchange are outlined in the
following table.
+----------+--------+-----------------------------------------------+
| Message | Flow | Format |
+----------+--------+-----------------------------------------------+
| Start | I -> R | <empty> |
| | | |
| Offer | R -> I | (PINHOLE_ID (IPV4_SELECTOR | IPV6_SELECTOR)* |
| | | ) | INFO |
| | | |
| Request | I -> R | CLOSE_PINHOLE PINHOLE_ID+ |
| | | |
| Response | R -> I | CLOSE_PINHOLE (PINHOLE_ID | INFO)+ |
+----------+--------+-----------------------------------------------+
The Start message is empty, as in the Open Pinhole exchange.
The responder constructs the Offer exactly as done for the Open
Pinhole exchange (as it must, since at this point in the protocol it
has no idea whether or not the initiator will be requesting to open
or close a pinhole).
The initiator constructs the Request as follows. The PINHOLE_ID sent
by the responder is ignored. The message MUST start with a
CLOSE_PINHOLE TLV, which indicates that the initiator is requesting
that one or more previously created pinholes are to be closed. The
PINHOLE_ID element associated with the pinhole(s) that the initiator
wishes to close are included in the message. At least one PINHOLE_ID
element MUST appear in the message.
The responder constructs the Reply as follows. The message MUST
start with a CLOSE_PINHOLE TLV, which acknowledges that the exchange
will close previously opened pinholes. For each PINHOLE_ID that
appears in the Request, the responder includes a PINHOLE_ID in the
Response, followed by a INFO TLV element. The INFO element contains
Shore & McGrew Expires March 11, 2007 [Page 13]
Internet-Draft AFWC September 2006
a Status Code of NOTIFY and an Info Code of OK if the pinhole was
closed successfully.
The Close Pinhole Exchange is the same for NATs as it is for
firewalls.
Shore & McGrew Expires March 11, 2007 [Page 14]
Internet-Draft AFWC September 2006
7. Data formats
The IP Firewall application defines the following TLV types:
7.1. IPV4_SELECTOR
IPV4_SELECTOR encodes a traffic selector, which defines a particular
IP Version Four packet flow. The firewall uses these values as the
basis for packet matches. The Value field of an IPV4_SELECTOR TLV
element consists of the ipv4_selector_t structure shown below, in
network byte order:
typedef struct {
uint32_t src_addr;
uint32_t src_mask;
uint32_t dst_addr;
uint32_t dst_mask;
uint16_t src_port_lo;
uint16_t src_port_hi;
uint16_t dst_port_lo;
uint16_t dst_port_hi;
uint16_t protocol;
uint32_t spi;
uint16_t reserved;
} ipv4_selector_t;
with the fields as follows:
src_addr: source address in the IP header
src_mask: a value to mask with the src_addr field
dst_addr: destination address in the IP header
dst_mask: a value to mask with the dst_addr field
src_port_lo: ports may be specified as a range of values; this is
the low value for the source port in the IP header
src_port_hi: high value for the range of source ports in the IP
header
dst_port_lo: low value for the range of destination ports in the IP
header
Shore & McGrew Expires March 11, 2007 [Page 15]
Internet-Draft AFWC September 2006
dst_port_hi: high value for the range of destination ports in the IP
header
protocol: the protocol number carried in the IP header
spi: IPSec SPI.
The value 0x00 is used in the protocol field to denote a match to any
protocol.
7.2. IPV6_SELECTOR
IPV6_SELECTOR encodes a traffic selector, which defines a particular
IP Version Six packet flow. The Value field of an IPV6_SELECTOR TLV
element consists of the ipv6_selector_t structure shown below, in
network byte order:
typedef struct {
uint128_t src_addr;
uint128_t src_mask;
uint128_t dst_addr;
uint128_t dst_mask;
uint32_t flow_label;
uint16_t src_port_lo;
uint16_t src_port_hi;
uint16_t dst_port_lo;
uint16_t dst_port_hi;
uint16_t protocol;
uint16_t reserved;
} ipv6_selector_t;
with the fields as described above.
7.3. NAT_TUPLE
The NAT_TUPLE TLV contains the description of an {address, port,
protocol} tuple for which a NAT table mapping is being requested. In
other words, the NAT_TUPLE describes an internal address.
typedef struct {
uint32_t addr;
uint16_t port;
uint16_t protocol;
uint32_t hint_addr;
uint16_t hint_port;
uint16_t hint_protocol;
Shore & McGrew Expires March 11, 2007 [Page 16]
Internet-Draft AFWC September 2006
} nat_tuple_t;
The addr field represents an IPv4 address. Because this is for NAT,
we assume that we will not need to support NAT functions for IPv6,
although this may be revisited if necessary.
When the initiator is making the request on behalf of another party
(for example, a call control server requesting a media pinhole for a
VoIP endpoint) the hint_addr, hint_port, and hint_protocol fields
SHOULD be used to assist a NAT device in resolving ambiguous
requests. An example of ambiguity would be those cases when the
NATted address spaces attached to two different interfaces on the
same NAT use the same or overlapping addresses.
An example of its use would be for, say, a VoIP call control server
to use the hint fields to send the {address, port, protocol} tuple of
the endpoint from which it received signaling to the NAT. The NAT
would search its mapping tables on all interfaces for a match. If a
match is found the interface with which the matching mapping is
associated would be the interface to which the request is applied.
If the hint fields are not used they MUST be null.
7.4. INFO
typedef struct {
uint32_t status_code;
uint32_t info_code;
} info_t;
The Status Code describes the status state machine of the sender of
the INFO element. If any condition occurred that will prevent the
successful completion of the exchange, then this field will have the
value ERROR. This value indicates to the recipient that it MUST NOT
expect the sender to participate in the exchange any further.
The Status Codes are:
Shore & McGrew Expires March 11, 2007 [Page 17]
Internet-Draft AFWC September 2006
+--------------+--------------------------------------------------+
| Message | Meaning |
+--------------+--------------------------------------------------+
| OKAY | No error, no message |
| | |
| ERROR | An error was encountered |
| | |
| CAPABILITIES | This element contains a capabilities description |
+--------------+--------------------------------------------------+
The Info Code provides detailed information, but does not convey any
information about the base authorization exchange.
The Info Code values that can be used by the IP Firewall Control
application are as follows:
+------------------------+------------------------------------------+
| Value | Meaning |
+------------------------+------------------------------------------+
| OK | No problems occurred |
| | |
| ACCESS_NOT_ALLOWED | Access is denied due to lack of |
| | authorization |
| | |
| DURATION_TOO_LONG | Duration requested is too long |
| | |
| BAD_PARAMETER | A bad parameter appeared in a request |
| | |
| TRY_AGAIN | Request cannot be completed, but try |
| | again |
| | |
| RESOURCE_NOT_AVAILABLE | A resource needed for the request is not |
| | available |
| | |
| NAT | This device provides NAT functions |
+------------------------+------------------------------------------+
7.5. NAT_INFO
The NAT_INFO TLV carries the response to the NAT request (implicit in
the inclusion of a NAT_TUPLE TLV in the Request message). It
includes both the internal and external addresses.
Shore & McGrew Expires March 11, 2007 [Page 18]
Internet-Draft AFWC September 2006
typedef struct {
uint32_t i_addr;
uint32_t e_addr;
uint32_t i_port;
uint32_t e_port;
uint16_t protocol;
} nat_info_t;
where the fields are as follows:
i_addr: Internal IPv4 address
e_addr: External IPv4 address
i_port: Internal port
e_port: External port
protocol Protocol (TCP, UDP, SCTP, etc.)
7.6. ICMP_MESSAGE
typedef struct {
u_char icmp_type;
u_char icmp_code;
} icmp_t;
ICMP_MESSAGE carries a description of a filter rule for ICMP
messages, based on ICMP message types and codes.
The values are as follows:
Shore & McGrew Expires March 11, 2007 [Page 19]
Internet-Draft AFWC September 2006
ICMP_ECHOREPLY 0
ICMP_UNREACH 3
ICMP_UNREACH_NET 0
ICMP_UNREACH_HOST 1
ICMP_UNREACH_PROTOCOL 2
ICMP_UNREACH_PORT 3
ICMP_UNREACH_NEEDFRAG 4
ICMP_UNREACH_SRCFAIL 5
ICMP_UNREACH_NET_UNKNOWN 6
ICMP_UNREACH_HOST_UNKNOWN 7
ICMP_UNREACH_ISOLATED 8
ICMP_UNREACH_NET_PROHIB 9
ICMP_UNREACH_HOST_PROHIB 10
ICMP_UNREACH_TOSNET 11
ICMP_UNREACH_TOSHOST 12
ICMP_UNREACH_FILTER_PROHIB 13
ICMP_UNREACH_HOST_PRECEDENCE 14
ICMP_UNREACH_PRECEDENCE_CUTOFF 15
ICMP_SOURCEQUENCH 4
ICMP_REDIRECT 5
ICMP_REDIRECT_NET 0
ICMP_REDIRECT_HOST 1
ICMP_REDIRECT_TOSNET 2
ICMP_REDIRECT_TOSHOST 3
ICMP_ECHO 8
ICMP_ROUTERADVERT 9
ICMP_ROUTERSOLICIT 10
ICMP_TIMXCEED 11
ICMP_TIMXCEED_INTRANS 0
ICMP_TIMXCEED_REASS 1
ICMP_PARAMPROB 12
ICMP_PARAMPROB_ERRATPTR 0
ICMP_PARAMPROB_OPTABSENT 1
ICMP_PARAMPROB_LENGTH 2
ICMP_TSTAMP 13
ICMP_TSTAMPREPLY 14
ICMP_IREQ 15
ICMP_IREQREPLY 16
ICMP_MASKREQ 17
ICMP_MASKREPLY 18
7.7. PINHOLE_ID
typedef struct {
uint32_t id;
uint32_t context;
Shore & McGrew Expires March 11, 2007 [Page 20]
Internet-Draft AFWC September 2006
} pinhole_id_t;
The PINHOLE_ID is an identifier generated by the responder and
associated with a particular pinhole. The id field of a PINHOLE_ID
TLV is 32 bits long, and MAY be treated as an unsigned integer in
network byte order (e.g. for display to the user). The method by
which the firewall generates these identifiers is intentionally left
unspecified, in order to provide maximum flexibility for
implementations. Of course, each PINHOLE_ID value associated with an
existing pinhole MUST be unique. Each PINHOLE_ID offered to a
controller in an Offer message SHOULD be unique, though it is
acceptable for a controller to offer the same value twice as long as
it detects this condition and does not attempt to install multiple
pinholes with the same PINHOLE_ID values.
The context field carries responder-specific information to
distinguish context. Examples of contexts include interface
identifiers and identifiers for virtualized firewalls or NATs.
7.8. APPLICATION_ID
typedef struct {
uint16_t id_no;
char version[14];
} application_id_t;
The APPLICATION_ID is a mechanism for identifying the application for
which the resources (firewall pinholes, NAT table mappings) are being
requested. It is expected that the information will be used as input
to a policy-based decision whether or not to grant the request.
The id_no member represents the application itself. It MUST use the
well-known port number, allocated by the IANA, for the application.
In the case where there is no well- known port, such as a Cisco-
proprietary protocol for which no well-known port has been requested,
a number outside the IANA registered port range MUST be allocated.
There are cases in which a protocol uses a dynamically allocated port
number -- for example, non-tunneled H.245 or RTP. In those cases the
application_id SHOULD be that of the parent protocol (say, H.225 in
the case of H.245 or SIP or RTSP in the case of RTP).
The version field carries a null-terminated ASCII representation of
the version number. If the version string is 14 octets long no null
termination is necessary; if the version string is more than 14
Shore & McGrew Expires March 11, 2007 [Page 21]
Internet-Draft AFWC September 2006
octets in length it MUST be truncated to 14 octets. For example,
version "6" would appear:
1 2 3 4
+-------------+-------------+-------------+-------------+
0 | 0x36 | 0x00 | | |
+-------------+-------------+-------------+-------------+
1 | | | | |
+-------------+-------------+-------------+-------------+
2 | | | | |
+-------------+-------------+-------------+-------------+
| | | | |
+-------------+-------------+-------------+-------------+
while version "3rev1 beta" would be represented as:
1 2 3 4
+-------------+-------------+-------------+-------------+
0 | 0x33 | 0x72 | 0x65 | 0x76 |
+-------------+-------------+-------------+-------------+
1 | 0x31 | 0x20 | 0x62 | 0x65 |
+-------------+-------------+-------------+-------------+
2 | 0x74 | 0x61 | 0x00 | |
+-------------+-------------+-------------+-------------+
| | | | |
+-------------+-------------+-------------+-------------+
Shore & McGrew Expires March 11, 2007 [Page 22]
Internet-Draft AFWC September 2006
8. Traffic Flows
A flow is defined as a set of IP packets passing through a particular
point in the network that match one or more IPV4_SELECTOR or
IPV6_SELECTOR elements. A selector A matches a packet P when the
following seven conditions hold:
1. (A.src_addr AND A.src_mask) equals (P.src_addr AND A.src_mask)
2. (A.dst_addr AND A.dst_mask) equals (P.dst_addr AND A.dst_mask)
3. A.src_port_lo <= P.src_port
4. A.src_port_hi >= P.src_port
5. A.dst_port_lo <= P.dst_port
6. A.dst_port_hi >= P.dst_port
7. A.protocol equals P.protocol, or A.protocol equals zero.
When the src_addr or dst_addr of a selector is zero, the selector
will match any source address or destination address, respectively.
Similarly, a selector with a protocol value of zero will match any
protocol. In the future, additional selector TLVs may be defined in
order to express additional information (such as TCP or IP options or
MPLS labels) or to express a particular sort of flow more compactly
(such as the UDP port pairs often used in RTP). However, any
additional selector TLVs will describe what the traffic flow of
interest is, and will not describe what should be done with it. If,
for example, a controller needs to express that a particular flow
should have QoS applied to it, or should be rate-limited, or should
be monitored or audited, then the specification of the responder
behavior with respect to the traffic flow MUST be expressed using TLV
elements that are separate from the selector elements.
Shore & McGrew Expires March 11, 2007 [Page 23]
Internet-Draft AFWC September 2006
9. Responder Discovery
In some cases, the initiator may need to open a pinhole, but not know
the responder to which the Open Pinhole exchange should be addressed.
The authorization interception feature can be used to find the
appropriate firewall, in some cases.
A network device that implements the authorization system has the
capability of intercepting packets that it is forwarding, and acting
on those packets if appropriate, and forwarding them otherwise. A
firewall implementing the Authorized IP Firewall Control application
MAY intercept Start messages for that application. An initiator MAY
send an Authorized IP Firewall Control message addressed to an end
host behind a responder onto which a pinhole should be installed.
Note that in order to discovery multiple nested firewalls, a firewall
implementing Start message interception SHOULD forward the Start
message on towards its destination.
This firewall discovery method will work only when the responder is
on both the path from the initiator to the end host and the path(s)
from the end host to the other devices to which it intends to
communicate over the pinhole. When a network is multi-homed, this
may not be the case.
Shore & McGrew Expires March 11, 2007 [Page 24]
Internet-Draft AFWC September 2006
10. Authorizations
We define the following TLV formats, for native authorization:
The FW_CTL TLV format has a zero-length Value field. It grants
permission to its holder to control responders to allow the flow of
traffic described by the TLV elements that follow it. If there are
no flow-description elements that follow it, then a FW_CTL element
does not actually convey any authorizations. For example, the
statement
FW_CTL IPV4_SELECTOR1 IPV4_SELECTOR2
grants permission to control any responder to permit the flow of
traffic described by the two selector elements that follow it.
The FW TLV format has a zero-length Value field. It grants
permission to its holder to act as a responder for the traffic
described by the TLV elements that follow it. If there are no flow-
description elements that follow a FW element, then the element
conveys no authorizations. For example, the statement
FW IPV4_SELECTOR1 IPV4_SELECTOR2 IPV4_SELECTOR3
grants permission to act as a responder and control the flow of
traffic described by the three selector elements that follow it.
A single authorization element MAY contain both a FW_CTL element and
a FW element. Formally, the authorizations have the format
((FW IPV4_SELECTOR+)|(FW_CTL IPV4_SELECTOR+))+
using the notation described above.
We say that selector A contains selector B, or B is contained by A,
whenever every packet that matches selector B also matches selector
A. This situation occurs if and only if all of the following
conditions hold:
1. (A.src_addr AND A.src_mask) equals (B.src_addr AND A.src_mask)
2. (A.dst_addr AND A.dst_mask) equals (B.dst_addr AND A.dst_mask)
3. A.src_port_lo <= B.src_port_lo
4. A.src_port_hi >= B.src_port_hi
Shore & McGrew Expires March 11, 2007 [Page 25]
Internet-Draft AFWC September 2006
5. A.dst_port_lo <= B.dst_port_lo
6. A.dst_port_hi >= B.dst_port_hi
7. A.protocol equals B.protocol, or A.protocol equals zero.
Note that if A contains B, it is not necessarily true that B contains
A. However, if A contains B and B contains C, then it follows that A
contains C.
When checking authorizations against requests, a responder MUST
o verify that the selector describing the authorizations granted by
the server to the initiator (I_AUTHS) are contained in the
server's authorizations.
o verify that the selector describing the initiator's request is
contained in the selector describing the authorizations granted by
the server to the initiator.
A future version of this specification may contain other
authorization elements.
Shore & McGrew Expires March 11, 2007 [Page 26]
Internet-Draft AFWC September 2006
11. NAT discussion
It may be the case that the firewall being controlled is co-resident
with a NAT or that there is a NAT between the controller and the
firewall. It may also be the case that we are controlling a stand-
alone NAT. This raises some issues, some of which are addressed in
this document and some of which are for future study.
11.1. Stand-alone NAT
This is straightforward -- we send requests to the NAT and the NAT
returns the external address, allowing us to use the external address
in protocols that make use of embedded addresses, such as VoIP
protocols or streaming media protocols.
The behavior of the Authorized IP firewall control protocol is the
same whether it is being used to control NATs or firewalls, with the
difference lying in the data elements.
11.2. The NAT is co-resident with the firewall
In this scenario the firewall should be treated as a stand-alone NAT.
That is to say, the data elements will include the NAT_TUPLE in the
Request and the NAT_INFO in the Response. The reason for this is
that it is assumed that an application would not want an external
address if it did not also want a firewall pinhole, and it would want
both resources to have the same lifetime.
When the Request arrives at the NAT/firewall device, the device MUST
process the NAT request first, and the results of the NAT processing
(that is to say, the NAT table mapping) passed to the firewall
function as part of the pinhole descriptor. If the NAT table mapping
is not acquired first and used in the filter description, the filter
rule that will be installed not be correct for processing inbound
(external->internal) traffic.
The firewall pinhole for outbound traffic will contain:
Source address: untranslated internal address
Source port: untranslated internal port
Destination address: untranslated peer address
Destination port: untranslated peer port
The firewall pinhole for inbound traffic will contain:
Shore & McGrew Expires March 11, 2007 [Page 27]
Internet-Draft AFWC September 2006
Source address: untranslated peer address
Source port: untranslated peer port:
Destination address: translated (external) address
Destination port: translated (external) port
11.3. There is a NAT between the controller and the firewall
The issue here is that NAT is transparent to the endpoint. In the
typical case an endpoint does not know whether or not there is a NAT
along the path between it and its peer. Even if communication fails
the endpoint cannot know whether the failure was caused by a NAT
interaction or some other network failure. When a NAT is present an
endpoint will not know the external address, which is the correct
one, to send in a pinhole request. A pinhole descriptor will contain
the endpoint's local address and port (the address on the network
interface card and the port number assigned by the local TCP or UDP
stack). In the case where a NAT is present between an endpoint and
the firewall on which it's requesting a pinhole, the address and port
local to the endpoint are not the address and port visible outside
the NAT, and the pinhole descriptor will not reflect that. The
pinhole will be for the "wrong" internal address.
Shore & McGrew Expires March 11, 2007 [Page 28]
Internet-Draft AFWC September 2006
12. NAT call flow examples
Below we show some sample SIP call flows, using the Authorized IP FW
Control application to acquire NAT table mappings (and open pinholes
if appropriate) to provide traversal capabilities. In all cases the
SIP messages are shown in black and the AFWC messages are shown in
red. These call flows assume the use of a 4-message exchange, which
may be reduced to two messages in future versions of this document.
In these examples, the endpoints or their call control servers always
function as initiators and the NATs always function as responders.
Because SIP (and, for that matter, H.323, RTSP, and other session-
oriented protocols) embed addresses in signaling messages it is
necessary to acquire NAT table mappings before sending an INVITE
(calling party) or a 200 OK (called party). In firewall-only
applications the request may be made before or after the signaling
message is sent, however that entails risking that the application
signaling progresses even if firewall resources are not available.
In these examples and in actual use, the endpoint (or its agent, such
as a call control server) will generally request NAT table entries
only for the address/port tuples on which it will be listening for
incoming media. The case in which requests must be made for mappings
for outbound media is that in which the NAT does not automatically
allocate mappings for new outbound data streams [ETH] i.e. the NAT is
entirely controlled and only creates mappings on explicit request.
In the exceptional case that the NAT is symmetric, both internal and
external addresses will need to be installed to describe a mapping.
12.1. Calling endpoint is NATted, controls firewall
In this example the calling party is NATted but is routing signaling
through a call control server. It is sending AFWC messages to the
firewall itself. For the sake of simplicity the call flow shows the
signaling being sent directly to the called party, however in actual
use it is likely that the signaling would be sent to the called
party's call control server.
Shore & McGrew Expires March 11, 2007 [Page 29]
Internet-Draft AFWC September 2006
Calling Caller's Caller's Called
endpoint NAT CCS Party
| start | | |
|------------->| | |
| | | |
| offer | | |
|<-------------| | |
| | | |
| request | | |
|------------->| | |
| | | |
| response | | |
|<-------------| | |
| | | |
| INVITE | | |
|=============> INVITE | |
| |==============>| INVITE |
| | |===========>|
| | | |
| | | |
| | | 200 OKAY |
| | |<===========|
| 200 OKAY | |
|<=============================| |
| | | |
| | | |
12.2. Calling endpoint is NATted, CCS controls firewall
In this example the calling endpoint is NATted, as well, however the
call control server is sending AFWC requests to the firewall/NAT.
Note that in this example the call control server is topologically
"outside" the firewall, which has implications for assumptions about
trust relationships and suggests that the notion of a "trusted
interface" cannot be relied upon in this case.
Shore & McGrew Expires March 11, 2007 [Page 30]
Internet-Draft AFWC September 2006
Calling Caller's Caller's Called
endpoint NAT CCS Party
| INVITE | |
|=============================>| |
| | | |
| | start | |
| |<--------------| |
| | | |
| | offer | |
| |-------------->| |
| | | |
| | request | |
| |<--------------| |
| | | |
| | response | |
| |-------------->| |
| | | |
| | | INVITE |
| | |===========>|
| | | |
| | | 200 OKAY |
| | |<===========|
| 200 OKAY | |
|<=============================| |
| | | |
| | | |
12.3. Called endpoint NATted
In this case the called party is NATted but its call control server
is accessible. The INVITE is sent to the called party's call control
server, which forwards it to the called party. Note that the call
control server cannot use AFWC to acquire a NAT table mapping until
it has received the 200 response from the called endpoint; this is
because it needs to send the address/port tuple on which the endpoint
expects to receive media as part of the AFWC request.
Shore & McGrew Expires March 11, 2007 [Page 31]
Internet-Draft AFWC September 2006
Calling Called party's Called Party's Called
endpoint CCS NAT Party
| INVITE | | |
|=============> | |
| | INVITE |
| |===========================>|
| | | |
| | 200 OKAY |
| |<===========================|
| | | |
| | start | |
| |-------------->| |
| | | |
| | offer | |
| |<--------------| |
| | | |
| | request | |
| |-------------->| |
| | | |
| | response | |
| |<--------------| |
| | | |
| | | |
| 200 OKAY | | |
|<=============| | |
| | | |
| | | |
Shore & McGrew Expires March 11, 2007 [Page 32]
Internet-Draft AFWC September 2006
13. Failover
This application does not define its own failover system, and instead
recommends that firewalls use the failover mechanisms that they have
in place. A firewall may not be able to retain pinholes across
reboots. However, if the firewall implements a checkpointing or
standby feature, the pinholes SHOULD be included in the state that is
checkpointed or duplicated on the standby system. The AFWC protocol
allows for a hot-standby system by allowing one device to respond on
behalf of another (assuming that the standby device is properly
authenticated and authorized). This feature should allow existing
standby systems to implement the AFWC without any additional changes.
It may be desirable to introduce a secure mechanism by which a
controller can discover if a firewall has reloaded. One way to do
this would be to use a 128-bit EPOCH value, which the firewall
selects randomly at boot time. By including an EPOCH element in the
Offer, the firewall could securely convey the current epoch to the
controller. By retaining and comparing epoch values, a controller
can detect if a firewall has reloaded.
Shore & McGrew Expires March 11, 2007 [Page 33]
Internet-Draft AFWC September 2006
14. Security Considerations
Shore & McGrew Expires March 11, 2007 [Page 34]
Internet-Draft AFWC September 2006
Appendix A. Acknowledgements
The authors would like to thank Raghu Gyambavantha, Eric Wang, and
Jan Vilhuber for their comments and suggestions.
Shore & McGrew Expires March 11, 2007 [Page 35]
Internet-Draft AFWC September 2006
Authors' Addresses
Melinda Shore
Cisco Systems
809 Hayts Road
Ithaca, New York 14850
USA
Email: mshore@cisco.com
David A. McGrew
Cisco Systems
510 McCarthy Blvd
Milpitas, California 95035
USA
Email: mcgrew@cisco.com
Shore & McGrew Expires March 11, 2007 [Page 36]
Internet-Draft AFWC September 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Shore & McGrew Expires March 11, 2007 [Page 37]