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

Versions: 00

Network Working Group                                           M. Shore
Internet-Draft                                             Cisco Systems
Expires: August 30, 2006                               February 26, 2006


                      The NLS Firewall Application
                       draft-shore-nls-fw-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 August 30, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The Network Layer Signaling Transport Layer provides a generalized
   packetization and messaging framework for on-path signaling.  It is
   designed to carry a variety of "applications."  This document
   describes a lightweight firewall pinholing application, designed to
   carry requests for firewall resources to firewalls along a path
   between two endpoints.






Shore                    Expires August 30, 2006                [Page 1]


Internet-Draft        The NLS Firewall Application         February 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  NLS Firewall Messages  . . . . . . . . . . . . . . . . . . . .  4
     2.1.  The NLS-FW Header  . . . . . . . . . . . . . . . . . . . .  4
       2.1.1.  Message Types  . . . . . . . . . . . . . . . . . . . .  4
       2.1.2.  Version  . . . . . . . . . . . . . . . . . . . . . . .  5
       2.1.3.  Length . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  NLS-FW TLVs  . . . . . . . . . . . . . . . . . . . . . . .  5
       2.2.1.  Network Access Identifier: Type=1  . . . . . . . . . .  6
       2.2.2.  Request TLV: Type=2  . . . . . . . . . . . . . . . . .  6
       2.2.3.  Lifetime TLV: Type=3 . . . . . . . . . . . . . . . . .  9
       2.2.4.  Response TLV: Type=4 . . . . . . . . . . . . . . . . . 10
       2.2.5.  Alert TLV: Type=5  . . . . . . . . . . . . . . . . . . 11
       2.2.6.  Teardown TLV: Type=6 . . . . . . . . . . . . . . . . . 11
   3.  NLS-FW Messaging Procedures  . . . . . . . . . . . . . . . . . 13
     3.1.  Sending a Request  . . . . . . . . . . . . . . . . . . . . 13
     3.2.  Firewall Request Processing Procedures . . . . . . . . . . 13
       3.2.1.  Alternative Firewall Processing Procedures . . . . . . 14
     3.3.  Sending a Response . . . . . . . . . . . . . . . . . . . . 14
     3.4.  Alert Messages . . . . . . . . . . . . . . . . . . . . . . 14
     3.5.  Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
     4.1.  Attacks Against Requests . . . . . . . . . . . . . . . . . 16
     4.2.  Attacks Against Responses  . . . . . . . . . . . . . . . . 16
     4.3.  Attacks Against Alerts . . . . . . . . . . . . . . . . . . 16
     4.4.  Topology Exposure  . . . . . . . . . . . . . . . . . . . . 16
     4.5.  Denial of Service  . . . . . . . . . . . . . . . . . . . . 17
   5.  Proxies  . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
     6.1.  NLS-FW Message Types . . . . . . . . . . . . . . . . . . . 19
     6.2.  NLS-FW TLVs  . . . . . . . . . . . . . . . . . . . . . . . 19
     6.3.  NLS-FW Request Subtypes  . . . . . . . . . . . . . . . . . 19
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 20
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 22













Shore                    Expires August 30, 2006                [Page 2]


Internet-Draft        The NLS Firewall Application         February 2006


1.  Introduction

   The Network Layer Signaling Transport Protocol [Shore] provides a
   generalized transport for carrying signaling messages between two
   endpoints.  By "signaling messages" we mean messages intended to be
   intercepted and interpreted by network devices through which the
   message is routed.

   In the firewall NLS application, the messages are requests for
   firewall pinholes.  An endpoint wishing firewall pinholes for a
   particular data stream sends a message towards the other endpoint of
   that stream.  The message contains a description of the pinhole(s)
   along with associated information which may be used as the basis for
   granting or denying the request (i.e. authorization policy data).
   When a firewall intercepts the message it extracts the request,
   verifies the authentication, and either authorizes or denies the
   pinhole request based on local security policy.



      +--------+      +------------+    +--------+
      | Host A |----->| Firewall A |--->| Host B |
      +--------+      +------------+    +--------+



   Figure 1

   Design goals for NLS-FW include:

   o  Low messaging overhead

   o  Low endpoint memory consumption

   o  Minimal retained state not directly associated with firewall
      resources

   o  Clean, robust NAT interactions

   o  Supporting, rather than bypassing, local security policy

   Throughout this document we refer to the endpoint initiating the
   Request as the "sender" and its peer endpoint as the "receiver,"
   using the terminology from RSVP [RFC2205].







