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

[Thomas Narten <[e-mail]>]

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