Francis Dupont writes and Jari Arkko responds: > - same (comment/request for improvement) > > o Cryptographically Generated Addresses are used to assure that the > sender of a Neighbor or Router Advertisement is the owner of an > the claimed address. A public-private key pair needs to be > generated by all nodes before they can claim an address. > > => this suggests that all addresses should be CGAs. Of course this > is only one of the two cases: > - certified addresses (always the case for universal or static IID) > - CGAs (which always give local IID) Right. Should be fixed. > - 8.3 Other Requirements (comment) > > Hosts that use stateless address autoconfiguration MUST generate a > new CGA as specified in Section 4 of [27] for each new > autoconfiguration run. > > => I disagree: nodes should have the choice between using a certified > IID or a CGA based IID. My main name-server is a host and I don't > want to use CGA for it for many reasons. Of course, I use stateless > autoconfig even I've switched from EID64 IID to ::1 IID some months > ago. Sounds reasonable. > It is outside the scope of this specification to describe the use of > trusted root authorization between hosts with dynamically changing > addresses. Such dynamically changing addresses may be the result of > stateful or stateless address autoconfiguration or through the use of > RFC 3041 [9]. If the CGA method is not used, hosts would be required > to exchange certificate chains that terminate in a certificate > authorizing a host to use an IP address having a particular interface > identifier. This specification does not specify the format of such > certificates, since there are currently a few cases where such > certificates are required by the link layer and it is up to the link > layer to provide certification for the interface identifier. This > may be the subject of a future specification. > > => this is not sound with the MUST of the previous paragraph. > And not with all the CGA=yes/no in next sections... Ok. > Please fix this and don't forget that mandatory encumbered technologies > like CGA won't pass last calls (so don't make them mandatory). The intention is to not make them mandatory. By the way, the Ericsson license for CGA IPRs should not block the use of this technology... ------------- Pekka Nikander: Francis Dupont has requirested to allow the use of non-CGA addresses instead of CGA addresses, and to use certificates to authorize to use of such addresses. This is OK and in line with the earlier discussions at the WG. To clarify this, the following changes to the document were requested and made: >> - same (comment/request for improvement) >> >> o Cryptographically Generated Addresses are used to assure that the >> sender of a Neighbor or Router Advertisement is the owner of an >> the claimed address. A public-private key pair needs to be >> generated by all nodes before they can claim an address. >> >> => this suggests that all addresses should be CGAs. Of course this >> is only one of the two cases: >> - certified addresses (always the case for universal or static IID) >> - CGAs (which always give local IID) Proposed resolution: Added the following new text after the old text: This specification also allows one to use non-CGA addresses and to use certificates to authorized their use. However, the details of such use have been left for future work. >> - 8.3 Other Requirements (comment) >> >> Hosts that use stateless address autoconfiguration MUST generate a >> new CGA as specified in Section 4 of [27] for each new >> autoconfiguration run. >> >> => I disagree: nodes should have the choice between using a certified >> IID or a CGA based IID. My main name-server is a host and I don't >> want to use CGA for it for many reasons. Of course, I use stateless >> autoconfig even I've switched from EID64 IID to ::1 IID some months >> ago. Proposed resolution: Replace the text above with a new one: Hosts that use stateless address autoconfiguration, SHOULD generate a new CGA as specified in Section 4 of [27] for each new autoconfiguration run. The hosts MAY continue to use the same public key and modifier, and start the process from Step 4. For natural reasons, hosts that are configured with a static address (e.g. PREFIX::1), cannot use CGA. They SHOULD acquire a certificate and use certificate chain based authorization. >> It is outside the scope of this specification to describe the use of >> trusted root authorization between hosts with dynamically changing >> addresses. Such dynamically changing addresses may be the result of >> stateful or stateless address autoconfiguration or through the use of >> RFC 3041 [9]. If the CGA method is not used, hosts would be required >> to exchange certificate chains that terminate in a certificate >> authorizing a host to use an IP address having a particular interface >> identifier. This specification does not specify the format of such >> certificates, since there are currently a few cases where such >> certificates are required by the link layer and it is up to the link >> layer to provide certification for the interface identifier. This >> may be the subject of a future specification. >> >> => this is not sound with the MUST of the previous paragraph. >> And not with all the CGA=yes/no in next sections... This should be consistent now, with the above addition, shouldn't it? Unless anyone objects, I will consider this issue now Solved with these changes. ------------- Jari Arkko: I agree with the principle of what you are trying to do. But I wonder if we can simultaneously leave the cert-based scheme details outside the scope of the specification and have a keyword in the following text: For natural reasons, hosts that are configured with a static address (e.g. PREFIX::1), cannot use CGA. They SHOULD acquire a certificate and use certificate chain based authorization. How about changing this text to This specification does not address the protection of Neighbor Discovery packets for hosts that are configured with a static address (e.g., PREFIX::1). Future certificate chain based authorization specifications are needed for such hosts. ------------- Pekka Nikander: Ok to me. Changed for now. Still waiting possible ack/nack from Francis. ------------- James Kempf: I think there might be an issue with saying that cert-based SEND is FFS and then saying that hosts with static addresses SHOULD use it. ------------- Pekka Nikander: Jari already noticed this, and provided some alternative text. I think his suggestion is ok: > This specification does not address the protection of Neighbor > Discovery packets for hosts that are configured with a static address > (e.g., PREFIX::1). Future certificate chain based authorization > specifications are needed for such hosts. ------------- James Kempf: Yes, that sounds fine. ------------- -------------