RE: [LinkSec] EPON material
Mick,
I appreciate very much that you have studied the EPON case from the links I provided.
Maybe I exaggerated a little in saying that the planned security layer is near layer 3. However, I am not ready to fully withdraw the statement. You mention that security is below the MAC Service boundary and below the functionality provided by the bridge relay entity of .1D and .1Q. However, if multihop security with peer-to-peer model is supported, that security would practically share the bridging layer in the stack. Furthermore, at least in current 802 systems the upper layer is constantly required to mess with L2 by initiating ARP requests to make L2 memorize its topology. Since bridging is so dependent on ARP requests, one could argue that the "bridging and security" box in page iii of romanow_1_0703.pdf is near L3.
The answers below refer to Mick's comments about documents 3, 4, 7, and 8 in http://grouper.ieee.org/groups/802/3/efm/public/sep02/sec/. Mick's comments can be found further below in this email.
#3 The fact that MAC address encryption has been rejected does not make it the best choice for EPON. As once earlier, I suggest to visit the URL
http://network.ucomm.wayne.edu/vendor_count/index.php?submit=count. Let's say the last mile of a VLAN connection between a head office and a branch office is realized by an EPON access link. Other access customers sharing the same EPON with the branch office are able to make the analysis shown in the URL of all networked equipment both in head office and branch office that communicate over the link. A competitor company nearby could, for example, measure how much the machines in the branch office communicate to outside world through the company's firewall router residing at the head office. Of course, spying can be carried out in many places by accepting a small risk of getting caught and punished of tapping someone others wire but in EPON one can do it safely by monitoring one's own EPON interface. I'm sure operators will hesitate to deploy EPON, at least in business areas if MAC addresses are on the clear. I would hesitate to accept it in residential area either.
#4 Slide 2. In this slide we consider identity protection. Naturally, by using traffic analysis, one can find out what kind of traffic there is, but if someone claims that obscuring addresses is a minor obstacle in breaking identity protection (a slightly different aspect from what you commented), one should accompany that with a reference to a published investigation. Otherwise those claims should be disregarded. Traffic analysis can hardly make the above mentioned stock-of-equipment analysis. Maybe traffic analysis is able to pinpoint users with a relatively high probability from a series of data. However, if LLIDs and MAC addresses are obscured well enough, probabilities will start to work against an eavesdropper. Remember that it is difficult to store 1 Gbit/s traffic for long periods of time to be able to correlate the traffic profiles.
#4 Slide 3: Document #4 mentioned also those threats where real defense methods do not exist. Brute force attacks are such threats. It does not mean, however, that we should surrender completely. If there are means to recognize brute force attacks, an OLT, for example, should warn network management or at least make a log of the suspected attack.
#7 (1) The suggested EPON subgroup within LinkSec would be useful in helping to develop a simple single-link scenario that fits into MACsec standard. That group should be allowed to discuss internally the benefits of encrypting MAC addresses. (2) I tend to agree with this comment. (3) The current wired access transport (hundreds of millions of customers worldwide) omits man-in-the-middle case almost exclusively and relies on physical protection at link layer (L2). Will we find any customers who have relied until now on physical protection who would pay for a new L2 service that protects from man-in-the-middle threat at L2? (Wireless is a different story). I agree that a higher layer method can also be simplified by omitting man-in-the-middle attack although in multi-hop case there is practically no choice but to include it.
#8 The problem of trying to cover a broad range of solutions has been discussed way too little. I agree that authentication and the negotiation of encryption method could benefit from a more general solution. However, trying to find a good, general solution may multiply the required work in addition to leaving systems defendless against attacks carried out below the intended security layer. In addition, 802.11, .15, and .16 have single-link security schemes designed already. The .11 and .16 participants with whom I have discussed are reluctant of even thinking to re-engineer their systems to comply with the requirements of LinkSec.
Antti
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf
> Of ext Mick
> Seaman
> Sent: 17 August, 2003 19:33
> To: stds-802-linksec@ieee.org
> Subject: RE: [LinkSec] EPON material
>
>
>
> Annti,
>
> I have looked at your slides and they seem to consist of your
> simple assertion, not new, that security can not be modeled
> as a MAC Independent function below the MAC Service boundary
> - with no data to back it up. It is absolutely not true that
> the 802.1 MACsec works "resides relatively high in the stack
> near layer 3". It is below the MAC Service boundary and below
> the functionality provided by the bridge relay entity of .1D and .1Q.
>
> Relative to your list of EPON documents:
>
> #3 - it is true that we have rejected MAC Address encryption
> (which the document says we should study - which we have, and
> rejected for good reasons), otherwise I see no objective
> stated in this presentation that can not/will not be met.
>
> #4 - Slide 2 suggests that traffic analysis can be prevented
> by simply obscuring MAC Addresses and LLIDs and encrypting
> user data. As discussed at the last meeting, the methods used
> by those who are clever at traffic analysis would easily
> overcome such trivial obstacles, so the defence is not worth
> having. Slide 3 suggests that it is necessary to protect
> against a brute force denial of service attack on a shared
> media - I would suggest that this is simply impossible. There
> is a point here about more subtle attacks on OAM channels
> which deserves serious consideration as to whether access to
> an OAM channel should be treated as access through a MAC SAP
> - in which case the MACsec security should be applicable just
> fine. Slide 4 talks about an attack on user data integrity
> (malicious modification) which MACsec will handle just fine.
> I see nothing else in these slides we are not covering.
>
> #7 - Suggests that the special characteristics of EPON be
> used to simplify the security solution. This boils down to
> saving bytes for three reasons - (1) the point to point/point
> to multipoint nature of EPON allows the SAID to be very brief
> since the parties in the association are known, another way
> of thinking about this is that the LLID supplies part of the
> SAID (2) the timing characteristics of EPON can be used to
> convey an initialization vector and provide replay protection
> (3) the man-in-the-middle attack can be dismissed (it is
> claimed) since the fiber can't be interfered with. Taking
> these points one by one : (1) there is no reason at all that
> MACsec can't optimize down the size of the SAID on point to
> point links or virtual point to point links, and this has
> been specifically suggested. Use of this approach on EPON
> would be assisted by a proper description of the point to
> multipoint service as a MAC service, and I would suggest that
> we work on this in the context of P802.1ac. (2) I don't
> believe an initialization vector needs to be carried in each
> frame of MACsec in any case, as this can be distributed
> infrequently (as compared to data) with other key information
> and by the same means. Whether replay protection is of any
> value at or below link is an issue we still have to conclude.
> In any case I would be very wary of relying on timing
> characteristics to protect against replay. (3) If the
> man-in-the-middle attack can be dismissed for any significant
> market, it is entirely possible that we define a
> "confidentiality without integrity" service in MACsec and
> omit the check vector. There is nothing about low or high in
> the MAC layer that impinges upon this choice. I personally
> think there is much more interest in "integrity without
> confidentiality", but the point is that the case for
> disregarding an intermediate intruder can be made just as
> well within MACsec as currently envisaged as within an EPON
> specific framework.
>
> #8 - Considers preamble encoding of security information so
> as to circumvent the need to discuss Ethernet frame size
> again. I think we are over that hurdle since we require to
> have that discussion for the broad range of solutions.
>
> Mick
>
>
>
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of
> antti.pietilainen@nokia.com
> Sent: Thursday, August 07, 2003 6:27 AM
> To: stds-802-linksec@ieee.org
> Subject: [LinkSec] EPON material
>
>
> Hello all,
>
> In the last conference call it was agreed that I would
> provide EPON text that could be incorporated into the draft.
> After considering, I decided to do differently. EPON people
> have to find an adequate level of consensus before text could
> written that would have some chances of acceptance. People
> that were active on the area of security in EFM, have been
> passive for about one year and have been waiting to see how
> the LinkSec work starts to evolve.
>
> I noticed that the current draft represents quite different
> approach than considered by point-to-multipoint (P2MP) sub
> task force in EFM meetings. Therefore, I wrote a document
> "EFM - 802.1 cooperation" which points out a difference
> between EPON model and the current output of LinkSec, which I
> call the 802.1 model.
>
> People interested in EPON security should now consider
> whether they agree that it would be helpful to create either
> formal or informal EPON subgroup within LinkSec. If so,
> please contact me.
>
> Please visit
http://grouper.ieee.org/groups/802/3/efm/public/sep02/sec/ to study documents 3, 4, 7, and 8 to see aspects of the EPON model.
best regards
Antti
Antti Pietilainen
Nokia Research Center
P.O. Box 407
00045 NOKIA GROUP
Finland
tel. +358(0)71-8036660, fax. +358(0)71-8036214