Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard

The IESG
The IESG has received a request from the Dynamic Host Configuration WG to
consider the following documents:

- 'A DNS RR for Encoding DHCP Information (DHCID RR) '
   <draft-ietf-dnsext-dhcid-rr-10.txt> as a Proposed Standard
- 'Resolution of FQDN Conflicts among DHCP Clients '
   <draft-ietf-dhc-ddns-resolution-10.txt> as a Proposed Standard
- 'The DHCP Client FQDN Option '
   <draft-ietf-dhc-fqdn-option-11.txt> as a Proposed Standard
- 'The DHCPv6 Client FQDN Option '
   <draft-ietf-dhc-dhcpv6-fqdn-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[hidden email] or [hidden email] mailing lists by 2005-11-28.

The files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-10.txt
http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-10.txt
http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-11.txt
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-03.txt


_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Pekka Savola
Hi,

I'll break out the most substantial comments in separate messages..

On Mon, 14 Nov 2005, The IESG wrote:

> The IESG has received a request from the Dynamic Host Configuration WG to
> consider the following documents:
>
> - 'A DNS RR for Encoding DHCP Information (DHCID RR) '
>   <draft-ietf-dnsext-dhcid-rr-10.txt> as a Proposed Standard
> - 'Resolution of FQDN Conflicts among DHCP Clients '
>   <draft-ietf-dhc-ddns-resolution-10.txt> as a Proposed Standard
> - 'The DHCP Client FQDN Option '
>   <draft-ietf-dhc-fqdn-option-11.txt> as a Proposed Standard
> - 'The DHCPv6 Client FQDN Option '
>   <draft-ietf-dhc-dhcpv6-fqdn-03.txt> as a Proposed Standard

I have only one major comment on DHCID on its use of MD5 as a
glued-in hash-function.  The rest of the comments are rather
straightforward.

substantial
----------

    In order to avoid exposing potentially sensitive identifying
    information, the data stored is the result of a one-way MD5 [5] hash
    computation.  The hash includes information from the DHCP client's
    REQUEST message as well as the domain name itself, so that the data
    stored in the DHCID RR will be dependent on both the client
    identification used in the DHCP protocol interaction and the domain
    name.  This means that the DHCID RDATA will vary if a single client
    is associated over time with more than one name.  This makes it
    difficult to 'track' a client as it is associated with various domain
    names.

    The MD5 hash algorithm has been shown to be weaker than the SHA-1
    algorithm; it could therefore be argued that SHA-1 is a better
    choice.  However, SHA-1 is significantly slower than MD5.  A
    successful attack of MD5's weakness does not reveal the original data
    that was used to generate the signature, but rather provides a new
    set of input data that will produce the same signature.  Because we
    are using the MD5 hash to conceal the original data, the fact that an
    attacker could produce a different plaintext resulting in the same
    MD5 output is not significant concern.

==> while the informatione exposure of someone cracking the MD5 hash
is not too huge, I believe it is unacceptable to design new protocols
without the capability to switch the hash function as need be.  This
could be achieved for example by reserving one additional byte from
the start of the DHCID record to designate the hash function used.
If you don't bother to define your own registry (for all of me, you
could include MD5 there as well, but at least include SHA1 and
preferably also SHA-256), you could possibly re-use
http://www.iana.org/assignments/ds-rr-types or something like that.

That way, we can introduce new hash functions in a backward compatible
manner later on, with no need to revamp the protocol.

If we don't do this, we'll need to define DHCID2, DHCID3, .. etc.
records further down in the future (w/ different hash functions) and
make DHCP co-exist with all of them.  That's bound to cause a lot of
protocol complexity, and I don't think we want to go there.

...

                                  New DHCID RR type codes are
    tentatively assigned after the specification for the associated type
    code, published as an Internet Draft, has received expert review by a
    designated expert.  The final assignment of DHCID RR type codes is
    through Standards Action, as defined in RFC 2434 [6].

==> this new RR type code assignment procedure seems to be
underspecified.  Is there actually harm in just doing this through
expert review, and giving the expert guidance that at least an I-D
must be published?  If so, you could reword this like:

    New DHCID RR type codes are assigned through Standards Action or
    Expert Review as defined in RFC2434 [6].  The expert should require
    sufficient public specification of the new type code.

.. in any case, please use existing RFC2434 mechanism unless you're
absolutely sure those won't fit your needs.

semi-editorial
--------------

    Conflicts can arise if multiple DHCP clients wish to use the same DNS
    name.  To resolve such conflicts, "Resolution of DNS Name Conflicts"
    [1] proposes storing client identifiers in the DNS to unambiguously
    associate domain names with the DHCP clients using them.

==> conflicts also occur when multiple nodes use the same FQDN while only a
part of them uses DHCP.  So, the above applicability could be reworded,
e.g., like follows:

    Conflicts can arise if multiple nodes wish to use the same DNS
    name.  To resolve such conflicts when the nodes are using DHCP,
    "Resolution of DNS Name Conflicts"
    [1] proposes storing client identifiers in the DNS to unambiguously
    associate domain names with the DHCP clients using them.

3.5.  Examples

==> I'd also have liked to see an example of DHCPv6 DHCID generation.

editorial
---------
    A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
    Ethernet MAC address 01:02:03:04:05:06 using domain name
    "client.example.com" uses the client's link-layer address to identify
    the client.

==> you should probably use RFC3330 documentation prefix here instead of
10/8.

    To resolve such conflicts, "Resolution of DNS Name Conflicts" [1]
    proposes storing client identifiers in the DNS to unambiguously
    associate domain names with the DHCP clients to which they refer.

==> no refs in the abstract

    A set of procedures to allow DHCP [7] clients and servers to
    automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
    in "Resolution of DNS Name Conflicts" [1].

==> also refer DHCPv6 here, please

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

