headers
Ralph Droms | 2 Jul 2005 00:30
Picon
Favicon

Re: Abuse of the Preference option

Bud - by "abuses", do you mean, for example, a DoS attack by a rogue
DHCPv6 server?  

- Ralph

On Wed, 2005-06-29 at 14:08 +0200, Bud Millwood wrote:
> Has there been any discussion of possible abuses of the preference option 
> described in RFC 3315?
> 
> If a client is *required* to ignore other advertisements when a particular 
> advertisement has preference 255, doesn't this undermine a DHCP client's 
> ability to possibly make a more informed decision about which advertisement 
> to go with? Shouldn't the "preference" option be just that, a preference?
> 
> - Bud
> 
> Bud Millwood
> Weird Solutions, Inc.
> http://www.weird-solutions.com
> tel: +46 8 758 3700
> fax: +46 8 758 3687
> mailto:budm <at> weird-solutions.com
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
Permalink | Reply | 1 comment |
headers
C. M. Heard | 3 Jul 2005 23:46
Picon
Favicon

Re: I-D ACTION:draft-raj-dhc-tftp-addr-option-01.txt

On Thu, 30 Jun 2005 Internet-Drafts <at> ietf.org wrote:
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> 
> 
> 	Title		: TFTP Server Address DHCP Option
> 	Author(s)	: R. Johnson
> 	Filename	: draft-raj-dhc-tftp-addr-option-01.txt
> 	Pages		: 7
> 	Date		: 2005-6-30
> 	
> This memo defines the "TFTP Server Address" option as it is currently
>    in use by Cisco Systems.  The option number currently in use is 150.
>    This memo documents the current usage of the option in agreement with
>    RFC-3942 [7] , which declares that any pre-existing usages of option
>    numbers in the range 128 - 223 should be documented and the working
>    group will try to officially assign those numbers to those options.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-raj-dhc-tftp-addr-option-01.txt

The option described in this draft is not necessary, as the same
functionality has historically been provided by the 'siaddr' field
in DHCPOFFER/DHCPACK/BOOTREPLY messages.  One is therefore led to
question whether it is a good idea to permanently consume an option
code for this purpose.

At the very least, the documentation should point out that the
'siaddr' field is used for the same purpose as the option and should
provide recommendations on how to prevent/deal with conflicts.
(Continue reading)

Permalink | Reply | 0 comments |
headers
haoda | 5 Jul 2005 08:30

Release message in the exchange of Decline messages

Hi, everyone.

I want to confirm why the Release message be in the exchange 
of Decline messages.

Here is a diggest from the original text of RFC3315.  [Page 54]
======================================================
>18.2.7. Receipt of Decline Messages
>
>......
>   After all the addresses have been processed, the server generates a
>   Reply message and includes a Status Code option with the value
>  Success, a Server Identifier option with the server's DUID, and a
>   Client Identifier option with the client's DUID.  For each IA in the
>  Decline message for which the server has no binding information, the
>   server adds an IA option using the IAID from the Release message and
>  includes a Status Code option with the value NoBinding in the IA
>   option.  No other options are included in the IA option.
>   ....... 

Please notice this line,
>                                                      ......
the
>   server adds an IA option using the IAID from the Release message and

=======
>   includes a Status Code option with the value NoBinding in the IA
>   option.

At here, the IAID comes from the Release message!  But I think there is no
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stig Venaas | 5 Jul 2005 10:49
Picon
Picon

Re: Release message in the exchange of Decline messages

On Tue, Jul 05, 2005 at 03:30:23PM +0900, haoda wrote:
> Hi, everyone.
> 
> I want to confirm why the Release message be in the exchange 
> of Decline messages.
> 
> Here is a diggest from the original text of RFC3315.  [Page 54]
> ======================================================
> >18.2.7. Receipt of Decline Messages
> >
> >......
> >   After all the addresses have been processed, the server generates a
> >   Reply message and includes a Status Code option with the value
> >  Success, a Server Identifier option with the server's DUID, and a
> >   Client Identifier option with the client's DUID.  For each IA in the
> >  Decline message for which the server has no binding information, the
> >   server adds an IA option using the IAID from the Release message and
> >  includes a Status Code option with the value NoBinding in the IA
> >   option.  No other options are included in the IA option.
> >   ....... 
> 
> Please notice this line,
> >                                                      ......
> the
> >   server adds an IA option using the IAID from the Release message and
>  
> =======
> >   includes a Status Code option with the value NoBinding in the IA
> >   option.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bud Millwood | 5 Jul 2005 10:06

Re: Abuse of the Preference option

Yep, that's what I was thinking.

I'm not entirely sure what criteria a client could use when deciding to drop 
an ADV msg where pref=255, but if the "lock-in" behavior is not specified, at 
least a client is free to find creative ways of detecting illicit lock-in.

What's the impetus for specifying this behavior?

- Bud

