[CGA-EXT] Review draft-ietf-csi-proxy-send-01

[Roque Gagliano <[e-mail]>]

I reviewed the documents and here are my comments. Overall I found it clear and easy to read. 

Regards,

Roque.

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

1) 
Abstract:

As specified today SEND assumes that the node advertising
                     ^^^^^^
                    in RFC 3971

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.

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.

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".

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.

6) Normative references:
s/krishnan-cgaext-send-cert-eku/ietf-csi-send-cert-01
The document is now a WG item.