DHCP and FQDN conflicts [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Pekka Savola
In reply to this post by The IESG
On Mon, 14 Nov 2005, The IESG wrote:

> The IESG has received a request from the Dynamic Host Configuration WG to
> consider the following documents:
>
> - 'A DNS RR for Encoding DHCP Information (DHCID RR) '
>   <draft-ietf-dnsext-dhcid-rr-10.txt> as a Proposed Standard
> - 'Resolution of FQDN Conflicts among DHCP Clients '
>   <draft-ietf-dhc-ddns-resolution-10.txt> as a Proposed Standard
> - 'The DHCP Client FQDN Option '
>   <draft-ietf-dhc-fqdn-option-11.txt> as a Proposed Standard
> - 'The DHCPv6 Client FQDN Option '
>   <draft-ietf-dhc-dhcpv6-fqdn-03.txt> as a Proposed Standard

I have one major issue with 'Resolution of FQDN Conflicts among DHCP
Clients', the first issue below.  It fails to properly describe the
threats caused by DHCP clients requesting updating non-DHCP FQDN's
(like a random host from example.com requesting "www.example.com").
While this may not be a problem if DHCP clients belong to different
zones from non-DHCP clients, this is not discussed at all in the
document -- except ruled out of scope.

This discussion needs to be included.

.......

6.3.3.  FQDN in Use by another Client

    As the FQDN appears to be in use by another client or is not
    associated with any client, the updater can decide (based on some
    administrative configuration outside of the scope of this document)
    whether to let the existing owner of the FQDN keep that FQDN, and to
    (possibly) perform some FQDN disambiguation operation on behalf of
    the current client, or to replace the RRs on the FQDN with RRs that
    represent the current client.  [...]

==> this is the biggest short-coming in this specification.  The choice of
this "administrative configuration outside the scope of this document" has
enermous security implications which have not been discussed at all in
Security Considerations section or here.

Specifically, consider the scenario:

1) www.example.com is manually configured (no DHCP) to point to 1.1.1.1,
    hence has no DHCID records.
2) a node in example.com zone uses DHCP, and purports its name is
    "www.example.com".  The DHCP server may nor may not perform the update
    based on the "admin config outside the scope of this document".

When reading the specification, this specific danger should be very clearly
explained, and this should be reflected in the document.  I'd also suggest
that by default, the server MUST NOT (or SHOULD NOT) perform updates if
there is no DHCID RR.

...

6.3.2.  DNS UPDATE When FQDN in Use

    2.  A delete of the existing AAAA RRs on the FQDN if the updater does
        not desire AAAA records on the FQDN or this update is adding an
        AAAA and the updater only desires a single IP address on the
        FQDN.

==> how does the code know whether the updates only desires a single IP
address on the FQDN or not?   AFAICS, there's no way to signal this from the
DHCP client!

5.  DNS RR TTLs

==> this section describes which TTLs to use in DNS RRs with DHCP.  This has
nothing to do with conflict resolution, though it's convenient to specify
this (which applies to both DHCPv4 and DHCPv6) here instead of duplicating
the same text in both DHCPv4/v6 specifications.  But should this still be
moved there?


semi-editorial
--------------

    There are two DNS update situations that require special
    consideration in DHCP environments: cases where more than one DHCP
    client has been configured with the same FQDN and cases where more
    than one DHCP server has been given authority to perform DNS updates
    in a zone.

==> the first point is actually more generic than that (though you cover it
as well in section 6.3.3), but rewording would be useful.  How about:

    There are two DNS update situations that require special
    consideration in DHCP environments: cases where more than one node is
    configured with the same FQDN and cases where more
    than one DHCP server has been given authority to perform DNS updates
    in a zone.

