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]

 



With full due respect of conversation, I see Bernie’s point, towards flexibility. For e.g: We see two operators primary wherein, device operator would like to have base RFC3315 supported for n/w and security operator asking for security in n/w via RFC9999.

Regards, Yogendra Pal
From: "Bernie Volz (volz)" <volz@xxxxxxxxx>
Date: Tuesday, 31 January 2017 4:38 am
To: Ted Lemon <mellon@xxxxxxxxx>, "jouni.nospam" <jouni.nospam@xxxxxxxxx>
Cc: Tomek Mrugalski <tomasz.mrugalski@xxxxxxxxx>, "dhcwg@xxxxxxxx" <dhcwg@xxxxxxxx>, "draft-ietf-dhc-relay-server-security.all@xxxxxxxx" <draft-ietf-dhc-relay-server-security.all@xxxxxxxx>, "ietf@xxxxxxxx" <ietf@xxxxxxxx>, Jouni Korhonen <jounikor@xxxxxxxxx>, "int-dir@xxxxxxxx" <int-dir@xxxxxxxx>
Subject: RE: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02
Resent-From: <alias-bounces@xxxxxxxx>
Resent-To: <volz@xxxxxxxxx>, Yogendra Pal <yogpal@xxxxxxxxx>, <tomasz.mrugalski@xxxxxxxxx>, <suresh.krishnan@xxxxxxxxxxxx>, <terry.manderson@xxxxxxxxx>, Tomek Mrugalski <tomasz.mrugalski@xxxxxxxxx>
Resent-Date: Tuesday, 31 January 2017 4:39 am

Hi:

 

Let's take the 3315bis out of the discussion as we don't yet know when that will be available and we'd like to progress on this draft sooner than that (as it is shorter and easier to do). We can get back to it later, but let’s focus first on today’s issue with is the document with RFC 3315.

 

So if this is released as RFC9999, the only way you as someone looking for relay or server implementations (or both) could know that this is supported is by asking the supplier whether they support RFC3315 and RFC9999. RFC9999 does not have up update 3315. This is just like many of the other DHCP RFCs which extend the functionality – Leasequery, bulk Leasequery, active Leasequery, and the many options documents. If you want certain features and they are in other documents, you have to specify the complete list.

 

Saying it updates RFC3315 doesn’t help since there are plenty of existing implementations that don’t support IPsec.

 

 

 

Back to RFC 3315 bis (draft-ietf-dhc-rfc3315bis), that is still a work in progress. Our plans to date are that we’ll incorporate all of the changes of draft-ietf-dhc-relay-server-security but leave it OPTIONAL to implement IPsec. This means that once draft-ietf-dhc-rfc3315bis is published as an RFC, those that want IPsec will have to check that the implementation supports both the bis RFC and RFC9999 (or whatever number). But that’s the same that someone wanting Leasequery must do – they’ll need to check that the bis RFC and RFC5007 are supported.

 

The draft-ietf-dhc-rfc3315bis and/or draft-ietf-dhc-relay-server-security authors can always raise it to the DHC WG to see if there is sufficient consensus to make IPsec a MUST in the bis document. But there hasn’t been in the past.

 

-          Bernie

 

From: Ted Lemon [mailto:mellon@xxxxxxxxx]
Sent: Monday, January 30, 2017 5:54 PM
To: jouni.nospam <jouni.nospam@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 30, 2017, at 5:20 PM, jouni.nospam <jouni.nospam@xxxxxxxxx> wrote:

Now if I decide to implement rfc3315bis *with* security, follow all musts in Section 20.1, and listed “updates” in the header, I have still no guarantee whether I can interoperate with another rfc3315bis implementation because it decided to follow relay-server-security. That is not good.

 

Thanks.   This is the clarification I was looking for.

 


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