From 88369ad50928dfb4bea78c6e705c07023ebfd6c8 Mon Sep 17 00:00:00 2001 From: Ben Burwell Date: Thu, 11 Oct 2018 08:33:17 -0400 Subject: Fix some DHCP blog post typos --- _posts/2018-10-09-how-does-dhcp-work.md | 42 ++++++++++++++++----------------- 1 file changed, 21 insertions(+), 21 deletions(-) (limited to '_posts') diff --git a/_posts/2018-10-09-how-does-dhcp-work.md b/_posts/2018-10-09-how-does-dhcp-work.md index f9a2a0e..68c6331 100644 --- a/_posts/2018-10-09-how-does-dhcp-work.md +++ b/_posts/2018-10-09-how-does-dhcp-work.md @@ -93,16 +93,16 @@ in the Offer, including the rebinding and renewal periods, netmask, etc. --- Some observations: it makes sense to see UDP used for this protocol rather than -DHCP since TCP is connection-oriented and we don't know the address of the -server (nor our own address for that matter) at the beginning of this process. -It's also s easy to imagine havoc being wreaked on a network by creating a rogue -DHCP server that provides fake leases with conflicting IP addresses. +TCP since TCP is connection-oriented and we don't know the address of the server +(nor our own address for that matter) at the beginning of this process. It's +also easy to imagine havoc being wreaked on a network by creating a rogue DHCP +server that provides fake leases with conflicting IP addresses. Armed with my basic knowledge of how DHCP functions, I wanted to better -understand some I had encountered while experimenting. For instance, what is the -difference between "rebinding" and "renewal"? What is the reason for using -"seconds elapsed" as a kind of sequence number? My next stop to find answers was -the IETF RFCs. +understand some of what I had encountered while experimenting. For instance, +what is the difference between "rebinding" and "renewal"? What is the reason for +using "seconds elapsed" as a kind of sequence number? My next stop to find +answers was the IETF RFCs. As of this writing, there have been three iterations of the DHCP RFC, along with a few other extension/option RFCs. All three were written by Ralph Droms of @@ -110,9 +110,9 @@ Bucknell University. The first two ([RFC 1531][rfc1531] and [RFC 1541][rfc1541]) were published in October 1993, and the latest version, [RFC 2131][rfc2131], was published in March 1997. For historical context, I wanted to learn what had changed throughout the versions, so I ran `$ diff rfc1531.txt rfc1541.txt` (this -is one of those times that I love having the [RFC repository downloaded locally -with `rsync`](https://www.rfc-editor.org/retrieve/rsync/). There don't seem to -be any protocol changes between RFC 1531 and RFC 1541, just a few formatting and +is one of those times that I love having the [RFC repository available +locally](https://www.rfc-editor.org/retrieve/rsync/). There don't seem to be any +protocol changes between RFC 1531 and RFC 1541, just a few formatting and phrasing changes. Running `diff` on RFC 1531 and RFC 2131 produced quite a large output that I was not eager to read through, but conveniently, section 1.1 of RFC 2131 is called "Changes to RFC 1541". The 1997 changes are described as: @@ -145,16 +145,16 @@ page 15): > DHCPDISCOVER message. I did notice that there are a lot of sections with language like "a DHCP server -MAY extend a client's lease only if it has local administrative authority to do -so." But what if someone were to put a rogue DHCP server on the network, one -that did _not_ have "local administrative authority"? It's probably quite -possible to wreak a bit of havoc by creating a rogue DHCP server, though perhaps -not quite as easy as it might seem. Since DHCP leases often last for some time -(hours or days), existing clients might not be affected by the appearance of a -new server for quite a while. Besides, due to the binding mechanism, when a -client needs to renew its lease, it sends a unicast message directly to the -server it initially obtained the lease from rather than immediately resorting to -broadcasting a DHCPDISCOVER message. +MAY extend a client's lease **only if it has local administrative authority** to +do so" (emphasis added). But what if someone were to put a rogue DHCP server on +the network, one that did _not_ have "local administrative authority"? It's +probably quite possible to wreak a bit of havoc by creating a rogue DHCP server, +though perhaps not quite as easy as it might seem. Since DHCP leases often last +for some time (hours or days), existing clients might not be affected by the +appearance of a new server for quite a while. Besides, due to the binding +mechanism, when a client needs to renew its lease, it sends a unicast message +directly to the server it initially obtained the lease from rather than +immediately resorting to broadcasting a DHCPDISCOVER message. Since DHCP is often employed on a contiguous physical network segment, it may not always be possible to use a firewall to block traffic to the server port -- cgit v1.2.3