Subject: [pcp] strengthening PCP with Mapping Nonce

From: "Dan Wing" <[email-masked]>
Date: Fri, 17 Aug 2012 17:51:22 -0700

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

---

From: "Zhangzongjian (Thomas)" <[email-masked]>
Date: Wed, 22 Aug 2012 07:59:12 +0000

Dear wing

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
> Wing
> Sent: Saturday, August 18, 2012 8:51 AM
> To: [email-masked]
> Cc: 'Stuart Cheshire'
> Subject: [pcp] strengthening PCP with Mapping Nonce
> 
Thomas=>
Why does not the home NAT use the third party option? 
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.

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

Best regards
Thomas

---

From: Simon Perreault <[email-masked]>
Date: Wed, 22 Aug 2012 09:18:26 -0400

> Why does not the home NAT use the third party option?

In Dan's scenario the home NAT does not support PCP.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 22 Aug 2012 08:50:52 -0700

> From: Zhangzongjian (Thomas) [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2012 12:59 AM
> To: Dan Wing; [email-masked]
> Cc: 'Stuart Cheshire'
> Subject: RE: [pcp] strengthening PCP with Mapping Nonce
> 
> Dear wing
> 
> 
> > networks behind the same home NAT.  The hosts are on separate
> networks.
> > One
> > manually, and has a PCP-created mapping in the CGN.  The attacker
> uses
> > UPnP

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.

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

---

From: "Zhangzongjian (Thomas)" <[email-masked]>
Date: Thu, 23 Aug 2012 01:59:06 +0000

> From: Dan Wing [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2012 11:51 PM
> To: Zhangzongjian (Thomas); [email-masked]
> Cc: 'Stuart Cheshire'
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.  The MAP opcode MAY be permitted if the
> recommendation
> > > of
> > >                REQ-7 is adopted; the map opcode MUST NOT be
> permitted
> > > in
> > >                other circumstances.  These constraints MAY be
> relaxed
> > if

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 23 Aug 2012 09:49:27 -0700

> Sent: Wednesday, August 22, 2012 6:59 PM
...
> 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.
> 
> > > > 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
> > > > changes, but we are doing some text coordination before
> publishing -
> > > 27.
> > > >
> > > > -d
> > > >
> > > > -----
> > > >
> > > >            control over NAT mappings.  That protocol SHOULD be
> the
> > > Port
> > > >            Control Protocol [I-D.ietf-pcp-base], in which case
> the
> > > PCP
> > > >                Threat Model (see Section 17.2 of [I-D.ietf-pcp-
> base])
> > > is

---

From: "Zhangzongjian (Thomas)" <[email-masked]>
Date: Fri, 24 Aug 2012 08:06:18 +0000

>   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.
  How could the PCP client know the inner NAT is an unsupported PCP device.  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.
  PCP client also need to know the Out NAT support 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?
 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.

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?

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

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.

Regards
Thomas

> Sent: Friday, August 24, 2012 12:49 AM
> > > > >            C.  It MUST NOT support the THIRD_PARTY option
> except
> > > for

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 24 Aug 2012 09:19:23 -0700

> Sent: Friday, August 24, 2012 1:06 AM
> 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

> > > Do you mean that the home NAT does not support PCP client, PCP
> proxy
> > > and upnp-pcp interworking?
> >
> >
> > > > > 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
> > > > > > way, the attacker steals incoming traffic intended to go to
> the
> > > > > victim host.
> > > > > >
> > > > > >
> > > > > > Diagram:
> > > > > >
> > > > > > Please provide us feedback.  I expect to publish -27 soon
> with
> > > these
> > > > > >                requests received from "trusted" sources where
> it
> > > is
> > > > > >                endpoint independent filtering behavior
> described
> > > in

---

From: "Zhangzongjian (Thomas)" <[email-masked]>
Date: Sat, 25 Aug 2012 02:22:04 +0000

Dear Wing
Replay on line

> Sent: Saturday, August 25, 2012 12:19 AM
Thomas=>
Getting a mapping does not mean there is a inner NAT in CPE.  For example, the CPE supports UPnP-PCP interworking function.
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. 

> destination address that is the PCP server in the ISP's network

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 lifetime of the mapping in the in-home residential NAT doesn't
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. The remote user can't access the server on PCP client host, but it seems that CGN works better.

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

> UPnP IGD, NAT-PMP, or screen-scraping the HTTP, or a human reading
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.

> to each possible attack & victim host pair.
Thomas=> It is ok

---

From: Sam Hartman <[email-masked]>
Date: Sun, 26 Aug 2012 22:14:55 -0400

Hi.
Margaret Wasserman and I got together for about 1.5 hours to look at the
security implications of this proposal.
I've been pondering it since that meeting.

I believe that this proposal does improve the PCP protocol.
In  particular once we have a widely implemented security mechanism, a
proposal like this could help give deployers a better set of options
under the advanced threat model.
That is, people who do need a security mechanism could turn it
on. More people would find PCP met their security needs with  the nonce
mapping change than without it even if those people did not turn on a
security mechanism.

However, Margaret and I found that this change did not remove several of
the attacks that most concern us  when a security mechanism is not used.
So, I'm strongly against the idea of relaxing the restrictions in
section 17.1 of the  base specification even if this proposal is
adopted.

>From a process standpoint, I think several people in the security
community (myself included) supported the draft because of the
compromise we reached in the simple threat model. I think we'd need to
open up the document to fairly wide review if we changed those
restrictions to seek a new security balance. I think that would add
significant delay. I'd rather see us publish the base spec with as few
changes as possible and move on with the authentication work.  In that
document or a future document we can update security restrictions if we
gain consensus to do so.

Beyond the process issues, I continue to support the technical direction
of the simple thread model.

The most serious attacks are present when there are multiple layers of
NAT involved and the outer-most NAT has a PCP server.  PCP or some other
NAT control protocol really assists the attacker in that situation.  At
least with PCP we've thought through the security implications and we've
given recommendations.  Other NAT control protocols are worse than PCP
in their security impact on the Internet.
(I don't consider this justification for weakening the simple threat
model: when we standardize things in the IETF, we often find we're
considering security implications that pre-standardization efforts
didn't consider. That's part of our value add)

Even creating a very long-lived mapping in the PCP NAT can assist an
attacker. If there is  a longer-lived outer mapping, it can assist an
attacker behind the inner NAT in capturing traffic when the inner
mapping (but not outer mapping) expires.
These attacks are somewhat complex to analyze because you have to assume
things about application behavior.
That's one of the reasons we want a very conservative stance prior to
having a mandatory to implement security mechanism.

Being able to create a mapping can also be valuable in capturing
traffic.

A and B are behind the same two nats, N1 and N2. N1, the inner NAT does
not  support PCP; N2, the outer NAT does.

A is about to contact C.  Note that from the prospective of N2, B and A
have the same source address. So, B can create mappings on A's behalf if
it can guess the port A will use.  There are a number of cases where
this is probable, especially if you consider that B can create multiple
mappings.

So, B creates a mapping that A will happen to use. B is an attacker; it
can easily deal with PCP through an inner NAT. A, even if it does
support PCP probably will not choose to use it through N1.

Later as A's session is in progress, B deletes its mapping and attempts
to create a new mapping that will reuse the same external port on N2.

Obviously several factors affect this: N2's port allocation strategy,
the application characteristics, etc etc.  It's easy to decide that the
attack is too difficult in practice.  Unfortunately, people tend to find
ways to exploit resource allocation strategies, mount timing attacks,
etc in order to mount such attacks.  Once the attack has been scripted
in a convenient tool and argument that the attack is difficult to mount
holds little weight.

Yes, there are doubtless environments where being concerned with these
attacks is not necessary.  I strongly support moving as fast as we can
to a point where we have a security mechanism and we can give customers
the choice to either use the security mechanism or turn off restrictions
required by the simple threat model.  I do not support relaxing the
simple threat model to get there.  I do not support delaying the PCP
base spec significantly at this point in the process.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 27 Aug 2012 10:27:42 -0700

> Sent: Friday, August 24, 2012 7:22 PM
> > > >   Having created mappings in the inner NAT by some other means,
> the
> > > PCP
> > > >   is aware of the inner NAT, and has taken steps to create
> mappings
> > > in
> 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.
> 
> 
> 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.

> 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.
>
>
> 
> 
> >
> 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.
> 
> 
> >
> 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.
> > > >   Having created mappings in the inner NAT by some other means,
> the
> > > PCP
> > > >   is aware of the inner NAT, and has taken steps to create
> mappings
> > > in
> > > > >    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
> > > > >    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
> > > > > > > When home NAT receives a PCP MAP request with lifetime=0
> from
> > > > > attacker,
> > > > > > > option address as the source address to search the MAP
> entries.
> > > > > Then
> > > > > > > > draft-ietf-behave-lsn-requirements-09), the attacker
> sends a
> > > new
> > > > > PCP
> > > > > > > MAP
> > > > > > > >    REQ-9:  A CGN MUST implement a protocol giving
> subscribers
> > > > > > > explicit
> > > > > > > >            control over NAT mappings.  That protocol
> SHOULD
> > > be
> > > > > the
> > > > > > > Port
> > > > > > > >            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
> > > > > > > >                other circumstances.  These constraints
> MAY
> > be
> > > > > > relaxed
> > > > > > > if
> > > > > > > >                Threat Model (see Section 17.2 of [I-
> D.ietf-
> > > pcp-
> > > > > base])
> > > > > > > is
> > > > > > > >            E.  Mappings created by PCP MUST follow the
> same
> > > > > > > deallocation

---

From: "Zhangzongjian (Thomas)" <[email-masked]>
Date: Tue, 28 Aug 2012 06:58:47 +0000

> UPnP-PCP document, so I dunno if/how the working group will conclude
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

> Sent: Tuesday, August 28, 2012 1:28 AM

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 28 Aug 2012 08:02:59 -0700

> Sent: Monday, August 27, 2012 11:59 PM

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.

-d

> > > > > >   an intervening non-PCP-aware inner NAT is detected,
> mappings
> > > must
> > > > > >   mappings can be usefully created in the outer PCP-
> controlled
> > > NAT.
> > > > > >   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
> > > > > >   it by some other means, so that mappings created in the
> outer
> > > NAT
> > > > > (Inner NAT and Out NAT)?   PCP client need to know this first
> of
> > > all.
> > > >
> > > > > the lifetime of MAP in Out NAT is 12 hour, but the lifetime of
> MAP
> > > in
> > > > > 3. The Inner NAT function on CPE may be shut down for some
> reasons,
> > > how
> > > > > 4.How could the PCP client know the external IP address on
> inner
> > > NAT?
> > > >
> > > > > > > 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
> > > > > > 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.
> > > > > >
> > > > > >   an intervening non-PCP-aware inner NAT is detected,
> mappings
> > > must
> > > > > >   mappings can be usefully created in the outer PCP-
> controlled
> > > NAT.
> > > > > >   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
> > > > > >   it by some other means, so that mappings created in the
> outer
> > > NAT
> > > > > > > Draft-ietf-pcp-base-26 tells something about mis-match.
> Below
> > > are
> > > > > > >    and prevent accidental use of PCP where a non-PCP-aware
> NAT
> > > > > exists
> > > > > > > > > > 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:
> > > > > > > > > >
> > > > > > > > > >            Control Protocol [I-D.ietf-pcp-base], in
> which
> > > > > case
> > > > > > > the
> > > > > > > > > PCP
> > > > > > > > > >                lifetime less than the lifetime used
> for
> > > > > implicit
> > > > > > > > > >                mappings.
> > > > > > > > > >
> > > > > > > > > >                requests received from "trusted"
> sources
> > > where
> > > > > it
> > > > > > > is
> > > > > > > > > >                REQ-7 is adopted; the map opcode MUST
> NOT
> > > be
> > > > > > > > permitted
> > > > > > > > > > in
> > > > > > > > > >                a security mechanism consistent with
> PCP's
> > > > > > > Advanced
> > > > > > > > > >                used; this is expected to be rare for
> CGN
> > > > > > > deployments.
> > > > > > > > > >

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 28 Aug 2012 15:12:10 +0000

-----Original Message-----
From: Dan Wing <[email-masked]>
Date: Tue, 28 Aug 2012 08:02:59 -0700
To: "'Zhangzongjian (Thomas)'" <[email-masked]>, <[email-masked]>
Cc: 'Stuart Cheshire' <[email-masked]>
Subject: Re: [pcp] strengthening PCP with Mapping Nonce

>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?