<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<rfc category="std" docName="draft-maglione-pcp-radius-ext-08"
     ipr="trust200902">
  <front>
    <title abbrev="PCP RADIUS Extensions">RADIUS Extensions for Port Control
    Protocol (PCP)</title>

    <author fullname="Roberta Maglione" initials="R." surname="Maglione">
      <organization abbrev="">Cisco Systems</organization>

      <address>
        <postal>
          <street>181 Bay Street</street>

          <city>Toronto, ON </city>

          <code>M5J 2T3</code>

          <country>Canada</country>
        </postal>

        <phone></phone>

        <email>'robmgl@cisco.com'</email>
      </address>
    </author>

    <author fullname="Dean Cheng" initials="D." surname="Cheng">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>2330 Central Expressway</street>

          <city>Santa Clara</city>

          <region>CA</region>

          <code>95050</code>

          <country>USA</country>
        </postal>

        <phone>+1 408 330 4754</phone>

        <facsimile></facsimile>

        <email>dean.cheng@huawei.com</email>

        <uri></uri>
      </address>
    </author>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <date day="30" month="May" year="2013" />

    <workgroup>PCP WG</workgroup>

    <abstract>
      <t>This document specifies a new Remote Authentication Dial In User
      Service (RADIUS) attribute to carry a Port Control Protocol (PCP) Server
      Names. This attribute can be configured on a RADIUS server so that the
      information can be conveyed to Network Access Server (NAS) via RADIUS
      protocol, and the co-located Dynamic Host Configuration Protocol
      (DHCP/DHCPv6) server can then populate the information to PCP
      client.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>Port Control Protocol (PCP) <xref target="RFC6887"></xref>
      provides a mechanism to control how incoming packets are forwarded by
      upstream devices such as NATs and firewalls. PCP is a client/server
      protocol where a PCP client may reside on a host, a Customer Premises
      Equipment (CPE), etc., which communicates with a PCP server that may
      reside anywhere in a network.</t>

      <t><xref target="RFC6887"> </xref> defines a procedure for the
      PCP client to communicate with its PCP Server. The IP address of the PCP
      Server(s) can be configured to the PCP client; if not the PCP client
      assumes its default router as being its PCP server.</t>

      <t><xref target="I-D.ietf-pcp-dhcp"></xref> defines DHCPv6 and DHCPv4
      options which are meant to be used by a PCP client to discover a PCP
      server name. However, provisioning for name of the PCP server is
      required on a DHCPv4/DHCPv6 server before it can populate this
      information.</t>

      <t>Auto-configuration on a DHCPv4/DHCPv6 is possible in a broadband
      network, where typically, user profile is maintained on a Remote
      Authentication Dial In User Service (RADIUS) server and RADIUS protocol
      <xref target="RFC2865"></xref> is used to convey user-related
      information to other network elements including a host and CPE. <xref
      target="RFC6911"></xref> describes a typical
      broadband network scenario in which the Network Access Server (NAS) acts
      as the access gateway for the users (hosts or CPEs) and the NAS embeds a
      DHCPv6 Server function that allows it to locally handle any DHCPv6
      requests issued by the clients.</t>

      <t>In such environment, PCP server's name can be configured on a RADIUS
      server, which then passes the information to a NAS that co-locates with
      the DHCPv4/DHCPv6 server, which in turn populates the location of the
      PCP server.</t>

      <t>This document defines a new RADIUS attribute that can be used to
      carry a PCP server name. As defined in <xref
      target="I-D.ietf-pcp-dhcp"></xref>, a PCP Server Name can be a DNS name,
      IP literals strings, etc. This document is designed to allow for
      configuring PCP Server name which can be a DNS name, IP literals or any
      strings which may be passed to a local name resolution library on the
      PCP client side. Multiple occurrences of the PCP server name RADIUS
      attribute is supported.</t>

      <t>The proposed RADIUS attribute is designed to accommodate various
      deployment contexts (e.g., dedicated option per IP connectivity context,
      single option for dual-stack access, etc.).</t>

      <t>The approach described above is already used for providing the FQDN
      of the AFTR in the DS-Lite scenario <xref target="RFC6333"></xref> and
      the equivalent RADIUS attribute for the DS-Lite Tunnel Name is defined
      <xref target="RFC6519"></xref>.</t>
    </section>

    <section anchor="term" title="Terminology">
      <t>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 <xref
      target="RFC2119"></xref>.</t>

      <t>The following terms are defined in <xref
      target="RFC6887"></xref>:</t>

      <t><list counter="1" hangIndent="5" style="empty">
          <t>- Port forwarding</t>

          <t>- PCP</t>

          <t>- PCP client</t>

          <t>- PCP Server</t>
        </list>The following term is defined in <xref
      target="I-D.ietf-pcp-dhcp"></xref>:</t>

      <t><list counter="1" hangIndent="5" style="empty">
          <t>- PCP Server Name</t>
        </list></t>
    </section>

    <section title="PCP Server Configuration using RADIUS and DHCPv4/DHCPv6 ">
      <t><xref target="fig1"></xref> illustrates an example of how RADIUS
      protocol works together with DHCPv6, to allow a host to learn
      automatically the name of a PCP server in case of a PPP session that
      carries IPv6 traffic.</t>

      <t>The Network Access Server (NAS) operates as a client of RADIUS and
      co-locates with a DHCPv6 Server for DHCPv6. The NAS initially sends a
      RADIUS Access Request message to the RADIUS server, requesting
      authentication. Once the RADIUS server receives the request, it
      validates the sending client and if the request is approved, the RADIUS
      server replies with an Access Accept message including a list of
      attribute-value pairs that describe the parameters to be used for this
      session. This list MAY also contain the name of a PCP server. When the
      co-located DHCPv6 server receives a DHCPv6 message from 
