Subject: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

From: Marez Kevin-MGI1375 <[email-masked]>
Date: Wed, 8 Jan 2003 11:04:24 -0800

To all:

1) InterfaceSet textual convention

- The 'all external'  description refers to "external  physical instantiation".  With the introduction of eDOCSIS, the description needs to be clarified. This setting should also include the internal logical interface between the CM and a SAFE (eMTA, ePS, eSTB).
- Reference is made to filtering of stack and application traffic.  Currently in DOCSIS, stack and CM application traffic are not subject to filtering and it should probably remain this way.  Previously, it was unclear if traffic from applications such as eMTA should be subject to filtering.  However, eDOCSIS now makes this clear. 
- With the clarifications made by eDOCSIS, the benefits of updating the objects to use the InterfaceSet textual convention seems to be reduced.  IP filters are heavily used today.  Does this enhancement provide sufficient benefit to warrant this change?  If not, we should stick with what is currently defined in RFC 2669.

2) docsDevNmAccessTable Description.

The description contains the following:

"If the SNMP-COMMUNITY-MIB table has no entries, then this table has its normal access control (described above)meaning for v1 and v2c access. "

The above sentence is contradictory to the current DOCSIS OSSI spec.  If the device is in Coexistence mode (the only time that the SNMP-COMMUNITY-MIB is accessible), then the nmAccessTable is not accessible. Everything after the second paragraph could be deleted.

3) Support for software download using HTTP.  The motivation for adding the HTTP transport was to support S-MTA software download.  DOCSIS requires that software downloads be TFTP.  Do we want to consider stating that the HTTP method is optional, either in the description or with the MIBs compliance statement?

4) docsDevSwOperStatus description - "TFTP" should be "TFTP/HTTP".  Two instances.  Also, Section 3.2.1 will need to be updated to reflect these changes.

5) What is the relationship between docsDevSwServerTransportProtocol and docsDevSwFileNameURL?  What if docsDevSwServerTransportProtocol is set to "tftp" and the <protocol> portion of docsDevSwFileNameURL is set to "http"?

6) What is the relationship between docsDevSwServerAddress and the <server name> portion of docsDevSwFilenameURL?

7) What is the syntax for the <server name> portion of the docsDevSwFilenameURL?  It should be limited to an IP address since DOCSIS doesn't require the ability to resolve domain names.

8) Is there a need to update objects that refer to ports with the InetPortNumber textual convention defined in RFC3291?

9) docsDevCpeV6Table - Support for IP spoofing filters which rely on docsDevCpeTable was made optional in DOCSIS due to issues that couldn't be resolved at the time.  Given that, does it make sense to define docsDevCpeV6Table at this time?

10) docsDevVacmAccessExtTable - Is this table really needed when using SNMPv3?  The limited security provided in SNMPv1/2 necessitated having this functionality in the nmAccessTable.  Given SNMPv3 security, it doesn't seem like this functionality is necessary anymore.

Comments?

Kevin Marez
Motorola
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 8 Jan 2003 14:17:18 -0700

Kevin,

You have offered a number of very good comments for the Cable Device v2 MIB
in your email below. Please give me a few days to process and react to them.
I will try to capture the changes in my own January 20th draft submission.

In the meantime, what are other folks think about the following aspects of
the current Cable Device MIB draft?
- the introduction of the InterfaceSet syntax and the InterfaceSet objects:
docsDevFilterLLCInterfaceSet, docsDevFilterIpInterfaceSet and
docsDevVacmAccessInterfaceSet,
- the docsDevCpeTable (which is optional to implement for DOCSIS) and the
introduction of the docsDevCpeV6Table, and
- the introduction of docsDevVacmAccessExtTable, and the corresponding
deprecation of docsDevNmAccessTable.

-- Rich

-----Original Message-----
From: Marez Kevin-MGI1375 [mailto:[email-masked]]
Sent: Wednesday, January 08, 2003 2:04 PM
To: [email-masked]'
Subject: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

To all:

- The 'all external'  description refers to "external  physical
instantiation".  With the introduction of eDOCSIS, the description needs to
be clarified. This setting should also include the internal logical
interface between the CM and a SAFE (eMTA, ePS, eSTB).
- Reference is made to filtering of stack and application traffic.
Currently in DOCSIS, stack and CM application traffic are not subject to
filtering and it should probably remain this way.  Previously, it was
unclear if traffic from applications such as eMTA should be subject to
filtering.  However, eDOCSIS now makes this clear. 
- With the clarifications made by eDOCSIS, the benefits of updating the
objects to use the InterfaceSet textual convention seems to be reduced.  IP
filters are heavily used today.  Does this enhancement provide sufficient
benefit to warrant this change?  If not, we should stick with what is
currently defined in RFC 2669.

"If the SNMP-COMMUNITY-MIB table has no entries, then this table has its
normal access control (described above)meaning for v1 and v2c access. "

The above sentence is contradictory to the current DOCSIS OSSI spec.  If the
device is in Coexistence mode (the only time that the SNMP-COMMUNITY-MIB is
accessible), then the nmAccessTable is not accessible. Everything after the
second paragraph could be deleted.

3) Support for software download using HTTP.  The motivation for adding the
HTTP transport was to support S-MTA software download.  DOCSIS requires that
software downloads be TFTP.  Do we want to consider stating that the HTTP
method is optional, either in the description or with the MIBs compliance
statement?

4) docsDevSwOperStatus description - "TFTP" should be "TFTP/HTTP".  Two
instances.  Also, Section 3.2.1 will need to be updated to reflect these
changes.

5) What is the relationship between docsDevSwServerTransportProtocol and
docsDevSwFileNameURL?  What if docsDevSwServerTransportProtocol is set to
"tftp" and the <protocol> portion of docsDevSwFileNameURL is set to "http"?

6) What is the relationship between docsDevSwServerAddress and the <server
name> portion of docsDevSwFilenameURL?

7) What is the syntax for the <server name> portion of the
docsDevSwFilenameURL?  It should be limited to an IP address since DOCSIS
doesn't require the ability to resolve domain names.

8) Is there a need to update objects that refer to ports with the
InetPortNumber textual convention defined in RFC3291?

9) docsDevCpeV6Table - Support for IP spoofing filters which rely on
docsDevCpeTable was made optional in DOCSIS due to issues that couldn't be
resolved at the time.  Given that, does it make sense to define
docsDevCpeV6Table at this time?

10) docsDevVacmAccessExtTable - Is this table really needed when using
SNMPv3?  The limited security provided in SNMPv1/2 necessitated having this
functionality in the nmAccessTable.  Given SNMPv3 security, it doesn't seem
like this functionality is necessary anymore.

Comments?

Kevin Marez
Motorola

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 22 Jan 2003 14:37:46 -0700

Kevin,

This is the first of several responses to your comments about the Cable
Device MIB. My responses coincide with what I recently posted at
<http://www.ipcdn.org/docs-devicemib-id-012103.txt>.

This response concerns the use of ...IfIndex objects versus ...Interfaces +
...InterfaceSet objects for selecting interfaces in table rows.

>instantiation".  With the introduction of eDOCSIS, the description needs
>to be clarified. This setting should also include the internal logical 
>objects to use the InterfaceSet textual convention seems to be reduced.  
>IP filters are heavily used today.  Does this enhancement provide 
>sufficient benefit to warrant this change?  If not, we should stick with 
>what is currently defined in RFC 2669.

I recognize that the InterfaceSet TEXTUAL-CONVENTION did not catch on in the
cable industry, and eDOCSIS seems to have evolved beyond it -- as you noted
above.

Therefore, in my latest MIB version, I removed the ...Interfaces +
...InterfaceSet objects, and restored the ...IfIndex objects to current
status, e.g. docsDevFilterLLCIfIndex and docsDevFilterIpIfIndex. This is a
reversion to the RFC 2669 MIB definitions.

I also re-defined the VACM extension not to use the InterfaceSet
TEXTUAL-CONVENTION, e.g.

DocsDevVacmAccessExtEntry ::= SEQUENCE {
        docsDevVacmAccessIfIndex        InterfaceIndexOrZero
    }

docsDevVacmAccessIfIndex OBJECT-TYPE
        SYNTAX      InterfaceIndexOrZero
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
            "The entry interface to which this filter applies.  The
             value corresponds to ifIndex for either a CATV MAC or
             another network interface. If the value is zero, the filter
             applies to all interfaces. In Cable Modems, the default
             value is the customer side interface(s). In Cable Modem
             Termination Systems, this object has to be specified to
             create a row in this table.

             Note that according to the DOCSIS OSSIv1.1 specification
             [OSSI1.1], ifIndex '1' means that this row applies to
             all CPE (customer-facing) interfaces."
        ::= { docsDevVacmAccessExtEntry 1 }

(more about VACM in another email)

This allowed me to remove the InterfaceSet TEXTUAL-CONVENTION from the MIB
entirely, which avoids the problems you noted above.

-- Rich

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 22 Jan 2003 15:33:52 -0700

Kevin,

This response concerns the use of docsDevNmAccessTable with respect to SNMP
Coexistence.

>The above sentence is contradictory to the current DOCSIS OSSI spec.  If 
>the device is in Coexistence mode (the only time that the SNMP-COMMUNITY-
>MIB is accessible), then the nmAccessTable is not accessible. Everything 
>after the second paragraph could be deleted.

I agree, and I think I incorporated the changes to the DESCRIPTION:

docsDevNmAccessTable OBJECT-TYPE
        SYNTAX      SEQUENCE OF DocsDevNmAccessEntry
        MAX-ACCESS  not-accessible
        STATUS      deprecated
        DESCRIPTION
            "This table controls access to SNMP objects by network
             management stations. If the table is empty, access to SNMP
             objects is unrestricted.  This table exists only on SNMPv1
             or v2c agents and does not exist on SNMPv3 agents. See the
             conformance section for details.  Specifically, for v3
             agents, the appropriate MIBs and security models apply in
             lieu of this table.

             This table is deprecated.  Instead, use the SNMP
             coexistence MIBs from RFC2576, the TARGET and NOTIFICATION
             MIBs from the SNMP Applications RFC, and the VACM MIBs for
             SNMPv1 and V2C access."
        ::= { docsDevMIBObjects 2 }

Hopefully I used the correct wording in a related compliance statement:

GROUP docsDevNmAccessGroupV2
        DESCRIPTION
            "The objects in this group are only accessible from
             cable devices which are not operating in SNMP
             Coexistence mode [RFC2576] or in SNMPv3 mode [RFC3410].

             For devices which must support an SNMP operational mode
             that pre-dates SNMP Coexistence, e.g. [OSSI1.1], this
             group is mandatory in Cable Modems and is optional in
             Cable Modem Termination Systems."

-- Rich

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 22 Jan 2003 16:25:23 -0700

Kevin,

This response concerns the use of both HTTP and TFTP for software image
downloads.

>3) Support for software download using HTTP.  The motivation for adding 
>the HTTP transport was to support S-MTA software download.  DOCSIS 
>requires that software downloads be TFTP.  Do we want to consider stating 
>that the HTTP method is optional, either in the description or with the 
>MIBs compliance statement?
>

After considering all of these comments, I have come to the conclusion that
I need to remove the docsDevSwFilenameURL object from the MIB, and
restructure the other objects to maintain support for HTTP downloads. Here
are my top reasons:
- The semantics of the docsDevSwFilenameURL object overlaps too many other
software download MIB objects. One example is the conflict with
docsDevSwServerTransportProtocol per comment 5. Another example is the
conflict with docsDevSwServerAddress per comment 6.
- The URL scheme for "tftp" is not yet defined by the IETF. The URL scheme
for "http" is defined in RFC 1738 and RFC 2616. "tftp" is not listed in
<http://www.iana.org/assignments/uri-schemes>. The Cable Device MIB is
probably not the best location to define a new URL/URI scheme for a single
MIB object.

My new approach is to add only the docsDevSwServerTransportProtocol object
to the RFC 2669 MIB, and redefine other objects as appropriate:

docsDevSwServerTransportProtocol OBJECT-TYPE
        SYNTAX INTEGER {
            tftp(1),
            http(2)
        }
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION
            "This object specifies the transport protocol (TFTP or
             HTTP) to be used for software upgrades.

             If the value of this object is tftp, then the cable
             device uses TFTP [RFC1350] read request packets to
             download the docsDevSwFilename from the
             docsDevSwServerAddress in octet mode.

             If the value of this object is http, then the cable
             device uses HTTP 1.0 [RFC1945] or HTTP 1.1 [RFC2616]
             GET requests sent to host docsDevSwServerAddress to
             download the software image from path docsDevSwFilename.

             The default value of this object is tftp."
        ::= { docsDevSoftware 8 }

To clarify that the HTTP download mechanism is optional (comment 3), I added
the following compliance statement:

OBJECT docsDevSwServerTransportProtocol
         SYNTAX INTEGER { tftp(1) }
         DESCRIPTION
             "An implementation is only required to support TFTP
              software image downloads."

To clarify that the cable device might not be able to resolve a DNS host
name for HTTP or TFTP download (comment 7), I added the following compliance
statement:

OBJECT docsDevSwServerAddressType
         SYNTAX InetAddressType { ipv4(1) }
         DESCRIPTION
             "An implementation is only required to support IPv4
              addresses."

Here is the updated definition of docsDevSwOperStatus, per comment 4.

docsDevSwOperStatus OBJECT-TYPE
        SYNTAX INTEGER {
            inProgress(1),
            completeFromProvisioning(2),
            completeFromMgt(3),
            failed(4),
            other(5)
        }
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "InProgress(1) indicates that a TFTP or HTTP download is
             underway, either as a result of a version mismatch at
             provisioning or as a result of a upgradeFromMgt request.
             CompleteFromProvisioning(2) indicates that the last
             software upgrade was a result of version mismatch at
             provisioning. CompleteFromMgt(3) indicates that the last
             software upgrade was a result of setting
             docsDevSwAdminStatus to upgradeFromMgt.
             Failed(4) indicates that the last attempted download
             failed, ordinarily due to TFTP or HTTP timeout."
        REFERENCE
             "DOCSIS Radio Frequency Interface Specification, Section
             8.2, Downloading Cable Modem Operating Software."
        ::= { docsDevSoftware 4 }

Also per comment 4, here is the update to section 3.2.1:

3.2.1.  Handling of Software upgrades

   The Cable Modem software upgrade process is documented in [RFI1.0].
   From a network management station, the operator:

   o    sets docsDevSwServer to the address of the TFTP server for
        software upgrades

   o    sets docsDevSwFilename to the file pathname of the software
        upgrade image

   o    sets docsDevSwAdminStatus to upgrade-from-mgt

   While DOCSIS only specifies the implementation of the TFTP protocol
   [RFC1350] for file transfers, other functional entities embedded
   within the cable device (particularly a PacketCable Multimedia
   Terminal Adapter [MTA-PROV]) specify the optional implementation of
   the HTTP protocol [RFC1945][RFC2068] for file transfers. The value of
   the docsDevSwServerTransportProtocol object determines which protocol
   is used for SNMP-initiated software upgrade.

   One reason for the SNMP-initiated upgrade is to allow loading of a
   temporary software image (e.g., special diagnostic software) that
   differs from the software normally used on that device without
   changing the provisioning database.

   Note that software upgrades should not be accepted blindly by the
   cable device.  The cable device may refuse an upgrade if:

   o    The download is incomplete.

   o    The file contents are incomplete or damaged.

   o    The software is not intended for that hardware device (may
        include the case of a feature set that has not been purchased
        for this device).

   A cable device that implements the code verification mechanisms of
   [BPIPLUS] verifies the source and integrity of the downloaded image
   by validating one or more Code Verification Signatures that are
   bundled within the software upgrade.

-- Rich

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 22 Jan 2003 16:59:12 -0700

Kevin,

Here is my comment on the VACM issue:

>SNMPv3?  The limited security provided in SNMPv1/2 necessitated having 
>this functionality in the nmAccessTable.  Given SNMPv3 security, it 
>doesn't seem like this functionality is necessary anymore.

I would agree that it is better security to authenticate a keyed hash via
SNMPv3, than to rely on the incoming device interface for implied user
identification.

However, one interesting and important case is a CM diagnostic interface for
subscriber-side queries, after the CM registration process is completed. It
seems quite useful to allow subscriber tools (with SNMPv3 securityLevel of
noAuthNoPriv) to query cable modems over the CMCI (CPE interface) but not
over the RFI (RF interface).

-- Rich

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 22 Jan 2003 17:06:36 -0700

Kevin,

Here are some additional responses to your comments.

>InetPortNumber textual convention defined in RFC3291?

I assert that I can convert existing objects from SYNTAX
"Integer32 (0..65535)" to "InetPortNumber" without an OID renumbering.

According to RFC 2578 section 10.2:

(2)  The value of a SYNTAX clause may be replaced by a textual
     convention, providing the textual convention is defined to use the
     same primitive ASN.1 type, has the same set of values, and has
     identical semantics.

The common primitive ASN.1 type for both SYNTAXes is "INTEGER", the range of
values for both SYNTAXes is "(0..65535)", and the semantics are identical.

>docsDevCpeV6Table at this time?

I think the MIB doctor would prefer to see analogous objects for IPv4 and
IPv6 spoofing filters.

On the other hand, previous versions of the MIB indicated that the CPE
tables were mandatory, when in fact they have been optional in DOCSIS for
some time. That prompted the following new or revised compliance statements:

GROUP docsDevCpeGroupV2
        DESCRIPTION
            "This group is optional in Cable Modems, and MUST NOT
             be implemented in Cable Modem Termination Systems.
             See [SUBMGT-MIB] for a similar CMTS capability."

GROUP docsDevIpV6Group
        DESCRIPTION
            "This group is mandatory in IPv6-aware Cable Modems."

GROUP docsDevIpV6CpeGroup
        DESCRIPTION
            "This group is optional in IPv6-aware Cable Modems."

Because of the differences in compliance statements, I split up the
docsDevIpV6Group and docsDevIpV6CpeGroup.

-- Rich

---

From: Marez Kevin-MGI1375 <[email-masked]>
Date: Tue, 28 Jan 2003 09:09:48 -0800

Rich,

I understand the scenario you have presented, however, I think MSOs would typically use a private networking space for the RF-side and explicitly prevent access from outside that space.

Our concern here is that we are adding an additional level of complexity to the vacmAccess table that doesn't provide a great deal of benefit.

Greg, please respond I have misstated anything or if you have anything you'd like to add.  Thanks very much,

Kevin

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Wednesday, January 22, 2003 3:59 PM
To: 'Marez Kevin-MGI1375'
Cc: IPCDN WG (E-mail)
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Kevin,

-- Rich

---

From: Nakanishi Greg-MGI8179 <[email-masked]>
Date: Tue, 28 Jan 2003 09:42:36 -0800

Kevin, I think your point is accurate.

Just to expand upon it some...

Typically a CM will get a private IP address via DHCP.  This results in access to the CM through the HFC interface being limited to within the MSO's private IP network.  "Outsiders" (e.g. user's on the CMCI-side or on the Internet) will not be able to access a CM through the HFC interface.  Access to the CM from the CMCI interface is still allowed if the proper SNMP access controls are setup.  

I want to make sure that this proposed extension to the VACM table provides a good benefit over what is acheivable today with the mechanisms we already have.

greg

> From: Marez Kevin-MGI1375 
> Sent: Tuesday, January 28, 2003 9:10 AM
> To: 'Woundy, Richard'; Nakanishi Greg-MGI8179
> Cc: IPCDN WG (E-mail)
> I understand the scenario you have presented, however, I 
> think MSOs would typically use a private networking space for 
> the RF-side and explicitly prevent access from outside that space.
> 
> Our concern here is that we are adding an additional level of 
> complexity to the vacmAccess table that doesn't provide a 
> great deal of benefit.
> 
> Greg, please respond I have misstated anything or if you have 
> anything you'd like to add.  Thanks very much,
> 
> Kevin
> 
>

---

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 28 Jan 2003 11:51:13 -0700

Kevin, Greg,  

Following your thoughts. I think I got more findings that need to be
addressed in any case. 
The vacmAccess Interface requirements is being as a proposal since the
early versions of this draft.

We know your concerns and they are also related to different discussion
in the reflector (i.e. controlling the number of traps/notification by
touching the Notification Originator subsystem in the SNMP entity ) 

In this case the difficulty is to modify the Access Control Subsystem in
the SNMP entity, to being able to add the interface scheme, which is
perfectly valid under RFC2571/3411 architecture and AUGMENT clause in
RFC2578

We need more thoughs in the SNMP constrains we are trying to achieve
with the full coverage of MSO needs. 

The need is there:

what the SNMP stack providers may solve?  (Greg concerns of available
tools/design framework)
Will be Feasible or agree in certain MSO/management constrains?  ( few
options below)
Is the SNMPv3 group addressing this case or had ever think about this as
a standard mechanism? 
Will that be clearly extended for embedded cases with logical interfaces
instead of physical ones ( to avoid security holes ? 

Typical case: 

"Many" (how many is many?) CMs used to bridge the traffic (SNMP)
directed to the CM DHCP IP  from the CPE through the RF interface
Upstream.

For blocking traffic: 
These is trivial since MSO is able to place SNMP filters in the
CMTS/backbone
For getting CPE traffic: 
Could be  cumbersome in the presence of SNMP filters in the gateway or a
CM unable to register.  In the other hand the MSO/technician/User, must
know the CM IP that could be a problem or not desired always.

That one was partially solved with the well known IP 192.168.100.1

What is still a MSO constrain:
CMs able to talk to the SNMP stack from any CPE subnet ( spoof NMS IP )
( 1 hop)  and use the v1, v2c vacmAccess constrains for full access.

Also v3 noAuthNoPriv does not support the subletting as RFC 2576 defined
for coexistence v1 v2c and there is where Rich's case applied for
granting or blocking access.

If we agree the well know IP is the "only" way to talk to the CM for a
CPE with one hop ( CPE to CM DHCP IP queries forwarded through RF ) we
are OK and the vacm requirement may not needed, but some clarifications
are needed in the spec.
It creates the need to reconfigure the user CPE any time that a user may
need to talk to the CM.

With current requirements in either case: 
In the SNMP framework snmpv3 noAuthNoPRiv the access will be the same
for MSO and user Access.

With the Interface scheme an MSO will be able to set two different v3
users noAuthNoPriv with different access.

If not the case we still have the issue of blocking NMS spoofed Ips)
and the vacmAccessInterface is a way to block that.
Or define the ip forward mechanism better.

Eduardo

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2003 10:43 AM
To: 'IPCDN WG (E-mail)'
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Typically a CM will get a private IP address via DHCP.  This results in
access to the CM through the HFC interface being limited to within the
MSO's private IP network.  "Outsiders" (e.g. user's on the CMCI-side or
on the Internet) will not be able to access a CM through the HFC
interface.  Access to the CM from the CMCI interface is still allowed if
the proper SNMP access controls are setup.  

I want to make sure that this proposed extension to the VACM table
provides a good benefit over what is acheivable today with the
mechanisms we already have.

greg

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 28 Jan 2003 12:58:29 -0700

Eduardo,

I am sympathetic to Greg and Kevin's argument that perhaps the
docsDevVacmAccessExtTable extension to VACM should be deleted from the Cable
Device MIB, for three reasons:

1. Greg seems to have proposed a workaround for the use case I proposed.
Restating, the DOCSIS configuration file could set up the
docsDevFilterIpTable to reject UDP/SNMP traffic arriving on the RF/HFC
interface from any IP subnets other than the MSOs management station
subnets. This sounds like reasonable security practice in any case, i.e.
don't just rely on SNMPv3 authentication. It enables subscriber CM
management from the CMCI side, but not subscriber/random user access from
the RF/HFC side, per my use case.
2. I agree it would be much easier for vendors if they could leverage
standard SNMP agent stack implementations as much as possible. The extension
for DOCSIS-only devices makes this objective more difficult.
3. There is also a possibility that the IETF MIB doctor might frown on a
DOCSIS-specific extension to the VACM MIB.

Does anyone disagree? Shall I make this deletion?

Are there any other comments on the current Cable Device MIB -- which is now
posted on the IETF reflector,
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-04.txt>?

-- Rich

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]]
Sent: Tuesday, January 28, 2003 1:51 PM
To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail)
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Kevin, Greg,  

The need is there:

Typical case: 

For blocking traffic: 

Eduardo

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2003 10:43 AM
To: 'IPCDN WG (E-mail)'
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

greg

---

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 28 Jan 2003 14:28:43 -0700

I agree, 
The vacm extension should be removed, 
The IpFilter mechanism is a good practice and close all doors.

Eduardo 

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2003 12:58 PM
To: Nakanishi Greg-MGI8179; Eduardo Cardona
Cc: IPCDN WG (E-mail)
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Eduardo,

I am sympathetic to Greg and Kevin's argument that perhaps the
docsDevVacmAccessExtTable extension to VACM should be deleted from the
Cable Device MIB, for three reasons:

1. Greg seems to have proposed a workaround for the use case I proposed.
Restating, the DOCSIS configuration file could set up the
docsDevFilterIpTable to reject UDP/SNMP traffic arriving on the RF/HFC
interface from any IP subnets other than the MSOs management station
subnets. This sounds like reasonable security practice in any case, i.e.
don't just rely on SNMPv3 authentication. It enables subscriber CM
management from the CMCI side, but not subscriber/random user access
from the RF/HFC side, per my use case. 2. I agree it would be much
easier for vendors if they could leverage standard SNMP agent stack
implementations as much as possible. The extension for DOCSIS-only
devices makes this objective more difficult. 3. There is also a
possibility that the IETF MIB doctor might frown on a DOCSIS-specific
extension to the VACM MIB.

Are there any other comments on the current Cable Device MIB -- which is
now posted on the IETF reflector,
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-04.txt
>?

-- Rich

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]]
Sent: Tuesday, January 28, 2003 1:51 PM
To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail)
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Kevin, Greg,  

The need is there:

what the SNMP stack providers may solve?  (Greg concerns of available
tools/design framework) Will be Feasible or agree in certain
MSO/management constrains?  ( few options below) Is the SNMPv3 group
addressing this case or had ever think about this as a standard
mechanism? 
Will that be clearly extended for embedded cases with logical interfaces
instead of physical ones ( to avoid security holes ? 

Typical case: 

For blocking traffic: 
CMTS/backbone For getting CPE traffic: 

If we agree the well know IP is the "only" way to talk to the CM for a
CPE with one hop ( CPE to CM DHCP IP queries forwarded through RF ) we
are OK and the vacm requirement may not needed, but some clarifications
are needed in the spec. It creates the need to reconfigure the user CPE
any time that a user may need to talk to the CM.

If not the case we still have the issue of blocking NMS spoofed Ips) and
the vacmAccessInterface is a way to block that. Or define the ip forward
mechanism better.

Eduardo

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2003 10:43 AM
To: 'IPCDN WG (E-mail)'
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

greg

> I understand the scenario you have presented, however, I think MSOs 
> would typically use a private networking space for the RF-side and 
> explicitly prevent access from outside that space.
> 
> complexity to the vacmAccess table that doesn't provide a great deal 
> of benefit.
> 
> Greg, please respond I have misstated anything or if you have anything

> you'd like to add.  Thanks very much,
> 
> Kevin
> 
> 
> I would agree that it is better security to authenticate a keyed hash 
> via SNMPv3, than to rely on the incoming device interface for implied 
> user identification.
> 
> However, one interesting and important case is a CM diagnostic 
> interface for subscriber-side queries, after the CM registration 
> process is completed. It

---

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 28 Jan 2003 14:53:04 -0700

I forgot to mention something, 

3.3.2.2.  SNMPv3 Interface via vacm extension to be removed

Going back to Greg's comments? 

Is the filtering flow in 3.3 accurated enough to solve that in terms of
this filter schems?