(and similar, "s/DHCP clients/nodes/" throughout -- it's sufficient that one
node uses DHCP, the others don't need to..)


editorial
---------

    FQDN, or Fully Qualified Domain Name, is the full name of a system,
    rather than just its hostname.  For example, "venera" is a hostname
    and "venera.isi.edu" is an FQDN.  See RFC 1983 [7].

==> use "example.com", please.

     Through the use of the client
    FQDN option, DHCP clients and servers can negotiate the client's FQDN
    and the allocation of responsibility for updating the DHCP client's A
    and/or AAAA RRs.

==> also PTR records, not just A/AAAA..

When either a client or server
    adds A, AAAA, or PTR RRs for a client, it also adds a DHCID RR that
    specifies a unique client identity, based on data from the client's
    DHCPREQUEST message.

==> seems to use DHCPv4-specific terminology, also add DHCPv6 wording?

    The most important consideration in removing DNS entries is be sure
    that an entity removing a DNS entry is only removing an entry that it
    added, or for which an administrator has explicitly assigned it
    responsibility.

==> s/be/being/ ?

9.2.  Informative References

    [5]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
          March 1997.

    [6]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
          Carney, "Dynamic Host Configuration Protocol for IPv6
          (DHCPv6)", RFC 3315, July 2003.

==> These should likely be normative references.

    Sites that wish to permit a single FQDN to contain both A and AAAA
    RRs MUST make use of DHCPv4 clients and servers that support using
    the DHCP Unique Identifier (DUID) for DHCPv4 client identifiers such
    that this DUID is used in computing the RDATA of the DHCID RR by both
    DHCPv4 and DHCPv6 for the client, see Node-Specific Client
    Identifiers for DHCPv4 [14].

==> [14] should likely be a normative reference.  The good news is that it's
already in RFC editor's queue! :)

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard

Pekka Savola
In reply to this post by The IESG
On Mon, 14 Nov 2005, The IESG wrote:

> The IESG has received a request from the Dynamic Host Configuration WG to
> consider the following documents:
>
> - 'A DNS RR for Encoding DHCP Information (DHCID RR) '
>   <draft-ietf-dnsext-dhcid-rr-10.txt> as a Proposed Standard
> - 'Resolution of FQDN Conflicts among DHCP Clients '
>   <draft-ietf-dhc-ddns-resolution-10.txt> as a Proposed Standard
> - 'The DHCP Client FQDN Option '
>   <draft-ietf-dhc-fqdn-option-11.txt> as a Proposed Standard
> - 'The DHCPv6 Client FQDN Option '
>   <draft-ietf-dhc-dhcpv6-fqdn-03.txt> as a Proposed Standard

I read draft-ietf-dhc-dhcpv6-fqdn-03.txt.  I believe most of the
comments also apply to the DHCPv4 option.  I think the document set
was overall well written, though there seemed to be a couple of issues
which need to be resolved.

substantial
-----------

    The Client FQDN option MUST only appear in a message's options field
    and applies to all addresses for all IA_NA bindings in the
    transaction.

==> shouldn't this be rather specified the other way around, i.e., in
which cases the receivers MUST discard Client FQDN options?  Sooner or
later someone will send the option in a wrong place, and it makes
sense to guard against this in the receiver's implementation.

    o  Otherwise, if the client's "S" bit is 1 and the servers's
       configuration allows it to honor the client's request for the
       server to initiate AAAA RR DNS updates and if it has the necessary
       credentials, the server sets the "S" to 1.  If the server's "S"
       bit does not match the client's "S" bit, the server sets the "O"
       bit to 1.

==> the server cannot know, before it has tried DNS update, whether it has
"the necessary credentials", right?

    The server MAY perform these updates even if the client's message did
    not carry the Client FQDN option.  The server MUST NOT initiate DNS
    updates when responding with an ADVERTISE message to the client.

    The server MAY complete its DNS updates (PTR RR or PTR and AAAA RR)
    before the server sends the REPLY message to the client.
    Alternatively, the server MAY send the REPLY message to the client
    without waiting for the update to be completed.  Whether the DNS
    update occurs before or after the REPLY is sent is entirely up to the
    DHCPv6 server's configuration.

    If the server's AAAA RR DNS update does not complete until after the
    server has replied to the DHCPv6 client, the server's interaction
    with the DNS server MAY cause the DHCPv6 server to change the domain
    name that it associates with the client.  This can occur, for
    example, if the server detects and resolves a domain-name conflict
    [8].  In such cases, the domain name that the server returns to the
    DHCPv6 client would change between two DHCPv6 exchanges.

==> does the first paragraph work with Rapid Commit, as there are no
messages beyond Advertise?

==> actually, the 2nd sentence of 1st paragraph should maybe be placed at
the end of the second paragraph -- it'd seem more logical there.

==> how does the resolution process described in 3rd paragraph work with
Rapid Commit?  If DNS update is done after the last communication with the
client, it's not clear how you signal the changed FQDN to the client?

9.  Security Considerations

==> this section should provide a pointer to ddns-resolution's
security considerations section, highlighting the necessity of
implementing conflict resolution properly.  For example, something
like,

    It is critical to implement proper conflict resolution, and the
    security properties of conflict resolution apply [8].  For example,
    a DHCP-client from example.com should not be able to override,
    e.g., www.example.com.

editorial
---------

    Depending on the prescence of or type of authentication used with the

==> s/prescence/presence/

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Steven Bellovin
In reply to this post by Pekka Savola
In message <[hidden email]>, Pekka Savola writes:

>Hi,
>
>I'll break out the most substantial comments in separate messages..
>
>On Mon, 14 Nov 2005, The IESG wrote:
>> The IESG has received a request from the Dynamic Host Configuration WG to
>> consider the following documents:
>>
>> - 'A DNS RR for Encoding DHCP Information (DHCID RR) '
>>   <draft-ietf-dnsext-dhcid-rr-10.txt> as a Proposed Standard
>> - 'Resolution of FQDN Conflicts among DHCP Clients '
>>   <draft-ietf-dhc-ddns-resolution-10.txt> as a Proposed Standard
>> - 'The DHCP Client FQDN Option '
>>   <draft-ietf-dhc-fqdn-option-11.txt> as a Proposed Standard
>> - 'The DHCPv6 Client FQDN Option '
>>   <draft-ietf-dhc-dhcpv6-fqdn-03.txt> as a Proposed Standard
>
>I have only one major comment on DHCID on its use of MD5 as a
>glued-in hash-function.  The rest of the comments are rather
>straightforward.
>
>substantial
>----------
>
>    In order to avoid exposing potentially sensitive identifying
>    information, the data stored is the result of a one-way MD5 [5] hash
>    computation.  The hash includes information from the DHCP client's
>    REQUEST message as well as the domain name itself, so that the data
>    stored in the DHCID RR will be dependent on both the client
>    identification used in the DHCP protocol interaction and the domain
>    name.  This means that the DHCID RDATA will vary if a single client
>    is associated over time with more than one name.  This makes it
>    difficult to 'track' a client as it is associated with various domain
>    names.
>
>    The MD5 hash algorithm has been shown to be weaker than the SHA-1
>    algorithm; it could therefore be argued that SHA-1 is a better
>    choice.  However, SHA-1 is significantly slower than MD5.  A
>    successful attack of MD5's weakness does not reveal the original data
>    that was used to generate the signature, but rather provides a new
>    set of input data that will produce the same signature.  Because we
>    are using the MD5 hash to conceal the original data, the fact that an
>    attacker could produce a different plaintext resulting in the same
>    MD5 output is not significant concern.
>
>==> while the informatione exposure of someone cracking the MD5 hash
>is not too huge, I believe it is unacceptable to design new protocols
>without the capability to switch the hash function as need be.  This
>could be achieved for example by reserving one additional byte from
>the start of the DHCID record to designate the hash function used.
>If you don't bother to define your own registry (for all of me, you
>could include MD5 there as well, but at least include SHA1 and
>preferably also SHA-256), you could possibly re-use
>http://www.iana.org/assignments/ds-rr-types or something like that.
>
>That way, we can introduce new hash functions in a backward compatible
>manner later on, with no need to revamp the protocol.
>
>If we don't do this, we'll need to define DHCID2, DHCID3, .. etc.
>records further down in the future (w/ different hash functions) and
>make DHCP co-exist with all of them.  That's bound to cause a lot of
>protocol complexity, and I don't think we want to go there.

I agree with this comment.  The draft is wrong -- it asserts that a
"successful attack of MD5's weakness does not reveal the original data".
That's an overassumption -- we have no idea what such an attack would
yield, since no such attack currently exists.

