Re: [pcp] strengthening PCP with Mapping Nonce

"Dan Wing" <dwing@cisco.com> Fri, 24 August 2012 16:19 UTC

Return-Path: <dwing@cisco.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 1073C21F858F for <pcp@ietfa.amsl.com>; Fri, 24 Aug 2012 09:19:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.494
X-Spam-Level:
X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 g-qB6fo5iuha for <pcp@ietfa.amsl.com>; Fri, 24 Aug 2012 09:19:24 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D6F4721F8585 for <pcp@ietf.org>; Fri, 24 Aug 2012 09:19:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=10997; q=dns/txt; s=iport; t=1345825164; x=1347034764; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=jZepUy7FbPX20lig/oiEK7mTXyDueYfnvOHVOZYQxps=; b=AyPGuRHmgsmIEpDi8SP+e2PKFbhGRoWZBzP44zKrGFuacv6piHRKNRs5 rqBV7bf1CAskO+3uNmB7enO7GgBt79pSISS45BWOlXPVibunEP/v1cLv4 nt+A1jLIMjpPqAIxUVFwrq6qOa4DjFuLVw+d7zwqB0xd1vr7N9FOq5koO k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FAIqoN1CrRDoJ/2dsb2JhbABFqmqPeoEHgiABAQEDAQEBAQUKARcQLQcLBQcBAwIJDwICAgEBKAcZDhUKCQgCBAESCw4Jh2UFDJkloB+LCIcRA4hPhQ2WJoFngwM
X-IronPort-AV: E=Sophos;i="4.80,304,1344211200"; d="scan'208";a="53417092"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 24 Aug 2012 16:19:24 +0000
Received: from dwingWS (sjc-vpn2-607.cisco.com [10.21.114.95]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7OGJNsb020303; Fri, 24 Aug 2012 16:19:24 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Zhangzongjian \(Thomas\)'" <zhangzhongjian@huawei.com>, <pcp@ietf.org>
References: <028301cd7cdb$966780a0$c33681e0$@com> <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> <002301cd807d$e8d9fd40$ba8df7c0$@com> <0B2F754289D27B449F7F1B95456B77544EDC5131@szxeml524-mbs.china.huawei.com> <042601cd814f$421c41c0$c654c540$@com> <0B2F754289D27B449F7F1B95456B77544EDC53B3@szxeml524-mbs.china.huawei.com>
In-Reply-To: <0B2F754289D27B449F7F1B95456B77544EDC53B3@szxeml524-mbs.china.huawei.com>
Date: Fri, 24 Aug 2012 09:19:23 -0700
Message-ID: <07c901cd8214$39a4c970$acee5c50$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgwABEHyxAAFIZlwAAfravAAB3rq7AAEybCEA==
Content-Language: en-us
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: Fri, 24 Aug 2012 16:19:26 -0000

> -----Original Message-----
> From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com]
> Sent: Friday, August 24, 2012 1:06 AM
> To: Dan Wing; pcp@ietf.org
> Cc: 'Stuart Cheshire'
> Subject: RE: [pcp] strengthening PCP with Mapping Nonce
> 
> > In -27, we have tentatively added:
> >
> >   When such
> >   an intervening non-PCP-aware inner NAT is detected, mappings must
> >   first be created by some other means in the inner NAT, before
> >   mappings can be usefully created in the outer PCP-controlled NAT.
> >   Having created mappings in the inner NAT by some other means, the
> PCP
> >   client should then use the inner NAT's External Address as the
> Client
> >   IP Address, to signal to the outer PCP-controlled NAT that the
> client
> >   is aware of the inner NAT, and has taken steps to create mappings
> in
> >   it by some other means, so that mappings created in the outer NAT
> >   will not be a pointless waste of state.
> >
> 
> Dear Wing
> 
> I think I understand your proposal, but there still are some questions.
> 
> 1. How did PCP client (host) detect that there are two levels NAT
> (Inner NAT and Out NAT)?   PCP client need to know this first of all.

It can use UPnP IGD, NAT-PMP, or HTTP screen-scraping to communicate 
with the in-home residential NAT and get a mapping.  Then, it can
use traceroute or some other technique to learn the internal IP 
address of the CGN, and send it a PCP request.

