Subject: ra-privacy: my responses to comments

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 30 Jul 2013 07:12:34 +0200

Hi  All,

Many thanks to  the people who commented on my draft. 

Here are my responses. There was not enough time to respond to all comments
and it was difficult to discern and follow the comments one by one from the
audio tape. I had to listen to the audio repeatedly before I could put the
context of the comment together with the subject of the slide. 

To clarify, I used public addresses because other people on the mailing list
used this term. 

---------------------------------

Response to comments related to Lifetime of the IID:

@Fernando: 

Concerns: we will have thousands of IIDs if we want to generate a new IID
for each application

Answer:

There are some variables to be considered when maintaining the lifetime of
the IID. One  such variable is the maximum number of IIDs. The maximum
number of applications per IID and the maximum lifetime of the IID. If the
IID expires, it will keep its current connections but will not be able to be
used for new connections. If a node starts an application x, then it checks
whether or not any IIDs are available whose lifetime has not yet expired. If
there is/are, then it sorts them based on their lifetime and assign it/them
to the IID with the longest lifetime. 

If there is no IID available and the maximum number of IIDs has been
reached, then increase the maximum number of applications (variable keeps
this amount) for a specific IID with the longest lifetime.

If there is no IID available, but the maximum number of IIDs is NOT reached,
then generate a new IID and assign this application to it. For more
information please refer to the draft.

@Keith Moore: 

Concerns: Some applications can just use a different address for every new
application while other applications cannot, such as peer to peer, because
they would encounter a problem.

Answer: 

I assume that it is dependent on the implementation. This means, for
instance, that we can assume that we would have 1 IID for Internet explorer
and 1 IID for all sessions that were opened by one peer to peer application.
It is possible for me to clarify it in the draft by explaining how to assign
a new application to a new IID , just as I have explained with these two
examples.

@Dave Thaler:

Concerns: Why we did not mention application layer? Is it because we will
have a large number of addresses?

Answer: If you do not have some kind of variable to control the lifetime,
the maximum number of IIDs and the maximum number of application per IID (as
I explained a part of that algorithm to Fernando), then your concern is
valid. But if we consider the use of the algorithm mentioned in the draft.
then It is not valid. There was not enough time to discuss the whole
application layer algorithm in the 6man (as I had to spend 3 to 5 minutes
just explaining it). If you are still  having concerns, please share them
here. 

Concerns: The large numbers of sessions and everyone requiring a separate
neighbor discovery multicast address so this blows your multicast [...] So,
the bottom line is it is not scalable.

Answer: True and not true, This is because it depends on how you set the
maximum number of IIDs. If you set its default value in your network to
something like 5 or 10 or, an in general, a small number, then this will
never happen. I guess this is an issue with network policy as in my draft I
considered setting the default values by use of the option in the router
advertisement which can be set by the admins of each network.

Concerns: This lifetime issue should be in another draft and considered in a
separate document.

Answer: If the others feel this way, then I will do it.  The reason it
appears in this document is becauses because I wanted to address the problem
of cutting the connection when the lifetime of an IID has expired. 

Concerns: Slide 5, we should use large stable storage.

Answer: It is a wording issue. I guess we already discussed this offline.
Instead of "already assigned"
http://tools.ietf.org/html/rfc4941#section-3.2.1 step 4, we need to clarify
it as defined here

http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-04#section-4

@ I could not understand the name  :(  :  In this proposal the number of
addresses in a host increase dramatically. So I feel that if we are
specifying that kind of mechanism, the we should also specify what happens
if the network cannot  accommodate them. If you have so many addresses, in
some cases you won't have connectivity. There are too many addresses to be
able to protect the neighbor discovery cache.

Answer: I would improve the document and try to address this as well.
However, I do not presume that this will happen, based on the responses I
received from the other people here. 

--------------------------------------------------

The term public addresses:

@Keith Moore: 

Concerns: All IPv6 addresses are public addresses and should be available.
Not chosen a good term.

I just obtained that term from from the mailing list. Check this old list :
http://www.ietf.org/mail-archive/web/ipv6/current/msg17792.html 

A public address is one intended to be resolvable from higher-layer IDs such
as DNS names.
If this is wrong or I misunderstood the meaning , then I will change it to
"DNS addresses" or another term.  
What I knew before:
Global addresses = Router prefix + IID
Local Addresses = local prefix + IID
What I understood:
Public addresses = router prefix + IID  and has  DNS records (like a domain)
 
------------------------------------------
Security and Network Policy

@ I could not understand the name  :(   : Question about this section of
slide "if a user visit a website and harms by a cookie then we need to
change the IID". Do you think this is security mechanism to do this? I do
not consider to have a policy for the network.

Answer: I meant http cookies or server side cookies. Because client side
cookies can be harmful if there is a script from a website that might access
the other cookies in your computer.  This was just one reason to change the
IID addresses within and outside of the network. There is nothing mentioned
about this directly in the draft. I probably didn't express this idea
correctly so you had a misconception of what I was trying to say.  

If there are any more issues that I need to concern please leave your
comment here.

Thank you,

Best,

Hosnieh

---

From: [email-masked]
Date: Tue, 30 Jul 2013 16:20:38 +0800

Hi, Rafiee,
    I don't think using CGA by replacing the public key with a timestamp 
or other random string is a "higher randomzation" address generation 
method.
Hash is only one technique of generating a random like string, may not be 
the best one among those specified in RFC4086.

[email-masked] 写于 2013-07-30 13:12:34:

> Here are my responses. There was not enough time to respond to all 
> comments and it was difficult to discern and follow the comments one
> by one from the audio tape. I had to listen to the audio repeatedly 
> before I could put the context of the comment together with the 
> subject of the slide. 
> 
> To clarify, I used public addresses because other people on the 
> mailing list used this term. 
> Concerns: we will have thousands of IIDs if we want to generate a 
> new IID for each application
> 
> Answer:
> There are some variables to be considered when maintaining the 
> lifetime of the IID. One  such variable is the maximum number of 
> IIDs. The maximum number of applications per IID and the maximum 
> lifetime of the IID. If the IID expires, it will keep its current 
> connections but will not be able to be used for new connections. If 
> a node starts an application x, then it checks whether or not any 
> IIDs are available whose lifetime has not yet expired. If there 
> is/are, then it sorts them based on their lifetime and assign 
> it/them to the IID with the longest lifetime. 
> reached, then increase the maximum number of applications (variable 
> keeps this amount) for a specific IID with the longest lifetime.
> If there is no IID available, but the maximum number of IIDs is NOT 
> reached, then generate a new IID and assign this application to it. 
> For more information please refer to the draft.
> 
> @Keith Moore: 
> Concerns: Some applications can just use a different address for 
> every new application while other applications cannot, such as peer 
> to peer, because they would encounter a problem.
> 
> Answer: 
> instance, that we can assume that we would have 1 IID for Internet 
> explorer and 1 IID for all sessions that were opened by one peer to 
> peer application. It is possible for me to clarify it in the draft 
> by explaining how to assign a new application to a new IID , just as
> I have explained with these two examples.
> 
> @Dave Thaler:
> Concerns: Why we did not mention application layer? Is it because we
> will have a large number of addresses?
> 
> Answer: If you do not have some kind of variable to control the 
> lifetime, the maximum number of IIDs and the maximum number of 
> application per IID (as I explained a part of that algorithm to 
> Fernando), then your concern is valid. But if we consider the use of
> the algorithm mentioned in the draft. then It is not valid. There 
> was not enough time to discuss the whole application layer algorithm
> in the 6man (as I had to spend 3 to 5 minutes just explaining it). 
> If you are still  having concerns, please share them here. 
> 
> Concerns: The large numbers of sessions and everyone requiring a 
> separate neighbor discovery multicast address so this blows your 
> multicast [...] So, the bottom line is it is not scalable.
> 
> Answer: True and not true, This is because it depends on how you set
> the maximum number of IIDs. If you set its default value in your 
> network to something like 5 or 10 or, an in general, a small number,
> then this will never happen. I guess this is an issue with network 
> policy as in my draft I considered setting the default values by use
> of the option in the router advertisement which can be set by the 
> admins of each network.
> 
> Concerns: This lifetime issue should be in another draft and 
> considered in a separate document.
> 
> Answer: If the others feel this way, then I will do it.  The reason 
> it appears in this document is becauses because I wanted to address 
> the problem of cutting the connection when the lifetime of an IID 
> has expired. 
> 
> Answer: It is a wording issue. I guess we already discussed this 
> offline. Instead of “already assigned” http://tools.ietf.
> org/html/rfc4941#section-3.2.1 step 4, we need to clarify it as defined 
here
> @ I could not understand the name  :(  :  In this proposal the 
> number of addresses in a host increase dramatically. So I feel that 
> if we are specifying that kind of mechanism, the we should also 
> specify what happens if the network cannot  accommodate them. If you
> have so many addresses, in some cases you won’t have connectivity. 
> There are too many addresses to be able to protect the neighbor 
> discovery cache.
> 
> Answer: I would improve the document and try to address this as 
> well. However, I do not presume that this will happen, based on the 
> responses I received from the other people here. 
> 
> Concerns: All IPv6 addresses are public addresses and should be 
> available. Not chosen a good term.
> 
> A public address is one intended to be resolvable from higher-layer 
> IDs such as DNS names.
> If this is wrong or I misunderstood the meaning , then I will change
> it to “DNS addresses” or another term. 
> What I knew before:
> @ I could not understand the name  :(   : Question about this 
> section of slide “if a user visit a website and harms by a cookie 
> then we need to change the IID”. Do you think this is security 
> mechanism to do this? I do not consider to have a policy for the 
network.
> 
> Answer: I meant http cookies or server side cookies. Because client 
> side cookies can be harmful if there is a script from a website that
> might access the other cookies in your computer.  This was just one 
> reason to change the IID addresses within and outside of the 
> network. There is nothing mentioned about this directly in the 
> draft. I probably didn't express this idea correctly so you had a 
> misconception of what I was trying to say. 
> 
> 
> If there are any more issues that I need to concern please leave 
> your comment here.
> 
> Thank you,
> Best,
> Hosnieh
> 
>  --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 30 Jul 2013 10:33:01 +0200

Hi Zhou,

Thanks for the comment.

>    I don't think using CGA by replacing the public key with a timestamp or
other random string is a "higher randomzation" address generation method. 

I think it is misconception. One problem that I tried to address in my draft
(as a update to RFC 4941) is that the RFC might use RFC 4086 (no forcing to
use it). This means there might be no good randomization. In one section
then the RFC discussed about DHCPv6 and CGA. I only explained how to use CGA
if the security is not a concern by having a highly randomized approach. I
compared my approach with the approach already exist in the document and
assume the case where there is no force to use RFC 4086. 

Thanks,
Regards,
Hosnieh