More generally...  The currently-known attacks on MD5 are collision
attacks: it's possible to generate two inputs that produce the same
hash value.  This scenario requires a preimage attack; none are known.
It would not surprise me if someone were to develop one, but until that
happens we can't speculate on its properties.  There are, however, some
reasons for concern.  One of the options defined, the DHCPv4 Client
Identifier, probably doesn't have much entropy.  For example, a
suggestion in RFC 2132 says to use the ARP hardware type code and MAC
address.  There's exactly one interesting hardware type code for most
users, and the high-order 3 bytes of the MAC address are the
manufacturer's ID, not many of which are actually used.  Given that
this is an 8-byte input string and that MD5 has an 8-byte output, it is
plausible that comparatively few input strings hash to any given output.
If several of the input bytes are fixed, or at least constrained, there
may be only one.  For that matter, that assumption alone may lead to a
successful attack on MD5.

In fact, the Security Considerations section should analyze the
(non-trivial) probability of a brute-force attack.  Again, consider the
Client Identifier, which is likely 8 bytes long.  2 are fixed, and
hence irrelevant.  According to today's copy of
http://standards.ieee.org/regauth/oui/oui.txt there are 8786
manufacturer IDs, or slightly more than 8 bits.  Effectively, though,
it's less, since the usage is very non-uniform.  Even if is uniform,
though, that field plus the unit identifier only total slightly over 32
bits -- well within anyone's capabilities.

Most of this analysis applies to the other two options as well.

                --Steven M. Bellovin, http://www.cs.columbia.edu/~smb



_______________________________________________
Ietf mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Ted Lemon
In reply to this post by Pekka Savola
Making a hash function interchangeable in DHCID makes the conflict detection
algorithm hugely more complicated, and possibly not workable at all.   Think
about how that would work.

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Pekka Savola
On Sat, 26 Nov 2005, Ted Lemon wrote:
> Making a hash function interchangeable in DHCID makes the conflict detection
> algorithm hugely more complicated, and possibly not workable at all.   Think
> about how that would work.

AFAICS, it shouldn't be all that complicated as long as the
implementations [checking for conflicts] support all the algorithms
used at the site, right?

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Sam Hartman-5
In reply to this post by Steven Bellovin
>>>>> "Steven" == Steven M Bellovin <[hidden email]> writes:

I'm currently writing a discuss on the md5 issue.

At a minimum you will need to specify the complexity in order to deal with changing hash algorithms.

    Steven> More generally...  The currently-known attacks on MD5 are
    Steven> collision attacks: it's possible to generate two inputs
    Steven> that produce the same hash value.  This scenario requires
    Steven> a preimage attack; none are known.  It would not surprise
    Steven> me if someone were to develop one, but until that happens
    Steven> we can't speculate on its properties.  There are, however,


Actually, no, it's worse than that.  A preimage attack is sufficient
to break this.  However you cannot reduce a break of this system to a
preimage attack.  

We actually know very little about how much information hash functions
leak.  We can prove an uppor bound on this given the assumption that
they are one-way.  If they leak too much information then they are not
one-way and we can find preimages.

However I don't think we can say much more than that.  

we can treat a hash function as a random oracle and under that
assumption it does not leak information.  The random oracle assumption
is much stronger than collision resistance.  Collision resistance can
certainly be reduced to random oracle.  So, saying that you can find
collisions actually is a very strong strike against the use of a
particular hash function as a random oracle.

I am not happy with a protocol whose security depends on treating md5
as a random oracle.

--Sam


_______________________________________________
Ietf mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

RE: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Bernie Volz (volz)
In reply to this post by Pekka Savola
This would, as Ted indicates, greatly complicate the entire update
sequence. The current update sequence (see
draft-ietf-dhc-ddns-resolution-10.txt), never does a query of the RRs in
the server. Therefore, either we'd have to do a query first to obtain
the DHCID RR and extract the algorithm so we can do the comparison, or
we'd have to try each of the algorithms in a DNS update operation.
Neither of these is particularily pleasant (especially considering that
things can change between DNS operations).

And, if not all implementations support all algorithms, you'd have real
interop problems.

And, what's the benefit? It isn't like this information is hyper
sensitive (come on, IPv6 uses the mac address in the link identifier --
yes, I know about RFC 3041).

While MD5 could be compromised, you can't necessarily get back the mac
address that was used to generate the value.

Yet, we also have to remember that we're dealing with a 48-bit *INPUT*
in many cases for the DHCID -- the mac address. A brute force attack is
not out of the question if you really wanted to get the data (and given
the well known 24-bit OID values, you could probably cut down the bruce
force attack to make it very reasonable whatever scheme we used). If a
client identifier or DUID is used, this does likely mean more bits but
most client identifiers and DUIDs are based on mac addresses.

So, let's be realistic here and not unnecessarily complicate matters for
no real benefit.

If there is a strong argument to improve the security of this
information, we can debate whether SHA1 or SHA-256 be used for the
start. But, I for one don't see the need.

- Bernie

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Pekka Savola
> Sent: Saturday, November 26, 2005 2:10 PM
> To: Ted Lemon
> Cc: [hidden email]; [hidden email]; [hidden email];
> [hidden email]
> Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:
> 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed
> Standard]
>
> On Sat, 26 Nov 2005, Ted Lemon wrote:
> > Making a hash function interchangeable in DHCID makes the
> conflict detection
> > algorithm hugely more complicated, and possibly not
> workable at all.   Think
> > about how that would work.
>
> AFAICS, it shouldn't be all that complicated as long as the
> implementations [checking for conflicts] support all the algorithms
> used at the site, right?
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
> _______________________________________________
> dhcwg mailing list
> [hidden email]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

RE: Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard

Bernie Volz (volz)
In reply to this post by The IESG
A few comments below. Prefixed by BV>.

- Bernie

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Pekka Savola
> Sent: Saturday, November 26, 2005 9:36 AM
> To: [hidden email]
> Cc: [hidden email]
> Subject: [dhcwg] Re: Last Call: 'Resolution of FQDN Conflicts
> among DHCP Clients' to Proposed Standard
>
> On Mon, 14 Nov 2005, The IESG wrote:
> > The IESG has received a request from the Dynamic Host
> Configuration WG to
> > consider the following documents:
> >
> > - 'A DNS RR for Encoding DHCP Information (DHCID RR) '
> >   <draft-ietf-dnsext-dhcid-rr-10.txt> as a Proposed Standard
> > - 'Resolution of FQDN Conflicts among DHCP Clients '
> >   <draft-ietf-dhc-ddns-resolution-10.txt> as a Proposed Standard
> > - 'The DHCP Client FQDN Option '
> >   <draft-ietf-dhc-fqdn-option-11.txt> as a Proposed Standard
> > - 'The DHCPv6 Client FQDN Option '
> >   <draft-ietf-dhc-dhcpv6-fqdn-03.txt> as a Proposed Standard
>
> I read draft-ietf-dhc-dhcpv6-fqdn-03.txt.  I believe most of the
> comments also apply to the DHCPv4 option.  I think the document set
> was overall well written, though there seemed to be a couple
> of issues
> which need to be resolved.
>
> substantial
> -----------
>
>     The Client FQDN option MUST only appear in a message's
> options field
>     and applies to all addresses for all IA_NA bindings in the
>     transaction.
>
> ==> shouldn't this be rather specified the other way around, i.e., in
> which cases the receivers MUST discard Client FQDN options?  
> Sooner or
> later someone will send the option in a wrong place, and it makes
> sense to guard against this in the receiver's implementation.
>
>     o  Otherwise, if the client's "S" bit is 1 and the servers's
>        configuration allows it to honor the client's request for the
>        server to initiate AAAA RR DNS updates and if it has
> the necessary
>        credentials, the server sets the "S" to 1.  If the server's "S"
>        bit does not match the client's "S" bit, the server
> sets the "O"
>        bit to 1.
>
> ==> the server cannot know, before it has tried DNS update,
> whether it has
> "the necessary credentials", right?

BV> Well, the server generally assumes it has the right credentials if
it is configured with them. If the DHCP server is told to do updates and
provided credentials, they better be valid or no updates will get done
and this would generally be viewed as a configuration error. Perhaps it
is unnecessary to add this level of detail and we just drop "and if it
has the necssary credentials".

>
>     The server MAY perform these updates even if the client's
> message did
>     not carry the Client FQDN option.  The server MUST NOT
> initiate DNS
>     updates when responding with an ADVERTISE message to the client.
>
>     The server MAY complete its DNS updates (PTR RR or PTR
> and AAAA RR)
>     before the server sends the REPLY message to the client.
>     Alternatively, the server MAY send the REPLY message to the client
>     without waiting for the update to be completed.  Whether the DNS
>     update occurs before or after the REPLY is sent is
> entirely up to the
>     DHCPv6 server's configuration.
>
>     If the server's AAAA RR DNS update does not complete
> until after the
>     server has replied to the DHCPv6 client, the server's interaction
>     with the DNS server MAY cause the DHCPv6 server to change
> the domain
>     name that it associates with the client.  This can occur, for
>     example, if the server detects and resolves a domain-name conflict
>     [8].  In such cases, the domain name that the server
> returns to the
>     DHCPv6 client would change between two DHCPv6 exchanges.
>
> ==> does the first paragraph work with Rapid Commit, as there are no
> messages beyond Advertise?

BV> The text is correct. A REPLY is sent in response to a SOLICITI
w/RAPID COMMIT if the server is honoring the RAPID COMMIT. ADVERTISE is
only sent if the 4-message exchange is used.

>
> ==> actually, the 2nd sentence of 1st paragraph should maybe
> be placed at
> the end of the second paragraph -- it'd seem more logical there.
>
> ==> how does the resolution process described in 3rd
> paragraph work with
> Rapid Commit?  If DNS update is done after the last
> communication with the
> client, it's not clear how you signal the changed FQDN to the client?

BV> Rapid Commit has no bearing on this as the FQDN may not be updated
until after the REPLY (either for SOLICIT W/Rapid Commit / REPLY or
SOLICIT / ADVERTISE / REQUEST / REPLY). The updated FQDN would not be
communicated until some follow on client operation, such as a renewal.

>
> 9.  Security Considerations
>
> ==> this section should provide a pointer to ddns-resolution's
> security considerations section, highlighting the necessity of
> implementing conflict resolution properly.  For example, something
> like,
>
>     It is critical to implement proper conflict resolution, and the
>     security properties of conflict resolution apply [8].  
> For example,
>     a DHCP-client from example.com should not be able to override,
>     e.g., www.example.com.
>
> editorial
> ---------
>
>     Depending on the prescence of or type of authentication
> used with the
>
> ==> s/prescence/presence/
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
> _______________________________________________
> dhcwg mailing list
> [hidden email]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

RE: Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard

Pekka Savola
On Sun, 27 Nov 2005, Bernie Volz (volz) wrote:

>>        configuration allows it to honor the client's request for the
>>        server to initiate AAAA RR DNS updates and if it has
>> the necessary
>>        credentials, the server sets the "S" to 1.  If the server's "S"
>>        bit does not match the client's "S" bit, the server
>> sets the "O"
>>        bit to 1.
>>
>> ==> the server cannot know, before it has tried DNS update,
>> whether it has
>> "the necessary credentials", right?
>
> BV> Well, the server generally assumes it has the right credentials if
> it is configured with them. If the DHCP server is told to do updates and
> provided credentials, they better be valid or no updates will get done
> and this would generally be viewed as a configuration error. Perhaps it
> is unnecessary to add this level of detail and we just drop "and if it
> has the necssary credentials".

The server may not even be configured with *any* credentials (if DNS
updates aren't done with DNSSEC). The statement could probably be
removed and it'd be OK.

>> ==> does the first paragraph work with Rapid Commit, as there are no
>> messages beyond Advertise?
>
> BV> The text is correct. A REPLY is sent in response to a SOLICITI
> w/RAPID COMMIT if the server is honoring the RAPID COMMIT. ADVERTISE is
> only sent if the 4-message exchange is used.

OK, you know DHCP exchanges better than I do :).  I hope this isn't an
issue in DHCPv4 spec either.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Steven Bellovin
In reply to this post by Ted Lemon
In message <[hidden email]>, Ted Lemon writes:
>Making a hash function interchangeable in DHCID makes the conflict detection
>algorithm hugely more complicated, and possibly not workable at all.   Think
>about how that would work.
>
I confess that I don't see the problem.  The updater would do a DNS
query for DHCID RRs; it would be given all of the stored records.  The
updater would then use local policy -- that is, an ordered list of
preferred hash functions -- until it found one that was in the
response.  That one would be used.  If no locally-known hash functions
are in the list, it should behave as if there were no DHCID records
present for that name.  DNSSEC could protect against downgrade attacks.
(Speaking of which -- were I still AD, I'd ding this document for an
inadequate Security Considerations section -- apart from the
lack of discussion of brute force attacks, you should cite 3833 for DNS
attacks and explain what the risks are if someone can crack the hash
function by any means, including brute force or eavesdropping on the
wire or (perhaps) a misbehaving updater.)

