Subject: [pcp] draft-ietf-pcp-base: security impacts of section 6 design note

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Mar 2012 00:09:43 -0400

[IESg members with discusses on PCP and transaction identifiers, please
read; I propose another argument why you probably want one.]

As I mentioned Monday, I had not thought through the  implications of a
client receiving multiple responses.
In addition, when writing the security considerations text, we were
focusing on the goal described in section 17.
It is the
   security goal of the PCP protocol to limit any new denial of service
   opportunities, and to avoid introducing new attacks that can
   result
   in unauthorized changes to mapping state.  

That's fine as far as it goals.
However, PCP also gives nodes information on their external addresses.
So, to some extent it replaces STUN, or at least you can imagine a
legitimate node choosing to trust the external address reported by PCP
and not use STUN.
If a node should not trust the external address  received from a PCP
server, then we should not provide that address.

Now, trust is relative. There's always the possibility that there's an
extra layer of NAT beyond your PCP server it doesn't know about. I
suspect some applications will run STUN anyway. However, as I read the
spec today, this is not a requirement.

So, there's an additional security goal: application security MUST NOT
be reduced by trusting PCP rather than STUN. That is, we need to analyze
the attacks that have value on a mapped address.

Most applications will take their external address and give it to
people. They might use SDP or some directory service. They might send it
over some messaging service. But they expect someone out there to try
and connect to this address.

I see 3 important attacks:

1) By modifying  a client's view of its external address the attacker
can deny service to a client by  causing it register a bogus address at
which it will not receive traffic.

2) By modifying many clients' belief about their external address, an
attacker can create  DDOS by generating a lot of traffic to a site that
is not expecting it.

3) By modifying a client's idea of an external address, an attacker can
redirect traffic destined for the client to the attacker. This can be
used as part of a man-in-the-middle attack.

In my mind, two aspects of PCP make these attacks easier to mount than
similar attacks against STUN.

1) If a client follows the design note in section 6 and receives
multiple responses from a PCP server,  then the window of opportunity is
significantly increased over the STUN binding transaction. That
transaction is a simple request/response transaction; clients do not
expect to receive multiple responses. If an attacker cannot get there
first  then an attacker loses the window for the attack.

2) PCP is significantly more vulnerable to off-path attackers than
STUN. STUN includes a 96-bit transaction identifier that an attacker
MUST guess in order to respond to a request.  PCP does not include
anything like this.  An attacker needs to guess the internal address and
internal port.  State of art is to include some sort of transaction
identifier to defend against off-path attackers: we do it in L2TP, STUN,
and a number of UDP protocols like this. We really really wish we'd done
it in DNS. In fact our work with DNS and randomized ports and avoiding
fake responses strongly suggests that mounting attacks against protocols
without long transaction identifiers is easy especially if you have a
long time window.

PCP does have one thing that is an advantage over STUN. It's not much
help against the off-path attack in a number of important deployments
(switched LAN, enterprise guest network, firewall deployments without
NAT), but it does help with the increased time window for on-path
attackers.  There's a lot less on-path. If your PCP server is in your
CPE, the path from you to it is shorter than the path from you to a STUN
server.

I have two recommendations.

First, PCP should add a transaction ID between 96-bits and 128-bits. (No
reason to be weaker than STUN). I could be persuaded that 64-bits is
sufficient, but shorter than 64-bits seems like a really bad idea.)
Section 8.3 should be updated to require clients drop responses if the
transaction ID does not match the transaction ID in the request.
Section 8.3 can still say that clients SHOULD process multiple responses
from the same request.

Secondly, we should document in section 17 that there's a tradeoff in
processing multiple responses.

Something like:

Section 8.3 recommends that clients process multiple responses to a
single request. Doing so permits a server to reflect mapping changes to
clients more quickly. However, it increases the window of opportunity
for an attacker  to send fake responses including incorrect mapping
information. If clients use external addresses in this mapping
information then an attacker may mount a denial-of-service attack
against the client or third parties. Additionally, an attacker may be
able to redirect traffic destined for the client through the attacker.
A security mechanism meeting the advanced threat model (section 17.2)
is a mitigation for this class of attack.

I also note that we don't actually have security considerations text
about the PCP server's confidence in the external address it gives you
especially in the situation where there are multiple PCP servers.  I'm
happy to let that slide as it's complicated and this is late in the
process.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 27 Mar 2012 06:19:37 +0200

I think it would be possible to address the security issues raised in this message AND to maintain the operational model described in section 6 of the PCP specification, by using a randomly-generated nonce value (instead of a transaction ID), and associating that nonce with each client-server-address-protocol-port five-tuple.  So, effectively, each PCP mapping would have a nonce associated with it (on both the client and server sides) that would be used for further communication regarding that mapping.

Margaret

On Mar 27, 2012, at 6:09 AM, Sam Hartman wrote:

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

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 26 Mar 2012 23:26:07 -0700

Hi,

Can you comment how an hacker could mount such attacks in Wireless
networks or Wireline broadband with the minimum set of filters preventing
spoofing, etc? 

If I understand your proposal, and we include a transaction ID/nonce (TID
for short) we need more discussion:

1 - Since the protocol does not differentiate between retransmissions,
renewals and first requests, we need to define when TID will remain the
same or change.

2 - Client and Server will now have to remember the TID not only during
the transaction but for the lifetime of the mapping since the server might
need to send unsolicited responses affecting that mapping at any time and
client needs to validate it.

3 - Which TID should be used by multicast ANNOUNCE messages? Although risk
is low in link-local we need to certainly define the semantics.

4 - Probably need some guidelines on uniqueness in the case of failure,
high-availability, etc

Thanks,

Reinaldo

---

From: <[email-masked]>
Date: Tue, 27 Mar 2012 09:54:59 +0200

Dear Margaret,

Do you have in mind something similar to: http://tools.ietf.org/html/draft-boucadair-pcp-extensions-02#section-6 

   PCP CLIENT_ID (Code TBA, Figure 5) is a token randomly [RFC4086]
   generated by the PCP Client.  Only one CLIENT_ID Option MUST be
   present in a PCP message.  The PCP Client and PCP Server MUST store
   the value included in this Option in a PCP MAP request.

   o  The CLIENT_ID MUST be generated by the PCP Client and not the PCP
      Server;

   o  Upon change of the IP address of the PCP Client (or a third party
      on behalf of which a mapping has been created), the CLIENT_ID is
      used to update related mappings (e.g., PCP MAP delete request and
      PCP MAP create request);

   o  The same CLIENT_ID MUST be used for all requested mappings, unless
      a new CLIENT_ID is generated by the PCP Client (e.g., reboot, OS
      crash, etc.);

   o  The CLIENT_ID is stored by the PCP Server for all mappings
      (persistent storage);

Thanks.

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la 
>part de Margaret Wasserman
>Envoyé : mardi 27 mars 2012 06:20
>À : Sam Hartman
>Cc : [email-masked]; [email-masked]
>Objet : Re: [pcp] draft-ietf-pcp-base: security impacts of 
>section 6 design note
>
>
>I think it would be possible to address the security issues 
>raised in this message AND to maintain the operational model 
>described in section 6 of the PCP specification, by using a 
>randomly-generated nonce value (instead of a transaction ID), 
>and associating that nonce with each 
>client-server-address-protocol-port five-tuple.  So, 
>effectively, each PCP mapping would have a nonce associated 
>with it (on both the client and server sides) that would be 
>used for further communication regarding that mapping.
>
>Margaret
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Mar 2012 04:36:03 -0400

>>>>> "Reinaldo" == Reinaldo Penno <[email-masked]> writes:

    Reinaldo> Hi, Can you comment how an hacker could mount such attacks
    Reinaldo> in Wireless networks or Wireline broadband with the
    Reinaldo> minimum set of filters preventing spoofing, etc?

Well, if you explain the set of filters you're specifically talking
about, I can  better answer that.

On most wireless deployments I'm familiar with, very little prevents one
wireless client from spoofing IP addresses of another.

