[Ballot discuss]I'm sure I am behind the times and just not finding this, but I am not finding the interoperability report needed to ...

[Ballot discuss]I'm sure I am behind the times and just not finding this, but I am not finding the interoperability report needed to advance this.

2006-10-09

05

Cullen Jennings

[Ballot comment]Authors sent me the following explanation of the algorithm which I found much easier to follow. You might want to consider adding something ...

[Ballot comment]Authors sent me the following explanation of the algorithm which I found much easier to follow. You might want to consider adding something like this in the early part of the security section.

It is not easy to predict the next address which will be used because the history value is not externally visible.

First the node generates a 128 bit MD5 hash, say RES, using a random initial value.

Let's assume a function FIRSTx(foo) which returns the first x bits of foo and LASTx(foo) which returns the last x bits of foo.

The algorithm described in the document uses FIRST64(RES) as the interface identifier(setting bit 6 to 0) and stores LAST64(RES) as the history value for the next iteration. Since LAST64(RES) is not cryptographically related to FIRST64(RES), it will not be possible to guess HASH(LAST64(RES)) knowing just FIRST64(RES).

State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::External Party by Jari Arkko

2006-08-15

05

Jari Arkko

I reviewed the changes in a pre-version of draft -05. They looked good, but there was one editorial suggestion and one question. Expecting the authors ...

I reviewed the changes in a pre-version of draft -05. They looked good, but there was one editorial suggestion and one question. Expecting the authors to fix/respond and resubmit. All discusses have been addressed as far as I can see, including Cullen's.

2006-08-08

05

Ted Hardie

[Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie

2006-07-30

05

Jari Arkko

Implementation report for Linux (vs. Windows and FreeBSD) has been received and has been sent to the secretariat.

[Ballot discuss]Section 3.2.1 says: > > MD5 was chosen for convenience, and because its particular properties > were adequate ...

[Ballot discuss]Section 3.2.1 says: > > MD5 was chosen for convenience, and because its particular properties > were adequate to produce the desired level of randomization. IPv6 > nodes are already required to implement MD5 as part of IPsec [IPSEC], > thus the code will already be present on IPv6 machines. > I see no requirement for MD5 in IPsec. I have agreed to the following text on 11-July-2006 as a solution to this concern: > > MD5 was chosen for convenience, and because its particular properties > were adequate to produce the desired level of randomization. The node > MAY use another algorithm instead of MD5 to produce the random > interface identifier.

2006-06-05

05

Jari Arkko

5/6/06: Pinged chairs about the status.

2006-05-31

05

Magnus Westerlund

[Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund by Magnus Westerlund

2006-05-31

05

Dan Romascanu

[Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu

2006-05-27

05

Cullen Jennings

[Ballot discuss]Ok - I am going to enter a discuss here where I am 99% sure the answer is going to be Cullen you are ...

[Ballot discuss]Ok - I am going to enter a discuss here where I am 99% sure the answer is going to be Cullen you are totally confused, go read the document but if that is the case it will be easy to clear.

In section 3, point #3, we have as a requirement that if an attacker knows the current address, it is not easy to predict a future address. I agree this is the fundamental requirement. However I'm not sure I see how the history algorithm in section 3.2.1 does this. It seems that if you use address X, then X gets stored in the history. The next address will used will be MD5(X). It seems the attacker can predict this. Now I am sure that I must just be confused on what is happening here so straighten me out.

The storage algorithm never seems to add any new randomness in and the initially randomness has high odds of being really crappy because the entropy available to many devices the first time they boot is really low and often has bad problems based on implementers making very bad assumptions about what is random in systems that are basically highly deterministic by nature.

I'm sure I am behind the times and just not finding this, but I am not finding the interoperability report needed to advance this.

2006-05-27

05

Cullen Jennings

[Ballot discuss]Ok - I am going to enter a discuss here where I am 99% sure the answer is going to be Cullen you are ...

[Ballot discuss]Ok - I am going to enter a discuss here where I am 99% sure the answer is going to be Cullen you are totally confused, go read the document but if that is the case it will be easy to clear.

In section 3, point #3, we have as a requirement that if an attacker knows the current address, it is not easy to predict a future address. I agree this is the fundamental requirement. However I'm not sure I see how the history algorithm in section 3.2.1 does this. It seems that if you use address X, then X gets stored in the history. The next address will used will be MD5(X). It seems the attacker can predict this. Now I am sure that I must just be confused on what is happening here so straighten me out.

The storage algorithm never seems to add any new randomness in and the initially randomness has high odds of being really crappy because the entropy available to many devices the first time they boot is really low and often has bad problems based on implementers making very bad assumptions about what is random in systems that are basically highly deterministic by nature.

I'm sure I am behind the times and just not finding this, but I am not finding the interoperability report needed to advance this.

2006-05-27

05

Cullen Jennings

[Ballot Position Update] Position for Cullen Jennings has been changed to Discuss from Undefined by Cullen Jennings

2006-05-25

05

Cullen Jennings

[Ballot Position Update] New position, Undefined, has been recorded for Cullen Jennings by Cullen Jennings

2006-03-25

05

Margaret Cullen

Shepherding AD has been changed to Jari Arkko from Margaret Wasserman

2006-03-09

05

Margaret Cullen

State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Margaret Wasserman

State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza

2005-12-15

05

(System)

[Ballot Position Update] New position, yes, has been recorded for Allison Mankin by IESG Secretary

2005-12-15

05

Alex Zinin

[Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin

2005-12-15

05

Ted Hardie

[Ballot discuss]Update: The KAME and Windows implementation reports do not appear to cover quite the same ground. There is at least one ...

[Ballot discuss]Update: The KAME and Windows implementation reports do not appear to cover quite the same ground. There is at least one section (3.2) for which implementation is not in both.

In general, I think we need an interoperability report bundling these implementation reports, so that we have someone saying that the two implementations interoperate and how that interoperability was determined.

old:As Scott points out in his comments, this report only has a single implementation report, Dave Thaler's from Microsoft. I think we need two for the implementation report to be sufficient for DS.

2005-12-15

05

Brian Carpenter

[Ballot comment]Fully agree with Scott and Ted that we lack a sufficient interop report. It seems that the KAME FreeBSD report was not posted ...

[Ballot comment]Fully agree with Scott and Ted that we lack a sufficient interop report. It seems that the KAME FreeBSD report was not posted. Its core:

B. DAD Operation (Section 3.3) Verified the creation of a temporary address (which is to be unique on the link) and the performance of DAD on that address without disrupting other implementations. This was tested with various implementations from different origins including Linux and Solaris 10.

2005-12-15

05

Mark Townsley

[Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley

2005-12-15

05

Bert Wijnen

[Ballot discuss]- I agree with other IESG members, that the single implementation report is not sufficient to show INTEROPERABILITY between multiple (at least 2 ...

[Ballot discuss]- I agree with other IESG members, that the single implementation report is not sufficient to show INTEROPERABILITY between multiple (at least 2) genetically independent implementations

- I think it should be made clear that this doc obsoletes RFC3041

- I see that several "additions" were made (section 7) on top of what is in RFC3041. So does that allow to advance to DS, or would it be better to recycle at PS. Specifically since we only see a report of a single implementation.

2005-12-15

05

Bert Wijnen

[Ballot Position Update] New position, Discuss, has been recorded for Bert Wijnen by Bert Wijnen

2005-12-15

05

Jon Peterson

[Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson

2005-12-15

05

Brian Carpenter

[Ballot comment]Fully agree with Scott and Ted that we lack a sufficient interop report.

2005-12-15

05

Brian Carpenter

[Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter

2005-12-15

05

Bill Fenner

[Ballot comment]Don't forget to put the "Obsoletes RFC 3041" metadata in the note to the RFC Editor.

[Ballot discuss]Section 6 ends with a mini "Open Issues" section that wasn't in RFC 3041. I don't think a Draft Standard should have new open issues.

2005-12-15

05

Bill Fenner

[Ballot Position Update] New position, Discuss, has been recorded for Bill Fenner by Bill Fenner

2005-12-14

05

Ted Hardie

[Ballot discuss]As Scott points out in his comments, this report only has a single implementation report, Dave Thaler's from Microsoft. I think ...

[Ballot discuss]As Scott points out in his comments, this report only has a single implementation report, Dave Thaler's from Microsoft. I think we need two for the implementation report to be sufficient for DS.

2005-12-14

05

Ted Hardie

[Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie

[Ballot discuss]Section 3.2.1 says: > > MD5 was chosen for convenience, and because its particular properties > were adequate ...

[Ballot discuss]Section 3.2.1 says: > > MD5 was chosen for convenience, and because its particular properties > were adequate to produce the desired level of randomization. IPv6 > nodes are already required to implement MD5 as part of IPsec [IPSEC], > thus the code will already be present on IPv6 machines. > I see no requirement for MD5 in RFC 2401. I do not see one in the soon-to-be-published 2401bis either. I also looked in draft-ietf-ipsec-esp-ah-algorithms-02, and all MD5-related algorithms are MAY implement. I do not see a problem with MD5 in this case, but I think this rationale is incorrect today. It may have been correct when RFC 3041 was published.

2005-12-13

05

Russ Housley

[Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley

2005-12-13

05

Sam Hartman

[Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman

Oh, okay... I viewed the Problem Statement and the Background both as parts of the problem statement. Maybe if you just switched the order of 1.1 and 1.2 (so the RFC 2119 language comes first), that would be better. Or, just ignore this issue, as it is purely editorial.

>> 3. Protocol Description>>>> The goal of this section is to define procedures that:>>>> 1. Do not result in any changes to the basic behavior of addresses>> generated via stateless address autoconfiguration [ADDRCONF].>> 2. Create additional global scope addresses based on a random>> interface identifier for use with global scope addresses.>>>>>> What is meant by "for use with global addresses"? is this intended>> to be a restriction on how/when privacy addresses can be used?>>This is not an intended restriction. I can reword it to read>>"2. Create additional addresses based on a random interface identifier for> the purpose of initiating outgoing sessions">>instead of>>"2. Create additional global scope addresses based on a random> interface identifier for use with global scope addresses.Such> addresses would be used to initiate outgoing sessions.">>Does that sound OK?

Yes, that is better.

>> 3.1 Assumptions>>>> The following algorithm assumes that each interface maintains an>> associated randomized interface identifier. When temporary addresses>> are generated, the current value of the associated randomized>> interface identifier is used. The actual value of the identifier>> changes over time as described below, but the same identifier can be>> used to generate more than one temporary address.>>>> The algorithm also assumes that for a given temporary address, an>> implementation can determine the prefix from which it was generated.>> When a temporary address is deprecated, a new temporary address is>> generated. The specific valid and preferred lifetimes for the new>> address are dependent on the corresponding lifetime values set for>> the prefix from which it was generated.>>>>>> These two paragraphs are confusing to me. The node maintains a>> random IID from which multiple addresses can be generated of the>> form <prefix, IID>, right? These addresses will become deprecated>> when their lifetime expires, and new addresses will be generated.>> The implementation keeps track of what prefix was used to generate>> the addres and generates a new address for that prefix, right?>> Does it also need to generate a new random IID when this happens?>> In other words, is there anything in this mechanism that prevents>> generating the same privacy address again on the same interface>> using the same prefix and the same random IID (if it hasn't expired>> yet)?>>The mechanism certainly allows this behavior but it kind of defeats the purpose(to not have a stable interface identifier). The requirement to change the random interface identifier is a SHOULD and is described in section 3.5>>" Nodes following this specification SHOULD generate new temporary> addresses on a periodic basis. This can be achieved automatically by> generating a new randomized interface identifier at least once every> (TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR) time units.">>If you think this is should be a stronger requirement I can change it to a MUST at the cost of breaking backward compatibility. Let me know what you prefer.

The SHOULD is fine, but perhaps you could change the first paragraph of section 3.1 to read:

The following algorithm assumes that each interface maintains an associated randomized interface identifier. When temporary addresses are generated, the current value of the associated randomized interface identifier is used. While the same identifier can be used to create more than one temporary address, the value SHOULD change over time as described in section 3.5.

This would make it clearer that a person should look at section 3.5 to understand how the identifier will change over time.

I have a few AD Review comments on draft-ietf-ipv6-privacy-addrs-v2-03 that I would like to have resolved before I send this document to IETF LC. I've included those comments below.

Brian and Bob, the tracker indicates that this document is intended for publication as a Draft Standard, however RFC 3041 is currently at PS, and this document seems to contain some changes to the specification that would impact implementations (such as the requirement to perform DAD on all generated addresses). Is the tracker state correct? If so, what is the rationale for publishing this document at DS?

Thanks,Margaret

>> I think that sometihng went wrong with the structure of this document:

1. Do not result in any changes to the basic behavior of addresses generated via stateless address autoconfiguration [ADDRCONF]. 2. Create additional global scope addresses based on a random interface identifier for use with global scope addresses.

>> What is meant by "for use with global addresses"? is this intended

to be a restriction on how/when privacy addresses can be used?

3.1 Assumptions

The following algorithm assumes that each interface maintains an associated randomized interface identifier. When temporary addresses are generated, the current value of the associated randomized interface identifier is used. The actual value of the identifier changes over time as described below, but the same identifier can be used to generate more than one temporary address.

The algorithm also assumes that for a given temporary address, an implementation can determine the prefix from which it was generated. When a temporary address is deprecated, a new temporary address is generated. The specific valid and preferred lifetimes for the new address are dependent on the corresponding lifetime values set for the prefix from which it was generated.

>> These two paragraphs are confusing to me. The node maintains a

random IID from which multiple addresses can be generated of the form <prefix, IID>, right? These addresses will become deprecated when their lifetime expires, and new addresses will be generated. The implementation keeps track of what prefix was used to generate the addres and generates a new address for that prefix, right? Does it also need to generate a new random IID when this happens? In other words, is there anything in this mechanism that prevents generating the same privacy address again on the same interface using the same prefix and the same random IID (if it hasn't expired yet)?

2005-05-10

05

Margaret Cullen

State Changes to AD Evaluation::Revised ID Needed from Publication Requested by Margaret Wasserman