Shore                    Expires August 30, 2006                [Page 3]


Internet-Draft        The NLS Firewall Application         February 2006


2.  NLS Firewall Messages

   NLS Firewall messages are encapsulated in NLS-TL messages and sent
   with NLS-TL Application ID = 3.

   The NLS-FW packet format is:


      +-------------+-------------+-------------+-------------+
      |                      NLS-FW header                    |
      +-------------+-------------+-------------+-------------+
      |                                                       |
      //                        payload                      //
      //                                                     //
      |                                                       |
      +-------------+-------------+-------------+-------------+


   Figure 2

2.1.  The NLS-FW Header

   The NLS-FW header format is:


      +-------------+-------------+-------------+-------------+
      |   msg type  |   version   |          length           |
      +-------------+-------------+-------------+-------------+


   Figure 3

2.1.1.  Message Types

   The Message Type field is one octet in length.  There are three NLS
   Firewall message types:

   o  Request = 1

   o  Response = 2

   o  Alert = 3

   The Request message carries the firewall request from the sender
   towards its peer reciever, and includes a description of the firewall
   resources (pinhole) being requested.  The message is constructed by
   the sender and MAY NOT be modified by intermediate nodes.




Shore                    Expires August 30, 2006                [Page 4]


Internet-Draft        The NLS Firewall Application         February 2006


   The Response message carries the results of the request.  It is
   constructed by the receiver and sent towards the sender, and it MAY
   be modified by intermediate nodes.

   The Alert message is used to carry asynchronous notifications from
   firewalls to the sender, and MAY NOT be modified by intermediate
   nodes.  By "asynchronous" we mean that the messages are initiated by
   the firewalls and are not necessarily sent in response to request
   messages.

2.1.2.  Version

   The Version field is one octet in length and carries the NLS-FW
   version number.  The current version number is 1.

2.1.3.  Length

   The Length Field is two octets in length and carries the length in
   octets of the entire NLS-FW message payload, including the NLS-FW
   header.  It does NOT include the transport layer header.

2.2.  NLS-FW TLVs

   NLS-FW data elements are carred in {type,length,value} tuples (TLVs).
   Some of these data elements are appropriate only for particular types
   of NLS-FW messages, while others may be more generally applicable.

   The TLV format is:


      +-------------+-------------+-------------+-------------+
      |R|R|        type           |           length          |
      +-------------+-------------+-------------+-------------+
      //                      data element                   //
      +-------------+-------------+-------------+-------------+


   Figure 4

   where the fields are:

   Reserved:  The first two bits of the TLV are reserved for future use,
      to maintain compatibility with other TLV formats

   Type:  Identifier describing the TLV.  This is maintained through a
      registry (IANA)





Shore                    Expires August 30, 2006                [Page 5]


Internet-Draft        The NLS Firewall Application         February 2006


   Length:  The length of the TLV in octets, including the TLV header

   Data Element:  The actual content of the data element.  The data
      elements are described below

2.2.1.  Network Access Identifier: Type=1

   The Network Access Identifier (NAI) is a mandatory data element to be
   included in each NLS-FW payload as the first element following the
   NLS-FW header.  The format is described in [RFC2486], and it is
   carried in the NLS-FW message as follows:


      +-------------+-------------+-------------+-------------+
      |          length           |            NAI            |
      +-------------+-------------+-------------+-------------+
      //                         NAI                         //
      +-------------+-------------+-------------+-------------+


   Figure 5

   Length:  The length of the NAI in octets, NOT including the length
      field

   NAI:  A variable-length field carrying Network Access Identifier
      representing the user on behalf of whom the firewall resources are
      being requested.  This is usually also the sender of the NLS-FW
      request message, but not always (for example, when the request is
      being proxied)

2.2.2.  Request TLV: Type=2

   [Note: the request TLV format is flexible and can carry a variety of
   request types -- several payload formats are proposed here but-- they
   should not be construed as final or complete.]

   The request TLV consists of one or more descriptions of firewall
   resources (pinholes, usually) being requested.  It MAY NOT be carried
   in a Response Message.  There are several pinhole request formats.

   The request TLV uses the format shown in Figure 6.









Shore                    Expires August 30, 2006                [Page 6]


Internet-Draft        The NLS Firewall Application         February 2006


      +-------------+-------------+-------------+-------------+
      | req subtype |    flags    |          length           |
      +-------------+-------------+-------------+-------------+
      |                     pinhole ID                        |
      +-------------+-------------+-------------+-------------+
      |                                                       |
      //                   pinhole request                   //
      |                                                       |
      +-------------+-------------+-------------+-------------+


   Figure 6

   The fields are:

   Request Subtype:  the type of pinhole request contained in the
      payload.  See below.

   Flags:  flags for the request, as follows



         0x01 DENIED: at least one firewall along the path has denied
         the request

   Length:  the length in octets of the request, including the header

   pinhole ID:  a 32-bit random identifier to be used as a reference for
      the pinhole.

   Pinhole request:  the pinhole request itself

2.2.2.1.  Pinhole Descriptor: Subtype=1


      +-------------+-------------+-------------+-------------+
      |                    Internal address tag               |
      +-------------+-------------+-------------+-------------+
      |                    External IPv4 address              |
      +-------------+-------------+-------------+-------------+
      |                    External IPv4 netmask              |
      +-------------+-------------+-------------+-------------+
      | Protocol Id |   unused    |      External port        |
      +-------------+-------------+-------------+-------------+
      |  ICMP type  |  ICMP code  |          Options          |
      +-------------+-------------+---------------------------+





Shore                    Expires August 30, 2006                [Page 7]


Internet-Draft        The NLS Firewall Application         February 2006


   A Pinhole descriptor resembles a traditional firewall pinhole
   descriptor, with addresses, port numbers, TCP flags, and so on, and
   is derived from the Diameter [RFC3588] IPFilterRule AVP.  It differs
   from the traditional descriptor in its use of NLS tagged addresses
   (see XXX).

   Because NLS-FW is designed for pinholing along a path between two
   endpoints, wildcarding on internal addresses is not permitted.  That
   would be a configuration function, and firewall configuration is
   outside the scope of this protocol.  However, wildcarding is
   supported on "external"/foreign addresses to provide some flexibility
   as needed.

   The fields are as follows:

   Internal address tag:  The address tag to identify the address/port/
      protocol tuple being carried in a NAT_ADDRESS TLV in the NLS-TL
      header.  See section XXX.

   External IPv4 address:  The external address to be installed in this
      pinhole.

   External IPv4 netmask:  The network address mask for the external
      address in this pinhole, to allow network wildcarding.

   Protocol ID:  The IP protocol number.

   External port:  The TCP, UDP, or SCTP port number for the external
      address in this pinhole.

   ICMP type:  The ICMP type and ICMP code fields are ignored unless the
      ICMP bit is set in the options field.

   Options:  A subset of IP and TCP options.  See Figure 8



        FRAG                 . . . . . . . . . . . . . . . x
        SSRR                 . . . . . . . . . . . . . . x .
        LSRR                 . . . . . . . . . . . . . x . .
        RR                   . . . . . . . . . . . . x . . .
        TCPESTABLISHED       . . . . . . . . . . . x . . . .
        TCPSETUP             . . . . . . . . . . x . . . . .
        ICMP                 . . . . . . . . . x . . . . . .


   Figure 8




Shore                    Expires August 30, 2006                [Page 8]


Internet-Draft        The NLS Firewall Application         February 2006


      When the FRAG bit is set, match if the packet is a fragment but
      not the first fragment of a datagram.

      When the SSRR bit is set, match if the strict source route IP
      option is set.  The LSRR bit is used to indicate the loose source
      route IP option, and RR is used to indicate the record route IP
      option.

      TCPESTABLISHED is used to match TCP packets that have the RST or
      ACK bits set.  It is meaningless for non-TCP packets and the
      middlebox SHOULD return a "malformed request" error if it receives
      a request in which this bit is set but the protocol is not TCP.

      TCPSETUP is used to match TCP SYN packets.  It is meaningless for
      non-TCP packets and the middlebox SHOULD return a "malformed
      request" error if it receives a request in which this bit is set
      but the protocol is not TCP.

      The ICMP type and ICMP code fields are ignored unless the ICMP bit
      is set in the options field.

2.2.2.2.  Offset descriptor: Subtype=2


      +-------------+-------------+-------------+-------------+
      |          Offset           |          Length           |
      +-------------+-------------+-------------+-------------+
      //                        Value                        //
      +---------------------------+-------------+-------------+


   This object allows senders to request filtering on arbitrary values
   at arbitrary offsets from the start of the IP packet.  For example,
   this could be used to carry an IPSec SPI, which would allow filtering
   requests on encapsulated packets.

   Offset is a 16-bit value representing the number of octets from the
   start of the IP packet at which to begin the comparison.  Length is a
   16-bit value representing number of length in octets of the value to
   be compared against, and Value is a variable-length field carrying
   the Value itself.

2.2.3.  Lifetime TLV: Type=3

   The Lifetime structure is a 32-bit value which carries the duration
   for which the pinhole is being requested, expressed in seconds.





Shore                    Expires August 30, 2006                [Page 9]


Internet-Draft        The NLS Firewall Application         February 2006


      +-------------+-------------+-------------+-------------+
      |                       lifetime                        |
      +-------------+-------------+-------------+-------------+


2.2.4.  Response TLV: Type=4

   A Response TLV is used to return the results of a Pinhole Request
   back to the sender.  It is typically originated by the receiver,
   although in some cases it may be generated by a firewall within the
   network or by a proxy (see below).

   Its format is:


      +-------------+-------------+-------------+-------------+
      |                     pinhole ID                        |
      +-------------+-------------+-------------+-------------+
      |                         flags                         |
      +-------------+-------------+-------------+-------------+


   Figure 11

   The fields are:

   Pinhole ID:  the 32-bit random identifier contained in the request

   Flags:  Indicates success or failure, optionally including reason
      indicators:



         0x0000 success

         0x0001 failure, no reason given

         0x0002 malformed request

         0x0004 unauthorized operation

         0x0008 resources unavailable

      Flags may be OR'ed together







Shore                    Expires August 30, 2006               [Page 10]


Internet-Draft        The NLS Firewall Application         February 2006


2.2.5.  Alert TLV: Type=5

   An Alert TLV is used to carry Alert messages from firewalls to
   senders.  Its format is:


      +-------------+-------------+-------------+-------------+
      |    Type     |                 Code                    |
      +-------------+-------------+-------------+-------------+


   where the fields are:

   Type:  a one-octet field containing the message from the firewall to
      the sender.

   Code:  a three-octet field containing additional information related
      to the code

   The Types and Codes are:

   0x01:  Request denied
      0x001: Authorization denied
      0x002: Authentication failure
      0x003: Resources unavailable
      0x004: Malformed request
      0x005: No such resource exists

   0x02:  Pinhole deleted
      0x001: Time expired
      0x002: Resources exhausted

   0x03:  Pinhole will be deleted
      Number of seconds until deletion

   An Alert message of type 0x00 is invalid and MUST be ignored.

2.2.6.  Teardown TLV: Type=6

   The Teardown TLV is sent in a Request message, asking the firewall to
   delete the pinhole in the Pinhole ID.


      +-------------+-------------+-------------+-------------+
      |                       Pinhole ID                      |
      +-------------+-------------+-------------+-------------+





Shore                    Expires August 30, 2006               [Page 11]


Internet-Draft        The NLS Firewall Application         February 2006


   where Pinhole ID is the Pinhole ID of the pinhole the firewall is
   being asked to delete.

















































Shore                    Expires August 30, 2006               [Page 12]


Internet-Draft        The NLS Firewall Application         February 2006


3.  NLS-FW Messaging Procedures

3.1.  Sending a Request

   An endpoint wishing to request firewall pinholes along a path between
   itself and another endpoint will send an NLS-FW Request Message
   addressed to the endpoint.

   The format of an NLS-FW message is:

   o  NLS-FW header, followed by

   o  NAI, followed by

   o  One or more firewall pinhole requests

   Those messages SHOULD be sent with the BUILD-ROUTE bit set in the
   NLS-TL header.  This allows the creation of a pinned route, which
   improves error handling and the response when a request is denied
   (see XXX).

   The DENIED flag in each request header MUST be set to 0x0.

   Multiple Request payloads MAY be included in each Request message.

3.2.  Firewall Request Processing Procedures

   When an NLS-capable firewall receives an NLS message, it examines the
   application TLVs to determine whether or not it contains an NLS-FW
   payload.  If it does, it passes the payload, along with its
   associated NLS-TL NAT TLVs, to the NLS firewall application.

   The firewall application examines the request and, based on policy,
   determines whether or not it will grant the request.

   If the request is not granted, the DENIED flag MUST be set to 1.  The
   firewall MAY choose to send an Alert message directly back to the
   sender (originator) of the request.  However, in doing so the
   firewall exposes itself to the sender, which would be undesirable in
   cases where the network administrators wish to hide network topology,
   particularly the location of firewalls.

   A firewall denying a request MAY also add a reason by either
   inserting a Response TLV into the Request message if one is not
   already present, or by turning on the appropriate reason bits if one
   is already present.  It MAY NOT turn off any bits that are already
   on.




