Re: [Question]Is this behavior of the Reconfigure Key Authentication Protocol correct?

Hideshi-san - Your observaation is correect: the authentication key for
reconfiguration assumes that the key cannot be intercepted and used for
sending malicious Reconfigure messages.

- Ralph

On 3/10/06 7:09 AM, "Hideshi Enokihara" <Hideshi.Enokihara <at> jp.yokogawa.com>
wrote:

> Hi all,
> 
> I have some questions regarding Reconfigure Key Authentication Protocol.
> 
> Is this behavior(like following) of the Reconfigure Key Authentication
> Protocol correct?
> ---------------------------------
> 
>        Server  Client
>         |       |
>         |       |
>         | <---- | Solicit
>         | ----> | Advertise
>         | <---- | Request with Reconfigure Accept Option
>         | ----> | Reply with Reconfigure Accept Option
>         |       |       and Authentication Option  (*1)
>         |       |
>         |       |
>         | ----> | Reconfigure with comptuted Authentication (*2)
>         | <---- | Renew or Information-Request (*3)
>         |       |  (depend on Reconfigure message's(*2's) msg-type)

Re: draft-forte-dhc-passive-dad-01

Hi Andrea,

Andrea G Forte wrote:
> Greg,
> 
> please read answers inline.
> 
>> Sorry about the delay in replying.
> No problem at all. I was at the IETF meeting in Dallas.
 > Where you there as well? I would have liked to have your
 > feedback at the meeting after the presentation.

Sorry I couldn't come, my work is less focussed on IPv6
configuration at the moment.

>> Please be aware that the delays for link-local address
>> configuration will not be curtailed for this system,
>> as a link-local address is required to form a DHCP message.
>> For those addresses Optimistic DAD is still needed.
> We never intended pDAD to be a replacement for Optimistic DAD.
> pDAD is meant to address the DAD problem in IPv4 networks. We just 
> wanted to mention that perhaps it could be useful in IPv6 networks as 
> well (with all the limitations we discussed).

Certainly. Sorry I didn't provide feedback earlier about which
limitations are likely to be considered important.

> One thing I wanted to ask you about your last point is that apparently a 
> link-local address would be created mainly according to the client 
> unique ID. Another alternative would be to use something else like a 

Re: [Question]Is this behavior of the Reconfigure Key Authentication Protocol correct?

Hello Mr. Ralph Droms,

Thank you for your reply.

I could get correct understanding.

Best Regards,
On Sat, 1 Apr 2006 09:33:47 +0900
"Ralph Droms" <rdroms <at> cisco.com> wrote:

> Re: [dhcwg] [Question]Is this behavior of the Reconfigure Key Authentication Protocol correct?
> 
> Hideshi-san - Your observaation is correect: the authentication key for
> reconfiguration assumes that the key cannot be intercepted and used for
> sending malicious Reconfigure messages.
> 
> - Ralph
> 
> 
> On 3/10/06 7:09 AM, "Hideshi Enokihara" <Hideshi.Enokihara <at> jp.yokogawa.com>
> wrote:
> 
> > Hi all,
> >
> > I have some questions regarding Reconfigure Key Authentication Protocol.
> >
> > Is this behavior(like following) of the Reconfigure Key Authentication
> > Protocol correct?
> > ---------------------------------
> >

Timezones again.

First, on the subject of "imagined clients."

In the past week and change, I've been talking on this subject with
anyone who will listen.  I've been told I'm out of touch with users
needs by at least one individual, and that's not an acceptable thing
to even question.  Certainly, I am not unbiased on the subject.

I've talked with Jason Vas Dias who works on DHCP software distribution
stuff at Redhat (but his views aren't necessarily those of his
employer's).  He imparted to me a story that, in his corner of the
world, the TZ database did not have what he needed.  To get the correct,
current wall-clock time on their DHCP-connected systems, they actually
did use the time offset option (code 2) (hacking ISC "dhclient-script"
to do so) to set the wall clock.  This was done combining a fixed offset
from UTC TZ database entry, and using the time-offset field as a server-
supplied means of determining what he called "the political timezone."
This worked, because the DHCP server could be reconfigured with the
correct political time offset when the correct time to do so transpires
...and lease expiration timers could be reduced in advance so that
clients renewed their bindings shortly thereafter.

I've also talked with Mark Andrews, who after returning to Australia
after IETF 65 found himself in a taxi cab on the way home.  His
cell phone, his taxi driver, and his wife all disagreed on what the
correct local time was.  All because DST had been delayed a week due
to a game (cricket, I think).  The TZ database on his laptop would
also have had the wrong local wall-clock time, and that this would
have been an undesirable third false indicator.

I've also talked with a few Unix systems administrators, and no, they

draft-dhankins-pxelinux-00

draft-dhankins-pxelinux-00.txt, describing the once-site-local options
currently in use by the PXELinux bootloader is now available:

	http://www.ietf.org/internet-drafts/draft-dhankins-pxelinux-00.txt

Your comments will be wrapped in gossamer ribbons and cherished upon
the mantlepiece of my home.

OK not really.

This is a stake in the sand.  I want some feedback on what to do with one
of the options if you care to have an opinion.

--

-- 
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
dhcwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

Re: Timezones again.

Forgive me for giving you a pithy one-paragraph response, David, but it sounds 
llike the status quo (time zone offset) is actually perfectly fine for you, 
and that you do not need this new option we're discussing.  I realize, 
though, that that's not what you actually said.   Is there any truth to this 
conjecture of mine?

Re: Timezones again.

On Mon, Apr 10, 2006 at 03:56:04PM -0700, Ted Lemon wrote:
> Forgive me for giving you a pithy one-paragraph response, David, but it sounds 
> llike the status quo (time zone offset) is actually perfectly fine for you, 
> and that you do not need this new option we're discussing.  I realize, 
> though, that that's not what you actually said.   Is there any truth to this 
> conjecture of mine?

The status quo is actually perfectly fine for Jason Vas Dias, in DHCPv4
(he even said that).

I think the options suggested by Elliot provide some utility for people
who are not Jason but would also cover his needs and also be more
complete (rather than merely being the hammer he happened to have in his
toolbox at the time, and has now grown inseparable from).

You see, any new option, no matter what we do, will be work for him to
adopt.  He's busy enough as it is.

So the lack of status quo in DHCPv6 is again defined as the primary
problem.

But, hypothetically, if we were designing protocol for Jason's set of
problems as being representative of the majority of clients needs, then
Ralph's original draft is provably an adequate solution.

I think Elliot explicitly stipulates that there is a larger problem
set to solve for, that we can do better than merely adequate, and
that's where we're getting hung up.

--

-- 

Re: Timezones again.

On Apr 10, 2006, at 6:56 PM, Ted Lemon wrote:

> Forgive me for giving you a pithy one-paragraph response, David, but 
> it sounds
> llike the status quo (time zone offset) is actually perfectly fine for 
> you,
> and that you do not need this new option we're discussing.  I realize,
> though, that that's not what you actually said.   Is there any truth 
> to this
> conjecture of mine?

Although I will not presume to speak for David about his lack of need, 
I will note that he described different needs and objected to the 
suggestion that his clients are imaginary.

There are at least 3 issues that seem to be entangled tangled here.  
(1) The existing time offset (RFC 2131, option 2) lacks automatic 
changes at occasional times for the (horrible) Daylight Saving 
adjustment.  (2) The TZ database provides lots of historical 
information for hosts that have it (up to date) and lack only the name 
of the entry for where they are.  (3) Different options or sub-options 
of a new multi-purpose option could address issues 1 & 2.

IMHO assertions that all hosts need the name of the time-zone, either 
daylight-saving or otherwise overstates the requirement.  David 
provided examples where clients need just correct wall-clock time.  Of 
all the computers in my house (or pocket), only those with 
general-purpose operating systems bother with this - those with just 
radios, CD players, and/or telephone functions present just the time, 

Re: Timezones again.

On Monday 10 April 2006 16:59, John Schnizlein wrote:
> Although I will not presume to speak for David about his lack of need,
> I will note that he described different needs and objected to the
> suggestion that his clients are imaginary.

I won't quote your whole summary, but I think I agree completely both with the 
conclusion you've come to, and the reasons you stated for coming to it.   It 
does indeed sounds like David's needs are fully addressed by the POSIX 
option, and that, based on the needs expressed, he would never need to 
implement the TZ option.

Re: Timezones again.

On Mon, Apr 10, 2006 at 05:39:07PM -0700, Ted Lemon wrote:
> I won't quote your whole summary, but I think I agree completely both with the 
> conclusion you've come to, and the reasons you stated for coming to it.   It 
> does indeed sounds like David's needs are fully addressed by the POSIX 
> option, and that, based on the needs expressed, he would never need to 
> implement the TZ option.

I thought I typed 'in the absence of'.  I can't include the entire
discussion from each of them, I tried to cover the highlights, the gist
of the spectrum, and then summarize the consensus of all parties.  The
compromise that meets all their needs.

So:

- Some clients will exist for which, when POSIX is available but TZ is not,
  would prefer to use POSIX rather than nothing at all (but normally would
  prefer TZ).  Think North America, although less so these days, or any
  environment where 'political time zone' is not at the whim of some
  uncontrollable, chaotic, random event: TZ will generally be correct, and
  preferred, POSIX in the absence of TZ (or in the case where it is somehow
  provably inaccurate for wall clock time) is a desirable fall-back position.

- Some clients will exist for which, when TZ is available but POSIX is not,
  would prefer to use TZ rather than nothing at all (but normally would
  prefer to use POSIX because TZ is almost never correct).  I don't actually
  know what geopolitical sphere Jason is operating in, but I imagine he is
  not alone.  Mark Andrews, for example, lives in an environment where
  'political time zone' was decided by wether or not a game had finished.
  TZ in the absence of POSIX is a desirable fall-back position.