Also, PCP has to work in a lot of deployments. For example while it
might be easy to mandate ingress filtering behavior when a PCP server is
collocated with a gateway NAT, it seems more difficult when they are
separate boxes.

If you can describe what filters are present in your environment I'll
try to better answer the question.

However, we need a fairly broad solution for the spec because of  the
broad deployment options for PCP.

In terms of specific questions you ask.

If we choose a nonce rather than a transaction ID, we avoid questions
about retransmits vs new requests.

I'd recommend servers either use 0 or a value of their choice for
 announce messages.

Yes, clients and servers would need to remember the nonce. However  only
in cases where they already have state and it would be trivial to attach
this to existing state.

Clients would generate nonces randomly; we have easy citations for
advice on randomness that we can include.  I don't think there are any
high-availability concerns for client-generated nonces.

Thanks for your questions,

--Sam

---

From: <[email-masked]>
Date: Tue, 27 Mar 2012 10:59:10 +0200

Re-,

Please see inline.

Cheers,
Med 

>part de Sam Hartman
>Envoyé : mardi 27 mars 2012 10:36
>À : Reinaldo Penno

Med: Some experimental data can be found here about ip spoofing in wireless networks (Section 4.2.1):
http://research.microsoft.com/en-us/people/mzh/netpiculet.pdf: they were able to perform the IP spoofing test in 60 cellular
networks, among which only 4 allow IP spoofing.

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 27 Mar 2012 02:02:27 -0700

>about, I can  better answer that.

[Reinaldo] Traditional filters used both in Wireless and Wireline such as:

- Anti-spoofing: A CPE/UE/etc can not generate packets with a source
address different then the one allocated to it
- Reverse path forwarding checks.
- Packets coming through Internet facing interfaces can not have the PCP
Server address

>wireless client from spoofing IP addresses of another.

[Reinaldo] A wireless client can certainly spoof, whether it will make it
through the Gateway is another story. Same for broadband. You can spoof a
packet, but in general it will not go through RPF checks.

>collocated with a gateway NAT, it seems more difficult when they are

[Reinaldo] The attack vector I see is when the PCP Server is outside the
administrative domain of the ISP/Content provider or direct-P2P
communication is possible.

>broad deployment options for PCP.

[Reinaldo] Agree, but I'm thinking nonce should be optional for those
deployments that fall into the advance thread model.

>in cases where they already have state and it would be trivial to attach

This is not clear to me:

It is not clear to me clients always need to remember their mappings if
they are happy with the lifetime and are certain they will not need an
extension. The client still needs to listen to unsolicited responses, but
those have everything needed for the client to know what happen to a
mapping it installed before (without having to remember it).

But such a nonce precludes stateless (or lightweight) client because now
unsolicited messages need to be validated on a per transaction (mapping)
basis for the lifetime of the mapping - if I understand your proposal

It is also not clear to me how a PCP Proxy would work

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Mar 2012 05:13:16 -0400

>>>>> "Reinaldo" == Reinaldo Penno <[email-masked]> writes:

Ah, and here we see a terminology clash.
I think 802.11 as wireless.
I agree that  you can prevent one customer from spoofing another.
    >> However, we need a fairly broad solution for the spec because of
    >> the broad deployment options for PCP.

    Reinaldo> [Reinaldo] Agree, but I'm thinking nonce should be
    Reinaldo> optional for those deployments that fall into the advance
    Reinaldo> thread model.

I agree that if you're using a security mechanism then you don't need a
nonce. I'll note though that most security mechanisms will have a
session ID that fills the same role.
It may be much shorter though.

--Sam

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 27 Mar 2012 02:35:51 -0700

I just noticed my sentenced could have two interpretations. What I meant
was:

- Nonce should not required for those deployment where PCP Server and
clients and under one administrative domain. In others words, the current
spec is enough.

- Nonce could be required in those deployments that fall in the advanced
thread model. In this case nonce could be an optional PCP extension.

Thanks,

Reinaldo

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 27 Mar 2012 12:26:07 +0200

Hi Mohamed,

>   the value included in this Option in a PCP MAP request.