If you don't agree, I'd strongly suggest using SHA-256 instead of MD5.  
Yes, it's more expensive, but I doubt that that's a major hit on
overall system performance here.  It would also be useful to include in
the document some discussion of upgrade strategy -- how would we ever
switch to a new hash function?  That's non-trivial even for protocols
designed for agility, as Eric Rescorla and I have shown.  No matter how
it's done, this one is among the very hardest, since DNS servers would
have to supply DHCID records for several hashes for a number of years.

                --Steven M. Bellovin, http://www.cs.columbia.edu/~smb



_______________________________________________
Ietf mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Ted Lemon-2
On Monday 28 November 2005 10:49, Steven M. Bellovin wrote:
> I confess that I don't see the problem.

The problem is that in order to do what Pekka is proposing, we have to make a
substantial change to the protocol.   This creates two problems: first, it
means that this protocol, which is in wide use, has been in wide use for more
than five years, the standard for which has been under development for ten
years, will probably take another year to make standard, for this change
alone.   As it has many times before.   This is a major language tweak, and
will require substantial review.   Second, it renders implementations
substantially more complicated, and creates a knob that administrators need
to understand whether and how to turn, where no knob is needed.   Additional
knobs that aren't needed have a net negative impact on overall system
security - the overall impact of the proposed change will be to reduce, not
enhance security.

I support the changes suggested by Havard that simply reduce the security
claims being made here.   I do not support making any substantive changes to
the protocol at this point - to do so will simply delay it longer, and will
not add any value.   The only reason I can think of for not using MD5 is that
at some point people might want to be able to avoid having an MD5
implementation on their device because MD5 is generally deprecated.   I don't
think this is a practical concern - MD5 implementations are with us for the
long haul, deprecated or not.

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Ted Lemon-2
In reply to this post by Steven Bellovin
On Saturday 26 November 2005 09:56, Steven M. Bellovin wrote:
> In fact, the Security Considerations section should analyze the
> (non-trivial) probability of a brute-force attack.

It doesn't matter.   The point of the DHCID is to allow two servers to avoid
accidentally stepping on each other.   If you break the DHCID, what you get
is the ability to pretend that you are another DHCP client.   If you succeed
in doing this, you can take over that DHCP client's name, but you don't get
to keep it, because you are using the same identification as the other
client, and so it's going to take it back.   The information that you would
use to pretend to be the other client is routinely being sent over the
network in the clear, so you don't need to break the DHCID to get it - you
just need to listen on the wire for a packet from that client.   You can't do
the attack I've described unless you are on a network managed by a DHCP
server that manages the same namespace as the server that put in the
legitimate DHCID.

It's true that we could exhaustively go over all possible exploits, no matter
how trivial, no matter how useless, in the security considerations section.  
Do you honestly believe that this is necessary?

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Ted Lemon-2
In reply to this post by Sam Hartman-5
On Sunday 27 November 2005 15:21, Sam Hartman wrote:
> Actually, no, it's worse than that.  A preimage attack is sufficient
> to break this.  However you cannot reduce a break of this system to a
> preimage attack.  

It's always inspiring to meet someone who knows a lot about a complex topic
like hash algorithms.

> I am not happy with a protocol whose security depends on treating md5
> as a random oracle.

Again, very inspiring to meet someone who knows about md5, random oracles, et
cetera.   However, this protocol's security does not rely in any way on md5
or any other hash.   The hash is present as a privacy mask.   It has limited
value since the thing being protected is broadcast over the wire on a regular
basis, but we put it in because we were asked to.   The security of the
protocol rests on the security of the DNS update mechanism; if you are
concerned about DNS update security with your DHCP server, I suggest using
some kind of cryptographic authentication.   I use TSIG, and am reasonably
happy with it.

In order for the DHCID hash to be a security issue, it has to be the case that
you have more than one DHCP server that is permitted to update the same zone
in the DNS, and yet have no trust relationship between these DHCP servers.  
This is a contradiction in terms - if you don't have a trust relationship
between two updaters of the same zone, you don't have any update security at
all for that zone.

I would really encourage people who are commenting on this to please, please
read the drafts for detailed comprehension, not just for keywords.   I get
the impression that a lot of keyword triggering is going off here, and it's
really not constructive.

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Steven Bellovin
In reply to this post by Ted Lemon-2
In message <[hidden email]>, Ted Lemon writes:

>On Saturday 26 November 2005 09:56, Steven M. Bellovin wrote:
>> In fact, the Security Considerations section should analyze the
>> (non-trivial) probability of a brute-force attack.
>
>It doesn't matter.   The point of the DHCID is to allow two servers to avoid
>accidentally stepping on each other.   If you break the DHCID, what you get
>is the ability to pretend that you are another DHCP client.   If you succeed
>in doing this, you can take over that DHCP client's name, but you don't get
>to keep it, because you are using the same identification as the other
>client, and so it's going to take it back.   The information that you would
>use to pretend to be the other client is routinely being sent over the
>network in the clear, so you don't need to break the DHCID to get it - you
>just need to listen on the wire for a packet from that client.   You can't do
>the attack I've described unless you are on a network managed by a DHCP
>server that manages the same namespace as the server that put in the
>legitimate DHCID.
>
>It's true that we could exhaustively go over all possible exploits, no matter
>how trivial, no matter how useless, in the security considerations section.  
>Do you honestly believe that this is necessary?
>
It's the privacy aspect I'm concerned about.  The protocol has a
mechanism -- the hash -- intended to protect privacy.  There are
limitations to how well it works.  These may be unavoidable; that said,
they should be documented.  See Section 5 of RFC 3552, a BCP:

   Authors MUST describe

      1.   which attacks are out of scope (and why!)
      2.   which attacks are in-scope
      2.1  and the protocol is susceptible to
      2.2  and the protocol protects against

   ...

   There should be a clear description of the residual risk to the user
   or operator of that protocol after threat mitigation has been
   deployed.