>   How could the PCP client know the inner NAT is an unsupported PCP
> device. 

It doesn't know, and it doesn't care if the in-home residential
NAT supports PCP or not.  The attack works as long as the in-home
residential NAT allows the PCP request from the attacker's IP
address to the CGN's PCP server address.

> If inner NAT supports PCP, it will find the PCP request is a
> malformed packet. It may discard the packet as the error packet or
> packet from an attacker.

In the attack scenario, the in-home residential NAT ('inner NAT') does
not support PCP.

And, even if it did, the attacker's PCP packet is not being sent to
the in-home residential NAT -- the attacker's PCP packet has a
destination address that is the PCP server in the ISP's network 
(the CGN).

>   PCP client also need to know the Out NAT support PCP.

Yes, the attack is a PCP attack, and relies on the CGN supporting PCP.


> 2. You said that " mappings must first be created by some other means
> in the inner NAT". What is the means? Manually or dynamically?

Any of these would work: (a) UPnP IGD, (b) NAT-PMP, (c) screen-
scraping HTTP to the NAT's HTTP server, or (d) a human reading
the CLI or HTTP of the NAT and manually configuring the host
to send the proper PCP message.

>  I am afraid there will be a coincident lifetime problem.  For example
> the lifetime of MAP in Out NAT is 12 hour, but the lifetime of MAP in
> inner NAT is 1  hour. What will happen when inner NAT MAP's lifetime
> expired.

The lifetime of the mapping in the in-home residential NAT doesn't 
matter for this attack.


> 3. The Inner NAT function on CPE may be shut down for some reasons, how
> could the PCP client know the dynamic change on CPE?

If the in-home residential NAT is bridging (and is not a NAT), this
PCP attack is not possible.


> 4.How could the PCP client know the external IP address on inner NAT?

UPnP IGD, NAT-PMP, or screen-scraping the HTTP, or a human reading
the CLI or HTTP.

> 5.Is it possible that there are more than one external IP address
> (maybe a private IP address) on inner NAT external Pool? For example,
> different external IP for different service.

If the victim and the attacker have different IP addresses, from the
perspective of the carrier's PCP server, this specific PCP attack is
not possible.  That occurs if the in-home residential CPE is not
NATing (as described in (3)) or if separate IP addresses are assigned
to each possible attack & victim host pair.

-d


> Regards
> Thomas
> 
> 
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:dwing@cisco.com]
> > Sent: Friday, August 24, 2012 12:49 AM
> > 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 6:59 PM
> > > To: Dan Wing; pcp@ietf.org
> > > Cc: 'Stuart Cheshire'
> > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce
> > ...
> > > Thomas=>
> > > Do you mean that the home NAT does not support PCP client, PCP
> proxy
> > > and upnp-pcp interworking?
> >
> >
> > Correct -- the home NAT, in this attack scenario, is the home NAT
> > that is currently for sale at the local computer store, which do
> > not support PCP and do not know anything about PCP.
> >
> >
> > > But, how could the victim host create the MAP entries?
> >
> > The victim's host supports PCP in its application (or its
> > operating system), which sends the PCP request to the CGN
> > directly.
> >
> >
> > > 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.
> >
> > The PCP client in the (victim) host can overcome that by placing the
> > WAN address of the NAT into the PCP Client IP Address field of the
> > PCP packet.
> >
> > In -27, we have tentatively added:
> >
> >   When such
> >   an intervening non-PCP-aware inner NAT is detected, mappings must
> >   first be created by some other means in the inner NAT, before
> >   mappings can be usefully created in the outer PCP-controlled NAT.
> >   Having created mappings in the inner NAT by some other means, the
> PCP
> >   client should then use the inner NAT's External Address as the
> Client
> >   IP Address, to signal to the outer PCP-controlled NAT that the
> client
> >   is aware of the inner NAT, and has taken steps to create mappings
> in
> >   it by some other means, so that mappings created in the outer NAT
> >   will not be a pointless waste of state.
> >
> > -d
> >
> >
> > > 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