[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: I-D: Router Advertisement Based Privacy - draft-rafiee-6man-ra-privacy
From: "Hosnieh Rafiee" <ietf () rozanak ! com>
Date: 2013-06-18 17:33:01
Message-ID: 000601ce6c49$e54415e0$afcc41a0$ () rozanak ! com
[Download RAW message or body]
This is a multipart message in MIME format.
[Attachment #2 (multipart/alternative)]
This is a multipart message in MIME format.
I have improved the document and also clearly explained the problems that this \
document addresses in the Introduction section. I also improved the algorithm for IID \
lifetime, which is now a conditional application based lifetime.
<http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-04> \
http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-04
Abstract:
Privacy is an important issue which concerns many governments and
users, with its importance becoming more evident every day. Nodes
change their IP addresses frequently in order to avoid being tracked
by attackers. The act of frequently changing IP addresses also helps
to prevent the leakage of information by nodes. In IPv6 networks
there is currently one solution for maintaining the privacy of nodes
when IPv6 StateLess Address AutoConfiguration (SLAAC) (RFC 4862) is
used. Unfortunately there are some problems associated with this
solution which entails the use of the Privacy Extension (RFC 4941).
One of the issues with this RFC concerns the wording that is used
which allows the implementation to make the choice as to what
approach to use and in so doing, in some cases, the choice made is
not the most prudent or best approach and this is not ideal and can
cause some problems. Some of these problems are concerned with not
generating a new Interface ID (IID) after changing the router prefix.
Another concern would be the fact that nodes may use an IID that was
generated based on a MAC address as a public address, and then use
this in their response. The act of cutting the current connections to
other nodes, if the max lifetime of the old IID has elapsed, is also
not clearly explained nor is whether or not the already used IID
should be kept in stable storage, There is also a concern about the
need to have stable storage available for the generation of a
randomized IID. The RFC gives no explanation as to how to make use of
CGA in its randomizing solution when stable storage is not available
or how to use the same approach for random value generation in all
implementations where there is a lack of stable storage. The purpose
of this document is to address these issues, to update the current
RFC and to introduce a new algorithm for the lifetime of IID.
Please take a look and share your comments.
Thanks,
Regards,
Hosnieh
[Attachment #5 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type \
content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 \
(filtered medium)"><style><!-- /* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div \
class=WordSection1><p class=MsoPlainText>I have improved the document and also \
clearly explained the problems that this document addresses in the Introduction \
section. I also improved the algorithm for IID lifetime, which is now a conditional \
application based lifetime.<o:p></o:p></p><p class=MsoPlainText><a \
href="http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-04"><span \
style='color:windowtext;text-decoration:none'>http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-04</span></a> \
<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><span \
style='color:black'><o:p> </o:p></span></p><p \
class=MsoPlainText>Abstract:<o:p></o:p></p><p class=MsoPlainText> Privacy is an \
important issue which concerns many governments and<o:p></o:p></p><p \
class=MsoPlainText> users, with its importance becoming more evident every day. \
Nodes<o:p></o:p></p><p class=MsoPlainText> change their IP addresses frequently \
in order to avoid being tracked<o:p></o:p></p><p class=MsoPlainText> by \
attackers. The act of frequently changing IP addresses also helps<o:p></o:p></p><p \
class=MsoPlainText> to prevent the leakage of information by nodes. In IPv6 \
networks<o:p></o:p></p><p class=MsoPlainText> there is currently one solution for \
maintaining the privacy of nodes<o:p></o:p></p><p class=MsoPlainText> when IPv6 \
StateLess Address AutoConfiguration (SLAAC) (RFC 4862) is<o:p></o:p></p><p \
class=MsoPlainText> used. Unfortunately there are some problems associated with \
this<o:p></o:p></p><p class=MsoPlainText> solution which entails the use of the \
Privacy Extension (RFC 4941).<o:p></o:p></p><p class=MsoPlainText> One of the \
issues with this RFC concerns the wording that is used<o:p></o:p></p><p \
class=MsoPlainText> which allows the implementation to make the choice as to \
what<o:p></o:p></p><p class=MsoPlainText> approach to use and in so doing, in \
some cases, the choice made is<o:p></o:p></p><p class=MsoPlainText> not the most \
prudent or best approach and this is not ideal and can<o:p></o:p></p><p \
class=MsoPlainText> cause some problems. Some of these problems are concerned \
with not<o:p></o:p></p><p class=MsoPlainText> generating a new Interface ID (IID) \
after changing the router prefix.<o:p></o:p></p><p class=MsoPlainText> Another \
concern would be the fact that nodes may use an IID that was<o:p></o:p></p><p \
class=MsoPlainText> generated based on a MAC address as a public address, and \
then use<o:p></o:p></p><p class=MsoPlainText> this in their response. The act of \
cutting the current connections to<o:p></o:p></p><p class=MsoPlainText> other \
nodes, if the max lifetime of the old IID has elapsed, is also<o:p></o:p></p><p \
class=MsoPlainText> not clearly explained nor is whether or not the already used \
IID<o:p></o:p></p><p class=MsoPlainText> should be kept in stable storage, There \
is also a concern about the<o:p></o:p></p><p class=MsoPlainText> need to have \
stable storage available for the generation of a<o:p></o:p></p><p class=MsoPlainText> \
randomized IID. The RFC gives no explanation as to how to make use \
of<o:p></o:p></p><p class=MsoPlainText> CGA in its randomizing solution when \
stable storage is not available<o:p></o:p></p><p class=MsoPlainText> or how to \
use the same approach for random value generation in all<o:p></o:p></p><p \
class=MsoPlainText> implementations where there is a lack of stable storage. The \
purpose<o:p></o:p></p><p class=MsoPlainText> of this document is to address these \
issues, to update the current<o:p></o:p></p><p class=MsoPlainText> RFC and to \
introduce a new algorithm for the lifetime of IID.<o:p></o:p></p><p \
class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><span \
style='color:black'>Please take a look and share your \
comments.<o:p></o:p></span></p><p class=MsoPlainText><span \
style='color:black'>Thanks,<o:p></o:p></span></p><p class=MsoPlainText><span \
style='color:black'>Regards,<o:p></o:p></span></p><p class=MsoPlainText><span \
style='color:black'>Hosnieh<o:p></o:p></span></p></div></body></html>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic