Hi Stephen,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Envoyé : vendredi 6 juin 2014 17:59
À : BOUCADAIR Mohamed IMT/OLN; Ted Lemon
Cc : Brian E Carpenter; ietf-privacy@ietf.org; int-a...@ietf.org
Objet : Re: [Int-area]
On 6/7/2014 6:20 AM, Stephen Farrell wrote:
Yes, source addresses leak information that affects privacy. But
we do not have a practical way to mitigate that. So therefore
BCP188 does not call for doing stupid stuff, nor for new laws of
physics (unlike -04 of the draft we're discussing;-)
Dear all,
I would like to confirm this: As already pointed out by Bruno in
http://www.ietf.org/mail-archive/web/int-area/current/msg03904.html there is
the emergency call use case at ETSI and beside that there are application
proposals within WGs SFC, TCPM, etc. beside other drafts which refer
Re-,
Please see inline.
Cheers,
Med
-Message d'origine-
De : ietf-privacy [mailto:ietf-privacy-boun...@ietf.org] De la part de
Stephen Farrell
Envoyé : samedi 7 juin 2014 15:21
À : Dan Wing
Cc : ietf-privacy@ietf.org; Internet Area; Joe Touch
Objet : Re: [ietf-privacy] [Int-area] NAT
On 11/06/14 15:54, Joe Touch wrote:
On 6/7/2014 6:20 AM, Stephen Farrell wrote:
Yes, source addresses leak information that affects privacy. But
we do not have a practical way to mitigate that. So therefore
BCP188 does not call for doing stupid stuff, nor for new laws of
physics (unlike
@ietf.org; Internet Area; Joe Touch Objet : Re:
[ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Hi Dan,
On 07/06/14 02:38, Dan Wing wrote:
Stephen,
It seems NAPT has become IETF's privacy feature of 2014 because
multiple users are sharing one identifier (IP address and
presumably
On 6/11/2014 8:09 AM, Stephen Farrell wrote:
On 11/06/14 15:54, Joe Touch wrote:
On 6/7/2014 6:20 AM, Stephen Farrell wrote:
Yes, source addresses leak information that affects privacy. But
we do not have a practical way to mitigate that. So therefore
BCP188 does not call for doing
I agree entirely that defining host identification as a problem
indicates that the authors believe a solution is called for. I also
agree that the privacy impact of solution candidates must be discussed,
including making a concerted effort to mitigate the possibility of those
solution
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
On Jun 7, 2014, at 6:20 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote:
NATs have both good and bad properties. The slightly better privacy
is one of the good ones.
Better for the hosts they 'hide'; worse as a common network access point.
Consider an enterprise. There are two things we
Hi Dan,
On 07/06/14 02:38, Dan Wing wrote:
Stephen,
It seems NAPT has become IETF's privacy feature of 2014 because
multiple users are sharing one identifier (IP address and presumably
randomized ports [RFC6056], although many NAPT deployments use
address ranges because of fear of
In many countries service providers are required to track which user behind a
NAT mapped to what IP/port the used. NAT != privacy.
--
Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF
LEMONADE for mobile email! See http://www.standardstrack.com/ietf/lemonade/
On Jun
Hi Ted,
As far as this document is concerned, we are open to address technical
concerns. It will be helpful if these concerns are specific enough and
hopefully in reference to
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05.
Adding a discussion on potential
Re-,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Ted Lemon [mailto:ted.le...@nominum.com]
Envoyé : vendredi 6 juin 2014 12:48
À : BOUCADAIR Mohamed IMT/OLN
Cc : Brian E Carpenter; ietf-privacy@ietf.org; int-a...@ietf.org; Stephen
Farrell
Objet : Re: [Int-area] [ietf-privacy]
Stephen,
On 06/06/2014 00:48, Stephen Farrell wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya,
On 05/06/14 08:05, Hannes Tschofenig wrote:
If you want to review a document with privacy implications then
have a look at the NAT reveal / host identifier work (with
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 includes zero RFC2119 language except the single
word should (not
On 06/06/2014 09:26, Ted Lemon wrote:
On Jun 5, 2014, at 4:28 PM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
I have to call you on that. WG adoption is not approval. It's agreement
to work on a topic. It is not OK to attempt a pocket veto on adoption
because you don't like the
On 6/5/2014 1:28 PM, Brian E Carpenter wrote:
...
As a matter of fact I tend to agree with many of your criticisms
of the draft, and I like the idea (below) of adding what we might
call the misuse cases. That's a discussion the intarea WG could have.
Brian
I'd vote for WG adoption, and
I think Ted answered this but one little bit more...
On 05/06/14 21:28, Brian E Carpenter wrote:
Stephen,
On 06/06/2014 00:48, Stephen Farrell wrote:
Hiya,
On 05/06/14 08:05, Hannes Tschofenig wrote:
If you want to review a document with privacy implications then
have a look at the
-a...@ietf.org
Subject: Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On 6/5/2014 1:28 PM, Brian E Carpenter wrote:
...
As a matter of fact I tend to agree with many of your criticisms of
the draft, and I like the idea (below) of adding what we might call
the misuse cases. That's
On Jun 5, 2014, at 4:28 PM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
I have to call you on that. WG adoption is not approval. It's agreement
to work on a topic. It is not OK to attempt a pocket veto on adoption
because you don't like the existing content.
WG adoption is a pretty
Ted said:
If there are problems with the document, part of the adoption process should
be the identification of those flaws and an agreement to address them. So
bringing up those flaws during the adoption process is crucial to the process.
[BA] I would agree that there should be an agreement
28 matches
Mail list logo
