Subject: Re: [pcp] Resolving contentious issue #1: Epoch

From: Stuart Cheshire <[email-masked]>
Date: Fri, 22 Oct 2010 18:57:28 -0700

> The question is Do we need an Epoch in the PCP packet format?
> 
> The concept of Epoch is inherited from NAT-PMP, where it helps a local NAT to restore state.
> 
> I'd like the proponents and the opponents of Epoch to speak now and make their case.

Some points:

1. Some people may have not realized that I have no intention of Apple *EVER* making a NAT-PMP-to-PCP interworking gateway. My intention is that we make a good PCP design, and then Apple issues software updates to make all of its products support PCP natively. This means that PCP needs to meet the needs of both small and large NATs. We design other IETF protocols like TCP to cover both local and wide-area scenarios, and there's no reason we can't do the same for PCP.

2. One of the basic design principles of the Internet is end-to-end state, with a stateless network carrying packets. When stateless design is not possible, "soft state" is the next best thing, which is state than can be recovered when needed. The worst is "hard state", which is required for operation and unrecoverable if lost. NAT has broken this stateless design principle. However, if we can make it soft state, automatically recoverable when needed, then that's better than hard state.

3. Any design that states that failures can never happen is ignoring one of the basic tenets of Internet design -- failures do happen, and the brilliance of Internet protocols is that they handle these failures and recover. Any time you assert that failures can never happen within some operational model you assume, there are failures outside that model that still happen -- software bugs, hardware failures, the box below yours in the rack catches fire, etc. A good Internet design does not try to deny the existence of failures -- it accepts them and includes recovery mechanisms.

4. An Epoch timer in the packets provides one way for clients to intuit the *possible* loss of soft state and initiate recovery procedures. It may not be the only way. And it doesn't guarantee that state has been lost -- it's just a hint that it may have been. An Epoch timer alone may not be sufficient for networks where multicasting all the clients is not feasible. And it may not be necessary for super-expensive triple-power-supply bug-free fireproof jumbo-NATs, but it *is* necessary to support many low-end NATs, and as such it needs to be in the protocol.

5. Having optional elements in protocols makes testing harder, and often leads to interoperability problems where different implementations chose to implement different optional bits. A good protocol design is often one where everything is either mandatory or prohibited, with nothing optional. (Optional parts are often the visible result of a working group simply failing to come to agreement, and allowing that lack of agreement to live on in the form of poor on-the-wire interoperability is a terrible idea.)

6. All PCP implementations need to implement real-time clocks in order to know when to expire stale mappings, so the requirement to put this real-time clock value into the packet is not an onerous burden on any NAT, from smallest to largest. NATs that never fail never need to reset this real-time clock value back to zero. If any NAT inadvertently causes the real-time clock value to go backwards, then all that happens is clients may unnecessarily initiate recovery procedures. This may be an efficiency concern, but it is not a correctness concern. It should never happen, but if it does happen (hey, software does sometimes have bugs) then as long as it doesn't happen too frequently it's not a problem. (And if it does happen too frequently, then you replace the defective NAT with a better one, just as for any failing network hardware.)

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Oct 2010 10:25:17 +0200

Can you explain how your proposal fulfill the security requirement
for a CGN serving many customers? I'll summarize it by 'another
customer must not be allowed to overwrite my port forwarding
entries'.

Regards

[email-masked]

---

From: Stuart Cheshire <[email-masked]>
Date: Sat, 23 Oct 2010 10:02:37 -0700

> customer must not be allowed to overwrite my port forwarding

If you can explain a specific scenario you are concerned about, in  
which one customer overwrites another customer's mappings, then I'll  
try to comment on whether I believe having an Epoch time in the  
packets has any bearing on that particular scenario.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Oct 2010 20:30:14 +0200

=> I already answered to this question but as it is important:

"imagine I use telnet to remotely connect to a box which is behind
 the NAT embedded in my home gateway (PS: in fact I use ssh which is
 protected against this but I don't believe I am a standard user :-).
 Of course this needs a port forwarding entry, if the attacker can reboot
 the CGN controller and override this port forwarding entry, the next
 time I'll try to connect from the outside to my box I'll give my login
 and password believing I'll send it to my box."

BTW this problem is not from me. You have a weak form of it with
the hold down feature (11.2 of base-00) which requires to not
re-assign an expired or deleted PF during roughly 2*MSL.

Regards

---

From: Stuart Cheshire <[email-masked]>
Date: Sat, 23 Oct 2010 14:33:13 -0700

>  and password believing I'll send it to my box."

Now explain how you propose to solve this problem.

And then explain how having an Epoch time in the packets would affect  
your solution one way or another.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 24 Oct 2010 00:46:03 +0200

In your previous mail you wrote:

   > ...

=> the only way I can propose is to require stable storage on
the PCP server (the control part).
Now you can have another idea, I am not happy with such a requirement (*).

=> with stable storage on the PCP server the Epoch mechanism no longer
makes sense.

Regards

PS (*): there is another very not-technical reason to require
stable storage on the control part of a CGN but as France is at
the forefront of this I prefer to not think about it when I am
not compelled...

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Sat, 23 Oct 2010 22:40:50 -0700

This is a hypothetical situation with a lot of loose ends. How did the
attacker managed to "reboot" the CGN?
The CGN has bigger security vulnerabilities than the one you are talking
about, if an attacker can reboot a server at will.
Similarly, attacker overriding the port forwarding entry requires a lot
of timing events to occur correctly to be able to
hijack your PF entry. It is a weak example, I don't have to be an
insider to crack your telnet password, if you are on the internet
and using telnet, the possibilities of your password cracked can happen
before it reaches the CGN is equally large. 

Senthil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Francis Dupont
Sent: Saturday, October 23, 2010 2:30 PM
To: Stuart Cheshire
Cc: [email-masked]
Subject: Re: [pcp] Resolving contentious issue #1: Epoch

   

"imagine I use telnet to remotely connect to a box which is behind  the
NAT embedded in my home gateway (PS: in fact I use ssh which is
protected against this but I don't believe I am a standard user :-).
 Of course this needs a port forwarding entry, if the attacker can
reboot  the CGN controller and override this port forwarding entry, the
next  time I'll try to connect from the outside to my box I'll give my
login  and password believing I'll send it to my box."

BTW this problem is not from me. You have a weak form of it with the
hold down feature (11.2 of base-00) which requires to not re-assign an
expired or deleted PF during roughly 2*MSL.

Regards

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

---

From: Francis Dupont <[email-masked]>
Date: Sun, 24 Oct 2010 09:34:31 +0200

=> the example is from an earlier message where I tried to find the
worst case. In fact the attacker doesn't need to make the CGN reboot,
he only has to know it was rebooted before me (i.e., proactive vs
reactive attack).

   hijack your PF entry.

=> the only condition is the attacker sends his request before me
(i.e., a simple race).

   It is a weak example, I don't have to be an
   insider to crack your telnet password, if you are on the internet
   and using telnet, the possibilities of your password cracked can happen
   before it reaches the CGN is equally large.

=> you've used windows for a too long time (:-). Be serious, fortunately
a password can be made not so easy to crack.
And it is just an example: do you argue it doesn't matter someone could
easily overwrite your PFs and impersonate you for all your services
usable from the Internet?
   
Regards

---

From: <[email-masked]>
Date: Sun, 24 Oct 2010 17:13:51 +0200

Dear Francis,

The issue you are raising is not related to the Epoch usage. Epoch is meant to provide a hint to the PCP client to audit its mappings (Epoch has a set of limitations as I described in http://www.ietf.org/mail-archive/web/pcp/current/msg00091.html)

As for the security issue you described, I have proposed a solution based on the use of Client-ID to uniquely identify a PCP Client (see http://www.ietf.org/mail-archive/web/pcp/current/msg00055.html). I won't elaborate on this further because this is not in scope of the Epoch discussion.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francis Dupont
Envoyé : samedi 23 octobre 2010 10:25
À : Stuart Cheshire
Cc : [email-masked]
Objet : Re: [pcp] Resolving contentious issue #1: Epoch

Regards

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Francis Dupont <[email-masked]>
Date: Sun, 24 Oct 2010 19:40:31 +0200

The issue you are raising is not related to the Epoch usage.

=> it is indirectly related because if its solution is to require
to put the PCP server state in stable storage then the Epoch mechanism
doesn't make sense, i.e., it solves a problem which no longer exists.

   As for the security issue you described, I have proposed a solution
   based on the use of Client-ID to uniquely identify a PCP Client

=> a Client-ID solves some security issue but not this one (*).

Regards

PS (*): if the PCP server loses its state it loses in particular
the link between client PFs and client IDs. In fact IMHO the client-ID
idea works only with reliable state on the PCP server...