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

Hi Paul.

> > >        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 format is consistent with the formats presented in RFC 3495 (sections 
> 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   |
      +-----+-----+-----+-----+

> > >    5.   IANA Considerations
> >
> >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}."

works for me.

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

> Last sentence change to...

> "Further, the CMTS is explicitly configured to allow downstream traffic 
> 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
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg