Subject: Re: [dhcwg] draft-ietf-dhc-forcerenew-nonce-00

From: "Alper Yegin" <[email-masked]>
Date: Mon, 1 Feb 2010 11:00:37 +0200

Ted,

> This document specifically addresses the concern that an attacker could
> do a blind attack from off-network.

OK. It'd be good to capture that.

Then I have two points.

First one is, in the same document we shall also capture that an alternative
to this scheme for the deployments is to rely on ingress filtering (such
that firewalls don't allow an "off-network" nodes spoof "on-network" IP
addresses), or DHCP filtering (firewalls not allowing DHCP packets through).

Btw, if this is the only threat we are concerned, maybe we can also think of
a solution that relies on the DHCP client checking the TTLs of the received
packets. 

Secondly, the threat this solution mitigates does not cover all the ones
mentioned in RFC 3203. We need to capture that as well, so that people don't
assume this is a full replacement of RFC3118 for FORCERENEW.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ted Lemon
> Sent: Thursday, January 28, 2010 7:57 PM
> To: Yoshihiro Ohba
> Cc: WG; [email-masked]; Woundy, Richard; Ralph Droms
> Subject: Re: [dhcwg] draft-ietf-dhc-forcerenew-nonce-00
> 
> On Jan 28, 2010, at 9:09 AM, Yoshihiro Ohba wrote:
> > In general sending a shared key in clear text and later on
> > using it for message authentication is considered to be a
> > security hole.
> 
> This document specifically addresses the concern that an attacker could
> do a blind attack from off-network.   To prevent on-network attacks it
> would be necessary to implement RFC3118-style authentication.   I don't
> think the document claims to prevent on-network attacks; if it does, it
> needs to be updated to be more clear.
> 
> The point is to make attacks like the one that Dan Kaminsky publicized
> for DNS cache poisoning prohibitively expensive, *not* to authenticate
> the DHCP message.
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 1 Feb 2010 12:07:14 -0500

> maybe we can also think of a solution that relies on the DHCP client
checking the TTLs of the received
packets.

Please don't rely on client checking of TTLs. Legitimate DHCP servers
can be located in many places in an ISP's topology; it could be one hop
away or many hops away. One's backup DHCP server (for Failover) might be
in an entirely different location -- both physically and in the ISP's
topology.

In addition, the IP TTL values may legitimately change with an
intermittent routing topology change, so validating against the last IP
TTL value may not be correct.

There is an additional concern from RFC 4948 section 4.1 that *might*
apply here. But I'll defer to you since you know more about the mobile
networking world than I do.

>Everyone comes from Everywhere: in the earlier life of the Internet it
had been possible to get some indication of the authenticity of traffic
from a specific sender based for example on the Time To Live (TTL). The
TTL would stay almost constant when traffic from a certain sender to a
specific host entered an operators network, since the sender will
"always" set the TTL to the same value. If a change in the TTL value
occurred without an accompanying change in the routing, one could draw
the conclusion that this was potential unwanted traffic. However, since
hosts have become mobile, they may be roaming within an operator's
network and the resulting path changes may put more (or less) hops
between the source and the destination. Thus, it is no longer possible
to interpret a change in the TTL value, even if it occurs without any
corresponding change in routing, as an indication that the traffic has
been subverted.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alper Yegin
Sent: Monday, February 01, 2010 4:01 AM
To: 'Ted Lemon'; 'Yoshihiro Ohba'
Cc: 'WG'; [email-masked]; Woundy, Richard; 'Ralph Droms'
Subject: Re: [dhcwg] draft-ietf-dhc-forcerenew-nonce-00

Ted,

Then I have two points.

First one is, in the same document we shall also capture that an
alternative
to this scheme for the deployments is to rely on ingress filtering (such
that firewalls don't allow an "off-network" nodes spoof "on-network" IP
addresses), or DHCP filtering (firewalls not allowing DHCP packets
through).

Btw, if this is the only threat we are concerned, maybe we can also
think of
a solution that relies on the DHCP client checking the TTLs of the
received
packets. 

Secondly, the threat this solution mitigates does not cover all the ones
mentioned in RFC 3203. We need to capture that as well, so that people
don't
assume this is a full replacement of RFC3118 for FORCERENEW.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 1 Feb 2010 21:29:52 +0200

I agree, legitimate TTL fluctuations would break that approach.

> From: Woundy, Richard [mailto:[email-masked]]
> Sent: Monday, February 01, 2010 7:07 PM
> To: Alper Yegin; Ted Lemon; Yoshihiro Ohba
> Cc: WG; [email-masked]; Ralph Droms
> Subject: RE: [dhcwg] draft-ietf-dhc-forcerenew-nonce-00
>