Network Working Group                                         H. Soliman
Internet-Draft                                      Elevate Technologies
Intended status: Standards Track                                G. Daley
Expires: August 28, 2008
                                                             S. Krishnan
                                                                Ericsson
                                                       February 25, 2008


           Firewall Control for Public Access Networks (FCON)
                   draft-soliman-firewall-control-01

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 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).











Soliman, et al.          Expires August 28, 2008                [Page 1]


Internet-Draft          Firewall Control Protocol          February 2008


Abstract

   This document proposes a new mechanism that allows end nodes to
   signal its preferences for traffic filters to a firewall function in
   the network or to another node that controls the firewall function in
   the network.


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Protocol operation . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Firewall Scenarios . . . . . . . . . . . . . . . . . . . . . .  9
   5.  PDP Discovery  . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  DHCP extensions  . . . . . . . . . . . . . . . . . . . . . 12
       5.1.1.  PDP Sub-Option Format  . . . . . . . . . . . . . . . . 13
   6.  Authorization Mechanism  . . . . . . . . . . . . . . . . . . . 15
     6.1.  Proof of ownership . . . . . . . . . . . . . . . . . . . . 15
     6.2.  Firewall request policy  . . . . . . . . . . . . . . . . . 16
   7.  Protocol Messages  . . . . . . . . . . . . . . . . . . . . . . 17
     7.1.  The Request Message Format . . . . . . . . . . . . . . . . 17
     7.2.  The Response Message Format  . . . . . . . . . . . . . . . 18
     7.3.  The Init Message . . . . . . . . . . . . . . . . . . . . . 19
     7.4.  The Init Acknowledgement Message . . . . . . . . . . . . . 20
     7.5.  Protocol Options . . . . . . . . . . . . . . . . . . . . . 21
       7.5.1.  The Acknowledgement Option . . . . . . . . . . . . . . 21
       7.5.2.  The Filter Identifier Option . . . . . . . . . . . . . 22
       7.5.3.  The Nonce Option . . . . . . . . . . . . . . . . . . . 23
       7.5.4.  The Timestamp Option . . . . . . . . . . . . . . . . . 24
       7.5.5.  The IP Address Option  . . . . . . . . . . . . . . . . 25
       7.5.6.  The Cookie Option  . . . . . . . . . . . . . . . . . . 27
       7.5.7.  The Public Key Option  . . . . . . . . . . . . . . . . 28
       7.5.8.  The Lifetime Option  . . . . . . . . . . . . . . . . . 29
       7.5.9.  The Certificate Option . . . . . . . . . . . . . . . . 30
       7.5.10. The Digital Signature Option . . . . . . . . . . . . . 31
   8.  Establishing a Secure Connection . . . . . . . . . . . . . . . 34
   9.  Creating New entries . . . . . . . . . . . . . . . . . . . . . 35
   10. Updating Entries . . . . . . . . . . . . . . . . . . . . . . . 37
   11. Requesting an IPv4 Address . . . . . . . . . . . . . . . . . . 38
   12. Timeouts and Retransmissions . . . . . . . . . . . . . . . . . 39
     12.1. Session Start Delays . . . . . . . . . . . . . . . . . . . 39
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 40
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 41
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
   16. Normative References . . . . . . . . . . . . . . . . . . . . . 43
   Appendix A.  Dynamic PDP Discovery (Informative) . . . . . . . . . 45
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47



Soliman, et al.          Expires August 28, 2008                [Page 2]


Internet-Draft          Firewall Control Protocol          February 2008


   Intellectual Property and Copyright Statements . . . . . . . . . . 48


















































Soliman, et al.          Expires August 28, 2008                [Page 3]


Internet-Draft          Firewall Control Protocol          February 2008


1.  Requirements notation

   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 [RFC2119].














































Soliman, et al.          Expires August 28, 2008                [Page 4]


Internet-Draft          Firewall Control Protocol          February 2008


2.  Introduction

   The need for network protection has led operators to deploy firewalls
   with typical configurations that limit the traffic coming into or out
   of a network to the administrators configuration.  An administrators
   configuration is typically static and affects all users within the
   network.  While such security measure is regarded as successful and
   is widely deployed, it has several drawbacks from a user and network
   operator's points of view.  The assumption in such deployments is
   that there is a common configuration that satisfies all users.  That
   is, the same type of applications are used by all network users and
   that all users do not need to be reachable unless they initiate a
   connection.  Alternatively, in some deployment scenarios, e.g.  IP
   Multimedia System (IMS) in 3GPP, the assumption is that externally
   initiated connection will use a signaling protocol, through local
   proxies, and therefore a local firewall can be manipulated by such
   proxies to allow such connections.  Another assumption in deploying
   firewalls is that there is a Trusted side (the administrator's
   network) and an Untrusted side (The Internet).  This is reasonable in
   a network where you assume no one on the inside of the network would
   intentionally try to attack the network infrastructure.

   The assumptions above are clearly workable in a network where there
   is a defined behaviour for the users.  For instance enterprise
   network users can easily be told what applications and protocols are
   acceptable for the users according to company policy.  However, in a
   public network, such restrictions cannot be made without introducing
   serious limitations on users.  Furthermore, in a public network, one
   can no longer assume that users on the inside are trusted.  This is
   especially true in networks with anonymous users as well as users who
   may not be competent in protecting their own infrastructure.

   The need for firewalling traffic still exists in public networks.
   Operators may wish to provide general protection for their
   infrastructure and users.  At the same time, there is a clear need
   for flexibility in order to allow users a high degree of freedom in
   choosing the applications and protocols that they want to run.  The
   firewall function may also be located closer to the user than the
   traditional deployment of firewalls on the core edge of the network.
   This allows for greater scalability by allowing the firewall function
   to serve a smaller number of users, which reduces bottlenecks in the
   core.  This is particularly useful for IPv6 networks where there
   should be no need for Network Address Translators.

   To allow for a more flexible firewall deployment, both in the
   location and configuration of the firewall, this document proposes a
   new mechanism that allows end nodes to signal its preferences for
   traffic filters to a firewall function in the network or to another



Soliman, et al.          Expires August 28, 2008                [Page 5]