a client containing the PCP
      Server Option, it SHALL use the name returned in the RADIUS attribute as
      defined in this memo to populate the DHCPv6 PCP Server option defined in
      <xref target="I-D.ietf-pcp-dhcp"></xref>.</t>

      <t><figure anchor="fig1" height=""
          title="RADIUS and DHCPv6 Message Flow for a PPP Session">
          <artwork><![CDATA[   PCP/DHCPv6                         NAS                      AAA
  Client                           DHCPv6 Server              Server
    |                                  |                        |
    |----PPP LCP Config Request------> |                        |
    |                                  |----Access-Request ---->|
    |                                  |                        |
    |                                  |<-Access-Accept---------|
    |                                  | (PCP-Server-Name)      |
    |<-----PPP LCP Config ACK  -----   |                        |
    |                                  |                        |   
    |------ PPP IPv6CP Config Req ---->|                        |
    |                                  |                        |     
    |<----- PPP IPv6CP Config ACK -----|                        |
    |                                  |                        |  
    |-------  DHCPv6 Solicit  -------->|                        |
    |                                  |                        |
    |<-------DHCPv6 Advertisement------|                        |
    |  (PCP server Name DHCPv6 Option) |                        |
    |                                  |                        |
    |-------  DHCPv6 Request  -------->|                        |
    |  (PCP server Name DHCPv6 Option) |                        |
    |                                  |                        |
    |<-------- DHCPv6 Reply ---------  |                        |
    |  (PCP server Name DHCPv6 Option) |                        |
                        
                DHCPv6                         RADIUS 
]]></artwork>
        </figure></t>

      <t>The <xref target="fig2"></xref> illustrates how the RADIUS protocol
      and DHCPv6 work together to accomplish PCP client configuration when
      DHCPv6 is used to provide connectivity to a requesting host.</t>

      <t>The difference between this message flow and previous one is that in
      this scenario the interaction between NAS and AAA/ RADIUS Server is
      triggered by the DHCPv6 Solicit message received by the NAS from the
      DHCPv6 client, while in case of a PPP Session the trigger is the PPP LCP
      Config Request message received by the NAS.</t>

      <figure anchor="fig2" height=""
              title="RADIUS and DHCPv6 Message Flow for an IP Session">
        <artwork><![CDATA[ PCP/DHCPv6                           NAS                     AAA
  Client                           DHCPv6 Server             Server
    |                                  |                        |
    |------ DHCPv6 Solicit --------->  |                        |
    |                                  |                        |
    |                                  |----Access-Request ---->|
    |                                  |                        |
    |                                  |<-Access-Accept---------|
    |                                  | (PCP-Server-Name)      |
    |                                  |                        |
    |<-------DHCPv6 Advertisement------|                        |
    |  (PCP Server Name DHCPv6 Option) |                        |
    |                                  |                        |
    |-------  DHCPv6 Request  -------->|                        |
    |  (PCP Server Name DHCPv6 Option) |                        |
    |                                  |                        |
    | <-------- DHCPv6 Reply --------- |                        |             
    | (PCP Server Name DHCPv6 Option)  |                        |
                        
                DHCPv6                         RADIUS 
]]></artwork>
      </figure>

      <t></t>

      <t>In the scenario depicted in <xref target="fig2"></xref> 
      the Access-Request packet SHOULD contain a Service-Type
      attribute (6) with the value Authorize Only (17); thus,
      according to <xref target="RFC5080"></xref>,
      the Access-Request packet MUST contain a State attribute
      that it obtains from the previous authentication
      process.</t>

      <t>In both scenaiors mentioned above, Message-Authenticator
      (type 80) according to <xref target="RFC2869"></xref>
      SHOULD be used to protect both Access-Request and 
      Access-Accept Messages.</t>

<t> In case that the PCP server name is re-configured,
    the RADIUS server must send a RADIUS CoA message
   [RFC5176] that carries the RADIUS PCP server name 
   attribute to the
   NAS, which once accepts and sends back a RADIUS CoA ACK
   message, the new
   PCP server name replaces the original one and is then
   re-propulated by the DHCPv6 server.</t>

      <t>A similar message flow also applies to the IPv4 scenario when DHCPv4
      is used to provide connectivity to the user (<xref
      target="fig3"></xref>).</t>

      <figure anchor="fig3" height=""
              title="RADIUS and DHCPv4 Message Flow for an IP Session">
        <artwork><![CDATA[ PCP/DHCPv4                             NAS                     AAA
  Client                            DHCPv4 Server              Server
    |                                  |                        |
    |-------- DHCP Discovery --------> |                        |
    |                                  |                        |
    |                                  |----Access-Request ---->|
    |                                  |                        |
    |                                  |<-Access-Accept---------|
    |                                  | (PCP-Server-Name)      |
    |                                  |                        |
    |<--------- DHCP Offer ------------|                        |
    |    (PCP server Name Sub-Option)  |                        |
    |                                  |                        |
    |---------  DHCP Request  -------->|                        |
    |   (PCP server Name Sub-Option)   |                        |   
    |                                  |                        |
    | <--------- DHCP Ack -------------|                        |             
    |    (PCP server Name Sub-Option)  |                        |
        
                DHCPv4                         RADIUS 
]]></artwork>
      </figure>

      <t></t>

      <t>After receiving the PCP server name in the initial Access-Accept the
      NAS MUST store the received PCP Server Name locally. When the PCP Client
      sends a DHCPv4 message to request an extension of the lifetimes for the
      assigned address or prefix, the NAS does not have to initiate a new
      Access-Request towards the AAA server to request the PCP server name.
      The NAS retrieves the previously stored PCP Server name and uses it in
      its reply.</t>

      <t>If the DHCPv4 server to which the DHCP Renew message was sent at time
      T1 has not responded, the DHCPv4 client initiates a Rebind/Reply
      exchange with any available server. In this scenario the NAS MUST
      initiate a new Access-Request towards the AAA server, after the
      co-located DHCPv4 server receives the DHCP message. The NAS MAY include
      the PCP Server Name attribute in its Access-Request.</t>

      <t>If the NAS does not receive the PCP server name attribute in the
      Access-Accept it MAY fallback to a pre-configured default tunnel name,
      if any. If the NAS does not have any pre-configured default tunnel name
      or if the NAS receives an Access-Reject, the PCP client can not be
      configured by the NAS.</t>

<t>The handling when the PCP server name is re-configured
   on the RADIUS server is similar to that in IPv6 case, i.e.,
   the new PCP server name is conveyed to the NAS in  
   a RADIUS CoA message, which if accepted, the new
   PCP server name replaces the original one and is then
   re-propulated by the DHCPv4 server.</t>

      <t>The scenario with PPP Session and IPv4 only connectivity does not
      require DHCPv4: the whole configuration of the client is performed by
      PPP. This case is out of scope of this document because in order to
      complete the configuration of the PCP client a new PPP IPCP option would
      be required.</t>
    </section>

    <section anchor="Attrib" title="PCP-Server-Name RADIUS Attribute">
      <t>A new RADIUS attribute, called PCP-Server-Name, along with its format
      is defined below.</t>

      
          <t>The PCP-Server-Name attribute contains a name that refers to a
          PCP server the client requests to establish a connection to for PCP
          related service. The NAS shall use the name(s) returned in the
          RADIUS PCP-Server-Name attribute instance(s) to populate the PCP
          Server Name DHCP Sub-Option in IPv4 addressing context, or the PCP
          Server Name DHCPv6 Option in IPv6 addressing context, as determined
          by the DHCP server <xref target="I-D.ietf-pcp-dhcp"></xref>. The
          same or distinct PCP Server Names MAY be configured; it is out of
          scope of this document to elaborate on this point. Nevertheless, the
          PCP-Server-Name attribute conveys an indication for the deployment
          context.</t>

          <t>The PCP-Server-Name attribute MAY appear in an Access-Accept
          packet. This attribute MAY be used in Access-Request packets as a
          hint to the RADIUS server; for example if the NAS is pre-configured
          with a default PCP server name, this name MAY be inserted in the
          attribute. The RADIUS server MAY ignore the hint sent by the NAS and
          it MAY assign a different PCP Server name. If the NAS includes the
          PCP Server Name attribute, but the AAA server does not recognize it,
          this attribute MUST be ignored by the AAA Server. If the NAS does
          not receive PCP Server Name attribute in the Access-Accept it MAY
          fallback to a pre-configured default PCP server name, if any. If the
          NAS is pre-provisioned with a default PCP server name and the PCP
          server name received in Access-Accept is different from the
          configured default, then the PCP server name received in the
          Access-Accept message MUST be used for the session.</t>

          <t>The PCP server Name RADIUS attribute MAY be present in
          Accounting-Request records where the Acct-Status-Type is set to
          Start, Stop or Interim-Update. </t>

