Pekka Savola | 1 Dec 14:00 2005
Picon

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

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 
(Continue reading)

Bernie Volz (volz | 1 Dec 14:31 2005
Picon

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

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

The "N" bit is used by a client to request that the server *NOT* perform
any updates on its behalf. That is AAAA *AND* PTR.

   The "N" bit indicates whether the server SHOULD NOT perform any DNS
   updates.  A client sets this bit to 0 to request that the server
   SHOULD perform updates (the PTR RR and possibly the AAAA RR based on
   the "S" bit) or to 1 to request that the server SHOULD NOT perform
   any DNS updates.  A server sets the "N" bit to indicate whether the
   server SHALL (0) or SHALL NOT (1) perform DNS updates.  If the "N"
   bit is 1, the "S" bit MUST be 0.

The idea here was that there may be clients that don't want anything in
the DNS and this is a way they can request this. This is not negotiating
(Continue reading)

Bernie Volz (volz | 1 Dec 14:48 2005
Picon

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

How about we address issue 1 by expanding the DHCID RR type code. We
have 16-bits and we're just using 4 values presently. There's plenty of
room for future expansion *SHOULD* someone come along and demand a new
algorithm in the future. I can't see why this would EVER occur since
this really isn't about strong cryptographic protection (we're just
trying to make it non-trivial to find a client's identity by not storing
it in clear text).

In the -10 draft, Section 3.3 is:

3.3.  The DHCID RR Type Codes

   The DHCID RR Type Code specifies what data from the DHCP client's
   request was used as input into the hash function.  The type codes are
   defined in a registry maintained by IANA, as specified in Section 7.
   The initial list of assigned values for the type code is:

   0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7].
   0x0001 = The data portion from a DHCPv4 client's Client Identifier
      option [9].
   0x0002 = The client's DUID (i.e., the data portion of a DHCPv6
      client's Client Identifier option [10] or the DUID field from a
      DHCPv4 client's Client Identifier option [12]).

   0x0003 - 0xfffe = Available to be assigned by IANA.

   0xffff = RESERVED

---

(Continue reading)

David W. Hankins | 1 Dec 18:29 2005

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

On Thu, Dec 01, 2005 at 03:00:49PM +0200, Pekka Savola wrote:
> On Wed, 30 Nov 2005, David W. Hankins wrote:
> >Now, perhaps RFCs shouldn't read like "Choose your own Adventure"
> >novels.
> 
> 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..).

I think we should take this one back to the WG.  Find out how many
algorithms there are which people actually want to use, within each
how many "administrative policies" there are (and name them all), and
who is interested in each one (more importantly, which One Bernie still
has the strength to document, if any).

Split up and go our separate ways, make new documents for the
additional algorithms (or don't if the interested parties don't
feel a need to).

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

Welcome to DHCP?  I'm sorry, that wasn't fair.
(Continue reading)

Hallam-Baker, Phillip | 1 Dec 20:31 2005
Picon

RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]


> From: Sam Hartman [mailto:hartmans-ietf <at> mit.edu] 

> >>>>> "Ted" == Ted Lemon <Ted.Lemon <at> nominum.com> writes:
> 
>     Ted> On Monday 28 November 2005 20:00, Hallam-Baker, Phillip
>     Ted> wrote:
>     >> OK so why are you proposing a new protocol rather than writing
>     >> a description of the protocols that are already in use?
> 
>     Ted> It's inconvenient to use TXT records, because they are not
>     Ted> specific to the purpose.  If the user wants TXT records on
>     Ted> the name for some *other* purpose than marking the name with
>     Ted> a DHCID, it doesn't work.
> 
> Phil is suggesting something like _dhcid.domain .

My criteria here are that the DNS should support an extension mechanism
that allows the definition of new records at will without the need to
deploy ANY new code at either the client or the server.

Unless wildcards are required the prefix mechanism described in the SRV
rfc allows the existing deployed DNS to be extended without the need for
new code deployment. 

In the cases where wildcards are required for administrative convenience
the semantics of the DNS wildcard mechanism do not meet the use cases
that were described in MARID in any case.

What I suggest is a scheme where we regard the RR type as a means of
(Continue reading)

Ted Lemon | 1 Dec 21:57 2005

Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]

On Thursday 01 December 2005 12:31, Hallam-Baker, Phillip wrote:
> My criteria here are that the DNS should support an extension mechanism
> that allows the definition of new records at will without the need to
> deploy ANY new code at either the client or the server.

Right, we have that.   It's called the RRtype.   Many, many type codes are 
available.  Requiring the use of additional labels and not taking advantage 
of the very nice DNS update prerequisite support because someone doesn't want 
to support transparent addition of RRtypes is pathetic.   We've had the 
capacity to extend option codes in every DHCP server (as well as most 
clients) in existence practically since day one, and that's a much more 
complicated problem than handling new RRtypes.

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

Hallam-Baker, Phillip | 1 Dec 22:54 2005
Picon

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


> -----Original Message-----
> From: Ted Lemon [mailto:Ted.Lemon <at> nominum.com] 
> Sent: Thursday, December 01, 2005 3:58 PM
> To: Hallam-Baker, Phillip
> Cc: Sam Hartman; namedroppers <at> ops.ietf.org; Bernie Volz 
> (volz); ietf <at> ietf.org; iesg <at> ietf.org; dhcwg <at> ietf.org; Steven 
> M. Bellovin; Pekka Savola
> Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last 
> Call:'Resolution ofFQDN Conflicts among DHCP Clients' to 
> ProposedStandard]
> 
> On Thursday 01 December 2005 12:31, Hallam-Baker, Phillip wrote:
> > My criteria here are that the DNS should support an extension 
> > mechanism that allows the definition of new records at will without 
> > the need to deploy ANY new code at either the client or the server.
> 
> Right, we have that.   It's called the RRtype.   Many, many 
> type codes are 

NO YOU DO NOT

The majority of the deployed DNS infrastructure does not have the
ability to service new RRs.

The opposite claim has been advanced on several occasions but it is
untrue. There is NO version of the Windows DNS server capable of
PRODUCTION publication of new DNS RRs. A registry hack that does not
survive a reboot does not count. Microsoft has shown the actual DNS code
for saving a zone file, new RRs are simply not handled.
(Continue reading)

Douglas Otis | 1 Dec 23:55 2005

Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]


On Dec 1, 2005, at 11:31 AM, Hallam-Baker, Phillip wrote:

> A much better way to solve this problem is to introduce a pointer RR
> that obeys the semantics of *.example.com or #.example.com the same as
> any other non-prefixed pointer. The resolution process for a prefixed
> record then becomes :
>
> 1) record = resolve ("_prefix.example.com", {TXT, SRV, ...})
> 	if record != null return 'found'
> 2) pointer = resolve (example.com, PTR)
> 	if record == null return 'not found'
> 3) record = resolve ("_prefix." + pointer, {TXT, SRV, ...})
> 	if record != null return 'found' else return 'not found'
>
> This scheme also provides an additional management advantage,  
> instead of
> configuring policy for each machine individually I can define  
> different
> policy classes as needed and assign that policy to a particular  
> machine
> by specifying the corresponding pointer, eg:
>
> _dkim.servers.example.com     TXT "DKIM policy for servers"
> _yaddis.servers.example.com   TXT "Policy for YADDIS"
> _dkim.desktop.example.com     TXT "DKIM policy for desktops"

This approach would create several challenges.  With respect to  
DNSsec, additional lookups will be required to investigate above the  
set of PTR RRs, in addition to obtaining the PTR RRs.  Even with  
(Continue reading)

Mark Andrews | 2 Dec 00:23 2005

Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]


>  
> 
> > -----Original Message-----
> > From: Ted Lemon [mailto:Ted.Lemon <at> nominum.com] 
> > Sent: Thursday, December 01, 2005 3:58 PM
> > To: Hallam-Baker, Phillip
> > Cc: Sam Hartman; namedroppers <at> ops.ietf.org; Bernie Volz 
> > (volz); ietf <at> ietf.org; iesg <at> ietf.org; dhcwg <at> ietf.org; Steven 
> > M. Bellovin; Pekka Savola
> > Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last 
> > Call:'Resolution ofFQDN Conflicts among DHCP Clients' to 
> > ProposedStandard]
> > 
> > On Thursday 01 December 2005 12:31, Hallam-Baker, Phillip wrote:
> > > My criteria here are that the DNS should support an extension 
> > > mechanism that allows the definition of new records at will without 
> > > the need to deploy ANY new code at either the client or the server.
> > 
> > Right, we have that.   It's called the RRtype.   Many, many 
> > type codes are 
> 
> NO YOU DO NOT
> 
> The majority of the deployed DNS infrastructure does not have the
> ability to service new RRs.

	Actually the majority of DNS servers are capable of handling
	unknown RRs as are the majority of client resolver libraries.

(Continue reading)

rfc-editor | 2 Dec 03:10 2005

RFC 4280 on Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers


A new Request for Comments is now available in online RFC libraries.

        RFC 4280

        Title:      Dynamic Host Configuration Protocol (DHCP) Options
                    for Broadcast and Multicast Control Servers
        Author(s):  K. Chowdhury, P. Yegani, L. Madour
        Status:     Standards Track
        Date:       November 2005
        Mailbox:    kchowdhury <at> starentnetworks.com, pyegani <at> cisco.com,
                    Lila.Madour <at> ericsson.com
        Pages:      11
        Characters: 23001
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-dhc-bcmc-options-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4280.txt

This document defines new options to discover the Broadcast and
Multicast Service (BCMCS) controller in an IP network.  BCMCS is
being developed for Third generation (3G) cellular telephone
networks.  Users of the service interact with a controller in the
network via the Mobile Node (MN) to derive information required to
receive Broadcast and Multicast Service.  Dynamic Host Configuration
Protocol can be used to configure the MN to access a particular
controller.  This document defines the related options and option
codes.

(Continue reading)


Gmane