Internet-Draft          Firewall Control Protocol          February 2008


   node that controls the firewall function in the network.  The
   mechanism introduced in this document allows for a high degree of
   fexibility and security.  A generic mechanism for firewall control
   has the following advantage:

   o  Removes the reliance on specific application proxies for
      signalling to allow incoming connections.

   o  Allows easy deployment of new services without requiring specific
      application gateways.

   o  Allows easy deployment of new protocols that may not be known to
      the firewall and would otherwise be blocked.

   o  Allows maximum user control, which provides the finest granularity
      for firewall configuration.

   One of the approaches for firewall control can be found in
   [I-D.ietf-nsis-nslp-natfw].  However, this approach assumes a form of
   pre-established trust.  With mobility becoming the norm on the
   Internet, it is difficult to assume trust without the use of global
   Public Key Infrastructure (PKI), which is not available today.  Other
   approaches to firewall control include the presence of application
   proxies that are either colocated or physically separate from the
   firewall.  The mechanism introduced in this document allows end nodes
   to signal their preferences directly to the firewall, or to another
   entity that controls the firewall.  Hence, this mechanism allows
   network operators to continue the use of application proxies that
   control the firewall, while adding this new mechanism as a generic
   option.





















Soliman, et al.          Expires August 28, 2008                [Page 6]


Internet-Draft          Firewall Control Protocol          February 2008


3.  Protocol operation

   The FCON protocol allows nodes to send its preferences to a Policy
   Decision Point (PDP) in order to configure a firewall with those
   preferences.  The PDP may be located anywhere in the network,
   including the access router sharing the node's link.  Furthermore, it
   may be colocated with the firewall.  FCON allows the node to create
   new entries, add entries, as well as, modify or delete existing
   entries.  FCON uses ICMP for transporting its messages between the
   node in question and the PDP.  FCON can also be used to request the
   allocation of a unique IPv4 address and one or more port numbers by a
   Network Address Translator (NAT).

                                         |
                                         |
   +--------+                       +---------+
   |  PDP   |  2.PDP/PEP Protocol   |Firewall/|
   |        |<--------------------->|   NAT   |
   +--------+     (out of scope)    +---------+
       ^                                 |
       |                                 |
       | 1. FCON Protocol                |
       |                                 |
       |                                 |
   +--------+     3. Data Stream         |              +--------+
   | IPv6   |--------------------------->O------------->| Peer   |
   | Node   |                      <-----O--------------|  Node  |
   +--------+                            |              +--------+
                                         |


                   Figure 1: Communication architecture

   Nodes that implement FCON first need to discover the IP address of
   the PDP in order to send future messages.  The PDP's address is
   either included in a router advertisement option or a new DHCPv6
   option.  Alternative discovery mechanisms are described in Appendix
   A.  Following the discovery phase, a node may start sending messages
   to the PDP requesting that certain protocols or port numbers be
   opened for its traffic on a firewall or Policy Enforcement Point
   (PEP).  A node may also request a unique IPv4 address and one or more
   port numbers for NAT traversal.  All entries created by a node have a
   lifetime associated with them and MUST be refreshed in order to avoid
   losing them.  The lifetime is set by the PDP and cached by the node
   using FCON.

   Depending on the network configuration, from the end host's point of
   view, the PDP may be colocated with a firewall or separated.



Soliman, et al.          Expires August 28, 2008                [Page 7]


Internet-Draft          Firewall Control Protocol          February 2008


   Moreover, both functions could be colocated with an access router or
   located within the core network.  The protocol between the PDP and
   the firewall is outside the scope of this document.  Authentication
   and authorization of FCON messages takes place by the PDP.  The PDP
   is assumed to be authenticated with the firewalls through one of
   several methods, including manual configuration of security
   associations, public key-based authentication, or any other method
   deemed appropriate by the network administrator.

   Message authentication and authorization is a critical component of
   the FCON protocol.  Different deployment models may have different
   requirements for authentication and authorization.  In some
   deployments the use of public keys and trusted certificates can be
   sufficient to authorize an end node for FCON messages.  Examples of
   such deployments may include enterprise or home networks.  Other
   deployments may require proof that the sender is authorized to
   perform the action requested.  Given the information exchanged in the
   FCON messages, it is sufficient for a node to prove the ownership of
   the address included in a message to be authorized to perform the
   requested action provided that such action does not violate the
   network administrator's policies.  Hence, the PDP first needs to know
   that a sending node owns the address included in the message, then
   ensure that the request does not violate any known policies.
   Following such verification the PDP would configure the firewall/NAT
   with the necessary information requested by the end node.

   This specification allows FCON security to be based on self-generated
   public keys and Cryptographically Generated Addresses (CGAs).  This
   allows nodes to provide the necessary address ownership credentials
   in those deployments that require it.  Alternatively, public keys
   associated with PKI can be used for deployments that do not require
   proof of address ownership.



















Soliman, et al.          Expires August 28, 2008                [Page 8]


Internet-Draft          Firewall Control Protocol          February 2008


4.  Firewall Scenarios

   This section describes limitations in current firewall deployment,
   and illustrates challenges in attempting to control firewalls
   dynamically using FCON.  Scenarios are described which motivate
   features described in this document.

   Manual policy firewalls describe the state of the art, with respect
   to deployed networks.  A management platform acts as a static policy
   decision point, propagating policy out to one or more policy
   enforcement points.  Such an environment is displayed in Figure 2.
   Connection state creation occurs when data plane packets compliant
   with policy are received.

   Static firewalls such as these may exist where the PDP and PEP are
   collapsed into the same entity, and long term configuration occurs on
   the same device where connection state is created.

                               PEP
                               ^
                              /
                             /
                            /
                      PDP---\
                             \
                              \
                               V
   Host====================> PEP=====================>Peer
                              Connection
                                State
                               Creation

                         Figure 2: Static Firewall

   As shown in Figure 2, where connection state is required for inbound
   packet flows, the PEP's preconfigured policy is used to create
   inbound connection state.  Such connections are available at all
   times, and depend upon the specificity of the PDP's inbound policy in
   order to maintain internal network security.  These inbound
   communications remain available regardless of the lifetime of the
   individual server applications.










Soliman, et al.          Expires August 28, 2008                [Page 9]


Internet-Draft          Firewall Control Protocol          February 2008


                               PEP
                               ^
                              /
                             /
                            /
                      PDP---\
                             \
                              \
                               V
                               PEP
   Server <=====================O<=============== Client

                              Connection
                                State
                               Creation

              Figure 3: Inbound Connection on Static Firewall

   Problems emerged when people attempted to support peer-to-peer
   applications with dynamic source and destination addresses.  This is
   illustrated in Figure 4.  Transport layer connection state is unable
   to identify the upper layer inbound connection associated with the
   peer-to-peer application.  Inbound packets are dropped on the
   secondary session unless the Firewall snoops and understands the
   specific protocol, and the inbound policy is loosened to permit such
   inbound sessions.

                               PEP
                               ^
                              /
                             /
                            /
                      PDP---\
                             \
                              \
                               V        P2P Signaling
   Host =======================>PEP====================> Peer
                                X<=======================

           Figure 4: Peer-to-Peer Connection on Static Firewall

   By enabling dynamic signalling, a host can inform the network
   elements of its intention to send packets with a particular source
   and destination address, and transport profile.  This means that the
   policy decision and enforcement can occur at the time that the
   session is established, and adapt specifically to the needs of the
   network's current transmission profile.




Soliman, et al.          Expires August 28, 2008               [Page 10]


Internet-Draft          Firewall Control Protocol          February 2008


   In Figure 5, the host informs the PDP which protocols are expected
   through the network gateways using a Request message to create a flow
   decriptor entry in the firewall.  The PDP indicates whether the
   session will be allowed, and state created on the PEP.  In this case,
   a Response message is sent, indicating that the PDP believes the
   communications are allowed.

           Request

        /----------------PDP..
       //----------------/    .
      //   ACK         .
     / V                       V
    Host =====================>PEP======================= > Dest

               Figure 5: Outbound Session with PDP Signaling

   In many environments, multiple Firewalls exist on the path to the
   Internet.  This is shown in Figure 6.

   Signalling is either performed to a single PDP which passes
   information to both PEPs, or to a separate PDP for each PEP.  By
   using separate PDPs, different trust policy and vendor independence
   may be readily achieved.  This may particularly be applicable where
   the internal firewall is operated by an enterprise, and the exterior
   firewall by a service provider.



                Request
        /---------------->PDP..
       //-----------------/   .
      //    ACK        .
     / V                       V
    Host======================>PEP============>PEP============>Dest
     \ ^                        |               ^
      \ \            ACK        |               .
       \ \----------------------O------------\ .
        \---------------------->O----------->PDP
               Request          |

                   Figure 6: Multiple On-Path Firewalls









Soliman, et al.          Expires August 28, 2008               [Page 11]


Internet-Draft          Firewall Control Protocol          February 2008


5.  PDP Discovery

5.1.  DHCP extensions

   In order to configure PDPs on hosts using the existing access
   infrastructure, a DHCP option is provided.

   The option format includes PDPs with destination coverage information
   on a per-PDP basis in a suboption format.  This would allow for
   specific PDPs to have jurisdiction over different network ranges (for
   example, for a Data Centre, and an Internet Firewall).

   The DHCP option for identifying PDPs is described using the format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OPTION_FC_PDP           |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                     PDP Sub-option 1                          |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                     PDP Sub-option N                          +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 7: FCON PDP Discovery DHCPv6 Option

   OPTION_FC_PDP

      Assigned DHCP option code for PDP discovery.  TBD.

   option-len






Soliman, et al.          Expires August 28, 2008               [Page 12]


Internet-Draft          Firewall Control Protocol          February 2008


      The length of the entire option in bytes, less 4

   PDP Sub-option

      A sub option containing information for each PDP the host should
      configure.

5.1.1.  PDP Sub-Option Format

   Each PDP has its own IP address and validity information.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   PDP-SOPT    |    Prefixes   |       suboption-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                     PDP IP Address                            |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLen1   |     Prefix 1 ....                             |
   +-+-+-+-+-+-+-+-+                                               +
   |                                                               .
   .                                                               .
   .                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |  PrefixLen2   |   Prefix2...  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
   |                                                               .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                                                               .
   .                                                               .
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |  PrefixLenN   |   PrefixN...                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   .                                                               .
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |
   +-+-+-+-+-+-+-+-+

                Figure 8: FCON PDP Discovery DHCPv6 Option



Soliman, et al.          Expires August 28, 2008               [Page 13]


Internet-Draft          Firewall Control Protocol          February 2008


   PDP-SOPT

      A sub option

   Prefixes

      The number of prefixes covered by this PDP.

   suboption-len

      The length of the PDP sub-option in bytes, including all fields.

   PDP IP Address

      The IP Address of the PDP which is used as a destination for FCON
      requests.

   PrefixLen i

      The length of the next prefix, in bits.

   Prefix i

      The space consumed by the Prefix is the number of bytes required
      to store the prefix (PrefixLen i/8), rounded up to the nearest
      integer.  A Prefix of 0::/0 is encoded with a zero length Prefix
      Field, and indicates the PDP is responsible for all destinations.
























Soliman, et al.          Expires August 28, 2008               [Page 14]


Internet-Draft          Firewall Control Protocol          February 2008


6.  Authorization Mechanism

   The protocol described in this document uses a two step authorization
   procedure.  The right to control the firewall will be granted if

   o  The node making the request is behind the firewall and owns the IP
      address

   o  The request made by the node is allowed by local firewall policy.

6.1.  Proof of ownership

   This document relies on Cryptographically Generated Addresses (CGAs)
   as defined in [RFC3972] in order to prove that the requesting node
   owns the address from which the firewall control request was sent.
   This is possible because the CGA address of the node is derived based
   on a hash of the public key of node with other known pieces of
   information like the prefix.  The procedure for verification of CGA
   addresses is described in Section 5 of [RFC3972].  If the PDP receive
   a signed firewall control request message that includes the public
   key and the CGA of the requester it can verify that the sender of the
   request indeed owns the address and that the address corresponds to
   the public key carried in the message.  Since creating this signature
   requires the corresponding private key of the public key contained in
   the message, it can also conclude that the message has not been
   tampered with.  In addition to this, to prevent replay attacks, the
   PDP can verify that the sender is in fact reachable and alive, using
   a to be defined FCON protocol message that uses nonces to verify that
   the received message was not replayed from an earlier run of the
   protocol. e.g.  The PDP could send a nonce to the requesting node in
   this message encrypted by the public key of the requesting node.
   Only the requesting node can decrypt this message and obtain the
   nonce.  Then it needs to increment the nonce and encrypt it and send
   it back to the PDP.  Once the PDP receives this message it can be
   assured that the requester is alive and reachable.  If either of
   these tests fail, the PDP rejects the firewall configuration request
   with an error that indicates that the address ownership was not
   confirmed.

   Please note that the PDP does not have to verify who owns the public
   key.  It just needs to verify whether the owner of the address is the
   same as the owner of the public key contained in the signed message.
   It can do so solely based on the information contained in the message
   prefix of the address, public key etc., by running the algorithm
   mentioned earlier.






Soliman, et al.          Expires August 28, 2008               [Page 15]


Internet-Draft          Firewall Control Protocol          February 2008


6.2.  Firewall request policy

   Once the PDP has verified that the requesting node owns the concerned
   address and is reachable, the PDP needs to start processing the
   request message itself.  Since it is possible that the firewall
   control request may not conform to administrative policy, the PDP
   verifies that the request falls within the parameters specified by
   such policy.  If it does, the PDP starts acting on the request and
   sends configuration messages to the necessary firewall(s).  If not,
   the PDP rejects the firewall configuration request with an error that
   indicates that the request did not comply with local administrative
   policy.







































Soliman, et al.          Expires August 28, 2008               [Page 16]


Internet-Draft          Firewall Control Protocol          February 2008


7.  Protocol Messages

   FCON uses ICMPv6 for transporting its messages.  The protocol is
   based on a request respose message exchange.  Hence, two ICMP message
   types are needed.  The ICMP Code field is used to distinguish
   different types of FCON messages.  Each message can contain one or
   more options.  This sections lists all protocol messages and options.

7.1.  The Request Message Format

   The Request message is sent from the end node to the PDP.  The
   purpose of the message depends on the options included.  For each
   operation described in this specification a specific set of options
   must be included.  The format of the request message is shown below.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Session Id            |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Message Id                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   Figure 9: The Request Message Format

   Session Id

      An unsigned 16-bit integer that includes a session identifier.
      The session identifier is initially picked by the end node when a
      security association is created with the PDP.  The Session Id MUST
      be unique for a particular end node, which is identified by its
      public key.

   Reserved

      This field MUST be set to zero by the sender and ignored by the
      receiver.

   Message Id

      This field include a message identifier.  The message identifier
      is a simple counter incremented by 1 for every new message.  This
      field is used to match responses with their correcponding
      requests.






Soliman, et al.          Expires August 28, 2008               [Page 17]


Internet-Draft          Firewall Control Protocol          February 2008


7.2.  The Response Message Format

   The Response message is sent from the PDP to the end node in response
   to a request message sent from the end node.  The response message
   includes the same Session Id and Message Id that were included in the
   sender's Request message.  The Response message may contain several
   options.  The options contained in a given message depend on the type
   of operation requested in the Request message.  The format for the
   Response message is shown below.


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Session Id            |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Message Id                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                  Figure 10: The Response Message Format

   Session Id

      An unsigned 16-bit integer that includes a session identifier.
      The session identifier is initially picked by the end node when a
      security association is created with the PDP.  The Session Id MUST
      be unique for a particular end node, which is identified by its
      public key.

   Reserved

      This field MUST be set to zero by the sender and ignored by the
      receiver.

   Message Id

      This field include a message identifier.  The message identifier
      is a simple counter incremented by 1 for every new message.  A
      Response message's identifier is set to the message identifier of
      the corresponding request message.








Soliman, et al.          Expires August 28, 2008               [Page 18]


Internet-Draft          Firewall Control Protocol          February 2008


7.3.  The Init Message

   The Init message is sent from the end node to the PDP in order to
   establish a secure association before sending further requests.  This
   message MUST NOT include information about flows that need to be
   installed in the firewall.  Instead, the message contains the end
   node's security credentials and a challenge for the PDP.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Session Id            | Sec Mode      |  Reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Message Id                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                    Figure 11: The Init Message Format

   Session Id

      An unsigned 16-bit integer that includes a session identifier.
      The session identifier is initially picked by the end node when a
      security association is created with the PDP.  The Session Id MUST
      be unique for a particular end node, which is identified by its
      public key.

   Sec Mode

      This field indicates the type of credentials used to establish the
      security association.  A value of 1 indicates the use of self-
      generated public keys.  A value of 2 indicates the use of trusted
      certificates, which are either signed by the same administrative
      authority or a trusted third party.

   Reserved

      This field MUST be set to zero by the sender and ignored by the
      receiver.

   Message Id

      This field include a message identifier.  The message identifier
      is a simple counter incremented by 1 for every new message.







Soliman, et al.          Expires August 28, 2008               [Page 19]


Internet-Draft          Firewall Control Protocol          February 2008


7.4.  The Init Acknowledgement Message


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Session Id            | Sec Mode      |    Status     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Message Id                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 12: The Init Acknowledgement Message Format

   Session Id

      An unsigned 16-bit integer that includes the session identifier
      included in the Init message.

   Sec Mode

      This field includes the same value for the Sec Mode field included
      in the Init message if the Status field indicated a successful
      operation.  Otherwise, the field includes the value supported by
      the PDP.

   Status

      This field indicates the success or failure of the processing of
      the Init message.  Values below 128 indicate success, while values
      of 128 and above indicate failure.

   Message Id

      This field includes the value of the Message Id that was included
      in the Init message being responded to.

   The following values are reserved for the Status field:

      0 Success

      128 Reason unspecified

      129 Security mode not supported

      130 Invalid format

      131 Certificate not accepted




Soliman, et al.          Expires August 28, 2008               [Page 20]


Internet-Draft          Firewall Control Protocol          February 2008


7.5.  Protocol Options

7.5.1.  The Acknowledgement Option

   The Acknowledgement Option is used to carry information about a
   requested operation.  The format of the Acknowledgement option is
   shown below.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |   Status     |   Reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 13: The Acknowledgement Option Format

   Type

      A value assigned to this option.

   Length

      The length of this option in 8-octet units.

   Status

      This field indicates whether an operation was a success or a
      failure.  Values of 128 and higher indicate failure.  Otherwise
      this field indicates a successful operation.

   Reserved

      MUST be set to zero by the sender and ignored by the receiver.

   The following values are reserved for the Status field:

      0 Indicates Success.

      128 Failure, reason unspecified.

      129 Message poorly formed.

      130 Unknown session identifier.

      131 Flow descriptor format not supported

      132 Action not supported.




Soliman, et al.          Expires August 28, 2008               [Page 21]


Internet-Draft          Firewall Control Protocol          February 2008


      133 Security Information Required.

      134 Liveness Proof Required.

7.5.2.  The Filter Identifier Option

   The filter identifier option is used to encode information that
   describes a flow and the treatment needed for such flow.  A host may
   request that a flow be allowed, blocked, or removed from the
   firewall, which defaults to the firewalls original settings.


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Index              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Action     |    Format     |       PRI     |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Flow descriptor......
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 14: The Flow Identifier Option Format

   Type

      A value assigned to this option.  TBA

   Length

      The length of this option in 8-octet units.

   Index

      A Unique value that identifies a particular flow description.
      This value is assigned to the flow description by the end node.

   Action

      This field indicates the type of operation requested by the end
      node for the flow included in the option.  The following values
      are assigned to this field.  A Value of 1 indicates a request to
      Allow the flow. 2 indicates a request to Block a flow. 3 indicates
      a request to Update a flow. 4 indicates a request to Delete a
      flow.

   Format



Soliman, et al.          Expires August 28, 2008               [Page 22]