<t> The PCP server name RADIUS attribute MAY be present in
 an CoA-Request packet, when the PCP server name is re-configured. </t>
        
<t>The PCP Server Name RADIUS attribute
          MAY appear more than once in a message.</t>

      <t>A summary of the PCP-Server-Name RADIUS attribute format is shown
      below. The fields are transmitted from left to right.</t>

      <figure>
        <artwork><![CDATA[    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     |             Context           |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      PCP-Server-Name  ....          
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>

      <t>The description of the fields is as follows:</t>

      <t>Type:</t>

      <t><list counter="1" hangIndent="5" style="empty">
          <t>TBA1 for PCP-Server-Name.</t>
        </list></t>

      <t>Length: <list counter="1" hangIndent="5" style="empty">
          <t>This field indicates the total length in octets of this attribute
          including the Type, the Length fields.</t>
        </list>Context:<list counter="1" hangIndent="5" style="empty">
          <t>This field indicates the IP connectivity context: <list
              counter="1" hangIndent="5" style="empty">
              <t>0: Dual-Stack. The same option is provided for both DHCPv4
              and DHCPv6 requesting hosts.</t>

              <t>1: This option is provided for DHCPv4 requesting hosts.</t>

              <t>2: This option is provided for DHCPv6 requesting hosts.</t>
            </list></t>
        </list></t>

      <t>PCP-Server-Name:<list counter="1" hangIndent="5" style="empty">
          <t>Includes a PCP Server Name. As defined in , PCP Server Name is a
          UTF-8 <xref target="RFC3629"></xref> string that can be passed to
          getaddrinfo(), such as a DNS name, address literals, etc. The name
          MUST NOT contain spaces or nulls.</t>
        </list></t>

      <!-- ProvSnd -->

      <!-- ProvRecv -->

      <t></t>

      <t>This attribute is type of complex <xref target="RFC6158"></xref>.</t>

      <t></t>
    </section>

    <section title="Table of attributes">
      <t>The following table provides a guide to which attributes may be found
      in which kinds of packets, and in what quantity.</t>

      <t><figure>
          <artwork><![CDATA[Request Accept Reject Challenge Accounting  #   Attribute
                                Request
0+      0+     0      0         0+         TBA1 PCP-Server-Name
0-1     0-1    0      0         0-1         6   Service-Type
0-1     0-1    0-1    0-1       0-1         80  Message-Authenticator
]]></artwork>
        </figure></t>

      <t>The following table defines the meaning of the above table
      entries.</t>

      <t><figure>
          <artwork><![CDATA[0   This attribute MUST NOT be present in packet.
0+  Zero or more instances of this attribute MAY be present in
    packet.
0-1 Zero or one instance of this attribute MAY be present in packet.]]></artwork>
        </figure></t>
    </section>

    <section anchor="seccons" title="Security Considerations">
      <t>This document has no additional security considerations beyond those
      already identified in <xref target="RFC2865"></xref>.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests the allocation of a new Radius attribute types
      from the IANA registry "Radius Attribute Types" located at
      http://www.iana.org/assignments/radius-types:</t>

      <t><list style="empty">
          <t>PCP-Server-Name - TBA1</t>
        </list></t>
    </section>

    <section title="Acknowledgments">
      <t>The authors would like to thank Mario Ullio, Alan Dekok,
Sheng Jiang and Tassos Chatzithomaoglou for their
      valuable comments and assistance.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References"> 

      <?rfc include='reference.I-D.ietf-pcp-dhcp'?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.3629'?>

      <?rfc include='reference.RFC.2865'?>

      <?rfc include='reference.RFC.5080'?>
      
      
      
      <?rfc include='reference.RFC.6158'?>

      <?rfc include='reference.RFC.6519'?>

      <?rfc include='reference.RFC.6887'?>
    
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.2869'?>

      <?rfc include='reference.RFC.5176'?>

      <?rfc include='reference.RFC.6333'?>
      
      <?rfc include='reference.RFC.6911'?>

    </references>
  </back>
</rfc>
