RE: [LinkSec] LinkSec 80-2.1AE Teleconference notes 9/16/03
The provider bridge issue was the fact that provider bridges were the
only scenario that (given a default minimum security mode for a given
MAC/PHY) the other end might legitimately try to negotiate a mode of
lower security than the default, since the other end might be a
different MAC/PHY with a default of lower security.
My proposal was that this sort of 'negotiating down' shouldn't be
allowed and the lesser device would be required to negotiate up. This
way a device would not need to try and distinguish between a legitimate
other end over a provider bridge and an attacker impersonating a
provider bridge in order to cause a negotiation to a lower security
level.
Rene suggested the opposite position, that the aspects of higher
security (like a longer PN or ICV) would be an undue imposition on lower
speed devices.
So it's either:
1) Allowing 'lower security' packets onto a higher speed network via a
provider bridge, enabling an attacker to attack it with a higher speed
PHY not assumed in the design of the packet format
Or
2) Not allowing the above and imposing greater throughput constraints on
already slow links.
This is an issue to resolve or avoid by stealth and cunning.
-----
The .10 thing (that I remember) came from my observation that .10
allowed MTU contraction where the service supports it and fragmentation
where it does not.
The counter argument was that the fragmentation in .10 was very general.
Having not read up on .10 (everything I know about .10 came from emails
by Norm and Russ) I had assumed the fragmentation was of a trivial type
(one extra frame max) and I wasn't expecting anything more would be
proposed.
So my position moved to the concept being just fine, but if .10 is not a
good instance of the idea (change MTU + frag if you have to) then lets
write good one.
DJ
David Johnston
Intel Corporation
Chair, IEEE 802 Handoff ECSG
Email : dj.johnston@intel.com
Tel : 503 380 5578 (Mobile)
Tel : 503 264 3855 (Office)
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org] On Behalf
> Of allyn romanow
> Sent: Saturday, September 20, 2003 3:25 PM
> To: Russ Housley; allyn romanow; stds-802-linksec@ieee.org
> Subject: Re: [LinkSec] LinkSec 80-2.1AE Teleconference notes 9/16/03
>
>
>
> Russ, sorry, some of this should have been edited out as it's
> incomplete,
> see below.
> I've written what I thought the speakers meant, but if they
> would clarify
> it would be better--
>
> Allyn
>
> At 11:08 AM 9/20/2003 -0400, Russ Housley wrote:
>
> >I do not understand these paragraphs. Please explain.
> >
> >Russ
> >
> >At 11:14 PM 9/19/2003 -0700, allyn romanow wrote:
> >>Isn't key management policy outside of scope? Yes but need to define
> >>a security assoc that presupposes a key update mechanism
>
> I think this makes sense and refers to the fact that there
> are/will be
> multiple efforts under "linksec"- one is MACsec, the protocol
> definition,
> which does not do key management. I took this comment to mean
> that the
> general work of linksec includes key management, though
> MACsec doesn't.
> The person who said it could clarify further--
>
> >>.10 problem was that it allowed non interoperable
>
> sorry, incomplete notes
>
>
> >>Don't want to end up with the requirement that you would
> have to tell,
> >>or know what kind of bridge station is on
>
> I think this meant that the person felt that knowing whether
> a packet is
> going through a provider bridge or not, should not be
> knowledge that is
> required to make the security protocol work
>
> >>.10 fragmentation shouldn't be followed, allows arbitrary
> fragmentation
>
> I think the person who said this feels that 802.10 allows an
> arbitrary
> amount of fragmentation, in this case, more than
> fragmentation into two
> segments, and that he feels that he does not want LinkSec to do
> fragmentation in the same way that 802.10 did.
>
>
>
>