- Original Message -
From: Fernando Gont fg...@si6networks.com
To: Alissa Cooper acoo...@cdt.org
Cc: 6man-cha...@tools.ietf.org; Brian Haberman
br...@innovationslab.net; 6...@ietf.org; Dave Thaler
dtha...@microsoft.com; Ray Hunter v6...@globis.net; Fernando
Gont ferna...@gont.com.ar;
Hi Fernando,
At 13:02 06-06-2013, Fernando Gont wrote:
I'd personally prefer this not to be in the body of the document. For
the most part, because I think that we might benefit of a separate
document that does an analysis of all IID generation techniques, rather
than only this one (I had
I'll try to re-state one of my questions more simply, based on the -09:
How is the attack explained in C.4 mitigated by the mechanism specified in
draft-ietf-6man-stable-privacy-addresses-09?
One more comment below:
On May 31, 2013, at 8:23 PM, Fernando Gont ferna...@gont.com.ar wrote:
Hi Fernando,
On Jun 5, 2013, at 9:19 PM, Fernando Gont fg...@si6networks.com wrote:
On 06/06/2013 12:24 AM, Alissa Cooper wrote:
I'll try to re-state one of my questions more simply, based on the
-09:
How is the attack explained in C.4 mitigated by the mechanism
specified in
On 06/06/2013 03:40 PM, Alissa Cooper wrote:
For instance, Section B.1 explicitly says so (and this type of
attack is not meant to be solved by stable-privacy-addresses).
In some scenarios, it can be mitigated with RFC 4941. Hoawever, as
noted in Section C.4, even ith RFC4941 there are
On 06/06/2013 12:24 AM, Alissa Cooper wrote:
I'll try to re-state one of my questions more simply, based on the
-09:
How is the attack explained in C.4 mitigated by the mechanism
specified in draft-ietf-6man-stable-privacy-addresses-09?
It doesn't. For instance, Section B.1 explicitly says
On 05/30/2013 06:09 PM, Dave Thaler wrote:
Isn't it enough simply noting that the target node can be probed?
Getting into the specific details of the probe packet
(stimulus/response) seems like over-specifying things to me...
My opinion is that this example is important, since the example is
On 05/24/2013 03:22 PM, Tim Chown wrote:
I've tweaked the text a bit in the hopes that readers don't get the
impression that I'm arguing against use of RFC4941. (Most likely,
by the time you read this I'll have posted version -08... so please
check that one... and if there's still room for
On 05/28/2013 11:07 PM, Alissa Cooper wrote:
The second group of three are for nodes that only use temporary
addresses (but that also configure a stable address that never
gets used). This is what would be expected by users that want to
avoid correlation attacks, assuming their admins allow
On 05/29/2013 04:03 AM, Dave Thaler wrote:
[...] I could rely on the
ICMPv6 address resolution failed error messages sent by your local
router (i.e., if I receive one of such messages, you're not there. If I
don't,
you are).
Ok, yes that one is interesting.
An attacker just needs one
On 28 May 2013, at 22:07, Alissa Cooper acoo...@cdt.org wrote:
On May 26, 2013, at 9:01 AM, Fernando Gont fg...@si6networks.com wrote:
How about including something along these lines (*) in an Appendix?
(*) Discussion of possible attacks, and what stable privacy addresses do
about them
On 05/29/2013 04:00 AM, Dave Thaler wrote:
What does draft-ietf-6man-stable-privacy-addresses has to do with CGAs?
1) Both give random-per-network addresses, using Alissa's terminology.
CGA's doesn't seem to aim at stable-per-network addresses. For instance,
the modifier is expected to be
Hi Fernando,
Comments inline.
On May 26, 2013, at 9:01 AM, Fernando Gont fg...@si6networks.com wrote:
HI Alissa,
Thanks for posting this. Please find my comments inline...
On 05/24/2013 11:33 PM, Alissa Cooper wrote:
The rows of the table are the address generation methods that have
-ietf-6man-stable-privacy-addresses-07
Dave,
What does draft-ietf-6man-stable-privacy-addresses has to do with CGAs?
1) Both give random-per-network addresses, using Alissa's terminology.
2) Both generate an IP address using a secret + a network prefix + a DAD
counter + other information.
So
[...] I could rely on the
ICMPv6 address resolution failed error messages sent by your local
router (i.e., if I receive one of such messages, you're not there. If I
don't,
you are).
Ok, yes that one is interesting.
An attacker just needs one vector to be successful.
Agree.
Dave,
What does draft-ietf-6man-stable-privacy-addresses has to do with CGAs?
Has MS or Ericsson patented the use of PRFs?
Have you guys any IPR on RFC1948? -- Because
draft-ietf-6man-stableprivacy-addresses is essentially Bellovin's
RFC1948 applied to IPv6 addresses.
Thanks,
Fernando
On
On 05/25/2013 12:29 AM, Dave Thaler wrote:
[...]
The fact that you use a firewall is mostly irrelevant. I'd bet your firewall
still
reponds to some packets (e.g., packets with unsupported options?).
[..]
No, the Windows firewall doesn't allow any ICMP responses to unsolicited
traffic,
This discussion got me thinking about how to be rigorous in articulating the
specific threats that different kinds of addresses do and do not mitigate. I
put together a little table to try to sum this up:
http://www.alissacooper.com/files/IPv6-address-threats.pdf
The table assumes, for
I made updates in response to this email and Dave's emails and made the table
publicly viewable and editable if folks want to make further changes
themselves:
https://docs.google.com/spreadsheet/ccc?key=0Au4OS7RZgZwHdHozNzNHdUNtVEJSNlo3N3NFMG5Wa1Eusp=sharing
On May 24, 2013, at 6:28 PM, Brian
On 05/22/2013 03:34 AM, Dave Thaler wrote:
I attend an IETF meeting, and learn the IID of your laptop. Then I can
actively
probe your node regarding Is David at the office? Is David at home?,
etc simply because your IID is known and constant.
Since you're making this personal... please
On 24 May 2013, at 10:31, Fernando Gont fg...@si6networks.com wrote:
On 05/22/2013 03:34 AM, Dave Thaler wrote:
I attend an IETF meeting, and learn the IID of your laptop. Then I can
actively
probe your node regarding Is David at the office? Is David at home?,
etc simply because your
Hi,
In-line...
On 24 May 2013, at 02:00, Fernando Gont fg...@si6networks.com wrote:
Hi, Tim,
Thanks so much for your feedback! -- Please find my comments in-line...
On 05/22/2013 10:19 AM, Tim Chown wrote:
Overall, I think this is good work and should be progressed.
Thanks!
Huitema; He Xuan
Subject: Re: Comments on draft-ietf-6man-stable-privacy-addresses-07
This discussion got me thinking about how to be rigorous in articulating the
specific threats that different kinds of addresses do and do not mitigate. I
put
together a little table to try to sum this up
Haberman; 6...@ietf.org; Ray Hunter;
tom.petch; Christian Huitema; He Xuan
Subject: RE: Comments on draft-ietf-6man-stable-privacy-addresses-07
Thanks Alissa for the nice table, this is very helpful.
-Original Message-
From: Alissa Cooper [mailto:acoo...@cdt.org]
Sent: Friday, May 24
; Christian Huitema; He Xuan
Subject: Re: Comments on draft-ietf-6man-stable-privacy-addresses-07
This discussion got me thinking about how to be rigorous in
articulating the specific threats that different kinds of addresses do
and do not mitigate. I put together a little table to try
On 25/05/2013 10:04, Dave Thaler wrote:
Thanks Alissa for the nice table, this is very helpful.
Agreed. Two points though:
1. It seems to me that location tracking to the level of the 64-bit
prefix is *always* possible, which may well identify a specific
customer and/or physical location, but
: 6man-cha...@tools.ietf.org; Brian Haberman; 6...@ietf.org; Ray Hunter;
tom.petch; Christian Huitema; He Xuan
Subject: RE: Comments on draft-ietf-6man-stable-privacy-addresses-07
I'd also like to see CGAs (3972) added to this analysis. It seems to me
they're
the existing standards-track
Hi, Tim,
Thanks so much for your feedback! -- Please find my comments in-line...
On 05/22/2013 10:19 AM, Tim Chown wrote:
Overall, I think this is good work and should be progressed.
Thanks!
First, some general comments:
You may wish to be clearer earlier in the document (abstract
Hi Fernando,
I've read -07 and have some comments. Apologies if they are duplicates of
previous comments.
Overall, I think this is good work and should be progressed.
First, some general comments:
You may wish to be clearer earlier in the document (abstract and/or
introduction) that your
-ietf-6man-stable-privacy-addresses-07
Hi, Dave,
This issue was debated more than a year ago, at the IETF Paris timeframe.
Since then, the wg adopted this document, and we went through WGLC and
IETF LC. So I'm not sure how it helps to raise this point again and at this
point
in time
On 05/21/2013 10:34 PM, Dave Thaler wrote:
This issue was debated more than a year ago, at the IETF Paris timeframe.
Since then, the wg adopted this document, and we went through WGLC and
IETF LC. So I'm not sure how it helps to raise this point again and at this
point
in time.
The
Hi, Dave,
This issue was debated more than a year ago, at the IETF Paris
timeframe. Since then, the wg adopted this document, and we went through
WGLC and IETF LC. So I'm not sure how it helps to raise this point again
and at this point in time.
That said, please let me try to clarify a few
32 matches
Mail list logo
