Subject: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Nov 2017 13:08:12 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-dhc-relay-port-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(I want to "discuss" the following  DISCUSS point. If the answer is that this
is by design, and the working group thinks that the operational aspects are
reasonable, then I will clear.)

This extension places normative requirements on any upstream server or relay,
which may or may not implement this spec.  It further appears that if you try
to use this extension without that support, things will break. That seems to
require at least an update to the DCHP and DCHPv6 RFCs[1], and some method of
discovery or fallback would be helpful. Section 5.4 discusses this a little
bit, but I think it needs to talk about what to do when things fail. "Turn off
the feature if you don't get DHCP responses" doesn't seem satisfying.

[1] I see 3.1 and 3.2 make changes to 2131 and 3315, so it seems an "UPDATES...
" tag is needed one way or another.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-1, last paragraph: It seems like the 2119 keywords here would be better placed
in the later sections about relay and server behavior. I suggest moving them
there, and making the introductory language non-normative.

- 3.1 and 3.2: I am surprised not to see 2119 keywords in the language added to
2131 and 3315:

-8: This spec adds the ability to direct dhcp responses to non-standard ports.
If the working group believes that does not affect the security considerations,
please describe the rational. (I'm not saying that I think there's a problem,
but I think the burden is on the working group to explain why they think there
is not.)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Nov 2017 16:19:03 -0500

Ben, the idea is that this is a very targeted approach for SDNs, not something that makes sense as a general update to the DHCP base specifications.   Since relays and servers are generally within the same administrative domain, there is little danger of actual interop issues—the operator is going to be customizing these settings very deliberately.   We also tend to assume that the DHCP server is pretty easy to update compared to relays or clients, so the fact that an updated relay might not work with a non-updated server isn't a major issue.   This isn't like TLS 1.3 where the server and the middleboxes are operated by agencies unknown to each other.

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 30 Nov 2017 00:10:19 +0000

Hi Ben,

Thanks for the review.

I agree with Ted’s comment on this. This is targeted mainly in a single admin domain.
If an operator wants to turn on this feature on a relay(s), he/she can find out if the
server or upstream relay supports this or not, and it’s easy to disable this feature
if it does not work (could also be bugs in software).

Also, the configuration of the feature is on the relay, the upstream relays and
server as long as has the software upgraded, they don’t need configuration. This
is similar to other DHCP relay options, for example, the ‘Agent Cirucit ID’ or
the ’Subscriber-ID” sub-option, which does not require relay do discovery to find
out if server supports that or not, and as soon as the server has the updated software,
it would automatically supports this.

For the other "UPDATES..” tag. I’m quoting Bernie’s comment in another thread:

	"We’ve already had this discussion and debate. It only UPDATES if you want to
	use this new capabilities, we don’t have a flag for that. UPDATES usually implies
	that you must do that."

Best Regards,
- Naiming

> On Nov 29, 2017, at 1:19 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Nov 2017 18:15:16 -0600

Hi Ted,

It explicitly proposes changes to changes language to 2131 and 3315. I’m not sure how to read that in any other way than updating 2131 and 3315.

Otherwise, if this is only intended for a specific context, it would help to have some language in the draft describing that scope. As written, I don’t see why a reader that was not involved in the creation of the draft would not assume it to be general purpose.

I’m almost convinced by the “same administrative domain” (although I think my “customer owned” cable modem has a relay, and it’s sort of fuzzy who’s administrative it belongs to :-) ). I think it would help to strengthen the language in 5.4 to make it clear what will break if people get this wrong.

Paragraph 2 of that section seems vague about when such a relay might choose a DHCP vs non-DHCP port. Is there some expectation that the relay would listen on both ports, in case of stray responses?

Ben.

> On Nov 29, 2017, at 3:19 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Nov 2017 18:19:56 -0600

> On Nov 29, 2017, at 6:10 PM, Naiming Shen (naiming) <[email-masked]> wrote:
> 
> 
> Hi Ben,
> 
> Thanks for the review.
> 

Please see my comments to Ted (which crossed in the mail with your message)

> it would automatically supports this.

Sure, but “as long as the the software has been upgraded” is an important precondition.

> 	that you must do that.”

I don’t agree with that characterization of UPDATES. An update that adds an optional feature is still an update. Whether or not implementations are required to support it depends on the specifics of the update. The main purpose is that readers of the original RFC know they need to pay attention to the new one.

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 30 Nov 2017 00:32:50 +0000

Ben,

Inline,
On Nov 29, 2017, at 4:19 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

On Nov 29, 2017, at 6:10 PM, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ben,

Thanks for the review.

Just saw that. Will add stronger wording on the section 5.4. to warn operational
users on this issue.

True. But I’m also saying this draft is following the same model as the other relay-options.
If an operation is relying on the ‘Subscribe-ID’ to be returned, and the server has not
yet supported this in software, it is broken in the DHCP chain and the relay can not
function correctly also. We’ll put stronger wording in the draft.

I’ll defer this to the chairs.

Best Regards,
- Naiming

Best Regards,
- Naiming

On Nov 29, 2017, at 1:19 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Nov 2017 19:41:25 -0500

> Otherwise, if this is only intended for a specific context, it would help to have some language in the draft describing that scope. As written, I don’t see why a reader that was not involved in the…

Suppose they did.   What would go wrong?

> I’m almost convinced by the “same administrative domain” (although I think my “customer owned” cable modem has a relay, and it’s sort of fuzzy who’s administrative it belongs to :-) ). I think it w…

Why would the owner or operator of the cable modem configure it to use a different DHCP port?

That said, I agree that this shouldn't be stated as updates to documents it's not updating.   This is an extension, not an update.   So sections 3.1 and 3.2 should really be stated as additional behavior for conforming implementations, not as updates to the base documents.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Nov 2017 20:39:43 -0500

What I would suggest is that you actually just specify the behavior and not specify an update to the document.   Changing the wording around the update isn't solving the problem.   So e.g. in section 3.1:

OLD:
   This specification adds the following extension to the above
   paragraph.

      DHCP messages from a relay agent to a server are sent to the 'DHCP
      server' port (67), and the UDP source port it uses can be any
      valid UDP port available in the relay system, including the DHCP
      port 67.  The default port number is 67 if there is no explicit
      configuration for the generalized source UDP port extension for
      DHCP relay.

NEW:
Relay agents implementing this specification may be configured instead to send to a port number other than 67.   This will only work when the DHCP server or relay agent to which such a relay agent is forwarding messages is configured to listen on the same port.

And then do the same with section 3.2.

This makes the text a lot easier to follow, and doesn't imply that this document is in any way updating the base documents.

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 30 Nov 2017 02:01:26 +0000

Ted, and others,

Note that the server does not need to listen on this port, but it needs to send back
the relay-reply to that port, so I modified your text a little.
the HTML diff is enclosed.

Best Regards,
- Naiming

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Nov 2017 21:17:07 -0500

> the HTML diff is enclosed.

Oops, sorry, it's been a while since I was following this closely.  So the text should say something more like this:

Relay agents implementing this specification may be configured instead to use a source port number other than 67, and to receive responses on that same port.  This will only work when the DHCP server or relay agent to which such a relay agent is forwarding messages is upgraded to support this extension.

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 30 Nov 2017 02:22:34 +0000

Cool. new diff of html enclosed.

Best Regards,
- Naiming

---

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Nov 2017 20:24:13 -0600

First, as I said in my discuss point, I planned to clear after a round of discussion. I think the discussion is on the right track, so I will clear.

More inline:

> On Nov 29, 2017, at 6:41 PM, Ted Lemon <[email-masked]> wrote:
> 

I thought you were using the idea that this was not general purpose as an argument about why we don’t need to worry about people trying to mix relays that implement this with other elements that do not :-)

> Why would the owner or operator of the cable modem configure it to use a different DHCP port?

Sorry, the cable modem comment was merely an aside, not a material part of my argument. I recognize there’s no real reason for it to use this extension.

