Re: [pcp] strengthening PCP with Mapping Nonce

"Reinaldo Penno (repenno)" <repenno@cisco.com> Tue, 28 August 2012 15:12 UTC

Return-Path: <repenno@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 839D421F8513 for <pcp@ietfa.amsl.com>; Tue, 28 Aug 2012 08:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 Xs0oddJYV-CY for <pcp@ietfa.amsl.com>; Tue, 28 Aug 2012 08:12:13 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B171821F84F2 for <pcp@ietf.org>; Tue, 28 Aug 2012 08:12:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=20291; q=dns/txt; s=iport; t=1346166732; x=1347376332; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=iuCkfNX90mRGG4e6Ph65C4/Qu1k1m5x/O60Vpjphmq8=; b=hxWipzKN2zWeZmGCy8zivQ03s59yWwkykIL1CN3nN9AdHfXZJzbENgqF 7MczMurFisIyin0bj0Qp5EyfToxB/2j7y7RXEi37/ri6qywqHqO6gjKWc rA/+Y/O5H+2p5N2PJ8klLtgucqs21NNonJcrnGJKY4MHN8jZdlR/B25t6 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAHPfPFCtJV2Z/2dsb2JhbABFumqBB4IgAQEBAwEBAQEPASctBgELDAYBCBECAQEBAR8JLgsUCQgCBAENBRkJh2UGC5tQoEqLCIZZA5VWji6BZ4Jj
X-IronPort-AV: E=Sophos;i="4.80,327,1344211200"; d="scan'208";a="116039237"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 28 Aug 2012 15:12:11 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7SFCB01012575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Aug 2012 15:12:11 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Tue, 28 Aug 2012 10:12:10 -0500
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: "Dan Wing (dwing)" <dwing@cisco.com>, "'Zhangzongjian (Thomas)'" <zhangzhongjian@huawei.com>, "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: [pcp] strengthening PCP with Mapping Nonce
Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgwABEHyxAAFIZlwAAfravAAB3rq7AAEybCEAARu6pwAIesO8AAHDBB0AARF5uA///iVgA=
Date: Tue, 28 Aug 2012 15:12:10 +0000
Message-ID: <CC622CD9.99D3%repenno@cisco.com>
In-Reply-To: <073701cd852e$36ac8c40$a405a4c0$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.89.2.202]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007
x-tm-as-result: No--65.299500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E3F5D1967EF987458A9F3F07F59D3C16@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 15:12:14 -0000

-----Original Message-----
From: Dan Wing <dwing@cisco.com>;
Date: Tue, 28 Aug 2012 08:02:59 -0700
To: "'Zhangzongjian (Thomas)'" <zhangzhongjian@huawei.com>;, <pcp@ietf.org>;
Cc: 'Stuart Cheshire' <cheshire@apple.com>;
Subject: Re: [pcp] strengthening PCP with Mapping Nonce

>> -----Original Message-----
>> From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com]
>> Sent: Monday, August 27, 2012 11:59 PM
>> To: Dan Wing; pcp@ietf.org
>> Cc: 'Stuart Cheshire'
>> Subject: RE: [pcp] strengthening PCP with Mapping Nonce
>> 
>> > 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.
>
>Yes, I agree that would be strange.  But the current plan for PCP
>proxying has the PCP client only communicate with its local (closest)
>PCP server, and not communicate with every upstream PCP server.  So
>blocking that communication would be in line with the current plan
>for PCP proxying.  However, that current plan for PCP proxying might
>change if it doesn't work properly with PCP authentication or
>with asymmetric routing or some other new problem.


The I believe we should change otherwise wouldn't this be a problem for
the protocol evolution? Suppose I want to control the Firewall policies of
my machine in some datacenter from my home - and the CPE implements this
kind of 'blocking' PCP Proxy?
 

>
>-d
>
>
>> 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
>
>_______________________________________________
>pcp mailing list
>pcp@ietf.org
>https://www.ietf.org/mailman/listinfo/pcp