Re: [pcp] strengthening PCP with Mapping Nonce
"Zhangzongjian (Thomas)" <zhangzhongjian@huawei.com> Tue, 28 August 2012 07:00 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 86CA421F8474 for <pcp@ietfa.amsl.com>; Tue, 28 Aug 2012 00:00:15 -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 6augqryo9KBU for <pcp@ietfa.amsl.com>; Tue, 28 Aug 2012 00:00:13 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AA7BC21F8476 for <pcp@ietf.org>; Tue, 28 Aug 2012 00:00:12 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJB89464; Tue, 28 Aug 2012 07:00:11 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 28 Aug 2012 07:58:29 +0100
Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 28 Aug 2012 14:58:55 +0800
Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.83]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Tue, 28 Aug 2012 14:58:47 +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: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgwABEHyxAAFIZlwAAfravAAB3rq7AAEybCEAARu6pwAIesO8AAHDBB0A==
Date: Tue, 28 Aug 2012 06:58:47 +0000
Message-ID: <0B2F754289D27B449F7F1B95456B77544EDC59D9@szxeml524-mbs.china.huawei.com>
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> <07c901cd8214$39a4c970$acee5c50$@com> <0B2F754289D27B449F7F1B95456B77544EDC558E@szxeml524-mbs.china.huawei.com> <037101cd8479$43b2e840$cb18b8c0$@com>
In-Reply-To: <037101cd8479$43b2e840$cb18b8c0$@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: Tue, 28 Aug 2012 07:00:15 -0000
> If there is a UPnP-PCP interworking function in the CPE router, > I would expect the CPE router would prohibit PCP clients within > the home from communicating directly with the PCP server in the > CGN. However, the PCP working group has not yet finished the > UPnP-PCP document, so I dunno if/how the working group will conclude > on this problem. > It seems strange to prohibit PCP clients from communicating directly with PCP server. Sorry, I make a mistake on adding THIRD_PARTY question. Regards Thomas > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Tuesday, August 28, 2012 1:28 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: Friday, August 24, 2012 7:22 PM > > To: Dan Wing; pcp@ietf.org > > Cc: 'Stuart Cheshire' > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > Dear Wing > > Replay on line > > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > Sent: Saturday, August 25, 2012 12:19 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: 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. > > > > > Thomas=> > > Getting a mapping does not mean there is a inner NAT in CPE. For > > example, the CPE supports UPnP-PCP interworking function. > > If there is a UPnP-PCP interworking function in the CPE router, > I would expect the CPE router would prohibit PCP clients within > the home from communicating directly with the PCP server in the > CGN. However, the PCP working group has not yet finished the > UPnP-PCP document, so I dunno if/how the working group will conclude > on this problem. > > > > Learning the IP address of CGN means there is a CGN, but it does not > > mean it is the second NAT. it may be the first NAT or the third NAT. > > > > > > > > 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). > > > > Thomas=> > > Yes you are right. I mean when inner NAT has PCP proxy function, it may > > add a third party option. It won't know use source IP address or PCP > > Client's IP address in request header as the third party option value. > > PCP proxy may discard the PCP request packet as the illegal packet. > > Then the PCP client has to know whether CPE (inner NAT device) support > > PCP. If CPE does, it can't send the request packet with different > > source IP address and PCP Client's IP address. Or else it can do. > > The inner NAT has no reason to add THIRD_PARTY, because the PCP > request would come from the same IP address as the "PCP Client > Source IP Address" in the PCP request. And the current text in > pcp-base prohibits it from doing so, anyway. > > > > > > 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. > > > > > Thomas=> > > You are right, it has nothing to do with attack. > > I mean when we take consideration of two level NATs on draft-PCP-base, > > there will be a lifetime disaccord problem. When the lifetime of > > mapping entry in inner NAT expired, the mapping entry in outer NAT > > still active. > > Sure. Not much we can do about that. (I see Sam answered this > point in more detail over the weekend.) > > -d > > > > The remote user can't access the server on PCP client > > host, but it seems that CGN works better. > > > > > > > > > > > > > > > 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. > > > > > Thomas=> > > Right, but PCP client needs to know whether inner NAT shuts down to > > decide whether it constructs PCP request's PCP Client's IP address with > > source address or external IP address from inner NAT. I think there are > > varies reason that user will shut down NAT or turn on NAT function on > > CPE. > > > > > > > > > > > 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. > > > > > Thomas=> > > I remember that UPnP can get the IP address on WAN interface. But > > external IP address is a address pool of NAT. IP address on WAN and > > external IP address of pool may be the different IP address. > > I am not sure in this field. If there are an external IP in UPnP > > packets, it will be ok. > > > > > > > > > > 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. > > Thomas=> It is ok > > > > > > > > -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
- Re: [pcp] strengthening PCP with Mapping Nonce Dan Wing
- Re: [pcp] strengthening PCP with Mapping Nonce Zhangzongjian (Thomas)
- Re: [pcp] strengthening PCP with Mapping Nonce Dan Wing
- [pcp] strengthening PCP with Mapping Nonce Dan Wing
- Re: [pcp] strengthening PCP with Mapping Nonce Zhangzongjian (Thomas)
- Re: [pcp] strengthening PCP with Mapping Nonce Simon Perreault
- Re: [pcp] strengthening PCP with Mapping Nonce Zhangzongjian (Thomas)
- Re: [pcp] strengthening PCP with Mapping Nonce Dan Wing
- Re: [pcp] strengthening PCP with Mapping Nonce Zhangzongjian (Thomas)
- Re: [pcp] strengthening PCP with Mapping Nonce Sam Hartman
- Re: [pcp] strengthening PCP with Mapping Nonce Dan Wing
- Re: [pcp] strengthening PCP with Mapping Nonce Zhangzongjian (Thomas)
- Re: [pcp] strengthening PCP with Mapping Nonce Dan Wing
- Re: [pcp] strengthening PCP with Mapping Nonce Reinaldo Penno (repenno)