IP over Cable Data Network (ipcdn)

Woundy, Richard | 13 Apr 2002 03:48

Picon

IPCDN meeting minutes from Minneapolis

Folks,

Below are the meeting minutes for the IPCDN WG meeting in Minneapolis held
on March 19, 2002.

-- Rich

IETF IPCDN Meeting 
Minneapolis, Minnesota USA 
March 19, 2002

Reported by Jason Schnitzer (jason <at> stargus.com)

Administrative Items

- Andrew Valentine stepped down as co-chair due to a career change.
- Rich Woundy moved from Cisco to AT&T Broadband.
- A new co-chair position is under discussion.
- Meeting attendees engaged in a discussion over the relationship between
IPCDN internet drafts and CableLabs DOCSIS specification references.
CableLabs often mandates the implementation of obsolete IDs out of necessity
to "freeze" DOCSIS OSS MIB specifications for testing and certification
purposes. As a result, CableLabs often certifies CMTS and CM devices against
obsolete IPCDN MIB IDs. Is there a practical way to synchronize? It was
proposed by Thomas Narten (IESG area advisor) that stable MIB IDs be
released as informative or experimental RFCs for CableLabs certification
reference. Early help from IETF MIB doctors on new IPCDN MIBs might ease the
transition as well.
- Question: should the "Account Management" section of the DOCSIS OSS
specification be moved to the IETF IPCDN space for future work? Much of this

(Continue reading)

Woundy, Richard | 18 Apr 2002 18:04

Picon

DOCSIS IGMPv2 MIB

Folks,

I have received no further comments on the draft, "Application of the IGMP
MIB, RFC 2933, and Cable Device MIB, RFC 2669, to DOCSIS 1.1 Devices",
draft-ietf-ipcdn-igmp-mib-03.txt.

I am asking the area directors to forward the document to the IESG for
publication as an RFC with status of Proposed Standard.

-- Rich

Woundy, Richard | 18 Apr 2002 18:04

Picon

DOCSIS Subscriber Management MIB

Folks,

I have received no further comments on the draft, "Management Information
Base for DOCSIS Cable Modem Termination Systems for Subscriber Management",
draft-ietf-ipcdn-subscriber-mib-06.txt.

I am asking the area directors to forward the document to the IESG for
publication as an RFC with status of Proposed Standard.

-- Rich

Woundy, Richard | 18 Apr 2002 18:45

Picon

RE: draft-ietf-ipcdn-device-mibv2-01.txt

Ran,

I am looking at the BGP MIBs, and don't see any language about SNMPv2c and
its lack of real security.

"Definitions of Managed Objects for the Fourth Version of Border Gateway
Protocol (BGP-4)"
<http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-09.txt>

"Definitions of Managed Objects for the Fourth Version of Border Gateway
Protocol (BGP-4), Second Version"
<http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mibv2-02.txt>

Am I looking at the right documents?

In the meantime:
- I am advancing some WG documents (DOCSIS IGMPv2 MIB and Subscriber
Management MIB) that use the text in <http://www.ops.ietf.org/security.html>
(no mention of SNMPv2c).
- I am drafting an email for <mibs <at> ops.ietf.org> asking about adding the
text about SNMPv2c being as insecure as SNMPv1, that I will send out today.

-- Rich

-----Original Message-----
From: RJ Atkinson [mailto:rja <at> extremenetworks.com]
Sent: Tuesday, March 19, 2002 3:23 PM
To: 'Richard Woundy'
Cc: 'ipcdn <at> ietf.org'
Subject: Re: [ipcdn] draft-ietf-ipcdn-device-mibv2-01.txt

(Continue reading)

Woundy, Richard | 18 Apr 2002 18:59

Picon

RE: draft-ietf-ipcdn-device-mibv2-01.txt

Folks,

The current Security Guidelines uses the following text to warn against
using SNMPv1:

   SNMPv1 by itself is not a secure environment.  Even if the network
   itself is secure (for example by using IPSec), even then, there is no
   control as to who on the secure network is allowed to access and
   GET/SET (read/change/create/delete) the objects in this MIB.

Shouldn't this text also point out that SNMPv2c suffers from the same
security vulnerabilities? Note that SNMPv2c is explicitly mentioned in the
standard MIB boilerplate <http://www.ops.ietf.org/mib-boilerplate.html>.

Thanks to Ran Atkinson for pointing this out.

-- Rich

-----Original Message-----
From: RJ Atkinson [mailto:rja <at> extremenetworks.com]
Sent: Tuesday, March 19, 2002 3:23 PM
To: Richard Woundy
Cc: ipcdn <at> ietf.org
Subject: Re: [ipcdn] draft-ietf-ipcdn-device-mibv2-01.txt

