Re: [pcp] strengthening PCP with Mapping Nonce

"Zhangzongjian (Thomas)" <zhangzhongjian@huawei.com> Thu, 23 August 2012 02:02 UTC

Return-Path: <zhangzhongjian@huawei.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7807B21F854A for <pcp@ietfa.amsl.com>; Wed, 22 Aug 2012 19:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFlRNkI2+Zzj for <pcp@ietfa.amsl.com>; Wed, 22 Aug 2012 19:02:01 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4221A21F853D for <pcp@ietf.org>; Wed, 22 Aug 2012 19:02:01 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfwdlp03-ep.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJM59299; Wed, 22 Aug 2012 18:02:00 -0800 (PST)
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 18:59:12 -0700
Received: from SZXEML433-HUB.china.huawei.com (10.72.61.61) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 18:59:10 -0700
Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.83]) by szxeml433-hub.china.huawei.com ([10.72.61.61]) with mapi id 14.01.0323.003; Thu, 23 Aug 2012 09:59:06 +0800
From: "Zhangzongjian (Thomas)" <zhangzhongjian@huawei.com>
To: Dan Wing <dwing@cisco.com>, "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: [pcp] strengthening PCP with Mapping Nonce
Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgwABEHyxAAFIZlwA==
Date: Thu, 23 Aug 2012 01:59:06 +0000
Message-ID: <0B2F754289D27B449F7F1B95456B77544EDC5131@szxeml524-mbs.china.huawei.com>
References: <028301cd7cdb$966780a0$c33681e0$@com> <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> <002301cd807d$e8d9fd40$ba8df7c0$@com>
In-Reply-To: <002301cd807d$e8d9fd40$ba8df7c0$@com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.77.96]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: 'Stuart Cheshire' <cheshire@apple.com>
Subject: Re: [pcp] strengthening PCP with Mapping Nonce
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Aug 2012 02:02:02 -0000

> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com]
> Sent: Wednesday, August 22, 2012 11:51 PM
> To: Zhangzongjian (Thomas); pcp@ietf.org
> Cc: 'Stuart Cheshire'
> Subject: RE: [pcp] strengthening PCP with Mapping Nonce
> 
> > -----Original Message-----
> > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com]
> > Sent: Wednesday, August 22, 2012 12:59 AM
> > To: Dan Wing; pcp@ietf.org
> > Cc: 'Stuart Cheshire'
> > Subject: RE: [pcp] strengthening PCP with Mapping Nonce
> >
> > Dear wing
> >
> >
> > > -----Original Message-----
> > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
> > Dan
> > > Wing
> > > Sent: Saturday, August 18, 2012 8:51 AM
> > > To: pcp@ietf.org
> > > Cc: 'Stuart Cheshire'
> > > Subject: [pcp] strengthening PCP with Mapping Nonce
> > >
> > > We incorporated changes to draft-ietf-behave-pcp-base from IESG
> > review.
> > >
> > > After reading the PCP restrictions in REQ-9-A through E in
> > > draft-ietf-behave-lsn-requirements-09 (copied below for reference),
> > we had a
> > > productive phone call this week between Stuart Cheshire, Simon
> > Perreault,
> > > Sam Hartman, and myself.  During that discussion, we found a way to
> > > strengthen security of PCP against a specific attack and hopefully
> > soften
> > > some of the restrictions in both draft-ietf-behave-lsn-requirements
> > (REQ-9-A
> > > through E) and draft-ietf-pcp-base for the PCP Basic Threat Model,
> > when PCP
> > > is not using authentication.
> > >
> > > To achieve this, we need to improve how draft-ietf-pcp-base handles
> > Mapping
> > > Nonce values.  Currently, draft-ietf-pcp-base is pretty silent on how
> > and
> > > when the PCP client chooses its Mapping Nonce value, and says this
> > about
> > > server processing, which sort of implies the PCP client is free to
> > change
> > > the Mapping Nonce value whenever it likes,
> > > http://tools.ietf.org/html/draft-ietf-pcp-base-26#section-11.3,
> > >
> > >    The PCP server only needs to remember one Mapping Nonce value for
> > >    each mapping (that is, the most recent Mapping Nonce value
> > overwrites
> > >    the previous Mapping Nonce value).
> > >
> > > We would replace the above text with something like:
> > >
> > >    If the Internal port, Protocol, and Internal Address match an
> > >    existing explicit dynamic mapping, but the Mapping Nonce does not
> > >    match, the request MUST be rejected with a NOT_AUTHORIZED error
> > with
> > >    the Lifetime of the error indicating duration of that existing
> > >    mapping.  The PCP server only needs to remember one Mapping
> Nonce
> > >    value for each explicit dynamic mapping.
> > >
> > > with this change (and corresponding text for the PCP client's
> > generation of
> > > a Mapping Nonce, and corresponding text for PEER), we avoid the
> > attack
> > > described in detail below.
> > >
> > >
> > > Attack:  The attack is a traffic-stealing attack.  The diagram below
> > may
> > > help with the textual description.  The attack scenario is where
> > there is a
> > > CGN running PCP and a home NAT not running PCP, and two hosts on
> > separate
> > > networks behind the same home NAT.  The hosts are on separate
> > networks.
> > > One
> > > host is running a server (the victim) on the wired network, the other
> > host
> > > is the attacker on the guest Wi-Fi network.  The host running the
> > server has
> > > a mapping created in the NAT, which was created with UPnP IGD or
> > created
> > > manually, and has a PCP-created mapping in the CGN.  The attacker
> > uses
> > > UPnP
> > > IGD, NAT-PMP, STUN (RFC5389), or STUNT
> > > (http://nutss.gforge.cis.cornell.edu/stunt.php) to create a mapping
> > in the
> > > home NAT and learn the home NAT's "WAN" address.  The attacker
> > > formulates a
> > > PCP MAP request with the NAT's WAN address in the PCP Client IP
> > Address
> > > field, Lifetime=0, and sends that to the CGN, deleting the CGN's
> > existing
> > > mapping that goes to the victim machine.  That attack packet is sent
> > without
> > Thomas=>
> > Why does not the home NAT use the third party option?
> 
> In the above attack scenario, the home NAT does not support PCP at
> all.
> 
> And, if it did, there is no need for THIRD_PARTY if all traffic
> is NAT'ed to one IP address, as typically occurs with a residential
> NAT.
>
Thomas=>
Do you mean that the home NAT does not support PCP client, PCP proxy and upnp-pcp interworking?
But, how could the victim host create the MAP entries?
As you know the home NAT will change the source IP address of PCP request from hosts. This will result to mis-match with " PCP Client's IP Address" in PCP request heard. Then  PCP server will return an ADDRESS_MISMATCH error without creating MAP entry.

Draft-ietf-pcp-base-26 tells something about mis-match. Below are copied from last paragraph of chart 8.2 for reference.

The PCP server compares the source IP address (from the received IP
   header) with the field PCP Client IP Address.  If they do not match,
   the error ADDRESS_MISMATCH MUST be returned.  This is done to detect
   and prevent accidental use of PCP where a non-PCP-aware NAT exists
   between the PCP client and PCP server.  If the PCP client wants such
   a mapping it needs to ensure the PCP field matches its apparent IP
   address from the perspective of the PCP server.


 
> -d
> 
> > When home NAT receives a PCP MAP request with lifetime=0 from attacker,
> > it should add a third party option with the attacker's IP address in
> > this option. When CGN gets the PCP request, it will use the third party
> > option address as the source address to search the MAP entries. Then
> > the attacker can't delete the MAP entry created by victim.
> >
> >
> > > address spoofing.  120 seconds later (per REQ-8 of
> > > draft-ietf-behave-lsn-requirements-09), the attacker sends a new PCP
> > MAP
> > > request to try to acquire the (old) mapping of the victim host.  In
> > this
> > > way, the attacker steals incoming traffic intended to go to the
> > victim host.
> > >
> > >
> > > Diagram:
> > >
> > >                   +-------------+    +----------+
> > >   attacker -------+             |    |          |
> > >   (guest network) |             |    |          |
> > >                   |   home NAT  +----+    CGN   +----{Internet}
> > >   victim ---------+(without PCP)|    |(with PCP)|
> > >   (wired network) |             |    |          |
> > >                   +-------------+    +----------+
> > >
> > >
> > > Please provide us feedback.  I expect to publish -27 soon with these
> > > changes, but we are doing some text coordination before publishing -
> > 27.
> > >
> > > -d
> > >
> > > -----
> > >
> > >    REQ-9:  A CGN MUST implement a protocol giving subscribers
> > explicit
> > >            control over NAT mappings.  That protocol SHOULD be the
> > Port
> > >            Control Protocol [I-D.ietf-pcp-base], in which case the
> > PCP
> > >            server MUST obey the following constraints on its
> > behavior:
> > >
> > >            A.  It MUST NOT permit the lifetime of a mapping to be
> > >                reduced beyond its current life or be set to zero
> > >                (deleted).
> > >
> > >            B.  It MUST NOT permit a NAT mapping to be created with a
> > >                lifetime less than the lifetime used for implicit
> > >                mappings.
> > >
> > >            C.  It MUST NOT support the THIRD_PARTY option except
> for
> > >                requests received from "trusted" sources where it is
> > >                impractical for those sources to be spoofed.
> > >
> > >            D.  The MAP opcode MAY be permitted if the
> recommendation
> > > of
> > >                endpoint independent filtering behavior described in
> > >                REQ-7 is adopted; the map opcode MUST NOT be
> permitted
> > > in
> > >                other circumstances.  These constraints MAY be
> relaxed
> > if
> > >                a security mechanism consistent with PCP's Advanced
> > >                Threat Model (see Section 17.2 of [I-D.ietf-pcp-base])
> > is
> > >                used; this is expected to be rare for CGN deployments.
> > >
> > >            E.  Mappings created by PCP MUST follow the same
> > deallocation
> > >                behavior (REQ-8) as implicitly mapped traffic.
> > >
> > >
> > > _______________________________________________
> > > pcp mailing list
> > > pcp@ietf.org
> > > https://www.ietf.org/mailman/listinfo/pcp
> >
> > Best regards
> > Thomas