Subject: Re: [dhcwg] draft-xu-ipv6-ra-dhcp-server-option-00//re: IETF 77 minutes published.

From: Xu Xiaohu <[email-masked]>
Date: Mon, 10 May 2010 13:32:01 +0800

Hi Ted,

> -----邮件原件-----
> 发件人: Ted Lemon [mailto:[email-masked]]
> 发送时间: 2010年5月7日 22:07
> 收件人: Xu Xiaohu
> 主题: Re: [dhcwg] draft-xu-ipv6-ra-dhcp-server-option-00//re: IETF 77 
> minutes published.
> 
> On May 7, 2010, at 5:05 AM, Xu Xiaohu wrote:
> > 1) It can eliminate the latencies imposed by relay agents and 
> > prevent the clients from receiving and processing redundant 
> > responses from multiple DHCP servers.
> 
> You reference RFC3315 as proposing that relaying causes latency.   To be
honest,
> I have no idea why RFC3315 says this--I haven't run into latency issues in
the
> real world.   Have you encountered latency problems as a result of
relaying?

It's no doubt that forwarding them on the data plane at line rate will bring
less latency than processing them on the control plane, especially when the
control plane is much busy due to some reason. Of course, whether or not the
latency is a serious problem heavily depends on special application
scenarios. Maybe we can learn more experiences from the future large-scale
deployment of Mobile IP.

> > 2) The security threat of using rogue DHCP server/relay agent can be 
> > mitigated to some extent by using unicast, especially in the 
> > wireless environment. Of course, this benefit is largely based on 
> > the presumption that the rogue IPv6 Router Advertisement problem [I- 
> > D.draft-ietf-v6ops-rogue-ra-00] has been solved successfully.
> 
> How does unicast mitigate this threat?
> 
> > By using the unicast mode, at least the off-path attacks can be
eliminated.
> 
> I don't see how unicast has an effect on whether or not off-path 
> attacks are possible. Can you explain?

Unicast packets are harder to be intercepted by the malicious hosts than
multicast packets. In the unicast mode, the network operators don't need to
deploy any security policy on the LAN switches to prevent the bogus DHCP
servers/relays.

> > If somebody wants to prevent the on-path attack further, the DHCP 
> > server could use CGA and attach a signature on the messages it sends 
> > out. If this on-path attack prevention feature is desirable, it can 
> > be included in the next revision.
> 
> This seems to me to be unrelated to unicast.   I agree that CGA-signed
DHCP
> messages are a good idea, though.

Without the knowledge of the intended DHCP server addresses on the DHCP
clients, the CGA signature is almost meaningless since the bogus DHCP server
could response the clients' request by using its own CGA address and sign
the DHCP messages with its own CGA parameters. That's to say, CGA can only
be used to verify whether or not the received message is from the true owner
of the source address. As to whether or not the owner of that address is a
legitimate DHCP server, it is not the business of the CGA.

Provided that the clients could learn the legitimate DHCP server addresses
via RA while obtaining prefixes, with the help of the CGA, the DHCP clients
can verify whether or not the received DHCP response is from a legitimate
DHCP server. IMHO, this is the most important motivation for this draft.
 
Best wishes,
Xiaohu

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 May 2010 12:31:54 -0400

On May 10, 2010, at 1:32 AM, Xu Xiaohu wrote:
> control plane is much busy due to some reason.

Although this wouldn't be true of all routers, I don't think anyone would dispute that this would be a problem for a significant number of routers.

> Of course, whether or not the

My intuition says that if you have a network where the DHCP relay traffic represents a significant portion of the total traffic on the wire, you have configured your network badly.   It's always possible that future experience will prove me wrong, but I think that until we actually have an example of a well-configured network where the relay agents are showing a significant performance impact from DHCP relay traffic, this is a premature optimization.

> deploy any security policy on the LAN switches to prevent the bogus DHCP

This may be true in some cases, but again it indicates a problem in the implementation, not a problem in the protocol.   On a broadcast network, all packets reach all nodes; in this case unicast packets have the same problem as multicast packets.   In a switched network, where the switches are smart enough to only forward packets to their intended destination, multicast provides enough information that multicast packets should not be delivered to all nodes on the network.   If they are delivered to all nodes on the network, this is a problem with the switch, not a weakness of multicast.

> legitimate DHCP server, it is not the business of the CGA.

CGA can do a number of things for DHCP.   First of all, it lets us know if we are talking to the same device we talked to previously, because that device has proven to us that it possesses its key.   This is true both for DHCP clients and DHCP servers.   Second, for devices with long-lived addresses, like DHCP servers, the client can cache server information, and this can be used to identify rogue DHCP servers--if we see a server that has been marked by the user as legitimate, and also a server that has not, we can prefer configuration information from the legitimate server.

So yes, CGA by itself doesn't help us very much, but CGA in combination with other intelligence can be used to make DHCP much less vulnerable to attack by rogue servers.

> DHCP server. IMHO, this is the most important motivation for this draft.

From a security perspective, this doesn't make sense, though.   Why do you trust the RA?

I think there may be a pony in here somewhere--it's clear to me that at least I haven't thought through how CGA can be used by DHCP in any depth, and I need to do that.   But at the moment I don't see any strong argument for making this change to the DHCP protocol.

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 17 May 2010 10:26:17 +0800

Ted,

> 发送时间: 2010年5月11日 0:32
> 抄送: 'DHC Working Group'
minutes
> published.
> Although this wouldn't be true of all routers, I don't think anyone would
> dispute that this would be a problem for a significant number of routers.
> 
> My intuition says that if you have a network where the DHCP relay traffic
> represents a significant portion of the total traffic on the wire, you
have
> configured your network badly.   It's always possible that future
experience
> will prove me wrong, but I think that until we actually have an example of
a
> well-configured network where the relay agents are showing a significant
> performance impact from DHCP relay traffic, this is a premature
optimization.
> This may be true in some cases, but again it indicates a problem in the
> implementation, not a problem in the protocol.   On a broadcast network,
all
> packets reach all nodes; in this case unicast packets have the same
problem
> as multicast packets.   In a switched network, where the switches are
smart
> enough to only forward packets to their intended destination, multicast

I don't think the switches are that smart as you imaged. Since there is no
multicast protocol running on the DHCP relays or servers, the multicast DHCP
packets would be flooded to all nodes even the IGMP snooping is enabled on
the switches, unless the network operators have configured explicitly on the
switches which ports the DHCP relays or servers are attached to.

> provides enough information that multicast packets should not be delivered
to
> all nodes on the network.   If they are delivered to all nodes on the
network,
> this is a problem with the switch, not a weakness of multicast.
> 
> CGA can do a number of things for DHCP.   First of all, it lets us know if
we
> are talking to the same device we talked to previously, because that
device
> has proven to us that it possesses its key.   This is true both for DHCP
clients
> and DHCP servers.   Second, for devices with long-lived addresses, like
DHCP
> servers, the client can cache server information, and this can be used to
> identify rogue DHCP servers--if we see a server that has been marked by
the
> user as legitimate, and also a server that has not, we can prefer
configuration
> information from the legitimate server.

How could the client deem the server which INITIALLY responses its request
is a legitimate one?

The following statements are quoted from section 7.1 of RFC 3972 (CGA)
"  It is important to understand that an attacker can create a new
   address from an arbitrary subnet prefix and its own (or someone
   else's) public key because CGAs are not certified. ..."

> So yes, CGA by itself doesn't help us very much, but CGA in combination
with
> other intelligence can be used to make DHCP much less vulnerable to attack
by
> rogue servers.

Because you have to when the SLAAC is needed in some scenarios.

Xiaohu

> I think there may be a pony in here somewhere--it's clear to me that at
least
> I haven't thought through how CGA can be used by DHCP in any depth, and I
need
> to do that.   But at the moment I don't see any strong argument for making
this
> change to the DHCP protocol.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 May 2010 17:24:33 -0500

> switches which ports the DHCP relays or servers are attached to.

I don't understand what you mean by "no multicast protocol running on the DHCP servers and relays."   DHCP servers and relays are explicitly multicast.   And if the switches aren't smart enough to deal with this, that sounds like a problem with the switches.   Proposing a change to the DHCP protocol to address a problem with the switches seems backwards to me.

> How could the client deem the server which INITIALLY responses its request

It can't.   However, suppose you have a client that uses several IP networks frequently, and that client caches the DHCP server CGA info.   Now, a DoS attack occurs on one of these networks while the client is trying to communicate with the DHCP server.   The client can treat the DHCP server it communicated with before preferentially, and therefore successfully weather the DoS attack.

>   else's) public key because CGAs are not certified. ..."

This is true, but of course generating CGA addresses that validate is expensive.

> Because you have to when the SLAAC is needed in some scenarios.

Right.   And if you make the SEND RA the sole keystone of your security strategy, that makes DoS attacks and MiTM attacks easier, because you only have to convincingly lie to the host once.   If both DHCP and RA are protected by CGA, then you have to convincingly lie twice.

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 18 May 2010 09:30:18 +0800

Ted,

> 发送时间: 2010年5月18日 6:25
minutes
> I don't understand what you mean by "no multicast protocol running on the
DHCP
> servers and relays."   DHCP servers and relays are explicitly multicast.
And

Yes, DHCP servers and relays can receive and process multicast packets
destined to All_DHCP_Relay_Agents_and_Servers address. However, how could
the switch know which ports DHCP servers and relays are connected to without
the manual configuration as I mentioned above?

Could you please explain how the switches cleverly learn the above
information? 

> if the switches aren't smart enough to deal with this, that sounds like a
problem
> with the switches.   Proposing a change to the DHCP protocol to address a
> problem with the switches seems backwards to me.
> 
> It can't.   However, suppose you have a client that uses several IP
networks
> frequently, and that client caches the DHCP server CGA info.   Now, a DoS
attack

What about if the cached DHCP server is a rogue one?  In other word, how
could the client determine whether the cached DHCP server is legitimate or
not?

> occurs on one of these networks while the client is trying to communicate
with
> the DHCP server.   The client can treat the DHCP server it communicated
with
> before preferentially, and therefore successfully weather the DoS attack.
> 
> >> From a security perspective, this doesn't make sense, though.   Why do
you
> >> trust the RA?
> Right.   And if you make the SEND RA the sole keystone of your security
strategy,
> that makes DoS attacks and MiTM attacks easier, because you only have to
> convincingly lie to the host once.   If both DHCP and RA are protected by
CGA,
> then you have to convincingly lie twice.

On the other hand, the network operators would have to configure manually
security policies for RA and DHCP respectively if stateless DHCP messages
are forwarded in multicast. If unicast is used for stateless DHCP messages,
the network operators only need to secure the RA. Of course, CGA can be used
by the DHCP server optionally to avoid the MiTM attack. Anyway, before using
CGA to avoid DHCP server spoofing, the clients should know their intended
servers.

By the way, I don't know what's the major difference between using unicast
for DNS and using unicast for stateless DHCP (DNS/DHCP servers are BOTH
learnt from RA options) from the operational perspective.

Xiaohu