On Tuesday, March 19, 2002, at 02:40 , Richard Woundy wrote:
> I want to put together an updated version of this internet-draft.

	Thanks very much.  My primary goal is to keep the I-Ds (and
RFCs) in sync with the current reality.

(Continue reading)

RJ Atkinson | 18 Apr 2002 19:11

Re: draft-ietf-ipcdn-device-mibv2-01.txt

On Thursday, April 18, 2002, at 12:45 , Woundy, Richard wrote:
> I am looking at the BGP MIBs, and don't see any language about SNMPv2c 
> and
> its lack of real security.

Apparently some of my inputs were ignored/watered-down.  I'll go
email the BGP folks again to remind them...

The stuff that *is* in the Security considerations in -09 of the BGP
MIB is a starting point, in that it discusses specific objects
and why those particular objects have specific described security
risks.

Ran

RJ Atkinson | 18 Apr 2002 19:13

Re: draft-ietf-ipcdn-device-mibv2-01.txt


On Thursday, April 18, 2002, at 12:59 , Woundy, Richard wrote:

> Folks,
>
> The current Security Guidelines uses the following text to warn against
> using SNMPv1:
>
>    SNMPv1 by itself is not a secure environment.  Even if the network
>    itself is secure (for example by using IPSec), even then, there is no
>    control as to who on the secure network is allowed to access and
>    GET/SET (read/change/create/delete) the objects in this MIB.
>
> Shouldn't this text also point out that SNMPv2c suffers from the same
> security vulnerabilities? Note that SNMPv2c is explicitly mentioned in 
> the
> standard MIB boilerplate <http://www.ops.ietf.org/mib-boilerplate.html>.

	Thanks.

MIB Folks,

	It should also explicitly note that SNMPv1 and SNMPv2c both use 
clear-text
disclosing passwords -- which are not considered to provide acceptable
security for an IETF protocol.

	We need to start having MIBs mandate that implementers implement
SNMPv3 now that has advanced to Full Standard, IMHO.

(Continue reading)

Woundy, Richard | 19 Apr 2002 17:05

Picon

FW: Update on the DOCSIS DCI Suboption for the DHCP Relay Agent Information Option

Folks,

The information in this email pertains to the following requirement in the
DOCSIS 1.1 RFI, section 6.3.24:

"The CMTS MUST retain the device class information for use in the DHCP
Process. The CMTS MUST create a DHCP Agent Option 82 tuple with the device
class information and MUST insert this tuple in the DHCPDISCOVER from the
corresponding CM before forwarding that DHCPDISCOVER to the DHCP server."

This Option 82 suboption is now documented in RFC 3256. I have included the
RFC announcement below.

-- Rich

-----Original Message-----
From: RFC Editor [mailto:rfc-ed <at> ISI.EDU]
Sent: Thursday, April 18, 2002 7:00 PM
Cc: rfc-editor <at> rfc-editor.org; dhcwg <at> ietf.org
Subject: [dhcwg] RFC 3256 on The DOCSIS Device Class DHCP

A new Request for Comments is now available in online RFC libraries.

        RFC 3256

        Title:	    The DOCSIS (Data-Over-Cable Service Interface
                    Specifications) Device Class DHCP (Dynamic Host
                    Configuration Protocol) Relay Agent Information
                    Sub-option 
        Author(s):  D. Jones, R. Woundy

(Continue reading)

Wijnen, Bert (Bert | 22 Apr 2002 12:27

Picon

RE: draft-ietf-ipcdn-device-mibv2-01.txt

I am working on a revised text for the guideline.

Bert 

> -----Original Message-----
> From: RJ Atkinson [mailto:rja <at> extremenetworks.com]
> Sent: Thursday, April 18, 2002 7:13 PM
> To: Woundy, Richard
> Cc: 'mibs <at> ops.ietf.org'; IPCDN (E-mail)
> Subject: Re: [ipcdn] draft-ietf-ipcdn-device-mibv2-01.txt
> 
> 
> 
> On Thursday, April 18, 2002, at 12:59 , Woundy, Richard wrote:
> 
> > Folks,
> >
> > The current Security Guidelines uses the following text to 
> warn against
> > using SNMPv1:
> >
> >    SNMPv1 by itself is not a secure environment.  Even if 
> the network
> >    itself is secure (for example by using IPSec), even 
> then, there is no
> >    control as to who on the secure network is allowed to access and
> >    GET/SET (read/change/create/delete) the objects in this MIB.
> >
> > Shouldn't this text also point out that SNMPv2c suffers 
> from the same

(Continue reading)

C. M. Heard | 19 Apr 2002 22:15

Picon

RE: draft-ietf-ipcdn-device-mibv2-01.txt

Richard Woundy wrote:
> The wording of the Security Considerations in the drafts in this
> working group is constrained by the following guidance for MIB
> documents from the IETF O&M folks: <http://www.ops.ietf.org/security.html>.
>
> If we want to use text that specifically calls out the dangers/folly
> of using SNMPv2c, we should get feedback from the folks on the
> <mibs <at> ops.ietf.org> mailing list.

Please notice that the text of that page starts out with the words

   "This page defines guidelines [... ]"

Since these are guidelines, I would think that you are not constrained
to follow the text exactly if there are good reasons for a deviation.
In particular, strenghtening the standard admonitions might well be
in order for a MIB module that contains extraordinarily information.

> The current Security Guidelines uses the following text to warn against
> using SNMPv1:
> 
>    SNMPv1 by itself is not a secure environment.  Even if the network
>    itself is secure (for example by using IPSec), even then, there is no
>    control as to who on the secure network is allowed to access and
>    GET/SET (read/change/create/delete) the objects in this MIB.
> 
> Shouldn't this text also point out that SNMPv2c suffers from the same
> security vulnerabilities? Note that SNMPv2c is explicitly mentioned in the
> standard MIB boilerplate <http://www.ops.ietf.org/mib-boilerplate.html>.

(Continue reading)

Group

gmane.ietf.ipcdn.

Search Archive

Page

1 | 2

Articles in period: 17

April 2002

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

VAD implementation (29 Sep 2010)
FW: [Errata Held for Document Update] RFC5098 (1347) (11 May 2010)
FW: [Errata Held for Document Update] RFC5098 (1348) (11 May 2010)
FW: [Errata Held for Document Update] RFC5098 (1349) (11 May 2010)
WG Action: Conclusion of IP over Cable Data Network (ipcdn) (2 Apr 2009)
RFC 5428 on Management Event Management Information Base (MIB) for Pac (2 Apr 2009)
Concluding the IPCDN working group (10 Oct 2008)
FW: Protocol Action: 'Management Event Management Information Base (MI (19 Aug 2008)
Protocol Action: 'Management Event Management Information Base (MIB) f (19 Aug 2008)
draft-ietf-ipcdn-pktc-eventmess (-v14) (18 Aug 2008)
I-D Action:draft-ietf-ipcdn-pktc-eventmess-14.txt (18 Aug 2008)
I-D Action:draft-ietf-ipcdn-pktc-eventmess-13.txt (24 Jun 2008)
RFC 5098 on Signaling MIB for PacketCable and IPCablecom Multimedia Te (1 Mar 2008)
FW: Gen-ART review of draft-ietf-ipcdn-pktc-eventmess-12 (24 Jan 2008)
HPCNCS-08 Final call for papers (23 Jan 2008)
Last Call: draft-ietf-ipcdn-pktc-eventmess (Management Event Managemen (14 Jan 2008)
I-D Action:draft-ietf-ipcdn-pktc-eventmess-12.txt (19 Nov 2007)
I-D Action:draft-ietf-ipcdn-pktc-eventmess-11.txt (26 Oct 2007)
Protocol Action: 'Signaling MIB for PacketCable and IPCablecom Multim (22 Oct 2007)
draft-ietf-ipcdn-pktc-signaling was approved (18 Oct 2007)
Motorola's posting of IPR Disclosure (13 Sep 2007)

Archives

1	September 2010
3	May 2010
4	April 2009
3	October 2008
4	August 2008
2	June 2008
2	March 2008
6	January 2008
1	November 2007
4	October 2007
2	September 2007
5	August 2007
3	July 2007
4	June 2007
4	March 2007
2	January 2007
4	December 2006
4	November 2006
8	October 2006
2	September 2006
3	July 2006
10	June 2006
20	March 2006
16	February 2006
14	January 2006
15	December 2005
20	November 2005
27	October 2005
58	September 2005
36	August 2005
27	July 2005
37	June 2005
4	May 2005
6	April 2005
7	March 2005
26	February 2005
121	January 2005
7	December 2004
20	November 2004
47	October 2004
35	September 2004
42	August 2004
53	July 2004
19	June 2004
19	May 2004
74	April 2004
16	March 2004
43	February 2004
59	January 2004
22	December 2003
22	November 2003
72	October 2003
40	September 2003
78	August 2003
50	July 2003
37	June 2003
24	May 2003
24	April 2003
37	March 2003
34	February 2003
97	January 2003
51	December 2002
23	November 2002
33	October 2002
13	September 2002
4	August 2002
10	July 2002
11	June 2002
17	April 2002

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template