Internet-Draft          Firewall Control Protocol          February 2008


      This field indicates the format used for the flow descriptior.
      Values TBA

   PRI

      This field indicates the priority of a particular flow.  A lower
      value indicates a higher priority.  A value of 1 indicates the
      highest priority.  A value of zero is not allowed by this
      specification.  The rpiority field is needed in cases where two
      flow descriptions overlap while having conflicting Action fileds.
      The Action field included in the option with higher priority takes
      precedence.

   Reserved

      This field MUST be set to zero by the sender and ignored by the
      receiver.

7.5.3.  The Nonce Option

   The Nonce Option is illustrated in Figure 15 and is used to ensure
   freshness in acknowledgements from the PDP to the requesting FCON
   node.  It works by making sure that the PDP copies the Nonce Option
   from the request into the response.  The Nonce is checked along with
   other freshness and authentication information before

   As such, a new Nonce MUST be selected for each transmission of a
   request message.  PDPs receiving a valid request message MUST copy
   the Nonce option into the response, regardless of the status of any
   individual flow.

   The Nonce MUST be unpredictable, and SHOULD contain hardware
   generated randomness, where possible.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                 ...       Nonce                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                    Figure 15: The Nonce Option Format

   Type





Soliman, et al.          Expires August 28, 2008               [Page 23]


Internet-Draft          Firewall Control Protocol          February 2008


      A value assigned to this option.

   Length

      The length of this option in 8-octet units.

   Nonce

      The Nonce is a block of data selected by the requester to be sent
      to the PDP. the entire length of the Nonce block MUST NOT exceed
      384 bits.  It MUST contain at least 64 bits of unpredictable
      random data.  It SHOULD contain significantly more randomness.

      PDPs receiving the Nonce SHOULD cache it to ensure that duplicate
      request packets are not processed from the same source.

7.5.4.  The Timestamp Option

   The Timestamp option format is used to ensure attackers are unable
   create state in the future by replaying signed FCON messages.  It
   relies on congruence between clock information within nodes and PDPs,
   and therefore has some limitations where secured time synchronization
   is not available

   The following option format follows the principles and message
   formats as described in the [RFC3971], except that its protections
   may be weaker when operating in a multi-hop domain.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                          Timestamp                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 16: The Timestamp Option Format

   Type

      A value assigned to this option.

   Length




Soliman, et al.          Expires August 28, 2008               [Page 24]


Internet-Draft          Firewall Control Protocol          February 2008


      The length of this option in 8-octet units.

   Timestamp

      A 64-bit unsigned integer field containing a timestamp.  The value
      indicates the number of seconds since January 1, 1970, 00:00 UTC,
      by using a fixed point format.  In this format, the integer number
      of seconds is contained in the first 48 bits of the field, and the
      remaining 16 bits indicate the number of 1/64K fractions of a
      second.

   Each FCON message MUST contain the Timestamp option, and recipients
   SHOULD ensure that Timestamps are valid to prove freshnes of the
   message.

   Processing of this option follows that for SEND, except that that the
   corresponding figures for clock drift and fuzz are more lenient.
   This allows for longer attack windows of attack against FCON
   infrastructures, but also allows for deviations in packet transfer
   delays on multi-hop networks and the extended duration of the state
   created in Firewalls, as opposed to Neighbour Discovery:

      TIMESTAMP_DELTA 600 seconds (10 minutes)

      TIMESTAMP_FUZZ 6 seconds

      TIMESTAMP_DRIFT 1 % (0.01)

7.5.5.  The IP Address Option

   The IP address option is used by a node to request a unique IPv4
   address and one or more port numbers.



















Soliman, et al.          Expires August 28, 2008               [Page 25]


Internet-Draft          Firewall Control Protocol          February 2008


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |   PadLen      |    Protocol1  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |    ProtocolN  |            Padding...         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Interior Port 1         |         Exterior Port 1       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Interior Address  1                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Exterior Address  1                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Interior Port N         |         Exterior Port N       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Interior Address  N                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Exterior Address  N                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 17: The IP Address Option Format

   Type

      A value assigned to this option.

   Length

      The length of this option in 8-octet units

   Padlen

      The length in bytes of the Padding field

   Protocol i

      The ith IP protocol number

   Padding

      This field SHOULD be set to zero by the sender and ignored by the
      receiver.

   Interior Port i



Soliman, et al.          Expires August 28, 2008               [Page 26]


Internet-Draft          Firewall Control Protocol          February 2008


      The 16 bit Transport layer internal identifier of the of the ith
      session for which a mapping is requested.  Where such identifiers
      do not make sense for a particular protocol, this field SHOULD be
      set to zero

   Exterior Port i

      The 16 bit Transport layer identifier of the of the ith session
      for which a mapping is requested.  Where such identifiers do not
      make sense for a particular protocol , this field SHOULD be set to
      zero Requesters SHOULD set this field to zero, if they wish the
      PDP to assign a port

   Exterior Address i

      The address of the ith external IP address to which a mapping is
      requested.  Requesters SHOULD set this field to zero, if they wish
      the PDP to assign an address.

   Interior Address i

      The address of the ith internal IP address for which a mapping is
      requested

7.5.6.  The Cookie Option

   The Cookie Option contains a string of information chosen by the PDP
   to the host to when requesting further security credentials.

   The cookie can contain any information which the PDP desires, and the
   cookie must be returned to the PDP along with credential information

   When the host sends further credential information it MUST add the
   cookie to the Init or SEND Certification Path Advertisements sent to
   validate the credentials.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |C|          Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                            Cookie                             .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 18: The Cookie Option Format



Soliman, et al.          Expires August 28, 2008               [Page 27]


Internet-Draft          Firewall Control Protocol          February 2008


   Type

      The assigned type of this option (TBD).

   Length

      The length of this option in 8-octet units.

   C

      The Flag indicating Certificate Path Discovery is ok (Flag Set).

      This flag being set allows the response to use [RFC3971]
      Certifcation Path Advertisement Messages to convey the list of
      certificates for the respondent.  If this flag is not set, the
      sender MUST use Init messages instead.

      This Cookie is required to appear in all such messages (IANA
      Note).

   Length

      A string of bytes chosen by the PDP to ensure liveness of
      responses.  The entire option, carrying this field needs to be
      copied into an INIT for transmission to the PDP, along with
      credential information.

7.5.7.  The Public Key Option

   The Public Key option is used to provide information to the PDP about
   the identity being used to sign the message.  By using the key
   information in this option, or a cached copy, the PDP can use
   information in the Digital Signature Option, to verify the message's
   integrity.

   This Option MUST be present in the message sent from a particular
   host to a PDP, and from a PDP to a host with which it has not
   communicated, unless the same information is provided within the
   message using a Certificate Option.  If a host or PDP communicate
   with each other during a period where security state is still in
   existence, then the sender MAY leave this option out.

   Where a receiving endpoint does not support a Key Type, it may
   indicate this to the far end in an acknowledgement but otherwise
   SHOULD NOT create any state in PEPs.






