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

From: Thomas Narten <[email-masked]>
Date: Tue, 24 Jun 2003 14:17:16 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Fri, 27 Jun 2003 14:38:12 -0400

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

---

From: Thomas Narten <[email-masked]>
Date: Fri, 27 Jun 2003 16:03:04 -0400

Hi Ralph.

> 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.

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.

> 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.

> scenarios.

I have no problem with this.

> At the dhc WG meeting in San Francisco we agreed

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.

> 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