RE: Comments on draft-ietf-hubmib-efm-mib-02.txt

Back in Dec, multiple people weighed in that a TimeStamp was preferred over a DateAndTime.  Additionally, multiple people weighed in that they preferred one object over two.  I don't think anyone weighed in with a preference for using both.  Even the person that brought it up as a possibility (I think you know him!) had reservations about using both.  
 
So unless I hear that multiple people have preference for using both objects as time indicators for when events happened, I'd suggest we use TimeStamp and settle with that.
 
- Matt

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email protected]]
Sent: Thursday, March 03, 2005 9:35 AM
To: Matt Squire; [email protected]
Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt


I would suggest that we reach here a solution consistent with the EFM Cu MIB. There we decided to keep both a DateAndTime and a TimeStamp object. If DateAndTime cannot be filled in, then a all-zeros value will be used. 
 

Regards,

Dan

-----Original Message-----
From: Matt Squire [mailto:[email protected]]
Sent: 02 March, 2005 8:41 PM
To: Romascanu, Dan (Dan); [email protected]
Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt


 
One other technical issue to close out on (from a completely different thread) was related to whether the log entries of OAM events should use DateAndTime or TimeStamp objects.  This thread was discussed in December (see archives) and the strong consensus of the list was that a TimeStamp based on sysUpTime was much more universal and therefore much better.  So I'm also making the change to that object to use sysUpTime as a time indicator rather than DateAndTime. 
 
- Matt
 

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Matt Squire
Sent: Wednesday, March 02, 2005 2:45 AM
To: Romascanu, Dan (Dan); [email protected]
Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt


A stab at the technical issues below.  Thanks again.
- Matt



Technical

T1. I do not agree with the assertion made in the Security Consideration section that the read-write objects defined in this MIB module do not impact the users traffic, because they are only controls of the OAM protocol. For example the dot3OamLoopbackCommand object, puts the link on loopback mode. Even if there is another object that allows for the remote device to ignore the loopback commands, this does not help if the loopback command objects are activated in an improper manner. Also, an object like dot3OamAdminState if set to disabled(1) will cut-off the OAM functionality of the device, which does have a negative impact on the network behavior and can be considered as a possible source of attack. I would suggest that the editor makes another pass through the read-write objects and explicitly describes all the potential security hazard resulting from inadequate write operations on these objects.  

 We can break down the read-write objects pretty easily.  There are: 

1) AdminState & Mode.  I tried to address these variables (without calling them out explicitly) in the first 2 paragraphs of the security section by saying turning on OAM doesn't take up a lot of BW but it opens up the possibility of information access, and should be used in deployments where thats ok.  And that the mode can be used as a variable to control/limit that access.  

2) Loopback.  I have a paragraph on the dangers of loopback already.  

3) Event configuration.  I left out these r-w objects because I'm not sure how dangerous they are. Writes on these objects could result in more .3ah event notifications, but the frequency is controlled by the OAM protocol, so I didn't consider that a big threat.  They could also result in SNMP notifications, but again the frequency is controlled.  Since the frequency didn't seem a big deal, whats left seems to just be the threat of the information getting out from the notifications or OAM events.  But thats controlled by the adminState and mode, and didn't appear to be any more/less of then the information access generally available by enabling OAM in a mode that allows that access.  So I didn't mention it any more than the earlier things.  

So I should definitely mention that disabling OAM can interfere with certain management capabilities.  I can walk thru the logic on the event r-w objects if you think they deserve mentioning.  I'm not sure what to add beyond that.  

T2. What is the DEFAULT value of read-write objects like dot3OamAdminState and dot3OamMode? You need to describe the desired behavior of the agent at initialization before the first SetRequest command 

dot3OamAdminState already had some text on the default state being disabled.  But you're point is well taken. I made another scan for all read-write objects,and ensured each had at least a sentence reflecting the default state.  For most objects, it was fairly easy.  The only one I'm not sure about is the default dot3OamMode.  Its not clear that a default of passive or active is universally acceptable. For that object, I'm suggesting the following text on default value:  

"       The default value of dot3OamMode is dependent on the type of
       system on which this Ethernet like interface resides.  The
       default value should be 'active(1)' unless it is known that
       this system should take on a subservient role to the other
       device connected over this interface.  An example would be a
       modem or demarcation device on a customer premise, connected to
       carrier equipment at a central office. 

"

T3 In the Security section: 'By default, OAM is disabled on Ethernet-likeEthernet like interfaces and is therefore not a risk.' First there is an editorial problem (repeated words). Second, there may be a technical issue. As far as I remember from my participation in the EFM work, there is no interdiction in the standard to apply OAM to a non-EFM Ethernet interface. Did this change in the latest part of the work, when my attendance became rare?   

OAM can be applied to any Ethernet interface, EFM or otherwise. Is that what you're asking?

_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib