Subject: Re: [Ietf-krb-wg] WG Last Call: draft-sakane-dhc-dhcpv6-kdc-option-08

From: Shoichi Sakane <[email-masked]>
Date: Tue, 06 Apr 2010 14:07:00 +0900

Jeff,

Thank you for your comments.  That is very valuable for me, especially
language problem.

On 03/27/2010 08:17 PM, Jeffrey Hutzelman wrote:
> Following are my comments from my review of
> draft-sakane-dhc-dhcpv6-kdc-option-08:

> Note that this document suggests a number of changes, many of which are
> substantive rather than editorial.  Love's example notwithstanding, you
> should not make any of these changes until the WGLC period expires and
> a determination has been made, by Larry or myself, as to whether it is
> appropriate to make each change.

O.K.  I will wait for your decision.  Before that, I want to ask some questions.
There are 3 items that we need a decision.

1-1: Expand "DHCP"

  Jeff>
    Expand "DHCP"

  Shoichi>
    I am not sure whether it is better that the Kerberos option for both DHCPv4
    and DHCPv6 are described in a single document.  Yes, I understand most
    description including the introduction, the behavior of client and server,
    are same.  But, the format of the payload is different.
    I would like to ask to member of the group what we can do.

1-2: prividing an IPv4 address. section 2.2 (KDC Sub-Option)

  Jeff>
    > It is not recommended to provide an IPv4 address.

    Since most Kerberos deployments are currently IPv4-only, I'm not
    convinced this advice is appropriate.  If we believe as a WG that
    this is appropriate, then the phrase "not recommended" should be
    elevated to RFC2119 requirements language (i.e. uppercase), and
    this requirement should be stated separately, rather than as an
    aside to the description of the sub-option length.

  Shoichi>
    If my understanding is correct, it was the consensus of the krb-wg
    meeting in Stockholm.  However, I agree that currently most KDC
    is IPv4-based.  I am fine that the kerberos option for DHCPv6
    can provide any host's information as well as IPv4 address.
    I would like to ask to member of the group what we should do.

1-3: address family: KDC address (variable)

  Jeff> 
    There seems to be no explicit indication of the family of an address;
    instead, the recipient is expected to infer it from the address length.
    This seems brittle, as it assumes no one will wish to run Kerberos on
    a network protocol with 128-bit addresses other than IPv6, or on a
    protocol with 32-bit addresses other than IPv4.  I suggest including
    an explicit address family, perhaps drawn from the existing Address
    Family registry:
    http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml

  Shoichi>
    I wanted such suggestion.  I will add a field of the address family.
    When the field is added, the sub-option will have a 3-octet reserved
    field since the family number is 16-bit long.  Do we accept it ?
    To avoid it, another option would be that we can shorten the number
    to 8-bit from 16-bit.  But, it is backward.

    When we add the field of an address family as is, the message
    structure will be:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         SUB_OPTION_KDC        |          sub-opt-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Priority            |            Weight             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Transport Type|                   Reserved                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Address Family       |          Port Number          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                       KDC address (variable)                  :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Shoichi Sakane <[email-masked]>
Date: Tue, 06 Apr 2010 14:11:11 +0900

Jeff,

One question,

> > Section 3 (Client Operation):

> > The client MAY include the
> > DHCPv6 option number of the Kerberos option in the Option Request
> > Option defined in section 22.7 of RFC 3315 [RFC3315] in the
> > Information-request message.

> Also, we should probably mention that it is also appropriate for a
> client to use a Kerberos option contained in a previous DHCPv6
> response.

I don't understand why the client needs to use a Kerberos option
contained in a previous DHCPv6 response ?  Maybe, I don't share your
assumption.  Could you explain me what is your scenario ?

===
Shoichi Sakane

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 06 Apr 2010 14:24:28 -0400

> assumption.  Could you explain me what is your scenario ?

If a host (DHCP client) used DHCPv6 to obtain network configuration when it 
booted, and received the Kerberos option at that time, there's no need to 
send a separate Information-request message at a later time just to get 
Kerberos configuration.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: KAMADA Ken'ichi <[email-masked]>
Date: Thu, 08 Apr 2010 17:28:23 -0500

I read draft-sakane-dhc-dhcpv6-kdc-option-08.  Two comments
remained after filtering the points already noted by Jeff.

> Intended Status: Informational

The allocation policy for DHCPv6 option codes
<http://www.iana.org/assignments/dhcpv6-parameters/> requires
Standards Action.  Should this I-D be moved onto the standards track
to have OPTION_KRB allocated?

> 6. IANA Considerations

I would recommend consulting RFC 5226 for writing IANA Considerations.
As already pointed out, we need to create "realm-name Flags" and
"Service Type (to be renamed)" registries as well and to define
allocation policies for new registries.

Ken'ichi

---

From: Shoichi Sakane <[email-masked]>
Date: Fri, 09 Apr 2010 11:33:01 +0900

Ken'ichi,

> to have OPTION_KRB allocated?

Thanks for pointing it out.  Personally, I think this document should
be the standard track.   I would like to ask the chairs and member.

> allocation policies for new registries.

I agree with suggestions from Jeff and Ken'ichi.  I will add a text to
the IANA considerations.  I will take "Transport type".

Shoichi

---

From: Shoichi Sakane <[email-masked]>
Date: Fri, 09 Apr 2010 18:26:07 +0900

Hi Ted,

Thanks for these comments.  I will make responses to each issue separately.

On 04/09/2010 01:29 PM, Ted Lemon wrote:
> On Apr 8, 2010, at 6:28 PM, KAMADA Ken'ichi wrote:

Ted @ Fri, 9 Apr 2010 00:29:51 -0400>
> This may not be necessary.   There's been some movement in the
> direction of offering IESG approval as an alternative; the process of
> making that happen hasn't been completed yet, but we're hoping to
> make progress on it in the short term.
> As far as standards track goes, I wouldn't argue against doing
> this as a standards track document if there's demand.

If there is no barrier to deploy this option, I don't care whether
this option is the informational or the standard track.  I still 
need comments.

Shoichi

---

From: Shoichi Sakane <[email-masked]>
Date: Fri, 09 Apr 2010 18:28:48 +0900

> Second, you are using bitfields, and you shouldn't.
> The flag bits issue is perhaps less of a showstopper, but it's
> still generally not done.   Despite the fact that it could 
> potentially waste space, we normally just add bytes to indicate 
> boolean values.   Effectively that's what you're doing here, but
> unless you really anticipate future expansion, I'd just specify the
> possible values for this field as 0 or 1.

We need only one sign for it.  So I can accept your suggestion.

When we make the sub-option to an option there is another approach.
We will have two options and a single container for this purpose.

To be more precise: we need Realm Name Sub-Option, and a sign whether
this is default or not.  So, my idea is to create like Realm Name Option
and Default Realm Name Option.  The benefit is that the structure of
the container for this options could be unified to another option,
Client Principal Name Option.

===
Shoichi Sakane

---

From: Shoichi Sakane <[email-masked]>
Date: Fri, 09 Apr 2010 18:29:52 +0900

> First, you are using suboptions, and you shouldn't.
> Regarding the suboption problem, there is no shortage of option
> codes in DHCPv6, and suboptions are not part of the DHCPv6
> vernacular.   Adding support for suboptions just for Kerberos is a
> bad idea.   This is easy to fix--just get rid of the Kerberos option,
> and make all its suboptions into options.

I knew that there was a guideline related in the past.  There was only
one option for Kerberos in the early stage.  But, we had decided to
provide several information from the DHCP server for Kerberos.
And sometimes a server needs to provide multiple same option.
I was not sure that the DHCPv6 is allowed to do that, which means
a single DHCP message includes more than one option.
So, we decided to create an option and three sub-options.

If the DHCPv6 accepts to do that, it is probably no problem that
we make changes to the options from these sub-options.

===
Shoichi Sakane

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Apr 2010 00:29:51 -0400

> to have OPTION_KRB allocated?

This may not be necessary.   There's been some movement in the direction of offering IESG approval as an alternative; the process of making that happen hasn't been completed yet, but we're hoping to make progress on it in the short term.

As far as standards track goes, I wouldn't argue against doing this as a standards track document if there's demand.

My only comments on the document itself are the obvious ones.   First, you are using suboptions, and you shouldn't.   Second, you are using bitfields, and you shouldn't.   Third, you propose to allow IPv4 addresses, which isn't supported.

This document shouldn't progress without fixing these three problems.

Regarding the suboption problem, there is no shortage of option codes in DHCPv6, and suboptions are not part of the DHCPv6 vernacular.   Adding support for suboptions just for Kerberos is a bad idea.   This is easy to fix--just get rid of the Kerberos option, and make all its suboptions into options.

The flag bits issue is perhaps less of a showstopper, but it's still generally not done.   Despite the fact that it could potentially waste space, we normally just add bytes to indicate boolean values.   Effectively that's what you're doing here, but unless you really anticipate future expansion, I'd just specify the possible values for this field as 0 or 1.

DHCPv6 doesn't support carrying IPv4 addresses, so you can't specify that, and you certainly can't provide IPv4 addresses where IPv6 addresses are expected.   I realize that this seems weird, but think about how a DHCPv6 server or client would parse this: they'd have to have specific code just for the kerberos option, because no other option works this way.   In general, options must not require that the server, and especially the client, implement custom code in order to support them.

One last note: the document talks about how to use the Option Request Option.   This is unnecessary and could potentially create an interoperability problem.   RFC3315 describes the ORO and how to use it.   There is no need to mention it in this document.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Apr 2010 13:43:59 -0400

> Client Principal Name Option.

That sounds like a good solution.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Apr 2010 13:45:02 -0400

> So, we decided to create an option and three sub-options.

DHCPv6 does allow you to send more than one of the same option - there's no option concatenation like in DHCPv4.

---

From: Masahiro =Rhythm Drive= Ishiyama <[email-masked]>
Date: Mon, 12 Apr 2010 15:18:52 +0900

>>>>> On Fri, 9 Apr 2010 13:43:59 -0400, Ted Lemon <[email-masked]> said:
 > 

	How about KDC sub-option? Should it be integrated into
	(Default) Realm Name Option?  Or should we make KDC Option and
	enforce the order of the occurrence of these options?

masahiro

---

From: Masahiro =Rhythm Drive= Ishiyama <[email-masked]>
Date: Wed, 14 Apr 2010 14:47:32 +0900

>>>>> On Mon, 12 Apr 2010 11:26:29 -0400, Ted Lemon <[email-masked]> said:
 > 
 > On Apr 12, 2010, at 2:18 AM, Masahiro =Rhythm Drive= Ishiyama wrote:
 > You can't enforce the order in which options occur.   So if two hunks of data need to be connected, the only way to do it is to put them into the same option.

	So we would like to merge the current Realm Name sub-option
	and KDC sub-option into single (Default) Realm Name
	option. Any comments are appreciated.

masahiro