Soliman, et al.          Expires August 28, 2008               [Page 28]


Internet-Draft          Firewall Control Protocol          February 2008


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Key Type     |  Pad Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Public Key Information ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 ...       Padding                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 19: The Public Key Option Format

   Type

      A value assigned to this option.  TBA

   Length

      The length of this option in 8-octet units.

   Key Type

      A description of the keying information to be supplied in the
      following Public Key Information field.  The algorithms and
      formats to be supported are to be determined.  A type value of 1
      is CGA with the Public Key Information containing information
      compatible with [RFC3972] formats.

   Pad Length

      The length of the pad in bytes

   Public Key Information

      A stream of bytes describing a public key accordingto the
      algorithm specific format specified in they Key Type.

   Padding

      This field SHOULD be set to zero by the sender and ignored by the
      receiver.

7.5.8.  The Lifetime Option

   This lifetime option is included in the Response and Init
   Acknowledgement messages from the PDP to the end node to indicate the
   lifetime for the entries in a Request message or to indicate the



Soliman, et al.          Expires August 28, 2008               [Page 29]


Internet-Draft          Firewall Control Protocol          February 2008


   lifetime of a security association, respectively.  The option format
   is shown below.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Time                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                   Figure 20: The Lifetime Option Format

   Type

      A value assigned to this option.

   Length

      The length of this option in 8-octet units.

   Reserved

      This field MUST be set to zero by the sender and ignored by the
      receiver.

   Time

      This field contains the lifetime in units of seconds.

7.5.9.  The Certificate Option

   The Certificate option contains a digital certificate issued by one
   of the Certificate Authorities in the sender's trust chain.  It
   provides information about trust delegated to the sender or its
   authorizing authorities.  This option follows the same format as in
   [RFC3971], and the certificates can be sent in Certification Path
   Advertisement messages, between hosts and PDPs.

   The Certificate Option MAY be included in an FCON request or response
   message instead of including the Public Key option.  It is
   RECOMMENDED that only one of the Public Key Option or Certificate
   Option is included in any FCON request or response message.






Soliman, et al.          Expires August 28, 2008               [Page 30]


Internet-Draft          Firewall Control Protocol          February 2008


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Cert Type    |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Certificate ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 ...       Padding                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                 Figure 21: The Certificate Option Format

   Type

      A value assigned to this option.

   Length

      The length of this option in 8-octet units.

   Cert Type

      The type of certificate presented in the Certificate field.  Type
      1 is an X.509v3 digital certificate.

   Certificate

      A stream of bytes describing a one of the sender's certificates
      from it's trust chain.  The format of a particular certificate is
      governed by the Cert Type.

   Padding

      This field SHOULD be set to zero by the sender and ignored by the
      receiver.

7.5.10.  The Digital Signature Option

   The Digital Signature Option MUST be included in every FCON message,
   and authenticates the preceding message contents.  It does this by
   performing a signature over the message contents by the key
   identifies in the Key Hash field.  It is always placed last in any
   sequence of options, before presentation for transmission.

   If multiple identities are signing the message, the most specific
   user signs the message with the first digital signature option, over



Soliman, et al.          Expires August 28, 2008               [Page 31]


Internet-Draft          Firewall Control Protocol          February 2008


   all options preceding that one.  Subsequent signers include all
   required option information to ensure validation of their message
   after this signature, and then include their own digital signature at
   the end, signing over all included options, including the previous
   digital signature.  This allows user level and host level
   authentication within the same message, and provides distinction
   between administrative and non-power users on a multi-user server.

   If a device receives a digital signature and is unable to identify
   the Public Key to which the signature is tied, it may challenge the
   sender, or silently discard the received FCON message.  Therefore, it
   is important to include the Public Key Option in a message unless it
   is known that the peer device is known to have recently received it.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Sign Type    |   Pad Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                           Key Hash                            +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .     Digital Signature ...                                     .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 ...       Padding                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 22: The Digital Signature Option Format

   Type

      A value assigned to this option.

   Length

      The length of this option in 8-octet units.

   Sign Type






Soliman, et al.          Expires August 28, 2008               [Page 32]


Internet-Draft          Firewall Control Protocol          February 2008


      The type of digital signature used within the Digital Signature
      field of this option.

      Type 1 is allocated as a PKCS 1.5 Digital Signature over the field
      sequence as described in [RFC3971].

   Pad Length

      The length of the Padding field in octets.

   Key Hash

      The left most (most significant) 128 bits of an SHA-1 hash over
      the public key information included in a Public Key Information
      field of a Public Key Option.

   Digital Signature

      A digital signature of the format specified in the field Sign
      Type.  This signature is over the entire message, including the
      ICMPv6 Pseudo Header, and all options up to and preceding this
      option.

      The length of the Digital Signature field is the length in octets
      of the message subtracting 12 octets for fixed length fields, and
      the contents of the Pad Length field.

   Padding

      This field SHOULD be set to zero by the sender and ignored by the
      receiver.




















Soliman, et al.          Expires August 28, 2008               [Page 33]


Internet-Draft          Firewall Control Protocol          February 2008


8.  Establishing a Secure Connection

   A host wishing to request that state be created on a PEP signals a
   PDP with either an Init message containing credential information, or
   a Request message containing the filter information describing the
   host's intended protocol behaviour.

   Either of these messages MUST contain the Public Key Option (or a
   Substituted Certificate Option containing the relevant Public Key)
   and a Digital Signature Option, along with Timestamp and Nonce
   information.  In addition, the Init message contains a unique session
   identifier field selected by the requesting node.  This session
   identifier field will be used for subsequent signaling of other
   messages upon successful establishment of a secure session.

   If the PDP can determine from the contents of the message that it
   believes the host is an acceptable requester, it can respond to the
   request with the appropriate success acknowledgement in the Init
   Acknowledgement message.

   If the PDP is not able to authemticate or authorize the credentials
   for the host, it replies with an Init-Ack or Response containing a
   non success response code, and a Cookie Option.  Where the host
   wishes to establish a secure connection, the host must return this
   same cookie in the subsequent message (or messages for trust chains
   which exceed a single packet).

   The host may then send additional information in the form of either a
   sequence of Certificate Path Advertisements, if allowed in the Cookie
   option.  Finally, when all credentials are transmitted, the host
   again sends an Init message containing the last received cookie.

   For the case where the Init-Ack contained the failure code "Liveness
   Test Needed", no further credentials are required, although an Init
   MUST be resent containing the received Cookie Option.
















Soliman, et al.          Expires August 28, 2008               [Page 34]