> That said, I agree that this shouldn't be stated as updates to documents it's not updating.   This is an extension, not an update.   So sections 3.1 and 3.2 should really be stated as additional be…

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Nov 2017 20:30:42 -0600

Thanks for the updates.

In 5.4, you added advice to the first paragraph that one shouldn’t turn this on unless the upstream devices support it. That’s good. But I still wonder about the intent of the second paragraph. Is the intent that the relay listens for messages on _both_ ports? Or that it could be configure to listen on either? If a message arrives on the standard port in as a result of one from a non-standard port, is it valid?

Thanks!

Ben.

> On Nov 29, 2017, at 8:22 PM, Naiming Shen (naiming) <[email-masked]> wrote:
> 
> 
> <draft-ietf-dhc-relay-port-09-from-8.diff.html>
> 
> 
>> On Nov 29, 2017, at 6:17 PM, Ted Lemon <[email-masked]> wrote:
>>

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 30 Nov 2017 03:00:53 +0000

Hi Ben,

> On Nov 29, 2017, at 6:30 PM, Ben Campbell <[email-masked]> wrote:
> 
> Thanks for the updates.
> 

I think it's up to implementation. It is possible to listen on both ports, especially in ipv4 DHCP,
it has to listen on port 67 for client DHCP messages. For an implementation, if it configures
the relay-port feature and but receives the server relay-reply message on port 67, should it
drop or should it just log an error and keep handling this? either way is fine I think.

But from the large scale relay box implementation case, say there are three relay processes handling
the DHCP relay on the same box, there can be a default/central DHCP process just to receive on the
port 67, then dispatch the work to one of the relay-agents in round-robin fashion. In such a setup, if the
server does not support this feature, and it sends back on port 67, this central DHCP process may not
have information on which relay-agent to give it to. If it does, then that defeats the purpose of multiple
relay-agents on this box.

So to your question, it depends on the implementation and operational needs.

thanks.
- Naiming

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 30 Nov 2017 01:26:15 +0000

Have a change in section 3.1, 3.2 and 5.4, please review to see if this is enough.
Diff PDF enclosed:

Best Regards,
- Naiming

---

From: Ben Campbell <[email-masked]>
Date: Wed, 29 Nov 2017 22:02:56 -0600

> On Nov 29, 2017, at 9:00 PM, Naiming Shen (naiming) <[email-masked]> wrote:
> 
> 
> Hi Ben,
> 
> 

Thanks, and that seems reasonable. But I’m still unclear on the intent of that paragraph. Can you elaborate?

Ben.

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 30 Nov 2017 05:36:44 +0000

Ha, I missed that. This paragraph I took from AD review suggested text, and
it just means the implementation can have configuration knob to either enable
this feature by specifying a non-DHCP port number or disable that and leave
the port number to be at default:-)

I’ll modify the text so that is more readable. thanks.

- Naiming

On Nov 29, 2017, at 8:02 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

On Nov 29, 2017, at 9:00 PM, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ben,

On Nov 29, 2017, at 6:30 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Thanks for the updates.

Ben.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Nov 2017 07:36:24 -0500

I'm sorry to belabor this, but I'm realizing that there's a bit of ambiguity in the new text in that there are actually two types of messages sent by relays: server-direction and client-direction.   The current text doesn't make that distinction:

I do not know what the actual intention is—if all relay messages toward clients come from port 67, there's no problem.   All relay messages to clients _have_ to come from port 67.   It could be that you intend relay messages from relays to relays in the direction of clients to come from a different source port.   But right now I think that the text is just about messages from relays to relays or servers, in the direction of servers.   Is that correct?   If so, the easiest change would be something like this:

Relay agents implementing this specification may be configured instead to use a source port number other than 67 when relaying messages toward servers, and to receive responses toward clients on that same port. This will only work when the DHCP server or relay agent to which such a relay agent is forwarding messages is upgraded to support this extension.

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 30 Nov 2017 21:58:46 +0000

Ted,

NP. Sounds reasonable. I can adapt this in the next update. Thanks.

- Naiming

On Nov 30, 2017, at 4:36 AM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote: