On Fri, 2004-10-22 at 11:04, Suresh Krishnan wrote:
Can you give me more details or a pointer to such an attack? I will add
add some text and a reference to it.
There's a wealth of information about traffic analysis capabilities in
many books about WW-II-era codebreaking.
As a more modern
Pekka Savola wrote:
On Fri, 22 Oct 2004, Suresh Krishnan wrote:
Hi Pekka/Brian,
This is the text I added to have a per-prefix enable/disable
setting. Hope it resolves your issues.
Additionally, sites might wish to selectively enable or disable the
use of temporary addresses for some
Hi Pekka/Brian,
This is the text I added to have a per-prefix enable/disable
setting. Hope it resolves your issues.
Additionally, sites might wish to selectively enable or disable the
use of temporary addresses for some prefixes. For example, a site
might wish to disable
Hi Bill,
I have added the following text to include packet sizes and timing
Please note that an attacker, who is on path, may be able to perform
significant correlation based on
o The payload contents of the packets on the wire
o The characteristics of the packets such as packet
Hi Ralph,
* The abstract no longer refers to DHCP.
Nodes use IPv6 stateless address autoconfiguration to generate
addresses using a combination of locally available information and
information advertised by routers. Addresses are formed by combining
network prefixes with an
On Fri, 22 Oct 2004, Suresh Krishnan wrote:
Hi Pekka/Brian,
This is the text I added to have a per-prefix enable/disable
setting. Hope it resolves your issues.
Additionally, sites might wish to selectively enable or disable the
use of temporary addresses for some prefixes. For
On Wed, 20 Oct 2004, Ralph Droms wrote:
I disagree with the wording of this section regarding the use of DHCPv6 for
privacy addresses:
I thought you would, it was just a question when ;-)
At 12:03 AM 10/20/2004 -0400, Suresh Krishnan wrote:
* Added the following text specifying the
On Wed, 20 Oct 2004, Suresh Krishnan wrote:
o An attacker who is in the path between the node in question and
the peer(s) it is communicating to, and can view the IPv6
addresses present in the datagrams.
However, note that such on the path
Suggestion at the end...
Pekka Savola wrote:
On Wed, 20 Oct 2004, Suresh Krishnan wrote:
o An attacker who is in the path between the node in question and
the peer(s) it is communicating to, and can view the IPv6
addresses present in the datagrams.
Hi Ralph,
Please see my comments inline.
Thanks
Suresh
On Wed, 20 Oct 2004, Ralph Droms wrote:
I disagree with the wording of this section regarding the use of DHCPv6 for
privacy addresses:
At 12:03 AM 10/20/2004 -0400, Suresh Krishnan wrote:
* Added the following text specifying the
Hi Brian,
That sounds fair to me. I will come up with text with SHOULD language
for per-prefix enabling of privacy addresses. I just have to figure out
how it will interact/override with the global enable/disable option.
Pekka,
If I make this change, would you still like me to add specific
On Thu, 2004-10-21 at 00:49, Pekka Savola wrote:
However, note that an attacker, who is on path, may be able to
perform significant correlation based on the payloads of the packets
on the wire. Use of temporary addresses will not prevent such payload
based correlation
This clearly
On Thu, 21 Oct 2004, Suresh Krishnan wrote:
Hi Brian,
That sounds fair to me. I will come up with text with SHOULD language
for per-prefix enabling of privacy addresses. I just have to figure out
how it will interact/override with the global enable/disable option.
Pekka,
If I make
Hi Bill,
I would also mention packet sizes and timing in addition to payload
content. My understanding is that you can recover a surprising amount
of useful information without even looking at the payloads.
I would agree with you that a an attacker can extrapolate a lot about the
data,
Hi Pekka,
I am proposing the following changes to resolve the issues that you
raised.
* I have made all the changes we both agreed on.
* I have added the following problem statement
Addresses generated using Stateless address autoconfiguration
[ADDRCONF]contain an embedded 64-bit
On Wed, 20 Oct 2004, Suresh Krishnan wrote:
Addresses generated using Stateless address autoconfiguration
[ADDRCONF]contain an embedded 64-bit interface identifier, which
remains constant over time. Anytime a fixed identifier is used in
multiple contexts, it becomes possible to
Pekka Savola wrote:
...
* I hope the problem statement above justifies the use of privacy
addresses for ULAs
I'm not so sure: so, you'd assume that the evil enterprise
administrator would be eavesdropping and correlating enterprise's
internal traffic, or the enterprise's internal web servers
On Wed, 20 Oct 2004, Suresh Krishnan wrote:
Has the protection from your ISPs and federal agencies etc. really
been the requirement/goal from the start?
On-path does not have to be FBI/NSA or ISPs. It can be anyone on an
upstream network (even in the same organization as the user). I would
: 'Pekka Savola'; IPV6 IETF (E-mail)
Subject: RE: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt
Hi,
I am not exactly sure what part of the draft you are referring about,
but without the 2 hour lifetime rule stateless address autoconf is
susceptible to a denial of service attack using fake
Hi,
I am not exactly sure what part of the draft you are referring about,
but without the 2 hour lifetime rule stateless address autoconf is
susceptible to a denial of service attack using fake RAs with low
lifetimes. Can you give me the specifics regarding the text in the draft
which you
Sorry for the delay to respond to your quick response.. long email ;-)
On Wed, 13 Oct 2004, Suresh Krishnan wrote:
On Tue, 12 Oct 2004, Pekka Savola wrote:
FWIW, I think we should make the specification agnostic of the hash
algorithm. Either MD5 and SHA1 or whatever is just fine. There is no
: RE: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt
Hi,
I am not exactly sure what part of the draft you are referring about,
but without the 2 hour lifetime rule stateless address autoconf is
susceptible to a denial of service attack using fake RAs with low
lifetimes. Can you give me
Hi Pekka,
Thanks for the detailed comments. See my responses inline.
Regards
Suresh
On Tue, 12 Oct 2004, Pekka Savola wrote:
FWIW, I think we should make the specification agnostic of the hash
algorithm. Either MD5 and SHA1 or whatever is just fine. There is no
interoperability problem
23 matches
Mail list logo
