Subject: [Dhcpv6bis] Doubts on "Relay agents MUST NOT modify the message" restriction

From: Guido Marelli <[email-masked]>
Date: Thu, 4 Jun 2015 18:45:51 -0300

Dear all,

I've been working with DHCP for more than 8 years and I would like to get
involved in the DHC WG discussions. I'm reading rfc3315bis and caught my
attention what I believe is a change from the original specification and I
wasn't able to find the source of this change.

In section 21.2 (Relaying a Relay-reply Message) the revised rfc3315bis
says: "Relay agents MUST NOT modify the message."

As far as I understand, this statement has some compatibility issues with
the DOCSIS 3.1 Security Specification from Cablelabs
(CM-SP-SECv3.1-I02-150326).
In these type of networks, there are some security features that require
the relay agent to change the message (for example: TFTP proxy for hiding
the true address of the TFTP server). However, the option modified to
provide these features is the Vendor-Specific Information Option
(OPTION_VENDOR_OPTS).

I believe it would be interesting to have an exception and allow relay
agents to alter OPTION_VENDOR_OPTS to provide flexibility and permit
vendor-specific behavior. What are your thoughts on this matter?

Best Regards,
Guido

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 4 Jun 2015 22:32:51 +0000

Hi:

Thanks for looking at the document and noticing some of the differences!

The main reason for this statement is that this would break any kind of client/server data integrity checking that might exist (i.e., such as the Delayed Authentication, which we are planning to depreciate, draft-ietf-dhc-sedhcpv6-07, and also draft-cui-dhc-dhcpv6-encryption-00).

In DHCPv4, this was one reason that RFC 5107 was developed. But I suspect there are plenty of cases in DHCPv4 were similar things happen (i.e., in DOCSIS).

I would suspect the right way to have done this in DOCSIS would be for the Relay Agent to provide that information to the DHCPv6 server (in the Relay’s options) so the server can place that information into what goes to the client. But this does make the server more complicated too.

With the push for more secure and privacy networking in the IETF, it may be harder to do what is being done in the long term.

I guess the options include:

1.       Relaxing this statement (Relay agents MUST NOT modify the message) in some way. Though I think that is bad.

2.       Remove the statement and be silent on the issue. Again, I think that is bad as it probably lead to this (if RFC 3315 has explicitly stated this, perhaps it would have given pause to Cablelabs).

3.       Cablelabs might need to say “OK, new RFCxxxx says MUST NOT but we’re going to ignore that and understand it will prevent use of some security/privacy capabilities (but we don’t require DOCSIS devices to use those anyway)”.

4.       Cablelabs updates standard to have the Relay provide the information (as options, perhaps Cablelabs Vendor options) that the DHCPv6 server is to use in responding to the client (where applicable).

#4 is the best long term solution. #3 is probably what can be done in the interim (for DOCSIS).

We’ll see what others on the bis team think.

You may want to raise this with the CableLabs folks?

-          Bernie

From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Guido Marelli
Sent: Thursday, June 04, 2015 5:46 PM
To: [email-masked]
Subject: [Dhcpv6bis] Doubts on "Relay agents MUST NOT modify the message" restriction

Dear all,

I've been working with DHCP for more than 8 years and I would like to get involved in the DHC WG discussions. I'm reading rfc3315bis and caught my attention what I believe is a change from the original specification and I wasn't able to find the source of this change.

In section 21.2 (Relaying a Relay-reply Message) the revised rfc3315bis says: "Relay agents MUST NOT modify the message."

As far as I understand, this statement has some compatibility issues with the DOCSIS 3.1 Security Specification from Cablelabs (CM-SP-SECv3.1-I02-150326). In these type of networks, there are some security features that require the relay agent to change the message (for example: TFTP proxy for hiding the true address of the TFTP server). However, the option modified to provide these features is the Vendor-Specific Information Option (OPTION_VENDOR_OPTS).

I believe it would be interesting to have an exception and allow relay agents to alter OPTION_VENDOR_OPTS to provide flexibility and permit vendor-specific behavior. What are your thoughts on this matter?

Best Regards,
Guido

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Jun 2015 10:53:03 -0400

> I would suspect the right way to have done this in DOCSIS would be for the Relay Agent to provide that information to the DHCPv6 server (in the Relay’s options) so the server can place that informa…

Isn't this the problem RFC 6422 set out to solve?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 5 Jun 2015 14:56:23 +0000

Yes - sorry I missed recalling that document.

For DOCSIS, it may be a bit more complex since this would be providing specific Vendor-specific Information Option options, which would be merged with other options.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, June 05, 2015 10:53 AM
To: Bernie Volz (volz)
Cc: Guido Marelli; [email-masked]
Subject: Re: [Dhcpv6bis] Doubts on "Relay agents MUST NOT modify the message" restriction

On Jun 4, 2015, at 6:32 PM, Bernie Volz (volz) <[email-masked]> wrote:
> I would suspect the right way to have done this in DOCSIS would be for the Relay Agent to provide that information to the DHCPv6 server (in the Relay's options) so the server can place that information into what goes to the client. But this does make the server more complicated too.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Jun 2015 11:03:38 -0400

> For DOCSIS, it may be a bit more complex since this would be providing specific Vendor-specific Information Option options, which would be merged with other options.

Seems like an easy problem to solve.  Either have a separate set of vendor options for DOCSIS relays, or specify that the server merges them, and how it does it. Depending on how the DHCP server implements relay-supplied options, this might not even be an issue.

---

From: Guido Marelli <[email-masked]>
Date: Mon, 8 Jun 2015 14:55:44 -0300

I understood the whole idea behind the change. Thanks for the
clarifications!

Best regards,
Guido Marelli

On Fri, Jun 5, 2015 at 12:03 PM, Ted Lemon <[email-masked]> wrote:

> > For DOCSIS, it may be a bit more complex since this would be providing
> specific Vendor-specific Information Option options, which would be merged
> with other options.
>
> Seems like an easy problem to solve.  Either have a separate set of vendor
> options for DOCSIS relays, or specify that the server merges them, and how
> it does it. Depending on how the DHCP server implements relay-supplied
> options, this might not even be an issue.