[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/