\
[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                             Y. Cui
Internet-Draft                                                   J. Dong
Intended status: Standards Track                     Tsinghua University
Expires: April 18, 2011                                      Dayong. Guo
                                            Huawei Technologies Co., Ltd
                                                        October 15, 2010


                     pcp subscriber identification
               draft-cui-pcp-subscriber-identification-00

Abstract

   This document analyzes on PCP security problems related with
   subscriber identification, such as denial-of-service(DoS), unwanted
   deleting of mappings, man-in-the-middle(MITM), and stale mapping
   problem.  Then several solutions are proposed.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 18, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Cui, et al.              Expires April 18, 2011                 [Page 1]


Internet-Draft        pcp subscriber identification         October 2010


   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Security problem analysis of PCP separated scenario  . . . . .  4
     2.1.  DoS attacking with address spoofing  . . . . . . . . . . .  4
     2.2.  Unwanted Deleting of Mappings  . . . . . . . . . . . . . .  4
     2.3.  MITM attack  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.4.  Stale Mappings . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Possible solutions . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Authentication model for PCP . . . . . . . . . . . . . . .  5
     3.2.  Random number  . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Safe tunnel negotiation  . . . . . . . . . . . . . . . . .  6
     3.4.  Digit signature  . . . . . . . . . . . . . . . . . . . . .  6
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
















Cui, et al.              Expires April 18, 2011                 [Page 2]


Internet-Draft        pcp subscriber identification         October 2010


1.  Introduction

   PCP is primarily designed to be implemented in the context of large
   scale NAT deployments.  It offers the ability to configure a port
   forwarding capability in Service Provider NATs.  In a Service
   Provider case, subscriber identification and security are two of the
   important features.  It's the basic of providing port service and
   accounting.

   In Section 8.3 Subscriber Identification of current PCP
   protocol[I-D.draft-wing-softwire-port-control-protocol], PCP server
   uses IP address or prefix to identify PCP subscribers.  However, PCP
   is a lightweight protocol and no connection is required to be
   maintained between the Client and the Server.  It's very easy to
   create a fake IP address in many cases, so PCP server could not
   differentiate between legitimate requests and fake requests.  Due to
   these reasons, ISPs need more reliable technology to enhance the
   security.

   Generally in ISP networks, Broadband Network Gateway(BNG), aka
   Broadband Remote Access Server, provides the access authentication
   for subscribers.  The BNG can identify by means of subscribers
   information besides IP address, for example MAC address, Circuit ID
   of access device which subscribers are attached to [RFC3046], etc.
   If PCP server is embedded into BNG, it can identify a PCP client with
   the information provided by BNG.  In this case, PCP operations have
   high security.

   However, PCP server is usually coupled with Service Provider NAT
   rather than BNG.  When PCP server is separated from BNG, it can only
   identify PCP client by IP address, which may cause significant
   security problems.

   This document mainly focuses on the security problems in the
   separated scenario and methods on how to solve these problems.
















Cui, et al.              Expires April 18, 2011                 [Page 3]


Internet-Draft        pcp subscriber identification         October 2010


2.  Security problem analysis of PCP separated scenario

   PCP is a simple protocol based on UDP.  It achieves its purpose by
   one simply request/response procedure.  In separated scenario, these
   steps are vulnerable to denial-of-service (DoS), unwanted deleting of
   mappings, man-in-the-middle(MITM), and have stale mapping problem.

2.1.  DoS attacking with address spoofing

   Section 11.4 of PCP recommends IPv6 source address validation to
   protect against creating unwanted mappings.  However, an adversary
   can flood the PCP requests with bogus source address, which satisfies
   the validation rules, to cause DoS attacks exhausting mapping
   resources.  PCP server will allocate mappings for these illegal
   requests.  The limited mapping resources will soon be exhausted,
   causing legitimate subscribers not having available resources.

2.2.  Unwanted Deleting of Mappings

   In PCP, requests with internal IP address and lifetime set to zero
   are used to delete all mappings of a subscriber.  An adversary can
   flood the PCP requests with bogus source address deleting legitimate
   mappings.  By trying a large number of source addresses, an adversary
   may successfully delete some legitimate mappings.  This kind of
   attack will disrupt the normal PCP uses.

2.3.  MITM attack

   An adversary may try to eavesdrop and collect PCP requests.  The
   normal request message contains some internal port numbers the PCP
   client wants to request.  Adversary may increase a large number of
   fake internal ports and replay these requests.  Then PCP server has
   to allocate some additional mappings that are unnecessary.  If a
   large number of PCP requests are modified, the mapping resources
   would be exhausted.  On the other way, by setting the lifetime and
   internal address to zero, an adversary may successfully delete some
   mappings to disrupt normal PCP uses.

2.4.  Stale Mappings

   Section 11.6 of [I-D.wing-softwire-port-control-protocol] has
   described this problem.









Cui, et al.              Expires April 18, 2011                 [Page 4]


Internet-Draft        pcp subscriber identification         October 2010


3.  Possible solutions

   This section will introduce several possible solutions to
   authenticate legitimate clients.  According to different operating
   environment, ISPs could choose different method.

3.1.  Authentication model for PCP

   User name and password of a subscriber can be used to enhance PCP
   security.  As shown in figure 1, PCP client sends request message
   with an extended Informational Element(IE) including user name and
   password to the PCP server.  Then PCP server, as an AAA client,
   authenticates with AAA server via Diameter[RFC3588]/Radius
   protocol[RFC2865].  Only when the authentication succeeds can the PCP
   server start to allocate mappings to PCP client.

                            +---------+
                            |         |
                            |   AAA   |
                            |  server |
                            +---------+
                                 |
                                 |
                                 |
                                 |
       +---------+          +---------+             +----------+
       |   PCP   |          |   PCP   |             |          |
       |  client |----------|  server |-------------| Internet |
       |         |          |         |             |          |
       +---------+          +---------+             +----------+

   Figure 1: Authentication model

   With the adoption of the user name and password identification
   procedure, the DoS attack, unwanted mapping deleting and stale
   mapping problem can be well defended against.  This procedure doesn't
   change the original PCP procedure for there are no new steps.
   However, it adds AAA procedure.

3.2.  Random number

   With this method, when PCP server receives a PCP request from a
   subscriber for the first time, it will reply an Error Response with a
   random number without allocating mappings to the PCP client.  The
   random number can be contained in an IE.  When a PCP client receives
   this response with random number, it will resend another PCP request
   with the same random number IE.  The IE should be stored for later
   PCP communication.



Cui, et al.              Expires April 18, 2011                 [Page 5]


Internet-Draft        pcp subscriber identification         October 2010


   With the random number method, when DoS attack with faked source
   address arrives, PCP server will not allocate mappings immediately.
   On the contrary, it replies a packet to the faked source address to
   ask the PCP client for another request with the random number, which
   the attackers will never receive.  Furthermore, random number is
   valuable against unwanted deleting of mappings.

   However, it cannot defend MITM attacks.  This method increases steps
   of PCP communication procedure at the first time.

3.3.  Safe tunnel negotiation

   This method suggests a safe tunnel like TLS or IPsec to be
   established between PCP client and server before the starting of PCP
   communication.  Based on the established safe tunnel, the PCP
   communication would be safe.  All the problems stated in section 2
   could be solved.  Note that the negotiation procedure could be
   separated from PCP communication.

   As we known that PCP is designed as a lightweight protocol.  However,
   safe tunnel negotiation would makes the whole PCP procedure
   complicate.  Especially, PCP server needs to process a large number
   of encrypted/decrypted information to establish safe tunnel.  The
   costs for safe tunnel establishing may be more than that of PCP
   procedure itself.

3.4.  Digit signature

   The digit signature method suggests that PCP request and response
   messages should have an extended IE including digitally signed random
   number.  The random number is firstly generated by PCP server.  Every
   time when PCP server needs to send a response, it should generate a
   new random number and signs this random number.  Figure 2 is a simple
   procedure of the digit signature method.

  +---------+                                                 +---------+
  |   PCP   |                                                 |   PCP   |
  |  client |                                                 |  server |
  |         |                                                 |         |
  +---------+                                                 +---------+
     |     PCP request with digitally signed random number          |
     | ------------------------------------------------------->     |
     |                                                              |
     |                                                              |
     |    PCP response with digitally signed random number          |
     | <-------------------------------------------------------     |

   Figure 2: Digit signature method



Cui, et al.              Expires April 18, 2011                 [Page 6]


Internet-Draft        pcp subscriber identification         October 2010


   This method is considered to be more secure than random number method
   and not as complicated as safe tunnel negotiation method.

















































Cui, et al.              Expires April 18, 2011                 [Page 7]


Internet-Draft        pcp subscriber identification         October 2010


4.  Security Considerations

   To be defined.
















































Cui, et al.              Expires April 18, 2011                 [Page 8]


Internet-Draft        pcp subscriber identification         October 2010


5.  IANA Considerations

   No IANA requirement.
















































Cui, et al.              Expires April 18, 2011                 [Page 9]


Internet-Draft        pcp subscriber identification         October 2010


6.  Acknowledgments


















































Cui, et al.              Expires April 18, 2011                [Page 10]


Internet-Draft        pcp subscriber identification         October 2010


7.  References

7.1.  Normative References

   [I-D.wing-softwire-port-control-protocol]
              Wing, D., Penno, R., and M. Boucadair, "Pinhole Control
              Protocol (PCP)",
              draft-wing-softwire-port-control-protocol-02 (work in
              progress), July 2010.

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

7.2.  Informative References

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

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



























Cui, et al.              Expires April 18, 2011                [Page 11]


Internet-Draft        pcp subscriber identification         October 2010


Authors' Addresses

   Yong Cui
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6260-3059
   Email: yong@csnet1.cs.tsinghua.edu.cn


   Jiang Dong
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5822
   Email: dongjiang@csnet1.cs.tsinghua.edu.cn


   Dayong Guo
   Huawei Technologies Co., Ltd
   Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District
   Beijing  100085
   P.R.China

   Email: guoseu@huawei.com






















Cui, et al.              Expires April 18, 2011                [Page 12]