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

[Mark Stapp <[e-mail]>]

Thomas,
Thanks for the comments. Replies/questions inline:

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:

[...]

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

As the relay-agent option spec is written right now, there can only be a 
single instance of the relay-agent option. It's forbidden for a second 
relay to add another option, or modify the contents of an existing option.

We've talked within the working-group about deployments where there are 
multiple relay agents present, and in which more than one agent would like 
to insert relay options. I'm hoping that once authentication is possible 
between servers and agents, it will become possible to trust multiple 
instances of the option.

For the present, since we haven't decided how to (or whether to) revise 
3046, I needed some technique to allow for some of the known cases where 
more than one relay agent is involved. I consciously avoided trying to 
introduce a new option that could only be used for this purpose, tying the 
fate of agent authentication to it.

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

The semantics of the giaddr field is very clear - it's an ip address. The 
relay-id is (I hope) also clear, but potentially different. We allow the 
relay-id to be something other than an ip address, so requiring that the 
two fields be set to the same value may be confusing if a site has 
established some other basis for assigning relay-id values.

>Nits below.

I've fixed the typos you caught.

[...]

> >    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
>[...]
>less than, or less than or equal?

Quite right: should be <=.


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

Hmmm. I wrote "they only need to be locally unique." Is that unclear? Yes, 
I intended that the space be flat for the entire site. I don't expect more 
than a handful of keys to be in use, so I felt that that was adequate.

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

OK.

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

The user-visible behavior is different, though: 'disabled' is not the same 
as 'incompletely or incorrectly configured'. I wanted to provide a 
suggestion about the default since admins will have to deploy new software 
into their networks in order to get authentication. If the new 
authentication feature is disabled, the admin doesn't get an error message. 
If the new feature is enabled, then the admin immediately has a 
'misconfiguration' if there are no credentials, and the admin probably 
starts getting errors. That didn't seem helpful.

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

Actually, it is true in some interesting configurations. For example, it 
may be the relay in an L2 switch that has access to information like which 
device/slot/port the client is on, and knows the 802.1x information 
associated with the client.

-- Mark


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