Subject: Re: [v6ops] Some questions on draft-rafiee-v6ops-iid-lifetime

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 26 Oct 2013 00:55:04 +0200

Hi Fred,

Actually the content of this draft
(http://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime )  was presented
in IETF 87 as a part of ra-privacy. Some people during that meeting thought
that it is better to make this draft more generate and separate it from
ra-privacy;  http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy  (this
draft also does nothing with security and it address the problems with RFC
4941 and also deprecating EUI-64 in RFC 4941.  The draft "deprecated IID"
that is new and contain most of the section that is already explained in
ra-privacy could improve this existing draft)

So, iid lifetime draft, as you already know, does nothing with security but
it is a way of maintaining privacy and try to avoid sacrificing user's
connectivity in IPv6 networks. This draft, first, compares the current
mechanisms available for the lifetime of an IID and then offer a new
mechanism for the mentioned purpose (privacy and connectivity)

> 
> 1) Please provide a succinct problem statement for your draft. What
> problem/issue is this draft discussing? What operational problems does the
> proposal address in real life networks?

We tried to have a short problem statement at the end of Introduction. But
we are open to suggestions if you or anybody else think that there is  a
need for expanding this section.

> 
> 2) Where does this draft or presentation fits into v6ops' current charter
> (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing specific a
section(s)
> of the charter is preferable.

It might fit to number 4 and the rest of the explanation. Why we think it
can fit? It is because IPv6 addresses are public and at least at the moment
our computer connect to internet using its own unique IP address. I guess
this will open new issues for privacy and security. The reason is the
initial attack on node's security and privacy is to recon the node. So, when
your node has a fix IID, then the attacker has better possibility to attack
this node. 
Now the purpose of this draft is only to give information to the
implementers that they can improve the privacy and security of their
mechanisms. It also provide a way for privacy-aware-applications to use a
same framework which can also control the total number of IID and not
generate the IID themselves. 
This means they do not need to have any information about IP layer while at
the same time they can ensure their users that their application is
privacy-aware

> 3) Who is this draft's audience?

Privacy-aware implementers

> 4) Have any operators expressed interest in this draft or its problem
space,
> either via review or other discussion?

I guess I have already answered this 

> 5) Is this draft pursuing discussion in any other WGs? If so, please list
them
> here, along with rationale for the interaction with multiple WGs in
parallel.

Please check the recordings of ra-privacy (lifetime section) and the mailing
list discussion about ra-privacy after IETF 87

> 6) Is any protocol work being recommended in the draft?

It is actually in informational track that gives the choice for
implementers. I am also in the process of implementing it for Linux. 

Thank you again,
-----------smile----------
Hosnieh
. success is a journey, not a destination..
You cannot change your destination overnight, but you can change your
direction ... Focus on the journey

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 26 Oct 2013 07:37:00 +0000

Thanks.

Question for you. What is the interaction with draft-gont-6man-deprecate-eui64-based-addresses? In conversation with him there, you asked if he would be folding your draft into his and therefore making yours redundant. Does he plan to? If he does, it may be appropriate for you to become a co-author on that paper.

My sense, which could be completely incorrect, is that the exact value of the IID isn't all that interesting to most operators, as once it is in use nobody really cares how it was chosen. Duplicate IIDs in use would be a problem, so DAD is important. The means by which it is assigned is interesting (some operators require SLAAC, some use DHCPv6 but permit SLAAC, some require DHCPv6, and some assign IIDs to their servers or to routers for BGP purposes). Duplicate IIDs in use would be a problem, so DAD is important operationally if SLAAC is in use, and in DSL and Cable networks the behavior of DAD in their transmission systems is "interesting". The number of addresses that are in actual use at a given time (and therefore neighbor slots that are in use) is operationally interesting in that it affects and is affected by table capacity, and can therefore be an attack vector. The bits in the IID and the mechanism by which they are generated is, however, very important to 6man, which defines SLAAC. From that perspective, the paper may be of interest in 6man.

I'm looking, as always, for operational feedback on the list. But that's my initial thought.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 26 Oct 2013 11:34:16 +0200

Hi Fred,
Thanks again.

> 
> Question for you. What is the interaction with draft-gont-6man-deprecate-
> eui64-based-addresses? In conversation with him there, you asked if he
> would be folding your draft into his and therefore making yours redundant.
> Does he plan to? If he does, it may be appropriate for you to become a co-
> author on that paper.

That conversation is nothing to do with  Iid-lifetime draft which  we
submitted to v6ops. It is about ra-privacy which I submitted to 6man. 
Ra-privacy has been active for some months and the content of this new
submitted draft, "deprecate EUI-64", is the same as some sections in
ra-privacy. They wanted to have an informational draft recommending all
operators to use stable addresses.  Since I was improving ra-privacy, there
was a discussion about this and since I had a section about "Not using
EUI-64 in general" in my draft. I said it can be just changing a sentence in
this section to recommend using stable addresses as a public address. I
guessed we agreed on that. But now I see otherwise! 
Since they didn't discuss this with me and just suddenly submit a draft and
used the content of ra-privacy, I just asked them whether they want to merge
this work with their draft. But it appears they ignored my message! 

I thought in IETF you try first to improve the existing drafts and then if
the existing draft does n't address what you plan to do, you would submit a
new draft, but not copy and paste the content and make it new draft.

> My sense, which could be completely incorrect, is that the exact value of
the
> IID isn't all that interesting to most operators, as once it is in use
nobody
> really cares how it was chosen. Duplicate IIDs in use would be a problem,
so
> DAD is important. The means by which it is assigned is interesting (some
> operators require SLAAC, some use DHCPv6 but permit SLAAC, some require
> DHCPv6, and some assign IIDs to their servers or to routers for BGP
> purposes). Duplicate IIDs in use would be a problem, so DAD is important
> operationally if SLAAC is in use, and in DSL and Cable networks the
behavior
> of DAD in their transmission systems is "interesting". The number of
> addresses that are in actual use at a given time (and therefore neighbor
slots
> that are in use) is operationally interesting in that it affects and is
affected by
> table capacity, and can therefore be an attack vector. The bits in the IID
and
> the mechanism by which they are generated is, however, very important to
> 6man, which defines SLAAC. From that perspective, the paper may be of
> interest in 6man.
> 
> I'm looking, as always, for operational feedback on the list. But that's
my
> initial thought.

Iid- Lifetime is not about how you generate IID. It doesn't matter for it.
It only recommends a lifetime for the IID. You can use different approach to
generate your IID but at the same time care about your privacy.

Thanks again,

-----------smile----------
Hosnieh