Seems that SNMP traffic (Section 3.3) is not intuitively "forced" to go
to the ip filters (which after removing vacmExt will be mere NmAccess
Mode) before hitting the agent. ( I mean the NmAccess text from rfc2669
is distracting ?)
 
I've seen people  with different interpretations of how to "implement"
the filters based on directed to CM traffic or CM forwarded traffic
It may create confusion that as the diagram is following the Stack for
the RF-CPE or CPE-RF traffic the RF-CM CPE-CM trattic is not properly
represented : I add a little box of possible interpretation that should
be clarified.

               *****************
                * LLC Filter In *
                *****************
                        |
                        v
               *******************
               * Special Filters *
               *        |        *
               *        V        *
               *  ************   *
               *  * IP Spoof *   *
               *  ************   *
               *        |        *
               *        v        *

               * *************** *
               * * SNMP Access * *
               * *************** *
               *        |        *
               *******************
                        |           ------>  Wrong :  SNMP to CM traffic
processing
                        v
                ****************
                * IP Filter In *
                ****************
                        |           -------> Rigth:  SNMP to CM traffic
processing
                        v
                *****************
                * IP Filter Out *
                *****************
                        |
                        v
                ******************
                * LLC Filter Out *
                ******************

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2003 12:58 PM
To: Nakanishi Greg-MGI8179; Eduardo Cardona
Cc: IPCDN WG (E-mail)
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Eduardo,

-- Rich

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]]
Sent: Tuesday, January 28, 2003 1:51 PM
To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail)
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Kevin, Greg,  

The need is there:

Typical case: 

For blocking traffic: 

Eduardo

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2003 10:43 AM
To: 'IPCDN WG (E-mail)'
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

greg

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 28 Jan 2003 16:26:39 -0700

I wonder whether current CM vendors typically check the docsDevFilterIpTable
before they process a locally-addressed SNMP PDU.

Anyone know?

-- Rich

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]]
Sent: Tuesday, January 28, 2003 4:53 PM
To: Woundy, Richard; Nakanishi Greg-MGI8179
Cc: IPCDN WG (E-mail)
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

 

               *****************
                * LLC Filter In *
                *****************
                        |
                        v
               *******************
               * Special Filters *
               *        |        *
               *        V        *
               *  ************   *
               *  * IP Spoof *   *
               *  ************   *
               *        |        *
               *        v        *

               * *************** *
               * * SNMP Access * *
               * *************** *
               *        |        *
               *******************

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2003 12:58 PM
To: Nakanishi Greg-MGI8179; Eduardo Cardona
Cc: IPCDN WG (E-mail)
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Eduardo,

-- Rich

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]]
Sent: Tuesday, January 28, 2003 1:51 PM
To: Nakanishi Greg-MGI8179; IPCDN WG (E-mail)
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Kevin, Greg,  

The need is there:

Typical case: 

For blocking traffic: 

Eduardo

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2003 10:43 AM
To: 'IPCDN WG (E-mail)'
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

greg

---

From: Nakanishi Greg-MGI8179 <[email-masked]>
Date: Tue, 28 Jan 2003 16:03:06 -0800

I agree that the application of ipFilters to packets addressed to the CM is not very clear in the spec.  This topic comes up every now and then on the reflector.  I believe the generally accepted interpretation is that traffic addressed to the CM is NOT filtered.

The workaround that I proposed does not rely on the use of IP filters.  It just relies on the the partitioning of the private IP network that the CM is part of and the public IP network that the CPE is part of.  Typically, the CMTS will not route between these networks.

A user can access through SNMP his/her own CM through the diagnostic IP address; however, a user cannot access someone elses CM.  The packets from the user's CPE on the public network will not be routed by the CMTS to the private network on which someone else's CM resides.

greg

> Sent: Tuesday, January 28, 2003 3:27 PM
> To: 'Eduardo Cardona'; Nakanishi Greg-MGI8179
> Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail)
> great deal

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 28 Jan 2003 17:11:46 -0700

You're assuming that the CMTS implements the Subscriber Management MIB, and
has docsSubMgtPktFilterTable configured to prevent the forwarding of
subscriber CPE traffic to the private net CMs, right?

-- Rich

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]]
Sent: Tuesday, January 28, 2003 7:03 PM
To: Woundy, Richard; 'Eduardo Cardona'
Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail)
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

I agree that the application of ipFilters to packets addressed to the CM is
not very clear in the spec.  This topic comes up every now and then on the
reflector.  I believe the generally accepted interpretation is that traffic
addressed to the CM is NOT filtered.

The workaround that I proposed does not rely on the use of IP filters.  It
just relies on the the partitioning of the private IP network that the CM is
part of and the public IP network that the CPE is part of.  Typically, the
CMTS will not route between these networks.

A user can access through SNMP his/her own CM through the diagnostic IP
address; however, a user cannot access someone elses CM.  The packets from
the user's CPE on the public network will not be routed by the CMTS to the
private network on which someone else's CM resides.

greg

---

From: Nakanishi Greg-MGI8179 <[email-masked]>
Date: Tue, 28 Jan 2003 16:22:25 -0800

That could be one implementation.  

Another possibility is it could be done through IP forwarding tables.  Conceptually, the CMTS HFC interface is connected to two networks - one public and one private.  When a packet is received on the public interface (i.e. from the CPE) that is addressed to the private network, the forwarding table would not have a route for it and discards the packet.  

Although I don't know the CMTS implementation specifics, my understanding is that the described behavior is the way most MSOs operate their network.  i.e. CPE cannot communicate with someone else's CM.

greg

> Sent: Tuesday, January 28, 2003 4:12 PM
> To: 'Nakanishi Greg-MGI8179'; 'Eduardo Cardona'
> think MSOs

---

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 28 Jan 2003 18:04:48 -0700

Greg, 

The IP spaces is fine as soon as the user does not try to spoof an NMS
IP (where NmAccess beats SNMP by supporting interfaces for the non
authenticated communication)

Q1:
Does ALL CMs forward (theoretically yes because are bridges) to RFI all
( no ICMP) traffic (including CM DHCP IP) but "diagnostic IP
destination? 

If YES Greg's scenario follows the MSO normal filtering conditions ( i.e
UDP/TCP port fitering between subnets) 

If NO  

The case I am mentioning is a user spoofing an NMS IP (matches Ip
subnet) and contacting  the CH DHCP IP and then, the CM processes packet
without forwarding it to the network, replying back to the user.

To avoid the vacmExt, if the answer is 'NO', I think the below rules may
aliviate some problems:

   Flow            type       Destination
1) CPE -> CM       SNMP       "Diagnostic IP"  YES
2) CPE -> CM       SNMP       CM DHCP IP       NO -Q1-
3) CPE -> CM       ICMP       "Diagnostic IP"  YES
4) CPE -> CM       ICMP       CM DHCP IP       YES      
5) CPE -> CM       Other IP   both             NO ( some cases YES as
top services run in  CM stack like HTTP)

Req 2) seems to be the problem for the Interface requirement.
What makes is:  
Address Q1 in Coexistence v1, v2c 
V3 noAuthNoPriv if configured, (nothing to do) : same access level both
NMS and CPE users ( limited view recommended)

Eduardo

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2003 5:22 PM
To: 'Woundy, Richard'; Eduardo Cardona
Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Another possibility is it could be done through IP forwarding tables.
Conceptually, the CMTS HFC interface is connected to two networks - one
public and one private.  When a packet is received on the public
interface (i.e. from the CPE) that is addressed to the private network,
the forwarding table would not have a route for it and discards the
packet.  

Although I don't know the CMTS implementation specifics, my
understanding is that the described behavior is the way most MSOs
operate their network.  i.e. CPE cannot communicate with someone else's
CM.

greg

> > subnets. This sounds like reasonable security practice in any case, 
> > i.e. don't just rely on SNMPv3 authentication. It enables subscriber

> > CM management from the CMCI side, but not subscriber/random user 
> > access from the RF/HFC side, per my use case. 2. I agree it would be

> > much easier for vendors if they could leverage standard SNMP agent 
> > stack implementations as much as possible. The extension for 
> > DOCSIS-only devices makes this objective more difficult. 3. There is

> > also a possibility that the IETF MIB doctor might frown on a
> DOCSIS-specific

> > addressed in any case. The vacmAccess Interface requirements is 
> > being as a
> proposal since the

> > mechanism? Will that be clearly extended for embedded cases with 
> > logical interfaces

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 28 Jan 2003 18:17:05 -0700

Most CMTS deployments (that I am aware of) use a CMTS with a single IP
forwarding table, which forwards traffic based on destination IP address
only. That's even true in the Comcast and TWC footprints that concurrently
support multiple Internet service providers.

Some CMTS software supports multiple IP forwarding tables, where different
forwarding tables are used for different traffic sources. That is
particularly true for CMTSs that support MPLS and/or MPLS VPNs.

Note that a CMTS can be implemented as a pure bridge, with no IP forwarding
table at all. Hence my comment about the Subscriber Management MIB.

But I guess we agree that there are multiple technical alternatives to
extending the VACM table for CM diagnostic access by subscribers.

-- Rich

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]]
Sent: Tuesday, January 28, 2003 7:22 PM
To: Woundy, Richard; 'Eduardo Cardona'
Cc: IPCDN WG (E-mail); DOCSIS OSS (E-mail)
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Another possibility is it could be done through IP forwarding tables.
Conceptually, the CMTS HFC interface is connected to two networks - one
public and one private.  When a packet is received on the public interface
(i.e. from the CPE) that is addressed to the private network, the forwarding
table would not have a route for it and discards the packet.  

Although I don't know the CMTS implementation specifics, my understanding is
that the described behavior is the way most MSOs operate their network.
i.e. CPE cannot communicate with someone else's CM.

greg

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 28 Jan 2003 18:35:06 -0700

Eduardo,

There are at least five available standardized mechanisms to prevent
subscriber CPEs from spoofing NMS (or other) IP addresses:

1. The CPE IP address management controls on the CM from the Cable Device
MIB, aka docsDevCpe. These controls were made optional by the OSSI because
they were difficult to implement and deploy correctly, e.g. it is too easy
to capture an autoconfigured IP address as the "current" CPE IP address.
2. The CPE IP address management controls on the CMTS from the Subscriber
Management MIB, aka docsSubMgtCpeIpTable.
3. The source IP address filtering controls on the CM from the Cable Device
MIB, aka docsDevFilterIpTable. This can be used to prevent subscriber CPEs
from spoofing IP addresses at the granularity of IP subnets, but might not
be able to prevent spoofing the IP address of another subscriber CPE.
4. The source IP address filtering controls on the CMTS from the Subscriber
Management MIB, aka docsSubMgtPktFilterTable. This can be used to prevent
subscriber CPEs from spoofing IP addresses at the granularity of IP subnets,
but might not be able to prevent spoofing the IP address of another
subscriber CPE.
5. The CMTS source address filtering enabled by the DHCP lease query message
defined in draft-ietf-dhc-leasequery-04.txt.

Probably the most common deployed mechanism today would be #4 or a variant
of #4, e.g. CMTS router access control lists.

-- Rich

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]]
Sent: Tuesday, January 28, 2003 8:05 PM
To: Nakanishi Greg-MGI8179; Woundy, Richard
Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Greg, 

Q1:

If NO  

   Flow            type       Destination

Eduardo

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2003 5:22 PM
To: 'Woundy, Richard'; Eduardo Cardona
Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

greg

---

From: Nakanishi Greg-MGI8179 <[email-masked]>
Date: Tue, 28 Jan 2003 17:35:43 -0800

Eduardo,

The original use case given was the ability for the CPE to access it's own CM via SNMP, but not be able to access someone else's CM through the RF interface.  I'm assuming it OK for MSO staff to access the CM.

Allowing access to local CM --
To allow the CPE to access it's own CM, all that is required is a VACM entry with noAuthnoPriv to allow access to a restricted set of MIB objects.  In this case, from a security point of view, it shouldn't matter which IP address the SNMP request is sent to.  The VACM table will determine if access is allowed regardless of the IP address used.

Preventing access to someone else's CM --
This is supported by restricting the routing of packets between the public and private networks.  As we've been discussing, it appears there are a few methods in which this can be done.

MSO staff to access the CM --
If the SNMP request is generated from within the private network (e.g. MSO's NMS)then the access to the CM will be determined by the VACM table.

Does this address your concern?

greg

> Sent: Tuesday, January 28, 2003 5:05 PM

---

From: "Eduardo Cardona" <[email-masked]>
Date: Wed, 29 Jan 2003 07:01:40 -0700

Greg, Rich, 

Sorry if I wasn't clear.

I am fine with all the comments about spoofing and subnets isolation
mechanisms.

The case I am presenting ( not spoofing other CM's Ips)

It is the case of a user spoofing an NMS IP address with the solely
purpose of getting access to the SNMP entity of its own CM ( not traffic
intervention  in the RF), ( simulating the NMS network in the CPE side),
then the subnet Mask mechanism for Coesistence v1 v2c may failed in the
case of a CM that reply to SNMP request from CPEs ( CM believes that the
request is from a valid subnet, user still needs to guess the comminity
string)

In the case of v3 noAuthNoPriv as soon as is defined such view it
becomes a CPE user view ( no interface/subnet filtering). MSO can't have
an username for CPE and think in another user ( more privileges/access)
for exclusive MSO administration.

The point I am trying to get into is as more routing/ip aware stuff is
placed in the CMs: 

Just guessing:

A common behavior of a CPE SNMP request directed to CM DHCP IP is
forwarding to RF US and bounce back to CM side due the bridge nature of
the implementation.

That may stop happening since some CMs failed to filter SNMP traffic
based on interfaces since the CPE traffic appear as RF traffic ( bounded
back)

What some inmplementations may did was to start listening to SNMP to CM
DHCP IP and apply the NmAccess interface filter, 
  
If that's the case a CM will recognize a CM IP in

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2003 6:36 PM
To: Eduardo Cardona; Woundy, Richard
Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Eduardo,

The original use case given was the ability for the CPE to access it's
own CM via SNMP, but not be able to access someone else's CM through the
RF interface.  I'm assuming it OK for MSO staff to access the CM.

Allowing access to local CM --
To allow the CPE to access it's own CM, all that is required is a VACM
entry with noAuthnoPriv to allow access to a restricted set of MIB
objects.  In this case, from a security point of view, it shouldn't
matter which IP address the SNMP request is sent to.  The VACM table
will determine if access is allowed regardless of the IP address used.

Preventing access to someone else's CM --
This is supported by restricting the routing of packets between the
public and private networks.  As we've been discussing, it appears there
are a few methods in which this can be done.

MSO staff to access the CM --
If the SNMP request is generated from within the private network (e.g.
MSO's NMS)then the access to the CM will be determined by the VACM
table.

greg

> Req 2) seems to be the problem for the Interface requirement. What 
> makes is:
> Conceptually, the CMTS HFC interface is connected to two networks - 
> one public and one private.  When a packet is received on the public
> operate their network.  i.e. CPE cannot communicate with someone 
> else's CM.
> 
> greg
> 
> > You're assuming that the CMTS implements the Subscriber Management 
> > MIB, and has docsSubMgtPktFilterTable configured to prevent the 
> > forwarding of subscriber CPE traffic to the private net CMs, right?
> > 
> > -- Rich
> > 
> > I agree that the application of ipFilters to packets addressed to 
> > the CM is not very clear in the spec.  This topic comes up every now
> > and then on the
> > The workaround that I proposed does not rely on the use of IP 
> > filters.  It just relies on the the partitioning of the private IP 
> > network that the CM is
> > A user can access through SNMP his/her own CM through the diagnostic

> > IP address; however, a user cannot access someone elses CM.  The
> > packets from
> > > I wonder whether current CM vendors typically check the 
> > > docsDevFilterIpTable before they process a locally-addressed SNMP 
> > > PDU.
> > > 
> > > Anyone know?
> > > 
> > > -- Rich
> > > 
> > > Is the filtering flow in 3.3 accurated enough to solve that in 
> > > terms of this filter schems?
> > > 
> > > Seems that SNMP traffic (Section 3.3) is not intuitively "forced" 
> > > to go to the ip filters (which after removing vacmExt will be
> > mere NmAccess
> > > Mode) before hitting the agent. ( I mean the NmAccess text from 
> > > rfc2669 is distracting ?)
> > >  
> > > represented : I add a little box of possible interpretation that 
> > > should be clarified.
> > > 
> > > 
> > > 
> > >                *****************
> > >                 * LLC Filter In *
> > >                 *****************
> > >                         |
> > >                         v
> > >                *******************
> > >                * Special Filters *
> > >                *        |        *
> > >                *        V        *
> > >                *  ************   *
> > >                *  * IP Spoof *   *
> > >                *  ************   *
> > >                *        |        *
> > >                *        v        *
> > > 
> > >                * *************** *
> > >                * * SNMP Access * *
> > >                * *************** *
> > >                *        |        *
> > >                *******************
> > > 1. Greg seems to have proposed a workaround for the use case I 
> > > proposed. Restating, the DOCSIS configuration file could set up 
> > > the docsDevFilterIpTable to reject UDP/SNMP traffic arriving on
> > the RF/HFC
> > > We know your concerns and they are also related to different 
> > > discussion in the reflector (i.e. controlling the number of
> > traps/notification by
> > > In this case the difficulty is to modify the Access Control 
> > > Subsystem in the SNMP entity, to being able to add the interface
> scheme, which is
> > > CMTS/backbone For getting CPE traffic: Could be  cumbersome in the

> > > presence of SNMP filters in the gateway or a
> > > CMs able to talk to the SNMP stack from any CPE subnet ( spoof NMS

> > > IP ) ( 1 hop)  and use the v1, v2c vacmAccess constrains for
> full access.
> > > 
> > > Also v3 noAuthNoPriv does not support the subletting as RFC 2576 
> > > defined for coexistence v1 v2c and there is where Rich's case 
> > > applied for granting or blocking access.
> > > 
> > > are OK and the vacm requirement may not needed, but some 
> > > clarifications are needed in the spec. It creates the need to 
> > > reconfigure the user CPE
> > > If not the case we still have the issue of blocking NMS spoofed 
> > > Ips) and the vacmAccessInterface is a way to block that. Or define

> > > the ip forward
> > > Typically a CM will get a private IP address via DHCP.  This 
> > > results in access to the CM through the HFC interface being 
> > > limited to
> > within the
> > > MSO's private IP network.  "Outsiders" (e.g. user's on the 
> > > CMCI-side or on the Internet) will not be able to access a CM 
> > > through the HFC interface.  Access to the CM from the CMCI 
> > > interface is still allowed if
> > > [email-masked] https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 29 Jan 2003 10:36:36 -0700

I guess the biggest problem is when we don't use SNMPv3 authentication, and
when we don't use the docsDevNmAccessTable (e.g. with
docsDevNmAccessInterfaces restricting access from the CMCI) -- e.g. SNMP
Coexistence.

In the case of SNMP Coexistence, the only thing that stops end-users from
operator-level SNMP access is knowledge of the community string, which is
probably exposed as a plain-text ASCII string in the DOCSIS config files on
the TFTP servers.

Am I misinformed?

-- Rich

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]]
Sent: Wednesday, January 29, 2003 9:02 AM
To: Nakanishi Greg-MGI8179; Woundy, Richard
Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Greg, Rich, 

Sorry if I wasn't clear.

    

Just guessing:

  

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2003 6:36 PM
To: Eduardo Cardona; Woundy, Richard
Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Eduardo,

greg

---

From: "Eduardo Cardona" <[email-masked]>
Date: Wed, 29 Jan 2003 14:36:11 -0700

Rich, That's right. 

v3 noAuthNoPriv, is exactly what you say, MSOs should not have more than
minimal access to users (any : internal, customers) at that level  

Coexistence v1, v2c is almost what you said, with a little bit of extra
protection

MSO can use the TMAsk from RFC2576 to allow only some IP/subnets mask
associated with a community string ( indicated in the config file).

1) If a CM forward the SNMP CPE to CM IP traffic through the RF there is
no problem, traffic goes away 
2) If the CM does not forward the SNMP traffic, a User may be able to
spoof the NMS ip and get access to operator-level by gessing or
capturing the CM community string from config file of sniffing the RF
somw how.

Diagnostic IP forces the CPE to be in 192.168.100.x, solve the problem
only if CM forced to be in the same subnet ( limited view associated
with that) 
 
One solution I see for 2) is to force the CM to not respond directly to
SNMP from CPE and forward the packet to RF wich means only with
Diagnostic IP a CPE user can talk to the CM directly.

If CMs are no longer dumm bridges -case 1)-, IP applications on to of
the CM may create a relaxed packet handling for arbitrary configured IPs
in the CPEs 

Eduardo

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]] 
Sent: Wednesday, January 29, 2003 10:37 AM
To: Eduardo Cardona; Nakanishi Greg-MGI8179
Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

I guess the biggest problem is when we don't use SNMPv3 authentication,
and when we don't use the docsDevNmAccessTable (e.g. with
docsDevNmAccessInterfaces restricting access from the CMCI) -- e.g. SNMP
Coexistence.

In the case of SNMP Coexistence, the only thing that stops end-users
from operator-level SNMP access is knowledge of the community string,
which is probably exposed as a plain-text ASCII string in the DOCSIS
config files on the TFTP servers.

Am I misinformed?

-- Rich

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]]
Sent: Wednesday, January 29, 2003 9:02 AM
To: Nakanishi Greg-MGI8179; Woundy, Richard
Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Greg, Rich, 

Sorry if I wasn't clear.

    

Just guessing:

  
If that's the case a CM will recognize a CM IP in (

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Tuesday, January 28, 2003 6:36 PM
To: Eduardo Cardona; Woundy, Richard
Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Eduardo,

greg

> Does ALL CMs forward (theoretically yes because are bridges) to RFI 
> all ( no ICMP) traffic (including CM DHCP IP) but "diagnostic IP
> destination? 
> 
> If YES Greg's scenario follows the MSO normal filtering conditions ( 
> i.e UDP/TCP port fitering between subnets)
> 
> If NO
> 
> subnet) and contacting  the CH DHCP IP and then, the CM processes 
> packet without forwarding it to the network, replying back to the 
> user.
> 
> To avoid the vacmExt, if the answer is 'NO', I think the below rules 
> may aliviate some problems:
> 
>    Flow            type       Destination

> > packets from the user's CPE on the public network will not be routed

> > by the CMTS to the
> > > logical interfaces instead of physical ones ( to avoid security 
> > > holes ?
> > > 
> > > 
> > > Typical case:
> > >

---

From: Nakanishi Greg-MGI8179 <[email-masked]>
Date: Wed, 29 Jan 2003 14:41:19 -0800

Eduardo,

How much of an issue is this?  

This issue exists today independent of SNMP.  Has there been any operational problems caused because of this?

This issue is orthogonal to the SNMP access control.  Seems to me that the proper SNMPv3 access control should be the preferred method for restricting access to important information.  If noAuthnoPriv or the Community table is used, then it should be OK for anyone to access the information, otherwise setup the proper keys for secure access.

IMO, you don't want to force the CM to have to forward the packet upstream, just to have it returned by the CMTS.  This just wastes bandwidth.  Granted that as a dumb bridge this is what would happen.  However, the CM could be smart about it and turn it around internally.

greg

> Sent: Wednesday, January 29, 2003 1:36 PM
> > > > > From: Woundy, Richard 
> [mailto:[email-masked]]

---

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 30 Jan 2003 07:40:54 -0700

Greg, 

I agree with you that v3 noAuthNoPriv is in fact open access whatever is
made to try to secure the MSO SNMP access-level in other flavors of
SNMP. 

As I understand the v3 Auth management will take some time to happen
mainly to reconvert all MSO business and operation processes around
that.

The fact is that NmAccess v1, v2c works and very well. In standard
Network environments v1, v2c may be insecure but in a DOCSIS network is
secure enough (BPI and MSO NMS firewalls around its private network).

Two things:
A)  CM Filters not clear in how to handle snmp traffic directed to CM
IP, 
B) "smart" CMs is valid but is not generalized across the
implementations: 
    One of the reasons for Diagnostic IP (after registration) was to not
having 
    to know the CM DHCP IP.
    Also was brought up that many CMs are not "smart" so the traffic was
in any case 
    lost due the MSO in place gateway UDP/TCP port policy filter in the
return/forward path.

If there is no convergence in what is the required behavior, and all
kind of combinations can happen, no efforts in try to find work arounds
to simulate the vacm Ext interface will conduct to something practical.

We need to know if Coexistence v1, v2c at MSO access-level is needed,
otherwise we have to preclude RFC2576 or state in the spec the trivial
monitoring scope as you said to help MSOs to have a clear migration
path.
Or leave (Rich may have more clues for this) the deprecated NmAccess
(CABLE-DEVICE-MIB) as the main core management at the operational level.

Eduardo

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Wednesday, January 29, 2003 3:41 PM
To: Eduardo Cardona; Woundy, Richard
Cc: IPCDN WG (E-mail); DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] Comments on draft-03 of CABLE DEVICE MIB...

Eduardo,

This issue exists today independent of SNMP.  Has there been any
operational problems caused because of this?

This issue is orthogonal to the SNMP access control.  Seems to me that
the proper SNMPv3 access control should be the preferred method for
restricting access to important information.  If noAuthnoPriv or the
Community table is used, then it should be OK for anyone to access the
information, otherwise setup the proper keys for secure access.

IMO, you don't want to force the CM to have to forward the packet
upstream, just to have it returned by the CMTS.  This just wastes
bandwidth.  Granted that as a dumb bridge this is what would happen.
However, the CM could be smart about it and turn it around internally.

greg

> v3 noAuthNoPriv, is exactly what you say, MSOs should not have more 
> than minimal access to users (any : internal, customers) at that level
> 
> Coexistence v1, v2c is almost what you said, with a little bit of 
> extra protection
> 
> 1) If a CM forward the SNMP CPE to CM IP traffic through the RF there 
> is no problem, traffic goes away
> One solution I see for 2) is to force the CM to not respond directly 
> to SNMP from CPE and forward the packet to RF wich means only with
> the CM may create a relaxed packet handling for arbitrary configured 
> IPs in the CPEs
> 
> 
> Eduardo
> 
> 
> I guess the biggest problem is when we don't use SNMPv3 
> authentication, and when we don't use the docsDevNmAccessTable (e.g. 
> with docsDevNmAccessInterfaces restricting access from the CMCI)
> -- e.g. SNMP
> Coexistence.
> 
> purpose of getting access to the SNMP entity of its own CM ( not 
> traffic intervention  in the RF), ( simulating the NMS network in the
> CPE side),
> becomes a CPE user view ( no interface/subnet filtering). MSO can't 
> have an username for CPE and think in another user ( more
> privileges/access)
> forwarding to RF US and bounce back to CM side due the bridge nature 
> of the implementation.
> 
> What some inmplementations may did was to start listening to SNMP to 
> CM DHCP IP and apply the NmAccess interface filter,
>   
> own CM via SNMP, but not be able to access someone else's CM through 
> the RF interface.  I'm assuming it OK for MSO staff to access the CM.
> 
> public and private networks.  As we've been discussing, it appears 
> there are a few methods in which this can be done.
> 
> > makes is: Address Q1 in Coexistence v1, v2c

> > interface (i.e. from the CPE) that is addressed to the private 
> > network, the forwarding table would not have a route for it and 
> > discards the packet.
> > 
> > > reflector.  I believe the generally accepted interpretation is 
> > > that traffic addressed to the CM is NOT filtered.
> > > 
> > > part of and the public IP network that the CPE is part of.
> > > Typically, the CMTS will not route between these networks.
> > > 
> > > > CM unable to register.  In the other hand the
> > > > MSO/technician/User, must know the CM IP that could be a problem

> > > > or not desired always.
> > > > reconfigure the user CPE any time that a user may need to talk 
> > > > to the CM.
> > > > 
> > > > 
> > > > interface is still allowed if the proper SNMP access controls 
> > > > are setup.
> > > >