Subject: Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Dec 2012 15:14:58 -0600

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dhc-relay-id-suboption-11
Reviewer: Ben Campbell
Review Date: 2012-12-19
IETF LC End Date: 2013-01-07

Summary: This draft is basically ready for publication as a proposed standard. However, there is one comment from a prior review that I am not sure whether is resolved.

Major issues:

None

Minor issues:

-- In Sean Turner's 2009 review of version 07 of the document [ http://www.ietf.org/mail-archive/web/gen-art/current/msg04614.html ], he made the following comment:

> In the security considerations it says look to RFC 3046 and
> RFC 4030 for security considerations and then says SHOULD use the relay
> agent authentication option from RFC 4030.  RFC 3046 is targeted at
> network infrastructures that are "trusted and secure" and RFC 4030
> allows the relay agent to be part of this trusted and secure network.
> If an implementation doesn't use the relay agent authentication option,
> then the relay agent can't be part of the "trusted and secure" network.
>  This makes me think that the relay agent authentication option from
> RFC 4030 ought to be a MUST not a SHOULD?

I can't tell from the resulting conversation if that comment is addressed in the current text. Additional text has been added, but the SHOULD remains. I'm willing to accept it has been addressed if the author's say so--I only mention it to make sure it didn't fall through a crack.

Nits/editorial comments:

-- section 5, last paragraph:

I suggest removing the scare quotes around "stability". If there are concerns about whether such stability is real, it would be better to say that directly.

-- informative references:

draft-ietf-dhc-dhcpv4-bulk-leasequery-06 is now 07

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Dec 2012 09:40:18 -0600

Thanks for the timely response, and the background for the security language. 

This brings up one question, however. See inline: 

Thanks!

Ben.

On Dec 21, 2012, at 6:48 AM, RAMAKRISHNADTV <[email-masked]> wrote:

> Hi Ben,
> 
> Thank you for your review comments.
> Please find my responses inline below.
> 
> Regards,
> Ramakrishna DTV.
> 
>> -----Original Message-----
>> From: Ben Campbell [mailto:[email-masked]]
>> Sent: Thursday, December 20, 2012 2:45 AM
>> To: [email-masked]
>> Cc: [email-masked] Review Team; [email-masked] List
>> Subject: Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11
>> 
>> Summary: This draft is basically ready for publication as a proposed
>> standard. However, there is one comment from a prior review that I am
>> not sure whether is resolved.
>> 
>> Major issues:
>> 
>> None
>> 
>> Minor issues:
>> 
>> -- In Sean Turner's 2009 review of version 07 of the document [
>> http://www.ietf.org/mail-archive/web/gen-art/current/msg04614.html ], he
>> made the following comment:
>> 
> RFC3046 created the relay agent information option.
> Relay agent information option exists only in the messages between
> relay agents and DHCP servers. RFC3046 is targeted at network infrastructures
> that are "trusted and secure" as far as the paths among relay agents and DHCP
> servers is concerned. In many deployments, relay agents and DHCP servers
> are under a single administrative control. By careful design and engineering
> of the network, it is possible to ensure that the network infrastructure
> comprising relay agents and DHCP server is trusted and secure. To achieve that,
> RFC4030 may be used but is not a MUST. If not, RFC4030 would already be a MUST
> for RFC3046 deployment. But that is not currently the case.

Is the SHOULD use 4030 language a new normative requirement, or is it simply describing existing requirements from 3046 or elsewhere?  If it's a new normative requirement, then I am fine with your answer and withdraw the concern. If not, then it would be better to use descriptive rather than normative language in this draft.

>> I can't tell from the resulting conversation if that comment is
>> addressed in the current text. Additional text has been added, but the
>> SHOULD remains. I'm willing to accept it has been addressed if the
>> author's say so--I only mention it to make sure it didn't fall through a
>> crack.
>> 
> 
> We have indeed discussed about this comment and addressed it.
> 
> The following was a related comment from DHC WG Chair (Ted Lemon)
> (http://www.ietf.org/mail-archive/web/gen-art/current/msg04615.html):
> 
> 	"This document makes no changes to practice that require more or less security
> 	than is provided by existing relay agent options in RFC3046. Thus, the
> 	security considerations in RFC3046 should be adequate."
> 
> As Ted mentioned, our draft only proposes a new sub-option for relay-agent
> option which was originally created as part of RFC3046. So, the security
> considerations for RFC3046 apply to our draft as well. RFC3046 deployments may
> use RFC4030 as explained above. So, we indicated in our draft to refer to
> both RFC3046 and RFC4030. But there are no specific security issues in the
> new relay-id sub-option itself to make RFC4030 a MUST.
> 
> 
>> Nits/editorial comments:
>> 
>> I suggest removing the scare quotes around "stability". If there are
>> concerns about whether such stability is real, it would be better to say
>> that directly.
>> 
> 
> There is no need for these scare quotes. We will remove them.
> 
> We will update this.
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
> for the use of the addressee(s). If you are not the intended recipient, please
> notify the sender by e-mail and delete the original message. Further, you are not
> to copy, disclose, or distribute this e-mail or its contents to any other person and
> any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
> every reasonable precaution to minimize this risk, but is not liable for any damage
> you may sustain as a result of any virus in this e-mail. You should carry out your
> own virus checks before opening the e-mail or attachment. Infosys reserves the
> right to monitor and review the content of all messages sent to or from this e-mail
> address. Messages sent to or from this e-mail address may be stored on the
> Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Dec 2012 09:45:15 -0600

On Dec 21, 2012, at 8:27 AM, Ted Lemon <[email-masked]> wrote:

> On Dec 21, 2012, at 7:48 AM, RAMAKRISHNADTV <[email-masked]> wrote:
> To put it a bit differently, changing the security considerations for RFC3046 is out of scope for this document.   It could certainly be argued that the security considerations for RFC3046 are too weak, but if that is an argument that someone wants to make, the argument should be made in the context of updating RFC3046, not in the context of adding a new DHCP relay option.
> 

Thanks Ted, that makes perfect sense. 

As I responded separately to Ramakrishna, is the SHOULD use 4030 language a new requirement specific to this draft? Or is it just describing requirements in 3046 or elsewhere?

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Dec 2012 10:37:10 -0600

On Dec 21, 2012, at 10:06 AM, Ted Lemon <[email-masked]> wrote:

> On Dec 21, 2012, at 10:45 AM, Ben Campbell <[email-masked]> wrote:
> I suppose the authors should really answer this, but I was curious as well, and went looking.   I think RFC4030 should have updated RFC3046 to add this as a security consideration, but it did not.   However, e.g. RFC4243, RFC5010 and RFC5107 do add a similar requirement to their security considerations section, so it's probably fair to say that this has been informally adopted as appropriate practice for security considerations sections.   
> 
> Perhaps we should adopt the practice more formally... :)

Pending the authors' comments, it sounds like it's good as is. (Assuming that "adopt[ing] the practice more formally" isn't _this_ draft's problem :-)  )

---

From: RAMAKRISHNADTV <[email-masked]>
Date: Fri, 21 Dec 2012 12:48:13 +0000

Hi Ben,

Regards,
Ramakrishna DTV.

We will update this.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Dec 2012 14:27:17 +0000

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Dec 2012 16:06:30 +0000

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 24 Dec 2012 03:34:23 +0000

Hi Ben,

        One reply in line.

        We will bring out another revision after taking care of your suggestions once we have some more review comments.

Regards,
Bharat

> Is the SHOULD use 4030 language a new normative requirement, or is it
> simply describing existing requirements from 3046 or elsewhere?  If it's
> a new normative requirement, then I am fine with your answer and
> withdraw the concern. If not, then it would be better to use descriptive
> rather than normative language in this draft.
> 

Yes.

Also as mentioned by Ted, this draft is using a language similar to some existing RFCs.