Hi, Bernie,
Thank you for the detailed review. I was not able to access email regularly
recently and the situation will remain for another week or 10 days, but I
will try to reply as fast as I can. Please see comments in lines:
>Note that while the AUTH option needs to be generated last
>(since it covers the entire message), it does not have to be
>the LAST option in the message.
>
>In DHCPv6, no entity (relay agent or server) adds options to
>the messages while it is 'in-flight' as is done for the DHCPv4
>relay agent option. Once the message is formed, a relay may
>encapsulate it in a Relay Message option in its own message,
>but that does NOT alter the original message.
>
>I think:
>- CGA Signature can be anywhere in the message.
>- CGA Signature covers the ENTIRE message EXCEPT for some of
>its own fields and the AUTH option.
>- The AUTH option covers the ENTIRE message, including the CGA
>Signature option.
>
>This way, the AUTH gives complete protection of the entire
>message as it was intended to.
It works.
>I'm not sure if it will be common for the SIGNATURE and AUTH
>to be used together, as it seems to me that using the AUTH
>message gives the better protection to begin with. But, if
>they are used together, it works.
Sure they can be used together. The good part of SIGNATURE is that it can be
used in relay senarios, thus we don't need to rely on IPSEC for protection.
(for the issue you found in relay scenario, please see the following
comments)
>I'd also highly recommend the CGA stuff be limited to clients
>and servers (a client can add/server validate). Note that a
>server can NOT use this for to provide proof of a CGA (the
>server's source address) because this ONLY works when the
>client and server are on the same link.
>If a relay agent is involved, the source address of the packet
>sent to the client is a relay agent address and thus the
>Signature would never validate.
Thanks for the issue you found, it's very important.
The souce address lost problem happened only for SERVER-->Relay-->Client.
For Client-->Relay-->Server, the souce address is kept in "link-address"
field of relay messages. Comparing AUTH and SIGNATURE, we have the
situation:
No Relay C-->R-->S S-->R-->C
AUTH yes no no
SIGNATURE yes yes yes with
proper solution*
Possbile solutions*:
Server's DHCP message (in relay senario) carry source address of server. For
example, this can be done by defining new option to carry server's source
address; or simply use the Server Identifier Option, define a new "link
address plus time" type for DUID content.
SIGNATURE is good for Relay scenarios where AUTH does not work. Entities
along the route can sign messages as long as have the ability and are
configured to do so. Receiver's can tell which signature belongs to whom.
There are no pair-wise configurations of symmetric keys.
For the questions whether all relay nodes should sign the message or whether
the server/client should verify all the signatures, personally I think we
can leave the decision for implementations or policys. Of course it's worth
discussion whether we should enforce it in protocol.
BW,
Sean
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
