[LinkSec] Linksec call 9/02/03

["Dolors Sala" <dolors@ieee.org>]

This is a summary of the discussion in the last linksec call (9/02/03).

To call participants: Feel free to add, comment or clarify anything.

Comments and discussion are welcome from all.

 

There is no call next week. The next call is the following week on Sept 16.

 

The meeting is on Sept 22th. Please prepare the material to present the week before so we can post it on time to download before the meeting. Another message will be sent on this respect.

 

Dolors

 

---

 

Attendees: Onn Haran, David Johnston, Marcus Leech, Tom Dineen, Paul Congdon, Dolors Sala

 

We reviewed DJ material on cyphersuites.

 

The proposal on parameter specification of MACsec is using a cyphersuite with a well defined combination of options. The proposed options are:

    * Null

    * authorization only

    * AES-CCM mode (cheap and slow option)

    * AES-OCB mode (more expensive but fast option)

 

There seems to be agreement within the participants on this approach and options.

 

Since several technologies will use MACsec, options need to be optional. But a mandatory option is needed (in addition to the NULL option) for every technology.  There was discussion on what is the best way to define it, either allow every technology to define their mandatory option in a separate document or incorporate it in a table in MACsec. It is probably the same. Question is what is the easiest way to avoid administration process (PARs...). The consensus seems to be to define a default option mandatory for all to be used in case of nothing else defined. This also addresses the question of which option to use for provider bridges; this case needs a general option.

 

The proposed assignment of Ciphersuite ID is using ranges. Other participants seem to consider an ordinal order (1,2,3,...) a better option. It is easier to maintain consistency in the assignment policy in the future. We do not know how things may evolve and this fast/slow ranging may not be the significant one.

 

There seem to be interest (and consensus) on defining a single crypto scheme for integrity (authentication only mode) and confidentiality (other modes). This leads towards a CBC MAC function.

 

---

 

Summary and next steps:

 

There seems to be quite an agreement on the way to specify the parameters. So the next step is to discuss the header format with specific fields and sizes. This is the topic for next call.

 

DJ has some material from the discussion in 802.16.

 

The increase of frame size is an important issue for 802.3. Hence there is interest in having some of this discussion across the two reflectors (802.1, 802.3).

 

There could be an option of decreasing the MTU instead of increasing the frame size (as 802.11 is doing). This is something it has not been discussed in 802.3 but has a lot of impact with leverage equipment. But may be worthwhile exploring the tradeoffs.

 

One reasoning on how much the frame size may increase:

A hard limit of the frame size is 1636 (length field), subtracting the max frame size of 1618 and the 4 bytes of VLAN tags translates to a maximum increase of 14 bytes. This is not big enough for some implementations.

 

----

 

Next steps:

 

Discussions on frame formats and increase of frame size will be initiated on the reflector.

DJ will send material for discussion in a call  but he is attending his meeting next week.

 

Next call on Sept 16th (No call on Sept 9th).