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(_at_)cisco(_dot_)com<mailto:volz(_at_)cisco(_dot_)com>>
Date: Tuesday, 31 January 2017 4:38 am
To: Ted Lemon
<mellon(_at_)fugue(_dot_)com<mailto:mellon(_at_)fugue(_dot_)com>>,
"jouni.nospam"
<jouni(_dot_)nospam(_at_)gmail(_dot_)com<mailto:jouni(_dot_)nospam(_at_)gmail(_dot_)com>>
Cc: Tomek Mrugalski
<tomasz(_dot_)mrugalski(_at_)gmail(_dot_)com<mailto:tomasz(_dot_)mrugalski(_at_)gmail(_dot_)com>>,
"dhcwg(_at_)ietf(_dot_)org<mailto:dhcwg(_at_)ietf(_dot_)org>"
<dhcwg(_at_)ietf(_dot_)org<mailto:dhcwg(_at_)ietf(_dot_)org>>,
"draft-ietf-dhc-relay-server-security(_dot_)all(_at_)ietf(_dot_)org<mailto:draft-ietf-dhc-relay-server-security(_dot_)all(_at_)ietf(_dot_)org>"
<draft-ietf-dhc-relay-server-security(_dot_)all(_at_)ietf(_dot_)org<mailto:draft-ietf-dhc-relay-server-security(_dot_)all(_at_)ietf(_dot_)org>>,
"ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>"
<ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>>, Jouni Korhonen
<jounikor(_at_)gmail(_dot_)com<mailto:jounikor(_at_)gmail(_dot_)com>>,
"int-dir(_at_)ietf(_dot_)org<mailto:int-dir(_at_)ietf(_dot_)org>"
<int-dir(_at_)ietf(_dot_)org<mailto:int-dir(_at_)ietf(_dot_)org>>
Subject: RE: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02
Resent-From:
<alias-bounces(_at_)ietf(_dot_)org<mailto:alias-bounces(_at_)ietf(_dot_)org>>
Resent-To: <volz(_at_)cisco(_dot_)com<mailto:volz(_at_)cisco(_dot_)com>>,
Yogendra Pal <yogpal(_at_)cisco(_dot_)com<mailto:yogpal(_at_)cisco(_dot_)com>>,
<tomasz(_dot_)mrugalski(_at_)gmail(_dot_)com<mailto:tomasz(_dot_)mrugalski(_at_)gmail(_dot_)com>>,
<suresh(_dot_)krishnan(_at_)ericsson(_dot_)com<mailto:suresh(_dot_)krishnan(_at_)ericsson(_dot_)com>>,
<terry(_dot_)manderson(_at_)icann(_dot_)org<mailto:terry(_dot_)manderson(_at_)icann(_dot_)org>>,
Tomek Mrugalski
<tomasz(_dot_)mrugalski(_at_)gmail(_dot_)com<mailto:tomasz(_dot_)mrugalski(_at_)gmail(_dot_)com>>
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(_at_)fugue(_dot_)com]
Sent: Monday, January 30, 2017 5:54 PM
To: jouni.nospam
<jouni(_dot_)nospam(_at_)gmail(_dot_)com<mailto:jouni(_dot_)nospam(_at_)gmail(_dot_)com>>
Cc: Bernie Volz (volz)
<volz(_at_)cisco(_dot_)com<mailto:volz(_at_)cisco(_dot_)com>>; Tomek Mrugalski
<tomasz(_dot_)mrugalski(_at_)gmail(_dot_)com<mailto:tomasz(_dot_)mrugalski(_at_)gmail(_dot_)com>>;
dhcwg(_at_)ietf(_dot_)org<mailto:dhcwg(_at_)ietf(_dot_)org>;
draft-ietf-dhc-relay-server-security(_dot_)all(_at_)ietf(_dot_)org<mailto:draft-ietf-dhc-relay-server-security(_dot_)all(_at_)ietf(_dot_)org>;
ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>; Jouni Korhonen
<jounikor(_at_)gmail(_dot_)com<mailto:jounikor(_at_)gmail(_dot_)com>>;
int-dir(_at_)ietf(_dot_)org<mailto:int-dir(_at_)ietf(_dot_)org>
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(_dot_)nospam(_at_)gmail(_dot_)com<mailto:jouni(_dot_)nospam(_at_)gmail(_dot_)com>>
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.