On Saturday 02 July 2005 00:30, Ralph Droms wrote:
> Bud - by "abuses", do you mean, for example, a DoS attack by a rogue
> DHCPv6 server?
>
> - Ralph
>
> On Wed, 2005-06-29 at 14:08 +0200, Bud Millwood wrote:
> > Has there been any discussion of possible abuses of the preference option
> > described in RFC 3315?
> >
> > If a client is *required* to ignore other advertisements when a
> > particular advertisement has preference 255, doesn't this undermine a
> > DHCP client's ability to possibly make a more informed decision about
> > which advertisement to go with? Shouldn't the "preference" option be just
> > that, a preference?
> >
> > - Bud
> >
> > Bud Millwood
> > Weird Solutions, Inc.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernie Volz (volz | 5 Jul 2005 19:37
Picon
Favicon

RE: Release message in the exchange of Decline messages

This is obviously a typo. It should be "Decline" message.

The text for the two sections is essentially identical, and this just
was missed in the reviews.

- Bernie 

> -----Original Message-----
> From: dhcwg-bounces <at> ietf.org [mailto:dhcwg-bounces <at> ietf.org] 
> On Behalf Of haoda
> Sent: Tuesday, July 05, 2005 2:30 AM
> To: dhcwg <at> ietf.org
> Subject: [dhcwg] Release message in the exchange of Decline messages
> 
> Hi, everyone.
> 
> I want to confirm why the Release message be in the exchange 
> of Decline messages.
> 
> Here is a diggest from the original text of RFC3315.  [Page 54]
> ======================================================
> >18.2.7. Receipt of Decline Messages
> >
> >......
> >   After all the addresses have been processed, the server 
> generates a
> >   Reply message and includes a Status Code option with the value
> >  Success, a Server Identifier option with the server's DUID, and a
> >   Client Identifier option with the client's DUID.  For 
> each IA in the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stig Venaas | 5 Jul 2005 20:36
Picon
Picon

Re: Release message in the exchange of Decline messages

On Tue, Jul 05, 2005 at 01:37:47PM -0400, Bernie Volz (volz) wrote:
> This is obviously a typo. It should be "Decline" message.
> 
> The text for the two sections is essentially identical, and this just
> was missed in the reviews.

Perhaps we should post this in the RFC errata? Might help us remember
fixing this if/when updating 3315 too.

Stig

> 
> - Bernie 
> 
> > -----Original Message-----
> > From: dhcwg-bounces <at> ietf.org [mailto:dhcwg-bounces <at> ietf.org] 
> > On Behalf Of haoda
> > Sent: Tuesday, July 05, 2005 2:30 AM
> > To: dhcwg <at> ietf.org
> > Subject: [dhcwg] Release message in the exchange of Decline messages
> > 
> > Hi, everyone.
> > 
> > I want to confirm why the Release message be in the exchange 
> > of Decline messages.
> > 
> > Here is a diggest from the original text of RFC3315.  [Page 54]
> > ======================================================
> > >18.2.7. Receipt of Decline Messages
> > >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernie Volz (volz | 5 Jul 2005 20:46
Picon
Favicon

RE: Release message in the exchange of Decline messages

Is there such a thing?

I've been keeping a mail folder of issues that we'll need to address in
any 3315-bis type document as we advance that work to full standard?

- Bernie 

> -----Original Message-----
> From: Stig Venaas [mailto:Stig.Venaas <at> uninett.no] 
> Sent: Tuesday, July 05, 2005 2:37 PM
> To: Bernie Volz (volz)
> Cc: haoda; dhcwg <at> ietf.org
> Subject: Re: [dhcwg] Release message in the exchange of 
> Decline messages
> 
> On Tue, Jul 05, 2005 at 01:37:47PM -0400, Bernie Volz (volz) wrote:
> > This is obviously a typo. It should be "Decline" message.
> > 
> > The text for the two sections is essentially identical, and 
> this just
> > was missed in the reviews.
> 
> Perhaps we should post this in the RFC errata? Might help us remember
> fixing this if/when updating 3315 too.
> 
> Stig
> 
> > 
> > - Bernie 
> >
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stig Venaas | 5 Jul 2005 20:51
Picon
Picon

Re: Release message in the exchange of Decline messages

On Tue, Jul 05, 2005 at 02:46:16PM -0400, Bernie Volz (volz) wrote:
> Is there such a thing?

Check http://www.rfc-editor.org/cgi-bin/errata.pl

I think this is a good place to put such unless the errors are truly
trivial.

> I've been keeping a mail folder of issues that we'll need to address in
> any 3315-bis type document as we advance that work to full standard?

Yes, that's the alternative. It's good if we as a wg can have a
collective list of such. It's useful to implementors if this list
is public though.

Stig

> 
> - Bernie 
> 
> > -----Original Message-----
> > From: Stig Venaas [mailto:Stig.Venaas <at> uninett.no] 
> > Sent: Tuesday, July 05, 2005 2:37 PM
> > To: Bernie Volz (volz)
> > Cc: haoda; dhcwg <at> ietf.org
> > Subject: Re: [dhcwg] Release message in the exchange of 
> > Decline messages
> > 
> > On Tue, Jul 05, 2005 at 01:37:47PM -0400, Bernie Volz (volz) wrote:
> > > This is obviously a typo. It should be "Decline" message.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stig Venaas | 6 Jul 2005 21:25
Picon
Picon

dhc WG last call on <draft-ietf-dhc-dhcpv6-subid-00.txt>

This message announces a WG last call on "DHCPv6 Relay Agent
Subscriber-ID Option" <draft-ietf-dhc-dhcpv6-subid-00.txt>.
The last call will conclude at 1700 EST (USA) on 2005-07-20.

Please respond to this WG last call.  If you support
acceptance of the document without change, respond with a
simple acknowledgment, so that support for the document can
be assessed.  Lack of discussion does not represent positive
support.  If there is no expression of support for
acceptance during the WG last call, the document will not be
advanced to the IESG.

The draft draft-ietf-dhc-dhcpv6-subid-00.txt defines a new
Relay Agent Subscriber-ID option for DHCPv6.  The option
allows a DHCPv6 relay agent to associate a stable
"Subscriber-ID" with DHCPv6 client messages in a way that is
independent of the client and of the underlying physical
network infrastructure.  The draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-subid-00.txt

Stig Venaas
Permalink | Reply | 1 comment |

Gmane