Roque Gagliano wrote: > > I reviewed the documents and here are my comments. Overall I found it > clear and easy to read.
Sounds good. Thank you for taking the time to review the document. Some comments inline below: > -------------------------------------------- > > 1) > Abstract: > > As specified today SEND assumes that the node advertising > ^^^^^^ > in RFC 3971 Ok. How about? As specified in the current SEND specification [RFC3971], it is assumed that the node advertising... > 2) General comment on "ownership" of IP addresses: > The documents mentions in several parts that a host "owns" an address > or a prefix. Coming from the registry world, I can say that it is not > the correct terminology. IP addresses are not owned, they are allocated > or assigned. Then configured (dynamically or statically) in an > interface. Ownership has a meaning of property that should not be used. Well, actually that's a feature of CGA's, one can show proof-of-ownership by signing with the CGA's private key. I own my CGA because I generated it and the corresponding key pair, and you do not own it and you can't show proof of ownership because you don't have the private key. So I think we want to keep using that term. I can agree that we don't want to talk about a prefix owner, though, but I don't think we're doing that in the document. > 3) Section 4.1 > A ND Proxy shall parse any IPv6 packet it receives on a proxy interface > to check whether it contains one of the following ICMPv6 messages: > Neighbor Solicitation (NS), Neighbor Advertisement (NA), Router > Advertisement (RA), or Redirect. > ^^^^^ > Router Solicitation messages are missing, these are needed in example 3. The section 4.1. describe the RFC4389 use case. In this use case Router Solicitations (RS's) negotiate no link layer address and thus they do not require specific treatment compared to regular IPv6 data packets, as opposed to the messages listed above, NS, NA, RA and Redirect. > 4) Section 5. > > Paragraph 1: > It is written as if Proxy SEND only applies to RA and RS as it mentions > "assume that the owner of the address was the one who was advertising > the prefix". I rather say: "the address or prefix was configured in the > node originating the ND message". Ok. > Bullet 1: > s/krishnan-cgaext-send-cert-eku/ietf-csi-send-cert-01 > The document is now a WG item. > > Bullet 2: > s/has/hash > > 5) Section 6.1 Proxy Signature Option. > Here is my biggest issue, there is no possibility of transitioning from > one algorithm to another, the document sticks with SHA-1 as hashing > algorithm and RSA/SHA-1 for signature. Working in another protocol, > the SEC ADs made it clear that they are looking at documents to make > sure that there is a way to change the crypto algorithms if needed. The > host receiving the NDP message from the SEND Proxy needs to know the > signature alg. that is being used. One solution to this issue is to > define 8 bits of the Reserved bits where 4 of them define the hash > algorithms and the other 4 the signing algorithm. A transition > mechanism could be to include two PSOs extensions, one with each set of > algorithms. > > I know this may also have to do with the protocol agility discussion. > Again, you could check with the SEC ADs if this would be an issue for > them. The lack of algorithm agility is generic to SEND and not specific to the Secure Proxy ND mechanism. When the WG concludes on how to move forward with algorithm agility, we can publish an RFC updating both RFC3971 and this to be RFC to add algorithm agility. > 6) Normative references: > s/krishnan-cgaext-send-cert-eku/ietf-csi-send-cert-01 > The document is now a WG item. Ok. --julien _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
