IEEE 1910 Working Group meeting
Online Webex
March 7, 2014
4 PM to 6 PM
Call to order
Nirmala Shenoy, Chair of the IEEE 1910 Loop-Free Switching and Routing Working Group, called
the meeting to order at 16:05 EST.
Welcome, introductions, and disclosure of affiliations
Nirmala Shenoy asked the attendees to introduce themselves and announce their affiliation.
I
n Attendance
Nirmala Shenoy – RIT - Chair
Bill Stackpole - RIT - Secretary
Bruce Hartpence - RIT - Vice Chair
Daryl Johnson - RIT - Vice Chair
Lisa Perry - IEEE Standards Association - supports working group from staff side of IEEE
Reinhard Schrage – Schrage Consulting
Joseph Burnham - (no telephone access / headset issues)
Nirmala Shenoy called for patents. No claims were made. For claims either contact Nirmala or
Patent Com Administrator (IEEE website)
Review and approval of the agenda
Nirmala Shenoy asked if there were any additions to the draft agenda. None
responded
Motion #1
M: Bill Stackpole
S: Daryl Johnson
Passed by voice vote without opposition
Approval of meeting minutes from previous meeting on Policies and Procedures
Nirmala brought up the meeting minutes for review and discussed content. To insert names and
affiliations in the document
Motion #2
M: Bill Stackpole
S: Bruce Hartpence
Passed by voice vote without opposition
Discussion points for the 1910.1 project
1. Develop the protocol with or without security?
2. Meshed tree basic operations
Develop the protocol with or without security?
Should one allow layer 2 switched networks to be formed



Without authenticating switches joining the network?
Without encrypting switch control messages?
With data encrypted between end stations?
Daryl Johnson initiated a discussion to solicit commentary.
 Discussed issues of default configurations.
 Additional processing requirements for encryption.
 Implications of resolution times related to encrypting/decrypting traffic.
Reinhard contends that having an OPEN connection would be easier than managing all of the
overhead of a secure mode from the start
Nirmala asked about how we might have multiple levels of security and to elaborate on this.
Daryl addressed this with the following: (see table)
 level 1 passphrase only
 level 2 common certificate for authentication / encryption
 level 3 with each switch having a UNIQUE (rather than common)
certificate
For each encryption level, the encryption could be used for
Authentication
Encrypting control/management traffic
Encrypting all forwarded traffic (including control/management.)
Level # \ Application
1 – Pass Phrase
2 - Common Cert
3 - Unique Certs
Authentication
Management/control
Everything
Nirmala - should we consider encrypting communication of end stations?
Bruce said not a novel thing - should this be a responsibility of the switching protocol, the end
node, or something/somewhere else?
Daryl responded with the following points
 limits Man in the Middle / spoofing / other "traditional" attacks
 Mesh tree is in a position to do this fairly easily so that the topology can
incorporate security into the protocol from the start.
 including encryption from the start can help privacy issues
There was some discussion about what potential legal issues might be.
What about encrypting user data? What are the implications?
Reinhard - suggests that we have a written document to ensure that we capture the thoughts
discussed. As we are due to come out with a standard - we will need to decide how to ensure
that the contributions are well documented and edited.
Discussions on Authentication and Encryption of the traffic between switches.
The 3rd question was do we also encrypt the forwarded traffic between the switches. Reinhard
indicated that it's a good idea, but takes extra processing power. And Joe added that it could
slow traffic some.
Daryl: The question being posed is whether or not a connection should be permitted WITHOUT
being encrypted.
Reinhard: I think a connection does not have to be encrypted right from start up.
Joe: Is there authentication?
Nirmala - moving to the next topic.
Meshed Tree Basic Operations
At RIT Opnet was used to simulate the protocol
Some of the Processes identified were
1. Initialize,
2. Check on port status (root switch v non-root switch),
3. Timers,
4. Packet types.
INITIALIZATION: - upon startup (and in an ongoing basis) - record number of active (A)
ports, number of Meshed_Tree (MT) ports, number of Host (H) ports, and record disabled
ports (D)
ROOT Vs NON-ROOT SWITCH - see slide 11 of Nirmala's presentation.
Slide 12 - Discussion regarding the Meshed Tree Virtual ID table(s)
Bruce and Nirmala elaborated on the current configuration and ideas that are currently under
discussion
Slide 13 - discussion about VSATs (Virtual Source Address tables)
Slide 14 - How switches store VSATs and update VSATs was discussed
17:58 - motion to adjourn (Bill) - Seconded by Bruce Hartpence
Meeting Adjourned.
*** End Meeting Notes ***