Shore                    Expires August 30, 2006               [Page 13]


Internet-Draft        The NLS Firewall Application         February 2006


   Whether or not the request is granted, the NLS Transport Layer writes
   the hop information into the NLS-TL header and sends the request on
   towards the receiver.

3.2.1.  Alternative Firewall Processing Procedures

   The procedures described in the preceding section allow for what are
   essentially "discovery" procedures.  That is to say that all
   participating firewalls along the path are queried and they have the
   option of sending an alert back to the sender explaining the cause of
   the failure.

   It may be the case, however, that conserving bandwidth is a priority
   or that there is absolutely no desire to allow firewalls to send
   alerts back to the sender.  In that circumstance the first firewall
   that denies a request MAY return a response message towards the
   sender following the procedures described in Section 3.3.

3.3.  Sending a Response

   When a receiver or its proxy receives an NLS-FW Request message, it
   is responsible for generating a Response message and sending it back
   towards the sender.

   A response message consists of a NLS-FW header with Message Type set
   to Response, followed by the NAI included in the Request message,
   followed by one or more Response TLVs.  There MUST be one response
   for each pinhole request in the Request message.  If there is a
   Response TLV for a pinhole present in the Request message, that
   Response TLV MUST be copied exactly into the Response Message.  There
   MUST NOT be more than one Response TLV for each pinhole requested.

3.4.  Alert Messages

   A firewall MAY send unsolicited messages to the endpoint (or its
   proxy) that sent a request.  This may be in response to a request, or
   to send information about the status of an established firewall
   pinhole.  Alert messages MUST always be sent from the firewall to the
   sender.  They MUST NOT be sent by the sender or receiver, and they
   MUST NOT be sent from the firewall to the receiver.

   An alert message carries optional information which the firewall MAY
   wish to convey to the endpoint.  It is addressed to the sender's NLS
   signaling port as an NLS-FW message of type Alert (Type=3).  It
   contains an Alert TLV, described in Section 2.2.5






Shore                    Expires August 30, 2006               [Page 14]


Internet-Draft        The NLS Firewall Application         February 2006


3.5.  Teardown

   The circumstances under which a firewall pinhole may be deleted
   include:

   o  The requested lifetime has expired

   o  Timers local to the firewall (idle timer, for example) have
      expired

   o  The firewall needs to release resources to protect itself against
      attack

   o  The sender explicitly requests that a pinhole be deleted before
      its lifetime expires

   The Teardown TLV is used for explicit pinhole deletion requests.  A
   Teardown TLV MAY be carried in the same NLS-FW message as Pinhole
   Requests, but if it has the same Pinhole ID as a Pinhole Request in
   the same NLS-FW message, the request MUST be denied.  If an Alert
   message is sent to notify the sender, the Type MUST be "Request
   denied" and the Code MUST be "Malformed request (0x004)".





























Shore                    Expires August 30, 2006               [Page 15]


Internet-Draft        The NLS Firewall Application         February 2006


4.  Security Considerations

   A protocol which requests firewall resources is necessarily extremely
   sensitive.  It provides the opportunity to both violate network
   security policy and to commit denial-of-service attacks against on-
   path firewalls.

   The NLS Transport Layer provides hop-by-hop authentication for
   transport layer purposes, but it is inadequate to provide appropriate
   protection against the attacks described below.

   [Ed. note: Cryptographic mechanisms will be specified in the next
   version of this document]