Put another way, against a certain grade of attacker the mechanism
doesn't do its job.  That needs to be documented, so that people who
are concerned about the issue know to avoid this option.

                --Steven M. Bellovin, http://www.cs.columbia.edu/~smb



_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Mark Stapp

I don't object to Steve's proposal to clarify the goal and limitations
of the use of md5 in the security considerations section. what we're
trying to achieve in the DHCID rrs is certainly no stronger than the
'privacy' offered by stateless v6 addresses or rfc3041 addresses. we
aren't really making a 'privacy' claim; there's plenty of other
un-obscured information available in the DNS along with the DHCIDs.
we're only trying to make it difficult to track a DHCP client as it
moves from address to address. md5 makes it more difficult than the
plain-text version of an ethernet MAC address; that's "enough" for our
purpose.

would such a clarification be "enough" to resolve your DISCUSS, Sam
Hartman? that is, if it were clearer that we're only aiming for more
difficult than not difficult at all - would that be sufficiently clear
guidance to admins about what they should expect from this mechanism?

-- Mark


Steven M. Bellovin wrote:

>In message <[hidden email]>, Ted Lemon writes:
>  
>
>>On Saturday 26 November 2005 09:56, Steven M. Bellovin wrote:
>>    
>>
>>>In fact, the Security Considerations section should analyze the
>>>(non-trivial) probability of a brute-force attack.
>>>      
>>>
>>It doesn't matter.   The point of the DHCID is to allow two servers to avoid
>>accidentally stepping on each other.   If you break the DHCID, what you get
>>is the ability to pretend that you are another DHCP client.   If you succeed
>>in doing this, you can take over that DHCP client's name, but you don't get
>>to keep it, because you are using the same identification as the other
>>client, and so it's going to take it back.   The information that you would
>>use to pretend to be the other client is routinely being sent over the
>>network in the clear, so you don't need to break the DHCID to get it - you
>>just need to listen on the wire for a packet from that client.   You can't do
>>the attack I've described unless you are on a network managed by a DHCP
>>server that manages the same namespace as the server that put in the
>>legitimate DHCID.
>>
>>It's true that we could exhaustively go over all possible exploits, no matter
>>how trivial, no matter how useless, in the security considerations section.  
>>Do you honestly believe that this is necessary?
>>
>>    
>>
>It's the privacy aspect I'm concerned about.  The protocol has a
>mechanism -- the hash -- intended to protect privacy.  There are
>limitations to how well it works.  These may be unavoidable; that said,
>they should be documented.  See Section 5 of RFC 3552, a BCP:
>
>   Authors MUST describe
>
>      1.   which attacks are out of scope (and why!)
>      2.   which attacks are in-scope
>      2.1  and the protocol is susceptible to
>      2.2  and the protocol protects against
>
>   ...
>
>   There should be a clear description of the residual risk to the user
>   or operator of that protocol after threat mitigation has been
>   deployed.
>
>Put another way, against a certain grade of attacker the mechanism
>doesn't do its job.  That needs to be documented, so that people who
>are concerned about the issue know to avoid this option.
>
> --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>
>
>
>_______________________________________________
>dhcwg mailing list
>[hidden email]
>https://www1.ietf.org/mailman/listinfo/dhcwg
>
>  
>

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Sam Hartman-5
>>>>> "Mark" == Mark Stapp <[hidden email]> writes:


    Mark> would such a clarification be "enough" to resolve your
    Mark> DISCUSS, Sam Hartman? that is, if it were clearer that we're
    Mark> only aiming for more difficult than not difficult at all -
    Mark> would that be sufficiently clear guidance to admins about
    Mark> what they should expect from this mechanism?

So, as I described in my response to  Russ, I'm asking for three things:

1) algorithm agility

2) Remove the paragraph explaining why md5 is OK or provide a
   theoretical model under which we can reason about how good a hash
   is at keeping stuff private.

3) Use sha-1 or sha-256 instead of md5.


I feel very strongly about point 1.  Unfortunately I think this is the
point the working group most objects to.  I understand the concerns
about the complexity of the update process.  However I also know that
security primitives are things that you need to replace from time to
time.  If you were using md5 because it had a relatively even
distribution of outputs you could probably convince me that you don't
need a way to update it.  However even if weakly you're using md5 for
its cryptographic properties.  Those can change over time so you need
a mechanism to react to those changes.


I suspect we can all agree that we need to either reword claims about
security of cryptographic primitives so they are clearly true or
remove those claims.  So I don't think that we're going to have much
of an issue with point 2.

I think there is room for discussion on point 3.  I think sha-1 or
sha-256 would be a better choice.  I think that there is an argument
that md5 is not so bad that it cannot be used.  If the working group
ends up responding that it would really like to use md5, I can go to
the security community and see what people think there.

--Sam

_______________________________________________
Ietf mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

Re: DHCP and FQDN conflicts [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

David W. Hankins
In reply to this post by Pekka Savola
I haven't seen any replies in this corner of the thread.  Apologies
if this has been covered elsehwere.


On Sat, Nov 26, 2005 at 04:27:27PM +0200, Pekka Savola wrote:
> I have one major issue with 'Resolution of FQDN Conflicts among DHCP
> Clients', the first issue below.  It fails to properly describe the
> threats caused by DHCP clients requesting updating non-DHCP FQDN's
> (like a random host from example.com requesting "www.example.com").
> While this may not be a problem if DHCP clients belong to different
> zones from non-DHCP clients, this is not discussed at all in the
> document -- except ruled out of scope.

The WG felt that it was necessary to include language in the document
that gives implementors freedom to use alternative algorithms.  This
is one such case...where the 'example algorithm' the document set out
to describe handles the condition you describe easily (without a need
for security consideration) because the existence of an A record
without a DHCID results in update failure and the client is given a
unique name instead.

Admittedly, this makes the document 'mosey' a bit.

But it would be foolhardy to ask the authors to document every single
possible security implication of every single possible alternate
algorithm, including the alternative possibilities the WG discussion
asked it to explicitly permit.

I think the security section would rapidly become larger than the
document in total.


Now, perhaps RFCs shouldn't read like "Choose your own Adventure"
novels.

And asking the authors to mud the language to endorse alternative
algorithms was a waste of their time.

Perhaps the document should have documented one algorithm, noted
the possible existence of others only, and continued to document
exactly one algorithm implementing exactly one administrative
policy consistently throughout.

And leave all else to future work.

I seem to recall someone actually saying that in the WG traffic on
the subject.  I think it was the author.  Perhaps we should have
listened, or more of us should have agreed.


Overall, that's probably healthier for the DHCP-accessed dynamic
DNS universe...that the "RFCfoo compliant" text on each product
be the same only on those products that are actually intercompatible,
not merely those who once met the algorithm described in the draft
in a subway.


I've got to agree on this tangent with Pekka here.


> 6.3.2.  DNS UPDATE When FQDN in Use
>
>    2.  A delete of the existing AAAA RRs on the FQDN if the updater does
>        not desire AAAA records on the FQDN or this update is adding an
>        AAAA and the updater only desires a single IP address on the
>        FQDN.
>
> ==> how does the code know whether the updates only desires a single IP
> address on the FQDN or not?   AFAICS, there's no way to signal this from the
> DHCP client!
That's correct, this is the operator's decision, which may be made
for them by software of specific manufacture (or defaults of same).

A system administrator may preside over an array of DHCP clients, let us
imagine, that do not tell the DHCP server to RELEASE their lease prior
to being uncerimoniously removed from the networks to which they are
attached.

In this case, it is desirable for the clients to be treated as though
they only ever have a single address.  The old addresses are stale, and
continued resolution of them in the DNS only produces timeouts (or
failure to operate if the software can't seek to the working address).

A client or server implementation may elect to simply delete all old
A/AAAA records whenever it updates.

Or it may elect to teardown the previous records prior to updating (ISC
DHCP "one-lease-per-client true;" syntax for example).

Or, if it believes both addresses are actually in use or at least leaves
it up to the client to release their leases if they aren't, it can
allow multiple addresses.


So if the 'updater', be that client or server, be that software of ISC
or Kame or Cisco or Nominum manufacture, be that Fred or George's
system, chooses, it can do what it pleases.

>     Through the use of the client
>    FQDN option, DHCP clients and servers can negotiate the client's FQDN
>    and the allocation of responsibility for updating the DHCP client's A
>    and/or AAAA RRs.
>
> ==> also PTR records, not just A/AAAA..

No.  Only A/AAAA.  The PTR is always updated by the server.  Hence
the responsibility of updating the A/AAAA is the only thing that's
negotiated in the FQDN option.

--
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [dhcwg] DHCP and FQDN conflicts [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

Pekka Savola
On Wed, 30 Nov 2005, David W. Hankins wrote:

> On Sat, Nov 26, 2005 at 04:27:27PM +0200, Pekka Savola wrote:
>> I have one major issue with 'Resolution of FQDN Conflicts among DHCP
>> Clients', the first issue below.  It fails to properly describe the
>> threats caused by DHCP clients requesting updating non-DHCP FQDN's
>> (like a random host from example.com requesting "www.example.com").
>> While this may not be a problem if DHCP clients belong to different
>> zones from non-DHCP clients, this is not discussed at all in the
>> document -- except ruled out of scope.
>
> The WG felt that it was necessary to include language in the document
> that gives implementors freedom to use alternative algorithms.  This
> is one such case...where the 'example algorithm' the document set out
> to describe handles the condition you describe easily (without a need
> for security consideration) because the existence of an A record
> without a DHCID results in update failure and the client is given a
> unique name instead.
...
> Now, perhaps RFCs shouldn't read like "Choose your own Adventure"
> novels.
...
> Perhaps the document should have documented one algorithm, noted
> the possible existence of others only, and continued to document
> exactly one algorithm implementing exactly one administrative
> policy consistently throughout.

My problem is that the spec leaves the algorithm completely open.
There is at least one simple algorithm (just blindly update if there's
no DHCID) has severe problems in certain kinds of zones.  This doc
should discourage or disallow that algorithm by default.  As for the
rest, I don't really care (though as a user, it would likely have been
nice if the behaviour between different vendors would have been
consistent, but we aren't going to get that it seems..).

>> 6.3.2.  DNS UPDATE When FQDN in Use
>>
>>    2.  A delete of the existing AAAA RRs on the FQDN if the updater does
>>        not desire AAAA records on the FQDN or this update is adding an
>>        AAAA and the updater only desires a single IP address on the
>>        FQDN.
>>
>> ==> how does the code know whether the updates only desires a single IP
>> address on the FQDN or not?   AFAICS, there's no way to signal this from the
>> DHCP client!
>
> That's correct, this is the operator's decision, which may be made
> for them by software of specific manufacture (or defaults of same).

This is exactly the problem: the software choosing what's best for the
user.

> A system administrator may preside over an array of DHCP clients, let us
> imagine, that do not tell the DHCP server to RELEASE their lease prior
> to being uncerimoniously removed from the networks to which they are
> attached.
>
> In this case, it is desirable for the clients to be treated as though
> they only ever have a single address.  The old addresses are stale, and
> continued resolution of them in the DNS only produces timeouts (or
> failure to operate if the software can't seek to the working address).
>
> A client or server implementation may elect to simply delete all old
> A/AAAA records whenever it updates.

That would be unfortunate.  Wouldn't it be sufficient that the server
removes the DNS records after the lease expires?  Then if the user
doesn't reconnect anywhere else prior to lease expiry, all is cool.

>>     Through the use of the client
>>    FQDN option, DHCP clients and servers can negotiate the client's FQDN
>>    and the allocation of responsibility for updating the DHCP client's A
>>    and/or AAAA RRs.
>>
>> ==> also PTR records, not just A/AAAA..
>
> No.  Only A/AAAA.  The PTR is always updated by the server.  Hence
> the responsibility of updating the A/AAAA is the only thing that's
> negotiated in the FQDN option.

Re-read the spec. The client can tell the server NOT to update the
PTR record, though the spec is written so that the server can update
it anyway if it wants to (a 'MAY').

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
12