martillo@cpoint.UUCP (Joacim Martillo) (01/27/89)
Anyone know of any references to layer encapsulation in official OSI or CCITT documents. The problem is as follows: LLC type II is reliable and one might want to provide security on a per logical link basis, Unless you want to provide reliability in the security layer itself, to make sure that applications which run in a secure environment, you want to put the security layer between LLC and the MAC layer, but at that point in the stack the protocol software should only be looking at the MAC addresses and security cannot be provided on a per logical link basis. And if the security layers lives at the top of LLC, then the security layer has to provide reliability. I vaguely remember having this problem at Bell Labs when working on Data Teleconferencing and the solution was layer encapsulation where the security procedures would encapsulate the protocol layer, but I simply don't remember where this was described in the CCITT or OSI documents. If someone could give a pointer, I would be grateful.
martillo@cpoint.UUCP (Joacim Martillo) (02/02/89)
In article <2016@cpoint.UUCP> martillo@cpoint.UUCP (Joacim Martillo) writes: >Anyone know of any references to layer encapsulation in official >OSI or CCITT documents. The problem is as follows: >LLC type II is reliable and one might want to provide security >on a per logical link basis, Unless you want to provide reliability >in the security layer itself, to make sure that applications which >run in a secure environment, you want to put the security layer >between LLC and the MAC layer, but at that point in the stack >the protocol software should only be looking at the MAC addresses >and security cannot be provided on a per logical link basis. >And if the security layers lives at the top of LLC, then the >security layer has to provide reliability. >I vaguely remember having this problem at Bell Labs when working >on Data Teleconferencing and the solution was layer encapsulation >where the security procedures would encapsulate the protocol >layer, but I simply don't remember where this was described in >the CCITT or OSI documents. If someone could give a pointer, >I would be grateful. I am following the current deliberations of the 802.10 committee on this issue. Tony Bono had what I consider a good original proposal for an architecture to deal with the issue. Apparently, the committee could not shoot down the proposal, but because he did not give a detailed functional specification (which was not what I understood to have been originally requested), the committee decided that they would only provide security procedures at the boundary between LLC and the MAC (based on pairwise MAC addresses) and not at the boundary between the Network Layer and LLC based on LSAP/DSAP pairs for a given MAC layer connection. Personally, I can think of many reasons why one might want to provide pairwise LSAP/DSAP security rather than simply point-to-point MAC address based security. It seems to me perfectly reasonable that Network Management communications streams, OSI communications streams or TCP/IP communications streams might all require different security procedures at the boundary between LLC and the network layer. Personally, I would think distributed multi-level security would be a nice thing. Providing security procedures on a per LSAP/DSAP basis would give the possibility of multi-level security at the link-layer, so that a given host might be able to realize that a given data stream from a host was trusted at a secret level because the user had logged into the console in a room guarded by guys with machine guns while another data stream from the same host was not trusted at all because the user had dialed in from outside. I see this situation all the time. Everytime someone wants to incorporate some new idea into OSI which actually give some reason to switch from TCP/IP to OSI, it gets shot down at the committee level. Now I understand why the best standards are those which were ad hoc standards first, and only much later standardized by the international committees. Any comments?
pete@sun360.Online.Nixdorf.De (pete delany) (03/18/89)
In article <2028@cpoint.UUCP>, martillo@cpoint.UUCP (Joacim Martillo) writes: > Path: nixctc!unido!mcvax!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!encore!cloud9!jjmhome!cpoint!martillo > From: martillo@cpoint.U> > > I see this situation all the time. Everytime someone wants to > incorporate some new idea into OSI which actually give some reason to > switch from TCP/IP to OSI, it gets shot down at the committee level. > Now I understand why the best standards are those which were ad hoc > standards first, and only much later standardized by the international > committees. Any comments? I've been hacking on OSI code for the past few years, and I also doubt the value of spending a lot of money trying to get people to accept these standards dictated by the central committees. Clearly, the problem is with the 'authorities' participating in the market. Pete Delaney - Nixdorf UCC | pete@NIXCTC.DE Prefered Addr Loffel Strasse 3 | pyramid!nixctc!pete UUCP from Calf 7000 Stuttgart 70 | pete@RELAY.HUJI.AC.IL Backup Address West Germany | Phone: +49 (711) 7685-128