RE: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi:

It sounds like we should not use:

"The following text replaces the text in RFC3315 section 21.1 ..."

But instead just use something close to the following which replaces 1st paragraph in section 3:

   For DHCPv6 [RFC3315], this specification REQUIRES IPsec encryption of relay to
   relay and relay to server communication.

   For DHCPv4 [RFC2131], this specification REQUIRES IPsec encryption of relay to
   server communication.

   By using IPsec with encryption for this communication,  the potentially sensitive
   client message and relay included information, such as the DHCPv4 relay-agent
   information option (82), vendor-specific information (for example, [CableLabs-DHCP]),
   and Access-Network-Identifier Option(s) [RFC7839], are protected from pervasive
   monitoring and other attacks.

What is in other documents doesn't really matter ...

- Bernie

-----Original Message-----
From: jouni.nospam [mailto:jouni.nospam@xxxxxxxxx] 
Sent: Thursday, January 26, 2017 1:59 PM
To: Ted Lemon <mellon@xxxxxxxxx>
Cc: Bernie Volz (volz) <volz@xxxxxxxxx>; Tomek Mrugalski <tomasz.mrugalski@xxxxxxxxx>; dhcwg@xxxxxxxx; draft-ietf-dhc-relay-server-security.all@xxxxxxxx; ietf@xxxxxxxx; Jouni Korhonen <jounikor@xxxxxxxxx>; int-dir@xxxxxxxx
Subject: Re: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02


> On Jan 26, 2017, at 10:36 AM, Ted Lemon <mellon@xxxxxxxxx> wrote:
> 
> On Jan 26, 2017, at 1:25 PM, jouni.nospam <jouni.nospam@xxxxxxxxx> wrote:
>> Hmm.. I really do not like specification “games” like this. If you cannot justify a MUST into RFC3315bis, then trying to circumvent the fact in another document (that does not update the RFC3315 or RFC3315bis) should not be a Standards Track document. I could accept this as a BCP or a like.
> 
> Hm, then you are saying that every extension ever done to a protocol that, if it contains MUSTs, MUST update that protocol, even if implementations that support the extension can interoperate with implementations that do not and vice versa.   What’s your basis for this?

No. But in this case there are pieces of text that change specific places in the original document from SHOULDs to MUSTs, musts to MUSTs, and adds few pieces of new stuff, etc. Now how that in not updating? Changes or “extensions” like that would be nice to follow from the base document.

- Jouni




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]