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

[Ralph Droms <[e-mail]>]

Thomas,

The two techniques in this document both address the same
problem: the authentication of messages exchanged between
DHCP relay agents and DHCP servers.  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.

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.  At the dhc WG meeting in San Francisco we agreed
to advance the two techniques in a single document.

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.

Mark will respond to your comments specific to the
relay agent option definition.

- Ralph

At 02:17 PM 6/24/2003 -0400, Thomas Narten wrote:
>The WG has requested publication of this document as a PS. My review
>comments:
>
>High-level comments:
>
>This document contains two logically separate documents, an
>IPSec-based solution and one that uses the Relay Agent option. I think
>it would be better to have the two approaches documented in separate
>IDs (with a non-normative cross pointer to the other). This will help
>in the future when it becomes time to advance (or retire) one of them,
>etc. Plus, by being together, issues on one technique will block
>publication of both schemes. I'll note that the description of the
>IPSec approach is very skimpy. I predict that a review from an IPsec
>person will request that more details be added...
>
>Second, I'm confused about the Relay Indentifier field, when it is
>needed (and why). It kind of seems to me that its needed to identify
>which relay agent added a particular set of relay agent options, but
>in that case, this isn't an authentication-specfic issue and would
>perhaps better be handeled in a way that isn't specific to the
>authentication suboption. (i.e, so it could also be used if the
>authentication suboption is not present).
>
> >    The Relay Identifier field is used by relay agents that do not set
> >    giaddr, as described in RFC 3046 [2], Section 2.1.
>
>I reread this section, and didn't feel like I completely understood...
>
>There are times when a relay agent just adds more suboptions to an
>existing relay-agent option, rather than appending a new set? That
>makes it harder to identify who inserted what option... This is even
>worse when one node signs (cryptographicall) information provided by
>another, and the "trust" is not based on strong crypto...
>
> >    selects an appropriate Replay Detection value.  The sender places its
> >    identifier into the Relay ID field, if necessary, or sets the field
> >    to all zeroes.  The sender sets the suboption length, places the
>
>Why not just always include it, since the field is there anyway...
>That would seem to simplify things...
>
>Nits below.
>
> >    and servers to autenticate the identity of the source and contents of
>
>typo
>
> >    Four bits are reserved for future use.  These bits SHOULD be set to
> >    zero, and MUST be ignored when the suboption is processed.
>
>Not quite true, as the integrity check includes them? Reword?
>
> > 4.2 Replay Detection
> >
> >    The replay-detection mechanism is based on the notion that a receiver
> >    can determine whether or not a message has a valid replay token
> >    value.  The default RDM, with value 1, specifies that the Replay
> >    Detection field contains an increasing counter value.  The receiver
> >    associates a replay counter with each sender, and rejects any message
> >    containing an authentication suboption with a Replay Detection
> >    counter value less than the last valid value.  DHCP servers MAY
> >    identify relay agents by giaddr value or by other data in the message
> >    (e.g.  data in other relay agent suboptions).  Relay agents identify
> >
>
>less than, or less than or equal?
>
> >    the its notion of the last valid replay counter value associated with
>
>s/the its/its/
>
> >    The Key ID exists only to allow the sender and receiver to specify a
> >    shared secret in cases where more than one secret is in use among a
> >    network's relays and DHCP servers.  The Key ID values are entirely a
> >    matter of local configuration; they only need to be locally unique.
> >    This specification does not define any semantics or impose any
> >    requirements on this algorithm's Key ID values.
>
>name space could be clearer. Would it be better to just say the
>combination of relay id/key ID is unique?  or something else? Or is it
>really intended that IDs are a flat space for the entire site?
>
> >    should expect an Authentication suboption.  The receiver MAY be
> >    configured to drop incoming messages that do not contain a valid
> >    relay agent information option and Authentication suboption.
>
>better: MUST support configuration that allows ...
>
>NOte: since the signature is at the end of the option, wouldn't it be
>better to have the integrity check be performed up to the signature,
>but exclude it? What is the value in setting it to zero an including
>it in the check?
>
> > Use of the authentication suboption SHOULD be disabled by default.
>
>Seems unnecessary. How can the  suboption be used in the absence of
>keying info, which needs to be manually configured?
>
> > 4.7.1 Receiving Messages from Other Relay Agents
> >
> >    There are network configurations in which one relay agent adds the
> >    relay agent option, and then forwards the DHCP message to another
> >    relay.  For example, a layer-2 switch might be directly connected to
> >    a client, and it might forward messages to an aggregating router,
> >    which sets giaddr and then forwards the message to a DHCP server.
> >    When a DHCP relay which implements the Authentication suboption
> >    receives a message, it MAY use the procedures in Section 4.6 to
> >    verify the source of the message before forwarding it.
>
>Example could be better. An L2 switch presumably is not a relay
>agent...
>
>Thomas
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg