From:
Sheng Jiang [mailto:shengjiang at huawei.com]
Sent: Friday, July 11, 2008 9:06
AM
To: 'Shane Kerr'
Cc: dhcwg at ietf.org;
sshen at huawei.com
Subject: RE: [dhcwg] A new draft
of draft-jiang-dhc-secure-dhcpv6 is submitted. Comments are welcome!
Hi, Shane,
Thanks Shane for your comments. For
some reason, my reply to you on July 8th did not show up on the DHC mail list.
So I post it again.
What you listed are all good
examples while there are many more examples. In this draft, we were trying to
do was to explain security feature of our design in a general way, such as
"prevent faking a server or client" instead of giving details like
"prevent a fake server to do *.*", since we probably cannot enumerate
all scenarios.
Our design does prevent from
faking a server when this server's public key is known by other users. If a
DHCPv6 server's public key is well known, no advertise can be faked on behalf
of this server. If I understand you right, you are talking about the case when
a malicious user uses his own pub/priv key to generate a signature and pretend
to be a server. In this case, the receiver can find out that the fake public
key does not match the server (either from the local public key list or from
certificate trust chain), hence drop the fake advertise.
Best regards,
Sheng &
Sean
From:
Shane Kerr [mailto:shane at ca.afilias.info]
Sent: Tuesday, July 08, 2008 5:06
AM
To: Sheng Jiang
Cc: dhcwg at ietf.org
Subject: Re: [dhcwg] A new draft
of draft-jiang-dhc-secure-dhcpv6 is submitted. Comments are welcome!
Sheng Jiang,
On Jul 4, 2008, at 10:58 +0200, Sheng Jiang wrote:
A new draft of draft-jiang-dhc-secure-dhcpv6 is
submitted. Comments are welcome!
Filename:
draft-jiang-dhc-secure-dhcpv6
I haven't done a detailed review, but I think this is
an interesting idea worthy of being pursued.
But maybe in the draft you can explain a bit more
about the specific attacks this is designed to prevent?
As I understand it, this technique will prevent an
attacker:
- from sending an invalid binding in a Request
- from Declining a message on behalf of a client
- from Releasing a lease of a client (or
renewing, but I don't see that as a major problem)
- from causing a client to Reconfigure
It will not prevent an attacker from sending an
Advertise and acting as a DHCPv6 server. (Maybe something like the RA spoofing
prevention draft could be used for this, but that is probably the subject of a
separate draft.)