Internet-Draft          Firewall Control Protocol          February 2008


9.  Creating New entries

   Entries consist of one or more flow identification options that are
   sent from an end node to the PDP.  In order to create entries the end
   node must send a Request message to the PDP.  The Request message
   MUST contain and appropriate session identifier value, and a Message
   identifier.  The message identifier can be implemented as a
   monotonously increasing counter.  The Request message contains the
   following options:

   o  One or more Flow Identification options.  Each option contains a
      unique Index field, an appropriate Action field, a format field
      indicating the format of the flow descriptor and an appropriate
      priority in the PRI field.

   o  The Nonce option

   o  The Digital Signature option.

   Upon receiving the Request message, the PDP verifies the signature in
   the message.  If the verification fails, the message is silently
   discarded.

   Upon successful verification of the Request message, the PDP checks
   the message header.  If the session identifier is not known, the PDP
   sends a Response message with the same session and message
   identifiers and includes and Acknowledgement option with the status
   field set to 130.

   If the message is correctly formed, the PDP inspects each flow
   identification option.  If an error is found in any of the flow
   options, the PDP sends a Response message with the Acknowledgement
   indicating failure with the appropriate error code.  The failed
   options MUST be included in the Response message. successful options
   are processed by the PDP.

   The process of updating existing flows is described in Section 10.

   If all options are processed successfully, the PDP sends a Response
   message.  The session and message identifier fields are set to the
   same value in the Request message.  The Response message includes the
   following options:

   o  The Acknowledgement option.  This option's status field indicates
      success

   o  The Lifetime option.  This option includes the lifietime
      associated with the new entries.  The end node needs to refresh



Soliman, et al.          Expires August 28, 2008               [Page 35]


Internet-Draft          Firewall Control Protocol          February 2008


      those entries before the lifetime expires.

   o  The nonce option.

   o  The Digital Signature option.

   Note that the process of adding new entries does not require the end
   nodes to send all existing entries.  Only new flows need to be
   included in the Request message.










































Soliman, et al.          Expires August 28, 2008               [Page 36]


Internet-Draft          Firewall Control Protocol          February 2008


10.  Updating Entries

   Updating existing entries may take place due to the need for changing
   the flow description, deleting an existing entry, or simply
   refreshing an entry before its timer expires.  When refreshing
   entries there is no need for the requesting node to send the entire
   Flow identifier option in a Request message.  It is sufficient to
   send the option without the flow descriptor.

   Updating entries is done using the same Request message as described
   in Section 9 Upon receiving the Request message, the PDP verifies the
   Digital signature option.  If the verification failed, the message is
   silently discarded.

   After successfully verifying the message, the PDP processes each flow
   identifier option for formatting, flow descriptor (if the FID field
   indicates a new flow) and the Action field.  If all of the flow
   identifier options are rejected, the PDP responds with a Response
   message, including the acknowledgement option, which indicates
   failure with an appropriate error code.

   If some of the filter identifier options are rejected and others are
   accepted, the PDP responds with the Response message, including the
   acknowledgement option, which indicates partial success.  The
   Response message also includes the lifetime option with an
   appropriate lifetime for the accepted options.  In addition, the
   Response message includes all of the failed options.  Each of the
   failed options includes a Status field, which indicates the reason
   for failure.

   After receiving the Response message, the requesting node updates its
   list of accepted entries and the corresponding lifetimes for those
   entries.


















Soliman, et al.          Expires August 28, 2008               [Page 37]


Internet-Draft          Firewall Control Protocol          February 2008


11.  Requesting an IPv4 Address

   A requesting node may wish to know the public IPv4 address and port
   numbers allocated to it by a NAT for one or more of its applications.
   To do that, it can request one or more IP addresses and port numbers
   while specifying the protocol that it wants to use.  This is done by
   sending a Request message that includes the following options:

   o  The IP address option.

   o  The nonce option.

   o  The digital signature option.

   Upon receiving the Request message, the PDP verifies the digital
   signature included.  If the verification failed, the PDP silently
   discards the message.

   If the PDP allows nodes to request an IPv4 address, it can proceed
   with the processing of the IP address option.  Otherwise, the PDP
   rejects the request by sending a Response message with an
   acknowledgement option contaiing the appropriate error code.

   If the IP address option is valid, the PDP proceeds to allocate the
   requested address(es) and port numbers.  The method used by the PDP
   to communicate with the NAT/firewall is outside the scope of this
   document.

   If after allocating the IP address to the requesting node, the PDP
   sends a Response message including the IP address option, which
   includes the allocated addresses and ports, the nonce option, the
   lifetime option and the digital signature option.

   Upon receiving the Response message and verifying the digital
   signature option, the requesting node can use the IP address(es) and
   ports allocated in the message for the duration of the lifitime
   option.  Should the requesting node wish to refresh the allocated
   addresses and ports, it MUST send the Request message with the IP
   address option including all the previously allocated IP addresses
   and ports.











Soliman, et al.          Expires August 28, 2008               [Page 38]


Internet-Draft          Firewall Control Protocol          February 2008


12.  Timeouts and Retransmissions

   Where a host receives no response to a packet sent directly to a PDP,
   it may need to retransmit its initial packet.  Each request MAY be
   transmitted up to four (4) times, each with a different Nonce and
   updated TimeStamp.  Separation between one transmission and its next
   should be performed such that timeouts are exponential.  RECOMMENDED
   timeouts are 1,2 and 4 seconds.  A host SHOULD delay an initial
   retransmission by between 0 and 100ms, to ensure any retransmissions
   are serialized.

   The PDP never sends packets to the host, except in response to an
   FCON message.  In order to respond in sufficient time, it is
   recommended that the PDP respond without induced delay to any packet
   sent directly to its IP address.

12.1.  Session Start Delays

   When a new session is established, if a data plane transmission
   delays until FCON acknowledgements are received, there is likely to
   be significant added delay for every TCP or UDP session creation.  It
   is therefore recommended that FCON immediately precedes packet
   transmission on the data plane, where it is not harmful to lose one
   or two of the initial packets.  This may for example, be the case
   with unreliable protocols such as VoIP.

   Also, when a host has one or more existing communications open in
   negotiation with a PDP, it is possible to send the packets
   immediately after sending the FCON request.  This optimizes for the
   case where new state is able to be created immediately, and reduces
   latency at the risk of causing packet loss and retransmission on
   initial packets.

   Where a host has not communicated to a PDP previously, it MAY induce
   additional delay before sending the data plane packets, in order to
   limit additional delays due to retransmission and timeout at the
   Transport Layer of the data session.

   Significantly, when FCON packet loss or delay occurs on the
   signalling path, this means that packet loss or delay will ensue,
   with the timings described in the prior section.










