Re: [dhcwg] AD review of draft-ietf-dhc-relay-agent-auth-01.txt

Ralph Droms <rdroms@cisco.com> Thu, 03 July 2003 13:16 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09784; Thu, 3 Jul 2003 09:16:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3wO-0003ZD-Bg; Thu, 03 Jul 2003 09:16:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y3vu-0003Yv-Td for dhcwg@optimus.ietf.org; Thu, 03 Jul 2003 09:15:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09765 for <dhcwg@ietf.org>; Thu, 3 Jul 2003 09:15:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y3vt-0006AT-00 for dhcwg@ietf.org; Thu, 03 Jul 2003 09:15:29 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19Y3vs-0006AP-00 for dhcwg@ietf.org; Thu, 03 Jul 2003 09:15:28 -0400
Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 03 Jul 2003 06:11:44 -0700
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h63DEoQr013334; Thu, 3 Jul 2003 06:14:51 -0700 (PDT)
Received: from rdroms-w2k.cisco.com (rtp-vpn1-313.cisco.com [10.82.225.57]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAK09451; Thu, 3 Jul 2003 09:14:49 -0400 (EDT)
Message-Id: <4.3.2.7.2.20030703090403.03faa038@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 03 Jul 2003 09:14:41 -0400
To: Thomas Narten <narten@us.ibm.com>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] AD review of draft-ietf-dhc-relay-agent-auth-01.txt
Cc: mjs@cisco.com, dhcwg@ietf.org
In-Reply-To: <200306272003.h5RK34Rk004698@rotala.raleigh.ibm.com>
References: <Message from rdroms@cisco.com of "Fri, 27 Jun 2003 14:38:12 EDT." <4.3.2.7.2.20030625173824.00bbd0f8@funnel.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

Thomas ... comments in line.

At 04:03 PM 6/27/2003 -0400, Thomas Narten wrote:
>Hi Ralph.
>
> > The two techniques in this document both address the same
> > problem: the authentication of messages exchanged between
> > DHCP relay agents and DHCP servers.
>
>Yes. But the solutions are very different, and will likely be
>implemented by different people or as different products. I.e,. the
>IPsec part will require help from the platform on which the server
>runs, as opposed to be part of the DHC package. In fact, it may be
>implementable without touching the DHC server at all.

Your last sentence points out one of the reasons to write
one document: it's not clear that the IPsec solution is
really a separate protocol.

The consensus of the WG was that the two solutions are complementary
alternatives to a single problem, and that writing a single document
that addresses the relay agent message authentication problem
makes it easier for admins to evaluate and choose between the
two solutions.

>Another thing, when vendors say "we've implemented RFC XX", will that
>mean the IPsec technique, or the relay agent option, or both? Having
>both in the same document will likely be a bit more confusing.

"Implementing RFC XXXX" will mean having a solution to the
relay agent message authentication problem.


> > The title of the document should, perhaps, read "Authentication of
> > DHCP Message Exchanged Between Relay Agents and Servers".  The two
> > techniques for authentication are described in a single document
> > because they are applicable in different scenarios.
>
>If both were likely to be implemented together, I'd not have an issue
>with this. But I suspect this won't be the case.

OK.

Thomas, your last sentence here sounds like you have a solution
in mind already that is in conflict with the consensus of the WG,
as expressed in the WG meeting in SF.

> > Prior to the last dhc WG meeting, you had asked for a comparison
> > of the two techniques, which John Schnizlein published on the
> > dhc WG mailing list.  Based on that comparison, the consensus
> > of the WG was that the two techniques should be advanced
> > together, because neither was appropriate for all operational
> > scenarios.
>
>I have no problem with this.
>
> > At the dhc WG meeting in San Francisco we agreed
> > to advance the two techniques in a single document.
>
>I guess I wasn't paying attention during this part of the
>conversation, and am suggesting that keeping them in separate
>documents would be preferable.

OK ... but this suggestion is in opposition to the expressed
consensus of the WG.  We will have to go back to the WG
for consensus that rewriting the specification as two
documents is acceptable.


> > The description of the use of IPsec for authentication was copied
> > from an earlier draft of the DHCPv6 specification.  The text in
> > draft-ietf-dhc-relay-agent-auth-01.txt is the same as in the version
> > of the DHCPv6 specification that has been accepted as a Proposed
> > Standard.  The more detailed list of rules in the DHCPv6
> > specification will be used as the basis to provide additional detail
> > in this document.
>
>Fair enough. For background, I was also partly reflecting a private
>comment bellovin made a while back when I pointed him to the
>document. He said it was "thin" (or some such) and would probably need
>more detail. But he didn't provide specifics. It's also the case that
>in the IESG, we've seen a number of documents that for security say
>"just use IPsec". But in practice, the details can sometimes be tricky
>if you really want interoperability. E.g., there is a whole document
>on the topic for L2tp (RFC 3193). And MIPv6 also has a separate
>document (draft-ietf-mobileip-mipv6-ha-ipsec-03.html). In any case, I
>think we probably agree that there are fairly few words. If folk from
>the IPsec community think that is all that is needed, great. But we
>haven't seen such a review yet, AFAIK.
>
>Thomas

I fully agree that the text *in the current document* is inadequate.  I
suggest using text that addresses essentially the same problem from
a specification that has already been accepted by the IESG.

We have seen a review of the same list of rules in the DHCPv6 specification.
Do you have some reason to believe that those rules will not be
acceptable in this document?

- Ralph



>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg