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.
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