Soliman, et al.          Expires August 28, 2008               [Page 39]


Internet-Draft          Firewall Control Protocol          February 2008


13.  IANA Considerations

   TBD
















































Soliman, et al.          Expires August 28, 2008               [Page 40]


Internet-Draft          Firewall Control Protocol          February 2008


14.  Security Considerations

   Certain assumptions underly the initial version of this draft, which
   need to be considered appropriately.  Firstly, the role of CGAs in
   providing proof of address ownership in this protocol is primarily an
   enabler, and may be insufficient in some environments to authorize
   communications for a particular destination.

   This may particularly be the case for devices with multiple users,
   where individuals have permission to access specific data services,
   but others are excluded.  CGAs at host level granularity are
   insufficient to distinguish which of the users is attempting a
   communication.

   Mechanisms which could be used to provide such distinction are user-
   level digital signatures over the filter message contents and
   freshness information, in addition to CGA information.  Additionally,
   to ensure that the PDP only has to process a single digital
   signature, subsets users on multi-host systems could be allocated
   CGAs tied to their own public key information while using that host.

   Therefore FCON messages from different users on a system would have
   different security credentials, and still allow CGA authorization.
   The internal processes on the host to allow for signing such messages
   is beyond the scope of this document, but it is easy to envisage an
   ICMP message signing service which a user subscribes to, that uses
   the subscribed private-key credentials to sign FCON and SEND
   messages.

   Regardless of the identity of the message signer, FCON request
   messages require authentication of the node, and the response
   messages require proof of the PDP's identity in order to prevent
   denial-of-service through spoofing attacks.  Denial of service can
   occur due to the requirement to process digital signatures on
   response messages.  Hosts which detect many excessive responses from
   PDPs, such as would indicate a denial-of-service attempt MAY defer
   processing digital signatures on responses, and rely on freshness and
   Nonce information in the message itself to determine if a digital
   signature needs to be processed.  This limits denial . of service
   attacks to those who are able to guess nonces, or are on the path to
   the PDP.










Soliman, et al.          Expires August 28, 2008               [Page 41]


Internet-Draft          Firewall Control Protocol          February 2008


15.  Acknowledgements


















































Soliman, et al.          Expires August 28, 2008               [Page 42]


Internet-Draft          Firewall Control Protocol          February 2008


16.  Normative References

   [I-D.ietf-nsis-nslp-natfw]
              Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies,
              "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
              draft-ietf-nsis-nslp-natfw-18 (work in progress),
              February 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999.

   [RFC3024]  Montenegro, G., "Reverse Tunneling for Mobile IP,
              revised", RFC 3024, January 2001.

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

   [RFC3519]  Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
              Network Address Translation (NAT) Devices", RFC 3519,
              May 2003.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.




Soliman, et al.          Expires August 28, 2008               [Page 43]


Internet-Draft          Firewall Control Protocol          February 2008


   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.







































Soliman, et al.          Expires August 28, 2008               [Page 44]


Internet-Draft          Firewall Control Protocol          February 2008


Appendix A.  Dynamic PDP Discovery (Informative)

   In some of the described scenarios, it may not be feasible to
   prepopulate the endpoints with information for all of the relevant
   PDPs responsible for firewall policy along a particular data path.
   For these scenarios, sending data to an existing configured PDP may
   be insufficient to create state in all firewalls on the path.  This
   may lead to packets being dropped, even though signalling has been
   performed, and all known signaling accomplished.

   One mechanism to ensure that all PDPs for a data path are informed of
   changes is to send CREATE packets along the path at the time
   establishing a data connection.  Such packets would be sent to the
   same IP source and destination as the packets in the data stream, but
   the IP packet would contain the Router-Alert Hop-By-Hop option
   [RFC2460].

   Enforcement or Decision Point devices which receive such probes,
   would refer the packet for processing, and identify that the ICMP
   message contained a CREATE operation.  The message filter contents
   would then define which sessions are requested to be allowed through
   the firewall.

   Depending upon policy, the PDP or PEP would either DENY the data
   flow, sending a CREATE-NACK message, refer the sender to an
   appropriate PDP using the PDP-REDIRECT message, or create the state
   for the session according to the filter, and send a CREATE-ACK.  In
   the case that the session state creation is refused or redirected,
   the CREATE packet packet itself is dropped.  In the alternative case
   where state is created, the CREATE packet should be forwarded onward
   toward its destination.  At this stage, the potential to create
   multiple responses to a single message is the primary danger of this
   method.

   An alternative which increases setup latency is to drop the CREATE
   packet when new state is created, and send a CREATE-ACK.  On each
   successive CREATE packet which does not alter session state, the
   CREATE packet is passed onward towards the destination.  This removes
   any multiplication attacks, but causes delay of up to N x RTT for N
   policy devices along the path.

   Similar operations for UPDATE would also occur, with state being
   created if it didn't exist, or replaced in the case it already was in
   place.

   Once a host discovers that a Policy Decision Point exists on a
   particular path, it can then signal directly to it.  Devices can add
   these to the PDPs discovered using DHCP or other mechanisms.



Soliman, et al.          Expires August 28, 2008               [Page 45]


Internet-Draft          Firewall Control Protocol          February 2008


   Even though the packets are sent between the same source and
   destination addresses as those of the data session, they may travel a
   different path to the actual data stream, for example due to load
   balancing.  In such a case, a PDP or PEP which receives the CREATE or
   UPDATE method can send a PDP-REDIRECT, to refer the origin to the
   appropriate policy decision point for the data flows.

   Where a host application accepts inbound packets passively, it may be
   useful to ensure that Policy enforcement and decision points beyond
   the DHCP configured range are included in signaling.  Such can be
   achieved by configuring a filter describing the allowed inbound
   source and destination addresses of packets and addressing a hop-by-
   hop CREATE packet to a set of potential inbound source addresses.

   Such probing can be limited in terms of the number of addresses to
   probe, as well as the time-to-live of the packet itself, in order to
   prevent impacts upon the network.


































Soliman, et al.          Expires August 28, 2008               [Page 46]


Internet-Draft          Firewall Control Protocol          February 2008


Authors' Addresses

   Hesham Soliman
   Elevate Technologies

   Email: hesham@elevatemobile.com


   Greg Daley

   Email: hoskuld@hotmail.com


   Suresh Krishnan
   Ericsson
   8400 Blvd Decarie
   Town of Mount Royal, Quebec
   Canada

   Email: suresh.krishnan@ericsson.com































Soliman, et al.          Expires August 28, 2008               [Page 47]


Internet-Draft          Firewall Control Protocol          February 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Soliman, et al.          Expires August 28, 2008               [Page 48]