4.1.  Attacks Against Requests

   The most obvious and potentially most dire attack against the Request
   facility is exploiting the ability to create firewall pinholes in
   order to allow unauthorized traffic through the firewall.  The
   Request Message MUST be authenticated.  It MUST be integrity
   protected in order to prevent an attacker along the path from
   modifying the request.

   Protection SHOULD also be provided against denial-of- service attacks
   (see Section 4.5

4.2.  Attacks Against Responses

   The primary attack against response messages is a denial-of-service
   attack, in which a false response reports the failure to create the
   requested pinholes.  The Response message MUST be authenticated and
   integrity-protected by the receiver.

4.3.  Attacks Against Alerts

   An attacker may send a bogus Alert message to inform a sender that a
   pinhole has been torn down when, in fact, it has not been.  Alert
   messages MUST be authenticated and integrity-protected.

4.4.  Topology Exposure

   Both service providers and enterprises are frequently reluctant to
   deploy a protocol which might expose information about the topology
   of their network, and in particular the location of their firewalls
   and other security devices.

   One of the advantages of the messaging model used by NLS-FW is that
   network topology may be completely concealed.  That is to say, the



Shore                    Expires August 30, 2006               [Page 16]


Internet-Draft        The NLS Firewall Application         February 2006


   only address that the endpoint has is the address of its peer for
   which it is requesting the pinhole.  A firewall MAY choose to reveal
   its location by sending an Alert message, but that is optional.

   Note that when Alert messages are used, an attacker may be able to
   discover firewall location or other topology information by injecting
   Request messages he knows will fail (for example, the authentication
   is incorrect) in order to force the firewall to return an Alert
   message.  The use of Alerts should be considered carefully, and in
   some cases local policy may be used to determine whether or not an
   Alert should be sent.  For example, Alerts may be sent in response to
   Requests arriving on inward-facing interfaces, but not outward-facing
   interfaces.

4.5.  Denial of Service

   Denial of service attacks are typically either attacks that consume
   all available resources or attacks that disable a device by making it
   unavailable (for example, an unauthorized shutdown).  The second type
   of attack is primarily operational (inside the box), and so we are
   primarily concerned with protecting resources.

   One common mechanism for executing denial of service attacks is to
   consume state.  Firewalling is an inherently stateful operation, and
   because NLS-FW is used to create and maintain firewall state care
   must be taken to protect against the use of NLS-FW to exhaust
   firewall resources.  In particular, we are concerned about protecting
   against exhausting the available pinhole/filter state, and about
   protecting against an unmanageable computational load being caused by
   an excessively large number of cryptographic operations.

   [stick drop strategy discussion here]



















Shore                    Expires August 30, 2006               [Page 17]


Internet-Draft        The NLS Firewall Application         February 2006


5.  Proxies

   Both the sender and receiver may be proxied in those cases where
   there is a desire to offload firewall signaling from endpoints.  When
   NLS-FW requests are proxied, the proxy will need to "know" which
   addresses and ports need firewall resources.  That suggests that
   either the proxy must be participating in the session (for example, a
   VoIP call control server) or that it can sniff signaling traffic.
   The latter case is somewhat fraught, since 1) the application traffic
   will have to be travelling in the clear or the proxy will have to
   have access to keying material that would allow it to decrypt the
   application traffic, and 2) the application would not have access to
   the results of the NLS-FW request, and in particular would not know
   not to continue if the request were denied.

   Because NLS-FW is a path-oriented signaling protocol, the proxy would
   need to be placed in a topologically-appropriate location.  In
   particular it would need to be behind the same set of firewalls as
   the endpoint for which it is acting as a proxy.
































Shore                    Expires August 30, 2006               [Page 18]


Internet-Draft        The NLS Firewall Application         February 2006


6.  IANA Considerations

   Because NLS-FW is carried as an NLS-TL application, TCP and/or UDP
   port numbers are unnecessary.  However, the NLS-FW Application ID (3)
   must be registered.

   Registries should be established for NLS-FW message types, TLVs, and
   firewall request subtypes.  Initial values are given below.

6.1.  NLS-FW Message Types


       NAME        VALUE        DEFINITION

       Request       1          See
       Response      2          See
       Alert         3          See


6.2.  NLS-FW TLVs


       NAME        VALUE        DEFINITION

       NAI           1          See
       Request       2          See
       Lifetime      3          See
       Response      4          See
       Alert         5          See
       Teardown      6          See


6.3.  NLS-FW Request Subtypes



       NAME                 VALUE        DEFINITION

       pinhole descriptor     1          See
       offset descriptor      2          See











Shore                    Expires August 30, 2006               [Page 19]


Internet-Draft        The NLS Firewall Application         February 2006


7.  References

7.1.  Normative References

   [Shore]  Shore, M., Biswas, K., and D. McGrew, "Network-Layer
            Signaling: Transport Layer", draft-shore-nls-tl-01.txt (work
            in progress), November 2005.

7.2.  Informative References

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier",
              RFC 2486, January 1999.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
































Shore                    Expires August 30, 2006               [Page 20]


Internet-Draft        The NLS Firewall Application         February 2006


Author's Address

   Melinda Shore
   Cisco Systems
   809 Hayts Road
   Ithaca, New York  14850
   USA

   Email: mshore@cisco.com










































Shore                    Expires August 30, 2006               [Page 21]


Internet-Draft        The NLS Firewall Application         February 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                    Expires August 30, 2006               [Page 22]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/