Re: [dhcwg] preliminary comments on draft-ietf-dhc-sedhcpv6-17

[Lishan Li <[e-mail]>]

2016-11-04 2:54 GMT+08:00 神明達哉 <[e-mail]>:

> At Thu, 3 Nov 2016 16:36:46 +0800,
> Lishan Li <[e-mail]> wrote:
>
> > > 2. Algorithm negotiation still doesn't make much sense to me.  I have
> > >    many questions and concerns related to this point, but instead of
> > >    raising each of these, I'd suggest one specific alternative to
> > >    consider: have the client send a list of supported algorithms in
> > >    the initial Information-Request, and let the server choose one set
> > >    of them and keep using the same set.  This way we don't have to
> > >    worry about an "algorithm not supported" error in the middle of a
> > >    DHCPv6 session (as a corollary, we don't have to worry about how to
> > >    return an encrypted reply when the client's preferred encryption
> > >    algorithm isn't supported by the server).  An obvious downside of
> > >    this is that it reveals some information of the client (the list of
> > >    supported/preferred algorithms), but IMO this is acceptable.
> > >
> > [LS]: In the current version, the server firstly sends a list of
> supported
> > algorithms through the Reply message. Then the client processes it
> > according to the following method:
> [...]
> > So it is not possible that the the server does not support the
> > acknowledged algorithms. So we also don't need to worry
> > about how to return an encrypted Reply when the client's
> > preferred encryption algorithm isn's supported by the server.
>
> One issue of this approach is that there's no way to recover from the
> situation where the client doesn't support any of the server-supported
> algorithms.

[LS]: For this situation, the client can sent the mandatory algorithms set
to the server.

Also, the server will have to include certificates of all
> the supported algorithms and signatures for all combinations of
> supported hash and signature algorithms as it doesn't know which of
> these works for the client.  This along with requiring the server
> to always include mandatory algorithms will make this approach
> workable, but it seemed to me to be unnecessarily wasteful and
> complicated.  Hence my suggestion.

[LS]: I don't think that the client/server need to contain all the
supported
algorithms. In default, all the servers and clients support the mandatory
encryption, signature, hash algorithms. So the client/server may just
need to contain the preferred algorithms and some of mandatory
algorithms. And Randy suggested us contain a list of algorithm, not
all the algorithm.

Besides, the current draft is not clear that the server needs to
> include all certificates and all combinations of signatures.  It's
> also awkward to mention the AlgorithmNotSupported status code if "it
> is not possible that the the server does not support the acknowledged
> algorithms".  So, whether or not my suggestion is adopted, the current
> version of draft has a lot of readability and technical issues (and so
> I think it's way far from being ready for a last call).  These are
> actually what I'd raise once I get to the point to discuss the content
> of the draft, but I wanted to address the higher level matters first.
>
[LS]: Maybe this version has some issues. I have submitted the xml/txt
files.
Could you please review the new version and modify it? I think that
we can discussed all the issues and move forward it as soon as possible.
And we can improve our efficiency in this way. Thanks a lot.

Best Regards,
Lishan