NSIS R. Hancock
Internet-Draft Roke Manor Research
Intended status: Experimental November 17, 2008
Expires: May 21, 2009
Using the Router Alert Option for Packet Interception in GIST
draft-hancock-nsis-gist-rao-00
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 May 21, 2009.
Abstract
The Generic Internet Signalling Transport (GIST) protocol depends on
packet interception to identify the nodes that should participate in
signalling sessions. The base protocol assumes n-tuple analysis of
the packet header as the interception algorithm. This document
describes an experimental extension to GIST to use the Router Alert
Option (RAO) to enhance interception efficiency. It describes the
tradeoffs in using such an approach including the impact on legacy
equipment and protocol deployability, and also the considerations to
be taken into account in selecting values for the RAO value field.
Hancock Expires May 21, 2009 [Page 1]
Internet-Draft RAO for GIST November 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Q-Mode Encapsulation Requirements . . . . . . . . . . . . . . 4
3. Design Space Discussion . . . . . . . . . . . . . . . . . . . 5
4. Compatibility Constraints . . . . . . . . . . . . . . . . . . 6
5. RAO Usage for GIST . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Packet Transmission . . . . . . . . . . . . . . . . . . . 9
5.2. Packet Reception . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Hancock Expires May 21, 2009 [Page 2]
Internet-Draft RAO for GIST November 2008
1. Introduction
The Generic Internet Signalling Transport (GIST) protocol
[I-D.ietf-nsis-ntlp] is designed to provide a general-purpose
messaging layer to carry signalling between end systems and
forwarding nodes (routers, middleboxes, etc.) in the Internet. GIST
supports multiple signalling applications, each of which is
implemented by an NSIS Signalling Layer Protocol (NSLP). GIST
defines a number of different message routing methods to support
different types of signalling: for example, routing signalling
messages along the path taken by a data flow, or routing signalling
messages to an egress gateway of a stub network. These message
routing methods require GIST operation to be aware of the topology of
the underlying infrastructure.
Rather than depending on the availability of global network topology
information, GIST uses packet interception to identify the nodes that
should participate in signalling sessions. Query packets are
injected into the network, encapsulated so they should follow a path
consistent with what is required for the signalling; GIST unaware
nodes are supposed to forward these Query packets as normal data
traffic, while GIST-aware nodes can extract them from the data path
and begin signalling with the Query sender.
The GIST protocol as defined in [I-D.ietf-nsis-ntlp] assumes n-tuple
analysis of the packet header as the interception algorithm. This
document describes an experimental extension to GIST to use the
Router Alert Option (RAO) to enhance interception efficiency. It
describes the tradeoffs in using such an approach, including the
impact on legacy equipment and protocol deployability, and also the
considerations to be taken into account in selecting values for the
RAO value field.
The structure of this document as follows. Section 2 describes the
requirements that GIST has for packet interception in general, and
Section 3 discusses the major alternative approaches and theoretical
tradeoffs. Section 4 describes the issues that arise in practice
with existing equipment and deployment practices, which render the
RAO difficult to use in some networks. The modifications to GIST
operation are given in Section 5, and corresponding IANA
considerations in Section 6. Finally, security considerations are
given in Section 7.
1.1. Requirements Language
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].
Hancock Expires May 21, 2009 [Page 3]
Internet-Draft RAO for GIST November 2008
2. Q-Mode Encapsulation Requirements
The requirements on encapsulation of GIST Q-mode messages can be
considered from two perspectives: functionally, and from the point of
view of the different types of node that have to handle the message.
These requirements apply essentially identically to IPv4 and IPv6.
+--------------+-------------------------+--------------------------+
| | Requirement on non-GIST | Requirement on GIST |
| | nodes | nodes |
+--------------+-------------------------+--------------------------+
| Routing | Must be forwarded in a | Special processing; |
| | way compatible with the | forwarding could take |
| | message routing | into account the |
| | requirements, based | contents of GIST |
| | only on the IP header | payloads |
| Transparency | Packets must be | Only packets that are |
| | forwarded (and not | genuine signalling |
| | dropped) unchanged | packets must be |
| | | intercepted |
| Interception | No interception, and no | Efficiently intercept |
| | or minimal overhead on | those packets related to |
| | passing through the | NSLPs implemented on the |
| | node | node, but forward others |
| | | transparently |
+--------------+-------------------------+--------------------------+
Table 1: Q-Mode Encapsulation Requirements
Note that, to retain some possibility of running GIST through NATs,
the GIST Q-mode encapsulation is fixed as being UDP; this means that
correct routing through non-GIST nodes depends on the assumption that
forwarding is on the basis of the IP header only. There are
additional features of the payload encapsulation that prevent GIST
nodes incorrectly processing non-GIST packets that happen to use the
same port number as GIST. GIST nodes are required to re-inject such
packets onto the forwarding path transparently. All these
requirements are handled by the Q-mode encapsulation rules defined in
the base GIST specification.
One particular requirement that distinguishes GIST from (for example)
RSVP is the requirement to support multiple NSLPs. A GIST node might
implement a single NSLP or it might implement several; it is
extremely unlikely to support all of them (because the set is
extensible). Therefore, the interception requirement for any
specific GIST node is to extract Q-mode messages for a strict subset
of NSLPs, and to forward the other Q-mode messages transparently.
This can be achieved by intercepting all Q-mode messages, and re-
Hancock Expires May 21, 2009 [Page 4]
Internet-Draft RAO for GIST November 2008
injecting irrelevant ones back on to the forwarding path after some
additional GIST processing, which is the behaviour implemented in the
current GIST specification.
3. Design Space Discussion
In this section, we compare two interception approaches:
o Using header n-tuple analysis, namely the use of a specific UDP
destination port. This is the approach of the current GIST
specification.
o Using the Router Alert Option (RAO), defined for IPv4 in [RFC2113]
and IPv6 in [RFC2711]. This is the approach defined
experimentally in this document.
The RAO analysis here makes the assumption that the value field in
the RAO can be assigned non-zero values, and that these values can be
used to filter subclasses of messages. This has long been the case
for IPv6. For IPv4, there are two issues:
o The existence of the necessary IANA registries. These are
established in [RFC5350].
o Whether the router alert is a feasible mechanism for use in the
current Internet, taking into the account the contraints imposed
by existing implementations. Some aspects of this are discussed
in [I-D.rahman-rtg-router-alert-dangerous].
This comparison is obviously not exhaustive. For example, there
could be approaches based on using a new IP protocol number (like
RSVP); however, these are ruled out a priori for NAT traversal
issues. We also ignore non-interception approaches, where a
candidate forwarding node is discovered by some other means (e.g. a
topology database, or traceroute) and addressed directly. (The
latter is considered further in Section 4.)
Consider the handling of various packet/node-type combinations: a
data (non-signalling packet); a non-GIST node handling a signalling
packet; a GIST node handling a signalling packet where it does not
host the NSLP; and a GIST node handling a signalling packet where it
does host the NSLP. The two interception approaches are compared in
the following table:
Hancock Expires May 21, 2009 [Page 5]
Internet-Draft RAO for GIST November 2008
+----------------+--------------------------+-----------------------+
| | Interception on n-tuple | Interception on RAO |
| | analysis | analysis |
+----------------+--------------------------+-----------------------+
| Data packet | Zero cost (n-tuple | Zero cost (RAO not |
| (non-GIST | analysis not performed) | present) |
| node) | | |
| Signalling | Zero cost (n-tuple | Cost to handle and |
| packet | analysis not performed) | forward RAO; possibly |
| (non-GIST | | on slow path |
| node) | | |
| Data packet | Cost to process header | Zero cost (RAO not |
| (GIST node) | n-tuple | present) |
| Signalling | Cost to process header | Cost to read RAO |
| packet (GIST | n-tuple, extract GIST | value and determine |
| node not | header and read NSLPID, | not relevant to local |
| hosting NSLP) | re-inject packet | signalling |
| Signalling | Irrelevant (dominated by | Irrelevant (dominated |
| packet (GIST | other signalling costs) | by other signalling |
| node hosting | | costs) |
| NSLP) | | |
+----------------+--------------------------+-----------------------+
Table 2: Q-Mode Encapsulation Requirements
Clearly, n-tuple analysis is the most favourable for non-GIST nodes;
the impact of using RAO depends on the quality of the RAO
implementation (in particular, whether they are able to filter on
unknown RAO values). The GIST nodes the situation is the opposite:
the n-tuple analysis must be carried out for every packet (not just
signalling ones), and if there is GIST traffic not relevant to the
node then it requires analysis of the GIST payload to detect this.
Note that in theory, the latter step would require UDP checksum
validation; however, ignoring checksum validation for the initial
NSLPID check does not lead to any new error cases. On the other
hand, the mere IP/transport header analysis itself may be expensive,
and this is particularly the case for IPv6 (where getting to the
transport header might require traversing IP destination options).
4. Compatibility Constraints
GIST depends on the transmission of Q-mode packets through the
network, and their interception at GIST-aware nodes. The
requirements for GIST-aware nodes are easy to ensure whichever design
approach is selected, and the issues are of load and extensibility
(see Section 3 above).
Hancock Expires May 21, 2009 [Page 6]
Internet-Draft RAO for GIST November 2008
However, GIST packets will also encounter non-GIST nodes, for which
the requirement of transparent forwarding might not be satisfied. If
non-GIST nodes block Q-mode packets, GIST will not function. It is
always possible for middleboxes to block specific traffic types; by
using a normal UDP encapsulation for Q-mode traffic, GIST allows NATs
at least to pass these messages, and firewalls can be configured with
standard policies. However, for any Q-mode encapsulation using RAO,
this can lead to additional problems. The situation is different for
IPv4 and IPv6.
The IPv4 RAO is defined by [RFC2113], which defines the RAO format
with a 2-byte value field; however, only one value (zero) was
defined, and the IANA registry for further allocations was only
established in [RFC5350]. [RFC2113] states that unknown values
should be ignored (i.e. the packets forwarded as normal IP traffic);
however, it has also been reported that some existing implementations
simply ignore the RAO value completely (i.e. process any packet with
an RAO as though the option value was zero). Therefore, a Q-mode
encapsulation using non-zero RAO values cannot be relied on to make
Q-mode traffic transparent to existing implementations. (Note that
it may still be valuable to be able to allocate non-zero RAO values
for IPv4: this makes the interception process more efficient for
nodes which do examine the value field, and makes no difference to
nodes which - incorrectly - ignore it. Whether or not non-zero RAO
values are used does not change the GIST protocol operation, but
needs to be decided when new NSLPs are registered.)
The second stage of the analysis is therefore what happens when a
non-GIST node which implements RAO handling sees a Q-mode packet.
The RAO specification simply states that "Routers that recognize this
option shall examine packets carrying it more closely (check the IP
Protocol field, for example) to determine whether or not further
processing is necessary." There are two possible basic behaviours
for GIST traffic:
1. The "closer examination" of the packet is sufficiently
intelligent to realise that the node does not need to process it
and should forward it. This could either be by virtue of the
fact that the node has not been configured to match IP-
Protocol=UDP for RAO packets at all, or that even if UDP traffic
is intercepted the port numbers do not match anything locally
configured.
2. The "closer examination" of the packet identifies it as UDP, and
delivers it to the UDP stack on the node. In this case, it can
no longer be guaranteed to be processed appropriately. Most
likely it will simply be dropped or rejected with an ICMP error
(because there is no GIST process on the destination port to
Hancock Expires May 21, 2009 [Page 7]
Internet-Draft RAO for GIST November 2008
deliver it to).
Analysis of open-source operating system source code shows the first
type of behaviour, and this has also been seen in direct GIST
experiments with commercial routers, including the case when they
process other uses of the RAO (i.e. RSVP). However, it has also
been reported that other RAO implementations may exhibit the second
type of behaviour. The consequence of this would be that Q-mode
packets are blocked in the network and GIST could not be used. Note
that although this caused by some subtle details in the RAO
processing rules, the end result is the same as if the packet was
simply blocked for other reasons (for example, many IPv4 firewalls
drop packets with options by default). Because of these issues, even
where a GIST extension is defined for using RAO for Q-mode, it will
be necessary to handle cases where signalling paths encounter nodes
which block Q-mode traffic in IPv4. There are essentially two
options. Which of these options to use would be a matter of
implementation and configuration choice.
o A GIST node can be configured to fall back to the base Q-mode
encapsulation, sending packets without the RAO at all. This
should avoid the above problems, but should only be done if it is
known that nodes on the path to the receiver are able to intercept
such packets.
o If a GIST node can identify exactly where the packets are being
blocked (e.g. from ICMP messages), or can discover some point on
the path beyond the blockage (e.g. by use of traceroute or by
routing table analysis), it can send the Q-mode messages to that
point using IP-in-IP tunelling without any RAO. This bypasses the
input side processing on the blocking node, but picks up normal
GIST behaviour beyond it.
If in the light of deployment experience the problem of blocked
Q-mode traffic turns out to be widespread and these techniques turn
out to be insufficient, a further possibility is to define another
alternative Q-mode encapsulation which does not use UDP. This would
require another specification extension. Such an option would be
restricted to network-internal use, since operation through NATs and
firewalls would be much harder with it.
The situation with IPv6 is rather different, since in that case the
use of non-zero RAO values is well established in the specification
and an IANA registry exists. The main problem is that several
implementations are still immature: for example, some treat any RAO-
marked packet as though it was for local processing without further
analysis. Since this prevents any RAO usage at all (including the
existing standardised ones) in such a network, it seems reasonable to
Hancock Expires May 21, 2009 [Page 8]
Internet-Draft RAO for GIST November 2008
assume that such implementations will be fixed as part of the general
deployment of IPv6. Concerns about router load as discussed in
[I-D.rahman-rtg-router-alert-dangerous] continue to apply.
5. RAO Usage for GIST
5.1. Packet Transmission
For the MRMs defined in [I-D.ietf-nsis-ntlp], this extension requires
that a Router Alert Option be included in all Q-mode packets, as part
of the IP header. The RAO requirements are the same for IPv4 and
IPv6. The value in the RAO is derived from the interception class
(see Section 6 below).
Implementations MUST provide a global option to enable or disable the
use of RAO, and RAO use MUST be disabled by default. RAO use SHOULD
be enabled in network environments where the use of RAO is considered
safe and where Q-mode packets are not liable to be blocked by legacy
equipment. Implementations MAY provide more fine-grained control,
e.g. to enable/disable RAO use on Q-mode packets on a per-destination
prefix basis, or if peer discovery fails.
5.2. Packet Reception
A node implementing this extension MUST use RAO inspection to make
the initial interception decision, and MUST transparently forward IP
packets containing unknown RAO values or RAO values not related to
interception classes of locally hosted NSLPs. A node MUST also
implement interception logic based based purely on IP-Protocol number
and transport header analysis. A node SHOULD provide a per-interface
option to enable/disable interception based on protocol number and
transport header analysis, and if provided, this option MUST be
enabled by default. The option SHOULD be disabled in network
environments where it is known that other GIST nodes are using RAO on
Q-mode packets.
6. IANA Considerations
Several different RAO values may be used by the NSIS protocol suite.
This GIST extension itself does not allocate any RAO values (for
either IPv4 or IPv6); an assignment is required for each NSLP
interception class (see section 5.3.2 of [I-D.ietf-nsis-ntlp]). The
assignment rationale for interception classes discussed in a separate
document [I-D.nsis-ext].
The effect of this experimental extension for GIST is that IANA must
Hancock Expires May 21, 2009 [Page 9]
Internet-Draft RAO for GIST November 2008
allocate an RAO value for each existing NSIS interception class. If
interception classes are to be allocated by IANA (see
[I-D.nsis-ext]), the IANA procedures must be extended so an RAO value
is allocated whenever a new interception class is created.
For all assignments associated with NSIS, the RAO specific processing
is the same and is as defined by this specification.
7. Security Considerations
A separate document has been prepared
[I-D.rahman-rtg-router-alert-dangerous] with extensive discussion of
security considerations on the general use of the RAO. There are no
additional considerations raised by this specification.
8. Acknowledgements
With thanks to all the participants in NSIS activities.
[I-D.ietf-nsis-ntlp] contains a fairly complete list.
9. Normative References
[I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", draft-ietf-nsis-ntlp-17 (work in
progress), October 2008.
[I-D.nsis-ext]
Manner, J., Bless, R., Loughney, J., and E. Davies, "Using
and Extending the NSIS Protocol Family", draft-nsis-ext-02
(work in progress), November 2008.
[I-D.rahman-rtg-router-alert-dangerous]
Rahman, R. and D. Ward, "Use of IP Router Alert Considered
Dangerous", draft-rahman-rtg-router-alert-dangerous-00
(work in progress), October 2008.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
Hancock Expires May 21, 2009 [Page 10]
Internet-Draft RAO for GIST November 2008
[RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the
IPv4 and IPv6 Router Alert Options", RFC 5350,
September 2008.
Author's Address
Robert Hancock
Roke Manor Research
Old Salisbury Lane
Romsy, Hampshire SO51 0ZN
UK
Email: robert.hancock@roke.co.uk
Hancock Expires May 21, 2009 [Page 11]
Internet-Draft RAO for GIST November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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.
Hancock Expires May 21, 2009 [Page 12]