I am not talking about this specifically, because the PCP CLIENT_ID value is one-per-client.  I was suggesting a one-per-mapping nonce that would be generated by the client the first time a new mapping is requested, and would be used for all messages related to that specific mapping.  As I said, it would be done on a per <client, server, mapping ip address, protocol, port> 5-tuple.  If a client received a message form the server using a nonce that did not correspond with an existing mapping maintained by the client, it would be ignored. 

If we decide we need this in the protocol, I probably wouldn't put it in an option, personally...  but, once we determine whether or not it is needed, we can talk about how best to include it.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 27 Mar 2012 12:41:45 +0200

Hi Reinaldo,

> clients and under one administrative domain. In others words, the current

How would a client or server detect that it was running in a deployment that prevented IP Address spoofing?

> threat model. In this case nonce could be an optional PCP extension.

I think you may be misunderstanding...

The goal of the _simple threat model_ is to be no less secure than existing deployments that use implicit mappings and STUN.  Sam has explained why he believes that some type of nonce/transaction ID is needed to make PCP (in the simple threat model) as secure as implicit mappings and STUN.  So, the whole point is that a nonce is needed when the PCP authentication mechanism is not used.

The advanced threat model is intended to actually be cryptographically secure, and one could potentially argue that a nonce is not needed when the PCP authentication mechanism is used.

Margaret

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 27 Mar 2012 04:49:54 -0700

>that prevented IP Address spoofing?

Configuration or provisioning. You have different behaviors for trusted
networks vs. untrusted networks. I guess no different than many actions a
user takes when is in, say, a hotspot vs. his(er) home.

>The goal of the _simple threat model_ is to be no less secure than
>existing deployments that use implicit mappings and STUN.  Sam has
>explained why he believes that some type of nonce/transaction ID is
>needed to make PCP (in the simple threat model) as secure as implicit
>mappings and STUN.

I understand the goal to be as secure as STUN, but not why. I mean, what
is the reasoning and use-case behind it?

>  So, the whole point is that a nonce is needed when the PCP
>authentication mechanism is not used.
>
>The advanced threat model is intended to actually be cryptographically
>secure, and one could potentially argue that a nonce is not needed when
>the PCP authentication mechanism is used.

This is what I do not follow. If somebody is really concerned with
security they should use your cryptographically secure proposal (I will
call Secure-PCP). And if they are not, they can run the base spec as is.
But we are saying there are a group of people that are (kind of) worried,
but not to the point to click the 'Secure PCP' button. And therefore for
those users we need a nonce. I would think putting the nonce as a PCP
extension would be appropriate.

Thanks,

Reinaldo

Thanks,

Reinaldo

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Mar 2012 07:53:55 -0400

>>>>> "Reinaldo" == Reinaldo Penno <[email-masked]> writes:

    Reinaldo> I just noticed my sentenced could have two
    Reinaldo> interpretations. What I meant was:

    Reinaldo> - Nonce should not required for those deployment where PCP
    Reinaldo> Server and clients and under one administrative domain. In
    Reinaldo> others words, the current spec is enough.

I'm concerned about attacks where one device in the administrative
domain attacks another.

Section 17.1 talks about cases such as a guest network and a corporate
network both behind the same firewall  but have different security
properties.
So, I'm worried about attackers within the same domain.  I think the
nonce is more important for the simple threat model than the advanced
threat model.

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 27 Mar 2012 05:26:14 -0700

>network both behind the same firewall  but have different security

[reinaldo] I skimmed that section (-24) but did not find this case. But in
my experience although guest networks sit behind the same firewall as
corporate users they are :

- In a separate security 'zone'
- Hosts in the guest 'zone' can not access hosts in the corporate 'zone'
- Probably those two 'zones' would be server by different PCP Servers (or
contexts).

Therefore a guest could not inject a spoofed PCP response. If it could
inject a spoofed packet (in general) then the enterprise has bigger
problems to deal with.

>nonce is more important for the simple threat model than the advanced

Given there are deployments with differing trusts and security levels I
would prefer nonce to be an extension.

Also, I'm still trying to understand the impacts of nonce on stateless PCP
clients and PCP Proxy.

Thanks,

Reinaldo