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

...inline...

At 03:36 PM 4/23/2003 -0400, Thomas Narten wrote:
>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   |
>       +-----+-----+-----+-----+

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 ?

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

OK

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

Yes

>But what about
>packets from spoofed addresses that correspond to DHC server
>addresses?

AFAIK, we are vulnerable.

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

OK

>Thomas

--

Paul Duffy
Cisco Systems, Inc.
paduffy@cisco.com

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg