On Jun 8, 2014, at 20:26 , Joe Touch to...@isi.edu wrote:
a NAT hides the host *at the expense* of exposing a router
If I have the energy to do a DoS attack, surely I have the energy to traceroute
the hosts I know to find a common routing point?
David Singer
Manager, Software
On 09/06/14 14:46, Brandon Williams wrote:
Would you please indicate where the draft proposes a new identifier? If
you are seeing a proposal for protocol changes somewhere in the draft,
editing work is required in order to either clarify or excise the
associated text.
Fair enough that its
On Jun 5, 2014, at 1:10 PM, Joe Touch to...@isi.edu wrote:
On 6/5/2014 5:48 AM, Stephen Farrell wrote:
I share those concerns. And adopting this without any consideration
of BCP188 would fly in the face of a very recent, very thoroughly
discussed, IETF consensus.
That BCP thankfully
Hi Stephen,
On 06/07/2014 09:20 AM, Stephen Farrell wrote:
Adding new identifiers with privacy impact, as proposed here, is
quite different.
It is not the intention of the authors for this to be a solution draft.
The draft is intended to describe address sharing use cases and
deployment
On Jun 9, 2014, at 12:32 PM, Eliot Lear l...@cisco.com wrote:
But does adding a header solve the problem? Not unless it is signed AND I
believe the signature. And then I had better be willing to spend the
processing time to sort out your good customers from your bad customers. I
might do
On 10/06/2014 04:43, Ted Lemon wrote:
On Jun 9, 2014, at 12:32 PM, Eliot Lear l...@cisco.com wrote:
But does adding a header solve the problem? Not unless it is signed AND I
believe the signature. And then I had better be willing to spend the
processing time to sort out your good customers
Just to be clear: that was SMTP. The calculus can be different for
other protocols, depending on their end to end nature. SMTP is very hop
by hop and it is very difficult to secure an entire path with confidence
due to downgrade attack threats. https would be a horse of a different
color.
On
