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 planned
- Original Message -
From: "Fernando Gont"
To: "Alissa Cooper"
Cc: <6man-cha...@tools.ietf.org>; "Brian Haberman"
; <6...@ietf.org>; "Dave Thaler"
; "Ray Hunter" ; "Fernando
Gont" ; "tom.petch" ;
"Christian Huitema" ; "He Xuan"
Sent: Thursday, June 06, 2013 9:02 PM
On 06/06/2013 03:40 PM
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
Hi Fernando,
On Jun 5, 2013, at 9:19 PM, Fernando Gont 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 draft-ietf-6man-stable-p
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 wrote:
>> Another point for clarifi
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 s
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 adm
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 ro
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 e
ject: Re: Comments on draft-ietf-6man-stable-privacy-addresses-07
>
> 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 ro
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.
>>
>> A
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 t
On 28 May 2013, at 22:07, Alissa Cooper wrote:
>
> On May 26, 2013, at 9:01 AM, Fernando Gont wrote:
>
>> How about including something along these lines (*) in an Appendix?
>>
>> (*) Discussion of possible attacks, and what stable privacy addresses do
>> about them (analyzing this for every p
> >> [...] 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 succes
ject: Re: Comments on draft-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 se
Hi Fernando,
Comments inline.
On May 26, 2013, at 9:01 AM, Fernando Gont 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
>> been discus
At 15:43 24-05-2013, Dave Thaler wrote:
It also now occurs to me that since RFC 3972 has IPR disclosures from both
Microsoft and Ericsson, those disclosures may or may not apply to
draft-ietf-6man-stable-privacy-addresses as well.
Per the Note Well, I'm at least sending this email, but will chec
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
> been discussed. The first three are for nodes that only use stable
> addresses and never use temporary addre
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
>
On 05/25/2013 12:19 AM, Dave Thaler wrote:
> I'd also like to see CGAs (3972) added to this analysis. It seems to me
> they're
> the existing standards-track "random-per-network" addresses. So all of the
> "random-per-network" statements would seem apply equally to the existing RFC.
>
> This dr
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 05
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=0Au4OS7RZgZwHdHozNzNHdUNtVEJSNlo3N3NFMG5Wa1E&usp=sharing
On May 24, 2013, at 6:28 PM, Brian
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 simplici
Cooper; Fernando Gont
> Cc: 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
[...]
> 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,
they're all dropped. This is what is sometimes
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 n
4 PM
> > To: Fernando Gont
> > Cc: Dave Thaler; 6...@ietf.org; 6man-cha...@tools.ietf.org; Brian
> > Haberman; Ray Hunter; tom.petch; Christian Huitema; He Xuan
> > Subject: Re: Comments on draft-ietf-6man-stable-privacy-addresses-07
> >
> > This discussion got me thinki
ls.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
Thanks Alissa for the nice table, this is very helpful.
> -Original Message-
> From: Alissa Cooper [mailto:acoo...@cdt.or
Hunter; tom.petch; 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
> t
Hi,
In-line...
On 24 May 2013, at 02:00, Fernando Gont 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!
>
>> First, some
On 24 May 2013, at 10:31, Fernando Gont 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 IID is
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 perso
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 meth
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.
>
ject: Re: Comments on draft-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 rais
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 thing
Disclaimer: haven't read all the prior list discussion so don't know if this
duplicates some existing discussion.
I have some fundamental problems with this document as is.
I will concentrate on sections 1, 2, and Appendix B, being the
motivation/goals/justification,
as opposed to the technical
38 matches
Mail list logo
