Subject: RE: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-02.txt

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 3 Mar 2005 16:59:24 +0200

I can live with this - this was a contributor opinion anyway, if this was not clear. 

Regards,

Dan

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: 03 March, 2005 4:51 PM
To: Romascanu, Dan (Dan); [email-masked]
Subject: RE: [Hubmib] 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-masked]]
Sent: Thursday, March 03, 2005 9:35 AM
To: Matt Squire; [email-masked]
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-masked]]
Sent: 02 March, 2005 8:41 PM
To: Romascanu, Dan (Dan); [email-masked]
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-masked] [mailto:[email-masked]]On Behalf Of Matt Squire
Sent: Wednesday, March 02, 2005 2:45 AM
To: Romascanu, Dan (Dan); [email-masked]
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-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 3 Mar 2005 10:26:12 -0500

I accept this as well.

My main concern was that there had been no discussion of the
additional complexity involved in having the NMS correlate entries
across devices using sysUpTime. However, to realize the benefits, the
agents would need to keep their clocks synchronized, which puts a
burden on the agents. Following basic SNMP philosphy, if there must be
complexity, it is better to have the manager suffer the complexity
than the agent.

I do agree with Dan's point, however. The MIB modules should be
consistent in how they address the problem.
 
David Harrington
[email-masked]
________________________________

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

	I can live with this - this was a contributor opinion anyway,
if this was not clear. 

	Regards,

	Dan

		-----Original Message-----
		From: Matt Squire
[mailto:[email-masked]]
		Sent: 03 March, 2005 4:51 PM
		To: Romascanu, Dan (Dan); [email-masked]
		Subject: RE: [Hubmib] 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-masked]]
			Sent: Thursday, March 03, 2005 9:35 AM
			To: Matt Squire; [email-masked]
			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-masked]]
				Sent: 02 March, 2005 8:41 PM
				To: Romascanu, Dan (Dan);
[email-masked]
				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-masked]
[mailto:[email-masked]]On Behalf Of Matt Squire
					Sent: Wednesday, March 02,
2005 2:45 AM
					To: Romascanu, Dan (Dan);
[email-masked]
					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?