Subject: [dhcwg] draft-ietf-dhc-pktc-kerb-tckt-01.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 22 Apr 2003 12:41:21 -0400

I've gone ahead and asked for the IETF LC to start for this document.

A few small comments:

>        Code   Len      TCM 
>       +-----+-----+-----+-----+  
>       | TBD |  2  | m1  | m2  | 
>       +-----+-----+-----+-----+

It might be better to not have m1/m2, since the text talks about a
single 16-bit field rather than two smaller fields.
            
>       The length MUST be 2.  The TCM field is encoded as an unsigned 16 
>       bit quantity per network byte-ordering rules.  Each bit of the TCM 

better wording for bit ordering might be:

      The length MUST be 2.  The TCM field is encoded as an unsigned 16 
      bit quantity in network byte order.  Each bit of the TCM

>    5.   IANA Considerations 

what about future assignments of bit values?

>       However, the scenario described above is unlikely to occur.  
>       Within the cable delivery architecture required by the various 
>       CableLabs projects, the DHCP client is connected to a network 
>       through a cable modem and the CMTS (head-end). The CMTS is 
>       explicitly configured with a set of DHCP servers to which DHCP 
>       requests are forwarded.  Further, a correctly configured CMTS 
>       will only allow downstream traffic from specific IP 
>       addresses/ranges. 
  
Could be more clear. I don't follow the last sentence, for example.

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

---

From: Paul Duffy <[email-masked]>
Date: Wed, 23 Apr 2003 15:26:20 -0400

Thanks Thomas...inline please...

>single 16-bit field rather than two smaller fields.

The format is consistent with the formats presented in RFC 3495 (sections 
8.3, 8.4, etc.).  I'm not sure what you are driving at.  Suggestions?

>       bit quantity in network byte order.  Each bit of the TCM

OK...will make that change in next draft.

>what about future assignments of bit values?

Yes, needs to be added.  How about...

"IANA is requested to maintain a new number space of "CableLabs Client 
Configuration Option Ticket Control Mask Bit Definitions", located in the 
BOOTP-DHCP Parameters Registry.  The initial bit definitions are described 
in section 4 of this document.  IANA is requested to register future bit 
mask definitions via an "IETF Consensus" approval policy as described in 
RFC 2434 [add ref}."

>Could be more clear. I don't follow the last sentence, for example.

Last sentence change to...

"Further, the CMTS is explicitly configured to allow downstream traffic 
only from specific IP addresses/ranges."

OK ?

P.S.  Should I hold the next draft until after IESG LC ?

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Wed, 23 Apr 2003 15:36:40 -0400

Hi Paul.

> 8.3, 8.4, etc.).

I guess we need to revise them and republish. :-)

> I'm not sure what you are driving at.  Suggestions?

THis is relatively minor thing, but since the field is 16-byte field,
it seems better to show it that way then to divide it up into
individual bytes.

Just change the picture to something like:
 
       Code   Len      TCM
      | TBD |  2  | TC Mask   |

> mask definitions via an "IETF Consensus" approval policy as described in 

works for me.

> only from specific IP addresses/ranges."

I don't follow the overall discussion to be honest. When clients are
using DHC, they don't have addresses yet. So what addresses are being
filtered? ANd how does this filtering prevent spoofing  of DHC
responses?

Are you saying that the CMTS verifies that all traffic supposedly
coming from a DHC server comes from a proper IP address (i.e., one
assigned ot a server?). That offers some protection. But what about
packets from spoofed addresses that correspond to DHC server
addresses? 

> P.S.  Should I hold the next draft until after IESG LC ?

Sounds reasonable.

Thomas

---

From: Paul Duffy <[email-masked]>
Date: Wed, 23 Apr 2003 15:59:54 -0400

...inline...

>Just change the picture to something like:

I'd much prefer leaving this as it is...its perfectly consistent with its 
parent RFC (3495).  IP addresses are also multi octet quantities...they are 
handled in a similar manner (not lumped into a single field).

OK ?

> > mask definitions via an "IETF Consensus" approval policy as described in

OK

>assigned ot a server?). That offers some protection.

Yes

>But what about

AFAIK, we are vulnerable.

> > P.S.  Should I hold the next draft until after IESG LC ?

OK

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Bud Millwood <[email-masked]>
Date: Mon, 28 Apr 2003 10:55:05 +0200

> > >single 16-bit field rather than two smaller fields.

FWIW, I agree with Thomas. I think it's just misleading to have it split if 
it's a 16 bit field. The picture above implies a struct with two bytes, and 
some need to work with the bytes separately.

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
mailto:[email-masked]

---

From: Paul Duffy <[email-masked]>
Date: Mon, 28 Apr 2003 10:17:18 -0400

Bud and all,

Am I missing something here?  If so, please set me straight...

1. RFC 2132 (options 24, 26, 35, 51, etc.) uses the same convention.

2. RFC 3495, which was approved by this group not two months ago,  is using 
this same convention (in multiple locations).  How did this convention fall 
out of favor in the last two months?

3. Given that RFC 3495 employs this convention, and given that this draft 
is a follow-on addition to 3495 (i.e. it will be implemented by all who are 
currently implementing 3495), I do not want to change conventions unless 
absolutely necessary.

???

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: Bud Millwood <[email-masked]>
Date: Mon, 28 Apr 2003 19:05:49 +0200

On Monday 28 April 2003 16.38, you wrote:

> >FWIW, I agree with Thomas. I think it's just misleading to have it split
> > if it's a 16 bit field. The picture above implies a struct with two
> > bytes, and some need to work with the bytes separately
>
> RFC 2132 uses the format used above repeatedly.   Maybe that is worth
> revisiting, but I don't think this draft should wait for such a debate
> to reach concensus.

Agreed. I never reflected on it in 2132. And I can't say I expected the 
discussion about it to last this long. :)

- Bud

Bud Millwood
Weird Solutions, Inc.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 29 Apr 2003 08:34:01 -0400

I agree with Paul, here.  The current diagram is consistent
in format with the earlier RFCs Paul cites.

- Ralph

At 10:17 AM 4/28/2003 -0400, Paul Duffy wrote:
>2. RFC 3495, which was approved by this group not two months ago,  is using this same convention (in multiple locations).  How did this convention fall out of favor in the last two months?
>
>3. Given that RFC 3495 employs this convention, and given that this draft is a follow-on addition to 3495 (i.e. it will be implemented by all who are currently implementing 3495), I do not want to change conventions unless absolutely necessary.
>
>???
>

---

From: Christopher Zydel <[email-masked]>
Date: Mon, 28 Apr 2003 10:38:03 -0400

Bud Millwood wrote:

>some need to work with the bytes separately
>

Chris