From owner-ietf-ppp@merit.edu Mon Jan 4 12:13:51 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id MAA09672; Mon, 4 Jan 1999 12:11:05 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 4 Jan 1999 12:03:59 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA09543 for ietf-ppp-outgoing; Mon, 4 Jan 1999 12:03:58 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA09530 for ; Mon, 4 Jan 1999 12:03:52 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id MAA02597 for ietf-ppp@merit.edu; Mon, 4 Jan 1999 12:03:52 -0500 (EST) Received: from cats.ucsc.edu (rumpleteazer.UCSC.EDU [128.114.129.45]) by merit.edu (8.9.1a/8.9.1) with ESMTP id VAA11354 for ; Fri, 1 Jan 1999 21:05:01 -0500 (EST) Received: from sasha.UCSC.EDU (12@sasha.UCSC.EDU [128.114.129.29]) by cats.ucsc.edu (8.8.6/8.8.4.cats-athena) with ESMTP id SAA00506 for ; Fri, 1 Jan 1999 18:05:04 -0800 (PST) From: Jim Warner Received: (from warner@localhost) by sasha.UCSC.EDU (8.8.8/8.8.8.cats-client) id SAA03213 for ietf-ppp@merit.edu; Fri, 1 Jan 1999 18:04:55 -0800 (PST) Date: Fri, 1 Jan 1999 18:04:55 -0800 (PST) Message-Id: <199901020204.SAA03213@sasha.UCSC.EDU> To: ietf-ppp@merit.edu Subject: draft pptp-07 comment Sender: owner-ietf-ppp@merit.edu The draft says in the security section: | 8. Security Considerations | | The security of user data passed over the tunneled PPP connection is | addressed by PPP, as is authentication of the PPP peers. Please consider turning this into a real reference with a footnote number. Speaking for myself, I haven't got a clue what I should read to follow up on this. Thanks. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Jan 4 12:20:38 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id MAA09919; Mon, 4 Jan 1999 12:19:10 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 4 Jan 1999 12:18:01 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA09876 for ietf-ppp-outgoing; Mon, 4 Jan 1999 12:18:00 -0500 (EST) Received: from main.via-net.net (main.via-net.net [209.116.97.64]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA09869 for ; Mon, 4 Jan 1999 12:17:50 -0500 (EST) Received: from bluegill (BLUEGILL.via-net.net [199.233.185.124]) by main.via-net.net (Post.Office MTA v3.5 release 214 ID# 0-52517U2500L250S0V35) with SMTP id net for ; Mon, 4 Jan 1999 12:16:40 -0500 Message-Id: <4.1.19990104121458.00968e60@via-net.net> X-Sender: KFox@via-net.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 04 Jan 1999 12:17:42 -0500 To: ietf-ppp@merit.edu From: Karl Fox Subject: New e-mail address Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu As I mentioned a few days ago, I no longer work for Ascend. I had hoped they would forward my e-mail for a while, but my former boss is refusing to do so. Consequently, please make sure you use my new address, karl@xc.org, rather than my old (and now defunct) addresses, karl@morningstar.com and karl@ascend.com. Sorry for the inconvenience, Karl Fox karl@xc.org PPPEXT Chair - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jan 5 16:06:46 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id QAA08571; Tue, 5 Jan 1999 16:03:01 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 5 Jan 1999 15:49:25 -0500 Received: by merit.edu (8.9.1a/8.9.1) id PAA08003 for ietf-ppp-outgoing; Tue, 5 Jan 1999 15:49:23 -0500 (EST) Received: from adtrn-srv1.adtran.com (mailin.adtran.com [206.166.249.110]) by merit.edu (8.9.1a/8.9.1) with ESMTP id PAA07966 for ; Tue, 5 Jan 1999 15:48:49 -0500 (EST) Received: from shannon.adtran.com (shannon.adtran.com [172.22.16.9]) by adtrn-srv1.adtran.com (8.8.8/8.8.8) with SMTP id OAA10551; Tue, 5 Jan 1999 14:48:08 -0600 (CST) Received: by shannon.adtran.com (SMI-8.6/SMI-SVR4) id OAA13963; Tue, 5 Jan 1999 14:52:21 -0600 From: sventers@adtran.com (Stuart Venters) Message-Id: <199901052052.OAA13963@shannon.adtran.com> Subject: Re: PPP at STS-192c draft To: smerchant@cimaron.com Date: Tue, 5 Jan 1999 14:52:21 -0600 (CST) Cc: ietf-ppp@merit.edu X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Shahrukh, With regards to aquiring frame sync when running over a raw bit stream and in particular determining if you are in framing alignment. What if you calculated a check code for each contiguious group of non-flag words and included the check value in the flag word following the group. If the check code were one bit long, would this provide the ability to determine if you are in alignment? Cheers, Stuart Venters - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jan 6 15:41:17 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id PAA02182; Wed, 6 Jan 1999 15:40:13 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 6 Jan 1999 15:32:45 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id PAA01925 for ietf-ppp-outgoing; Wed, 6 Jan 1999 15:32:44 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id PAA01920 for ; Wed, 6 Jan 1999 15:32:40 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id PAA09097 for ietf-ppp@merit.edu; Wed, 6 Jan 1999 15:32:39 -0500 (EST) Received: from cbgw2.lucent.com (cbgw2.lucent.com [207.24.196.52]) by merit.edu (8.9.1a/8.9.1) with SMTP id OAA01001 for ; Wed, 6 Jan 1999 14:58:56 -0500 (EST) Received: from pai820exch001h.wins.lucent.com by cbig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id OAA17715; Wed, 6 Jan 1999 14:59:17 -0500 Received: by pai820exch001h.micro.lucent.com with Internet Mail Service (5.5.2232.9) id ; Wed, 6 Jan 1999 14:58:35 -0500 Message-ID: <15A2D77655CDD1118B5500805F6FE87A013F0334@pai820exch002u.micro.lucent.com> From: "Langner, Paul (Paul)" To: "'Andrew G. Malis'" , ietf-ppp@merit.edu Cc: smerchant@cimaron.com Subject: RE: PPP at STS-192c draft Date: Wed, 6 Jan 1999 14:58:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Andy, With regards to the packet transfer of 8 packets, this is a provisionable value and is under investigation as to how to best use it in conjunction with the A/B messages. (i.e. once sync has occurred, space out the scrambler state retransmits). The other option is to retransmit after a certain number of bytes, which eliminates the long/short packet arguement. It is unclear what the best option will be. WRT the x^43 history, if you are referring to its use in ATM, it works OK there because the header isn't scrambled and provides transition density. Paul Langner -----Original Message----- From: Andrew G. Malis [mailto:amalis@casc.com] Sent: Tuesday, December 22, 1998 10:33 AM To: ietf-ppp@merit.edu Cc: smerchant@cimaron.com Subject: Re: PPP at STS-192c draft In his note on error multiplication, Dennis brought up SDL for OC-192c. I thought it was somewhat "interesting" that there wasn't anyone from Lucent at the meeting to present it. Dennis noted at one point in his note that he has some reservations about SDL (before he went on to sing its praises :-). I also have some comments about SDL that I haven't seen discussed on the list, so I thought I might mention them briefly, in no particular order: While the basic per-packet overhead is similar between HDLC-32 and SDL, SDL also needs to transfer the scrambler state in a special 12 byte packet every 8 packets, which adds additional overhead (especially given the number of TCP ACK packets out there). SDL's main claim to fame is the fixed overhead, since there aren't escapes. It's always been my opinion that the expansion arguments are very overrated when looking at real-world traffic, especially since there's a large class of IP packets (TCP ACKs, as I mentioned above) that applications cannot maliciously manipulate to try to cause expansion to occur. HDLC-32's use of the inner scrambler obviates that threat as well, as does the increased use of encryption for IP VPNs. Service providers have operational experience with the X^43+1 scrambler, and don't have any issues with it. I also prefer the simplicity of self-synchronous scramblers. I also agree with some of the replies to Dennis' message noting that error multiplication isn't a major worry given SONET error characteristics. Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-2074 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jan 6 15:41:20 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id PAA02188; Wed, 6 Jan 1999 15:40:18 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 6 Jan 1999 15:32:28 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id PAA01906 for ietf-ppp-outgoing; Wed, 6 Jan 1999 15:32:27 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id PAA01902 for ; Wed, 6 Jan 1999 15:32:19 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id PAA09077 for ietf-ppp@merit.edu; Wed, 6 Jan 1999 15:32:18 -0500 (EST) Received: from ihgw1.lucent.com (ihgw1.lucent.com [207.19.48.1]) by merit.edu (8.9.1a/8.9.1) with SMTP id OAA00862 for ; Wed, 6 Jan 1999 14:53:21 -0500 (EST) Received: from pai820exch001h.wins.lucent.com by ihig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id NAA21793; Wed, 6 Jan 1999 13:53:21 -0600 Received: by pai820exch001h.micro.lucent.com with Internet Mail Service (5.5.2232.9) id ; Wed, 6 Jan 1999 14:53:00 -0500 Message-ID: <15A2D77655CDD1118B5500805F6FE87A013F0333@pai820exch002u.micro.lucent.com> From: "Langner, Paul (Paul)" To: "'Dennis Ferguson'" , smerchant@cimaron.com Cc: ietf-ppp@merit.edu Subject: RE: PPP at STS-192c draft Date: Wed, 6 Jan 1999 14:53:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Sharukh, Check out the August IEEE Information Theory for a discussion of how to attack self-synchronizing scramblers on long packets. I haven't gotten around to it yet, but I suspect that it will be possible with a low 1's density probability sequence in 64K packets set up with the inverse SONET scrambler sequence to really cause some good timing recovery problems in POS networks. (This was actually one of the drivers behind SDL). An added note to the complexity arguement on byte escaped HDLC. From my experience, the complexity of building a byte-escaped HDLC engines is roughly nlogn, as the escaping process is done on a per byte basis, and does not depend on run-length history. The logn term arises from the pipelined MUXing that is required after a parallel escaper to store the escaped and potentially expanded bytes in a buffer after the escaper. As such, we had no real complexity issues with at OC-192 using the traditional POS method. So the only thing wrong with traditional POS (in my mind) is: 1) Susceptability to malicious attack by long packets with low ones density after SONET/SDH frame descrambling. 2) Susceptability to malicious attack with 0x7E or 0x7D packets. This can give output traffic schedulers grief when they are depending on known byte delivery in the channel. 3) Single bit errors can cause entire packet loss. 4) No ability to run without byte level framing being done a priori. 5) No real ability to estimate link BER from the channel. Paul Langner -----Original Message----- From: Dennis Ferguson [mailto:dennis@juniper.net] Sent: Sunday, December 20, 1998 11:39 PM To: smerchant@cimaron.com Cc: ietf-ppp@merit.edu Subject: Re: PPP at STS-192c draft Shahrukh, > 1. Choice of SONET payload scrambling polynomial > ------------------------------------------------ > You're right that x^43+1 is not maximal length (although "maximal > length" is harder to define for a self-synchronous scrambler where the > next state is not just a function of the current state, but also of the > input). I think this is the key point. A self-synchronous scrambler is not an LFSR, and doesn't produce a fixed, repeating output, so there is no sequence whose length needs to be maximized. That is, adding the extra term to the x^43+1 (or x^29+1) scrambler does not increase the number of states the scrambler can be in (all 2^43 or 2^29 states are possible in both cases), so adding the extra term doesn't make the precise output of the scrambler any harder to guess. Worse, what I think you're ignoring is the fact that self-synchronous scramblers are error-multiplying and adding more terms just makes a single bit error in the scrambled data turn into more errors after descrambling. That is, a single bit error in the x^43+1 scrambled payload turns into two bits in error after descrambling, one at the location of the bit error and one 43 bits later (i.e. a single bit error is turned into a 43 bit burst). Adding another term to the scrambler increases the number of bits in error after descrambling to 3, which is certainly not an improvement and is intuitively likely to make things worse since error multiplication has implications for error detection. The error multiplication is also the first objection I have to the two nested scramblers you are suggesting. If you run the x^43+1 scrambler over packet payload scrambled by the x^29+1 scrambler, then a single bit transmission error in a packet turns into a 4 bit error after descrambling; one at the location of the bit error, one 29 bits later, one 43 bits later and one 72 bits later. If you add a third term to packet scrambler, you now have a single bit error causing 6 bits to be in error after descrambling. If you also add a third term to the x^43+1 scrambler you end up with a single bit tranmission error turning into 9 errored bits after descrambling. You can't assume that this is without impact on error detection performance of the FCS. As you note later, > the strength of the CRC from 32 to 30 bits." CRC codes typically have > properties like: > > - Detects all single bit errors > - Detects all 2-bit errors for packet lengths <= P > - Detects all burst errors for burst lengths <= Q > - Detects (1-2^-N, N=32 in this case) of all multi-bit errors You are systematically ensuring that all transmission errors, even single bit errors, will have a burst length of at least 72 bits with at least 4 bits in error (6 bits with the extra term added to the x^29... scrambler) by the time your FCS sees them. My more serious objection to the x^29... scrambler applied only to packet data, however, is that for a given bit error rate on the circuit the use of the scrambler seems to me to cause the frame error rate to increase with decreasing frame transmission rates. For normal HDLC, without the use of any self-synchronous scrambler, a frame will be errored if a bit error occurs anywhere in the frame payload or in the immediately preceding or succeeding flags. The use of the x^43+1 scrambler widens this window to 43 bits in front of the preceding flag, but errors in the flags not immediately adjacent to the packet do not cause errors in the packet. With your proposal, however, an error anywhere in the flags between frames appears to cause the next frame to arrive to be dropped. That is, a bit error in the interpacket flags will cause the flags to appear as packet data. The FCS protection will likely cause this erroneous data to be dropped, but in the process of doing so you will change the state of the x^29... scrambler. This means that when you do receive a valid frame you will cause errors in the first 29 bits of the valid frame, causing it to be dropped as well. Since erroneous state in the x^29... scrambler will always persist until you receive (and damage) a valid frame, the probability of dropping a frame will depend not only on the length of the frame but also the number of flags preceding the frame. If you've been receiving idle flags for a long time the probability of damaging the next frame to arrive will approach unity. One could argue that the expected bit error rate for SONET should be low enough that this won't matter, but it strikes me as making the framing unnecessarily fragile (it also seems to me the low error rate argument might not necessarily apply at OC-192c either). So I have some reservations about the robustness of the packet scrambler you suggest. More generally, however, I also think that if we're to invent a new framing protocol for higher speeds, it is worth while to make sure the scheme that is chosen gives us maximal advantage. The one other alternative to this I've seen proposed is SDL, from Lucent, which I also have some reservations about but which strikes me as having distinct advantages over this. In particular: - Similar to octet-synchronous HDLC you depend on the SONET framing to align the framing to 32-bit boundaries. SDL does not necessarily depend on the SONET framing, an SDL framer could be built to deframe a bit stream sent over the raw fiber. - Your basic per-frame overhead, at 8 bytes per frame (4 bytes of flag, 4 bytes of FCS) is the same as SDL, but you additionally pad by 0-3 bytes for alignment and occasionally do transparency stuffing. SDL does no stuffing and doesn't bother to pad the frame. SDL actually could pad the frame, but I'd suggest that the implementation complexity of dealing with an odd number of bytes in a frame is not high; it maybe doubles the (relatively small) amount of logic devoted to the FCS computation. - SDL can also retain the 16-bit FCS, if this is worth anything, and can also run reasonably with no FCS at all, which is not useful for PPP but might be if the framed data includes error correction codes. - I think the real implementation complexity of HDLC at high speeds comes from stuffing for transparency. That is, bit-synchronous HDLC is hard if you can't run your data path a bit at a time, and octet-synchronous HDLC is hard if you can't run your data path a byte at a time. Similarly, HDLC-32 is only easy if you can run your data path 4 bytes wide. At OC-192c this means that HDLC-32 is only really easy at 311 MHz, which is more than a bit challenging with current technology and suggests that there'll be incentive to reinvent the framing protocol again if speeds beyond OC-192c become necessarily in the near term. SDL, on the other hand, eliminates transparency stuffing and associated complexity altogether. This seems to me to be fundamentally more scalable, and also permits one the possibility of doing really hard-core bandwidth scheduling on a circuit, something that is made annoyingly imperfect if your framer sometimes randomly grows packets by stuffing. - SDL makes sense at speeds lower than OC-192c, and potentially can fix the problems transparency stuffing causes there too. HDLC-32 is less attractive at lower speeds, so the stuffing problem remains (and it seems to me that if the packet expansion due to stuffing is a problem worth fixing at OC-192c it is also a problem worth fixing at lower speeds). - SDL doesn't use a self-synchronous scrambler, and hence doesn't cause error multiplication. Even if you wanted to retain the use of a self-synchonous scrambler to avoid SDL's scrambler state exchange, however, you could probably do this better with SDL too since SDL also doesn't send flags between packets; it instead sends packets that you throw away, and these could always be made to carry random data for the purpose of clearing errors out of the scrambler before real packets arrive again. If we're going to respecify the framing protocol I'd rather do this just once. It seems to me that SDL, or something more like SDL, might be more likely achieve this than hacking at HDLC. Do you disagree? Dennis Ferguson - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jan 7 09:33:43 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id JAA17511; Thu, 7 Jan 1999 09:31:12 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 7 Jan 1999 09:25:40 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id JAA17388 for ietf-ppp-outgoing; Thu, 7 Jan 1999 09:25:39 -0500 (EST) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.9.1a/8.9.1) with ESMTP id JAA17384 for ; Thu, 7 Jan 1999 09:25:31 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.1/8.9.1) id JAA17612 for ietf-ppp@merit.edu; Thu, 7 Jan 1999 09:25:30 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: PPP at STS-192c draft Date: 07 Jan 1999 09:25:30 -0500 Organization: IronBridge Networks Lines: 38 Message-ID: <863e5ni2hx.fsf@ironbridgenetworks.com> References: <15A2D77655CDD1118B5500805F6FE87A013F0333@pai820exch002u.micro.lucent.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu plangner@lucent.com ("Langner, Paul (Paul)") writes: > 2) Susceptability to malicious attack with 0x7E or 0x7D packets. This can > give output traffic schedulers grief when they are depending on known byte > delivery in the channel. This gets worse when one wants to deal with either G.711 (which has lots of 7D/7E in it) or WFQ finish times. The attack doesn't really have to be malicious; it can be an intrisic property of the data. > 3) Single bit errors can cause entire packet loss. > > 4) No ability to run without byte level framing being done a priori. > > 5) No real ability to estimate link BER from the channel. With my devil's advocate hat on: 3: SDL doesn't fix the single bit error problem on packet payloads; only on the headers. 4: HDLC runs just fine on bit-oriented links (you don't need octet stuffing there at all), and is much easier than SDL to implement. It's a tiny state machine. (It is nice that SDL runs over both types of media, but that's not the same as a requirement.) 5: BER estimation is something that *can* be done by use of the BIP-8 in SONET/SDH path byte B3 and by LQM over long periods of time. The one thing that SDL adds is the ability to measure BER accurately on an idle link, independent of path overhead. That's probably pretty valuable in 1:1 or 1:N sparing, but not so much in 1+1 configurations. (1+1 makes more sense to most IP folks, since it's the same as regular load balancing over multiple links.) -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jan 7 09:47:50 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id JAA17932; Thu, 7 Jan 1999 09:47:30 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 7 Jan 1999 09:46:48 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id JAA17906 for ietf-ppp-outgoing; Thu, 7 Jan 1999 09:46:47 -0500 (EST) Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1]) by merit.edu (8.9.1a/8.9.1) with SMTP id JAA17899 for ; Thu, 7 Jan 1999 09:46:40 -0500 (EST) Received: from pai820exch001h.wins.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id KAA03598; Thu, 7 Jan 1999 10:13:25 -0500 Received: by pai820exch001h.micro.lucent.com with Internet Mail Service (5.5.2232.9) id ; Thu, 7 Jan 1999 09:46:26 -0500 Message-ID: <15A2D77655CDD1118B5500805F6FE87A013F0351@pai820exch002u.micro.lucent.com> From: "Langner, Paul (Paul)" To: ietf-ppp@merit.edu, "'James Carlson'" Subject: RE: PPP at STS-192c draft Date: Thu, 7 Jan 1999 09:46:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Some comments with my "sympathy for the devil's hat" on: > ---------- > From: James Carlson[SMTP:carlson@ironbridgenetworks.com] > Sent: Thursday, January 07, 1999 9:25 AM > To: ietf-ppp@merit.edu > Subject: Re: PPP at STS-192c draft > > plangner@lucent.com ("Langner, Paul (Paul)") writes: > > 2) Susceptability to malicious attack with 0x7E or 0x7D packets. This > can > > give output traffic schedulers grief when they are depending on known > byte > > delivery in the channel. > > This gets worse when one wants to deal with either G.711 (which has > lots of 7D/7E in it) or WFQ finish times. The attack doesn't really > have to be malicious; it can be an intrisic property of the data. > > > 3) Single bit errors can cause entire packet loss. > > > > 4) No ability to run without byte level framing being done a priori. > > > > 5) No real ability to estimate link BER from the channel. > > With my devil's advocate hat on: > > 3: SDL doesn't fix the single bit error problem on packet payloads; > only on the headers. > - I agree - the issue is that being able to lose an entire packet with a single bit error in the 7E sabotages any ability to run FEC on the packets. > 4: HDLC runs just fine on bit-oriented links (you don't need octet > stuffing there at all), and is much easier than SDL to implement. > It's a tiny state machine. (It is nice that SDL runs over both types > of media, but that's not the same as a requirement.) > - I strongly agree - at low speeds. The thing with SDL is that it merges the packet delineation into the framing, so it can supersede the lower link framing (i.e. you could dispense with the DS-3/DS-1 overhead). > 5: BER estimation is something that *can* be done by use of the BIP-8 > in SONET/SDH path byte B3 and by LQM over long periods of time. The > one thing that SDL adds is the ability to measure BER accurately on an > idle link, independent of path overhead. That's probably pretty > valuable in 1:1 or 1:N sparing, but not so much in 1+1 configurations. > (1+1 makes more sense to most IP folks, since it's the same as regular > load balancing over multiple links.) > - I was being picky. This is really only of value if you run pure SDL without any lower frame, and has little to do with things from a PPP perspective. It is more of interest if you want to build a protected network using pure SDL links. > -- > James Carlson, Consulting S/W Engineer > IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 > Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 > "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jan 7 11:24:22 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id LAA20225; Thu, 7 Jan 1999 11:23:58 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 7 Jan 1999 11:19:55 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA20114 for ietf-ppp-outgoing; Thu, 7 Jan 1999 11:19:54 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA20107 for ; Thu, 7 Jan 1999 11:19:49 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id LAA17578 for ietf-ppp@merit.edu; Thu, 7 Jan 1999 11:19:48 -0500 (EST) Received: from firewall.sansurf.com ([209.157.8.161]) by merit.edu (8.9.1a/8.9.1) with ESMTP id BAA10870 for ; Thu, 7 Jan 1999 01:06:54 -0500 (EST) Received: from surfsup.sansurf.com (surfsup.sansurf.com [206.86.128.10]) by firewall.sansurf.com (8.9.1/8.9.1) with ESMTP id WAA06793; Wed, 6 Jan 1999 22:06:43 -0800 (PST) Received: from johnslaptop.sansurf.com ([206.86.128.148]) by surfsup.sansurf.com (8.8.8/8.8.8) with SMTP id WAA12847; Wed, 6 Jan 1999 22:06:43 -0800 (PST) Message-Id: <3.0.32.19990106220542.00accd88@stratumone.com> X-Sender: jjaeger@stratumone.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 06 Jan 1999 22:05:43 -0800 To: "Langner, Paul (Paul)" , ietf-ppp@merit.edu From: John Jaeger Subject: RE: PPP at STS-192c draft Cc: smerchant@cimaron.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Concerning the discussion over the last few weeks about the HDLC-32 proposal and related comments concerning requirements and alternatives for a new framing format in general, we would like to put forward the following comments. One of the initial benefits or motivations discussed for HDLC-32 is to reduce the complexity for high speed (STS-192) framing as compared to O-S HDLC. While it certainly results in reduced logic complexity, the fact that data expansion / contraction is still a result of the format, maintains a significant amount of the overall design complexity. There are a couple of implementation approaches that can be taken in generating the byte escaping hardware for STS-192, which result in a non-trivial but a manageable level of complexity. Several of these approaches are borrowed from processor design techniques. In superscalar processors, a similar problem exists in the instruction dispatch hardware where from an input stream of "N" instructions only x instructions are executed in a single cycle. In subsequent cycle, N-x instructions left over from the last cycle are combined with x instruction from the next cycle and dispatched for execution. Implementations of this type of hardware have been in existence in high-end processors running at multiples of 100's Mhz for the last few years. Additionally, one needs to remember that "N-byte" word implementations of byte escaping hardware have been designed & deployed and that the solution to this item need not necessarily push the operational speed of the logic. There are known ways of dealing with the byte oriented logic and data expansion / contraction of O-S HDLC and that a number of different approaches have been applied in STS-48 designs. Several of these designs are being extended (or have been extended if I interpret Mr. Langner’s previous mail correctly) to STS-192 rates without any undue increase in logic complexity. Specifying and deploying a new frame format just to accommodate the STS-192 rate is un-necessary if this complexity item is the chief obstacle being addressed. We concur with the previous comments that not addressing the possible error multiplication affects and associated packet error implications with nested scramblers and frame delineation logic could lead to unintended results. Care needs to be taken (irrespective of the objective link BER), that with respect to known link behaviors, any new framing format be robust as possible. Much has been discussed (and debated) over the past year regarding the link bandwidth expansion properties possible with O-S HDLC. It seems hypocritical to address this issue for the STS-192 rate while leaving it ‘as is’ for lower speed links. If it were deemed truly an issue that needs to be addressed, why would you not address it for all rates? If you can talk yourself into addressing this item for STS-192 only, is this item a sufficient enough impetus for a new format if O-S HDLC alternatives are equally viable from a design and implementation perspective? There seems to be a lack of consensus on the requirements and objectives that would merit a new framing format to be specified and deployed. If scalability is a requirement, one could easily argue that a factor 4 increase from current methods is inadequate (as has been stated previously several times on this list). Likely a more interesting question is the ability to run the framing format over non-SONET links. Is this required or desired? If yes, we should specify the framing format in its entirety to properly compare alternatives and assure that we do not have a deficient design on non-SONET links. A question to this list (as if the comments above won’t generate enough flack); can we effectively move forward with any new proposal without agreeing, or at least discussing in more detail, the requirements, capability and motivation for such an effort? In our opinion, this is difficult at best. ------ John Jaeger StratumOne Communications Direct: 408.946.3010 3900 Freedom Circle Main: 408.988.2229 Suite 102 Fax: 408.988.2571 Santa Clara, CA 95054 Internet: jjaeger@stratumone.com ------ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jan 7 17:26:24 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id RAA27804; Thu, 7 Jan 1999 17:25:41 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 7 Jan 1999 17:22:39 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id RAA27701 for ietf-ppp-outgoing; Thu, 7 Jan 1999 17:22:38 -0500 (EST) Received: from cbgw1.lucent.com (cbgw1.lucent.com [207.24.196.51]) by merit.edu (8.9.1a/8.9.1) with SMTP id RAA27697 for ; Thu, 7 Jan 1999 17:22:29 -0500 (EST) Received: from pai820exch001h.wins.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id RAA26848; Thu, 7 Jan 1999 17:19:46 -0500 Received: by pai820exch001h.micro.lucent.com with Internet Mail Service (5.5.2232.9) id ; Thu, 7 Jan 1999 17:22:13 -0500 Message-ID: <15A2D77655CDD1118B5500805F6FE87A013F0358@pai820exch002u.micro.lucent.com> From: "Langner, Paul (Paul)" To: "'ietf-ppp@merit.edu'" Subject: RE: PPP at STS-192c draft Date: Thu, 7 Jan 1999 17:22:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Oooops - July IEEE Information Theory -----Original Message----- From: Langner, Paul (Paul) Sent: Wednesday, January 06, 1999 2:53 PM To: 'Dennis Ferguson'; smerchant@cimaron.com Cc: ietf-ppp@merit.edu Subject: RE: PPP at STS-192c draft Sharukh, Check out the August IEEE Information Theory for a discussion of how to attack self-synchronizing scramblers on long packets. I haven't gotten around to it yet, but I suspect that it will be possible with a low 1's density probability sequence in 64K packets set up with the inverse SONET scrambler sequence to really cause some good timing recovery problems in POS networks. (This was actually one of the drivers behind SDL). An added note to the complexity arguement on byte escaped HDLC. From my experience, the complexity of building a byte-escaped HDLC engines is roughly nlogn, as the escaping process is done on a per byte basis, and does not depend on run-length history. The logn term arises from the pipelined MUXing that is required after a parallel escaper to store the escaped and potentially expanded bytes in a buffer after the escaper. As such, we had no real complexity issues with at OC-192 using the traditional POS method. So the only thing wrong with traditional POS (in my mind) is: 1) Susceptability to malicious attack by long packets with low ones density after SONET/SDH frame descrambling. 2) Susceptability to malicious attack with 0x7E or 0x7D packets. This can give output traffic schedulers grief when they are depending on known byte delivery in the channel. 3) Single bit errors can cause entire packet loss. 4) No ability to run without byte level framing being done a priori. 5) No real ability to estimate link BER from the channel. Paul Langner -----Original Message----- From: Dennis Ferguson [mailto:dennis@juniper.net] Sent: Sunday, December 20, 1998 11:39 PM To: smerchant@cimaron.com Cc: ietf-ppp@merit.edu Subject: Re: PPP at STS-192c draft Shahrukh, > 1. Choice of SONET payload scrambling polynomial > ------------------------------------------------ > You're right that x^43+1 is not maximal length (although "maximal > length" is harder to define for a self-synchronous scrambler where the > next state is not just a function of the current state, but also of the > input). I think this is the key point. A self-synchronous scrambler is not an LFSR, and doesn't produce a fixed, repeating output, so there is no sequence whose length needs to be maximized. That is, adding the extra term to the x^43+1 (or x^29+1) scrambler does not increase the number of states the scrambler can be in (all 2^43 or 2^29 states are possible in both cases), so adding the extra term doesn't make the precise output of the scrambler any harder to guess. Worse, what I think you're ignoring is the fact that self-synchronous scramblers are error-multiplying and adding more terms just makes a single bit error in the scrambled data turn into more errors after descrambling. That is, a single bit error in the x^43+1 scrambled payload turns into two bits in error after descrambling, one at the location of the bit error and one 43 bits later (i.e. a single bit error is turned into a 43 bit burst). Adding another term to the scrambler increases the number of bits in error after descrambling to 3, which is certainly not an improvement and is intuitively likely to make things worse since error multiplication has implications for error detection. The error multiplication is also the first objection I have to the two nested scramblers you are suggesting. If you run the x^43+1 scrambler over packet payload scrambled by the x^29+1 scrambler, then a single bit transmission error in a packet turns into a 4 bit error after descrambling; one at the location of the bit error, one 29 bits later, one 43 bits later and one 72 bits later. If you add a third term to packet scrambler, you now have a single bit error causing 6 bits to be in error after descrambling. If you also add a third term to the x^43+1 scrambler you end up with a single bit tranmission error turning into 9 errored bits after descrambling. You can't assume that this is without impact on error detection performance of the FCS. As you note later, > the strength of the CRC from 32 to 30 bits." CRC codes typically have > properties like: > > - Detects all single bit errors > - Detects all 2-bit errors for packet lengths <= P > - Detects all burst errors for burst lengths <= Q > - Detects (1-2^-N, N=32 in this case) of all multi-bit errors You are systematically ensuring that all transmission errors, even single bit errors, will have a burst length of at least 72 bits with at least 4 bits in error (6 bits with the extra term added to the x^29... scrambler) by the time your FCS sees them. My more serious objection to the x^29... scrambler applied only to packet data, however, is that for a given bit error rate on the circuit the use of the scrambler seems to me to cause the frame error rate to increase with decreasing frame transmission rates. For normal HDLC, without the use of any self-synchronous scrambler, a frame will be errored if a bit error occurs anywhere in the frame payload or in the immediately preceding or succeeding flags. The use of the x^43+1 scrambler widens this window to 43 bits in front of the preceding flag, but errors in the flags not immediately adjacent to the packet do not cause errors in the packet. With your proposal, however, an error anywhere in the flags between frames appears to cause the next frame to arrive to be dropped. That is, a bit error in the interpacket flags will cause the flags to appear as packet data. The FCS protection will likely cause this erroneous data to be dropped, but in the process of doing so you will change the state of the x^29... scrambler. This means that when you do receive a valid frame you will cause errors in the first 29 bits of the valid frame, causing it to be dropped as well. Since erroneous state in the x^29... scrambler will always persist until you receive (and damage) a valid frame, the probability of dropping a frame will depend not only on the length of the frame but also the number of flags preceding the frame. If you've been receiving idle flags for a long time the probability of damaging the next frame to arrive will approach unity. One could argue that the expected bit error rate for SONET should be low enough that this won't matter, but it strikes me as making the framing unnecessarily fragile (it also seems to me the low error rate argument might not necessarily apply at OC-192c either). So I have some reservations about the robustness of the packet scrambler you suggest. More generally, however, I also think that if we're to invent a new framing protocol for higher speeds, it is worth while to make sure the scheme that is chosen gives us maximal advantage. The one other alternative to this I've seen proposed is SDL, from Lucent, which I also have some reservations about but which strikes me as having distinct advantages over this. In particular: - Similar to octet-synchronous HDLC you depend on the SONET framing to align the framing to 32-bit boundaries. SDL does not necessarily depend on the SONET framing, an SDL framer could be built to deframe a bit stream sent over the raw fiber. - Your basic per-frame overhead, at 8 bytes per frame (4 bytes of flag, 4 bytes of FCS) is the same as SDL, but you additionally pad by 0-3 bytes for alignment and occasionally do transparency stuffing. SDL does no stuffing and doesn't bother to pad the frame. SDL actually could pad the frame, but I'd suggest that the implementation complexity of dealing with an odd number of bytes in a frame is not high; it maybe doubles the (relatively small) amount of logic devoted to the FCS computation. - SDL can also retain the 16-bit FCS, if this is worth anything, and can also run reasonably with no FCS at all, which is not useful for PPP but might be if the framed data includes error correction codes. - I think the real implementation complexity of HDLC at high speeds comes from stuffing for transparency. That is, bit-synchronous HDLC is hard if you can't run your data path a bit at a time, and octet-synchronous HDLC is hard if you can't run your data path a byte at a time. Similarly, HDLC-32 is only easy if you can run your data path 4 bytes wide. At OC-192c this means that HDLC-32 is only really easy at 311 MHz, which is more than a bit challenging with current technology and suggests that there'll be incentive to reinvent the framing protocol again if speeds beyond OC-192c become necessarily in the near term. SDL, on the other hand, eliminates transparency stuffing and associated complexity altogether. This seems to me to be fundamentally more scalable, and also permits one the possibility of doing really hard-core bandwidth scheduling on a circuit, something that is made annoyingly imperfect if your framer sometimes randomly grows packets by stuffing. - SDL makes sense at speeds lower than OC-192c, and potentially can fix the problems transparency stuffing causes there too. HDLC-32 is less attractive at lower speeds, so the stuffing problem remains (and it seems to me that if the packet expansion due to stuffing is a problem worth fixing at OC-192c it is also a problem worth fixing at lower speeds). - SDL doesn't use a self-synchronous scrambler, and hence doesn't cause error multiplication. Even if you wanted to retain the use of a self-synchonous scrambler to avoid SDL's scrambler state exchange, however, you could probably do this better with SDL too since SDL also doesn't send flags between packets; it instead sends packets that you throw away, and these could always be made to carry random data for the purpose of clearing errors out of the scrambler before real packets arrive again. If we're going to respecify the framing protocol I'd rather do this just once. It seems to me that SDL, or something more like SDL, might be more likely achieve this than hacking at HDLC. Do you disagree? Dennis Ferguson - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jan 7 23:14:56 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id XAA02708; Thu, 7 Jan 1999 23:14:21 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 7 Jan 1999 23:11:16 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id XAA02651 for ietf-ppp-outgoing; Thu, 7 Jan 1999 23:11:15 -0500 (EST) Received: from smtp-2.mdc.net (smtp-2.mdc.net [209.251.64.26]) by merit.edu (8.9.1a/8.9.1) with ESMTP id XAA02647 for ; Thu, 7 Jan 1999 23:11:07 -0500 (EST) Received: from cimaron.com (xcom-77-10.mdc.net [209.251.77.10]) by smtp-2.mdc.net (8.9.1/8.9.1) with SMTP id XAA22558 for ; Thu, 7 Jan 1999 23:06:15 -0500 (EST) (envelope-from smerchant@cimaron.com) Received: from cimaron.com [2.1.1.11] by cimaron.com [2.1.1.7] with SMTP (MDaemon.v2.7.SP1.R) for ; Thu, 07 Jan 99 23:04:39 -0500 Message-ID: <3695837D.E6ABF15@cimaron.com> Date: Thu, 07 Jan 1999 23:03:09 -0500 From: Shahrukh Merchant Organization: Cimaron Communications Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: Re: PPP at STS-192c draft References: <3.0.32.19990106220542.00accd88@stratumone.com> Content-Type: text/plain; charset=iso-8859-1 X-MDaemon-Deliver-To: ietf-ppp@merit.edu Reply-To: smerchant@cimaron.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by merit.edu id XAA02648 Sender: owner-ietf-ppp@merit.edu John Jaeger says; > Specifying and deploying a new frame > format just to accommodate the STS-192 rate is un-necessary if this > complexity item [stuffing/destuffing] is the chief obstacle being addressed. Well, no. I too believe that the stuffing/destuffing is only moderately complex to implement with well-understood techniques--I have never stated that as the reason for HDLC-32. (It does seem to have been disproportionately discussed here to the point that it has been made to seem a bigger issue that it is.) What in my mind is the biggest complexity in using o-s HDLC for STS-192c rates is one that, to my surprise, no one has mentioned yet (including myself :-): Assuming you have a 16-byte internal data path, (i.e., 78 MHz), you could have multiple packets all arriving within one clock cycle, i.e., you would need to process up to 4 packets simultaneously per clock cycle, which effectively quadruples you packet processing logic for these series of edge cases. There are many ways to solve this of course (including ways that look even more more like o-s HDLC, such as just padding out extra flags in that case), but given the motivation for change, there are additional benefits that may be attained by a new scheme (be it HDLC-32 or SDL or xyz): - Retain 32-bit boundaries throughout for further simplification; - Resolve the bandwidth expansion problem of o-s HDLC. - etc. > It seems > hypocritical to address [the bandwidth expansion] issue for the STS-192 rate while leaving it > ‘as is’ for lower speed links. If it were deemed truly an issue that needs > to be addressed, why would you not address it for all rates? I would call it "realistic." We do not operate in a "desert model" of the world (one in which you start with a clean sheet of paper every time). If any new scheme had to prove its cost-effectiveness on the basis of being able to fix all past sins, we would still be using the original form of digital communication (smoke signals :-). The two options are: 1. Go back and change everything that's been deployed or is in deployment (STS-3c, -12c, -48c, bit-synchronous links) to create the one Universal Protocol, or 2. More credibly, add yet another mode for "new equipment" that your new protocol will support. So now all established protocol/rate combinations will need another mode of operation, i.e., we have STS-12c with HDLC-32/SDL/whatever and you have the "compatibility mode" for o-s HDLC. Nothing precludes option (2). HDLC-32 and SDL and any number of other protocols will work just fine at lower rates. The scope of the HDLC-32 proposal was put in the STS-192c context not because it cannot be used at lower rates, but because (a) it comes about from the need for better implementation efficiency at STS-192c and (b) the cost-benefit tradeoff of actually retrofitting a "new and improved" scheme into pre-existing technology is entirely separable from showing that it COULD be done. I suspect that ultimately the marketplace will determine the retrofitting issue, although standard organizations can influence it and help avoid unnecessary proliferation of multiple standards. James Carlson : > As I said before, HDLC-32 just gives you an extra factor of four in > complexity reduction. If that's enough of a reduction that we don't > need to revisit this topic again in the next year in order to do > HDLC-128, then I guess I like the idea because of its simplicity. Let's talk about scalability. Firstly, the multiple-packet-in-one-cycle problem exists for any scheme that's been mentioned so far (and dominates all scalability issues as far as I'm concerned). But take a look at how long it took OC-192 to get to the point that OC-48 was--there is a gap of several years. (I'm NOT talking about how long it might take a particular datacomm company to decide that they need an OC-192 line card after they decide they need an OC-48 line card--perhaps that's just months these days! I'm referring to the time interval that the technologies in optics, fiber and hardware implementation speeds all came together to make it possible--these do NOT follow Moore's law.) And if you look at the even greater challenges needed to bring OC-768 to deployment, let alone STS-768c, having internal ASIC speeds of 311 MHz (which is what nicely scales HDLC-32--or anything else based on 32-bit words--from OC-192 to OC-768) seems like one of the easier problems! So no, I am not concerned about revisiting this for HDLC-128 even when we do get to OC-768. (And call me myopic, but I'm quite prepared not to worry about OC-3072. :-) > I agree. We should keep the existing protocols [at sub STS-192c rates] where we can for > compatibilities' sake, at least for purposes of discussion. We're in agreement on this one, including the "at least for discussion" part. On scrambling schemes and techniques: ------------------------------------ Dennis Ferguson says: > I'd also point out again that adding the third term to the self-sychronous > scrambler does nothing to improve its operation. It just increases the > error multiplication. Even if increased error multiplication is only a > small negative, there is no apparent offsetting positive that would make > adding the additional term to the scrambler desireable. The improvement with the third term, at least theoretically, is that since it is maximal length, it is harder to create a predictable pattern at the output of the scrambler. Let me give one scenario. If you put an all-zero data input to the x^29+1 scrambler, the output will be the 29-bit scrambler state, repeated over and over. For the 3-term scrambler, you will get the much longer maximal-length sequence. What practical effect does this have given the SONET scrambler that follows? I don't know--perhaps it doesn't matter, or perhaps it doesn't matter enough to offset the error multiplication. Can someone quantify the "attack potential" of the 2 scramblers better? As far as error multiplication, the practical effect is actually minimal if you DON'T have the further error multiplication of the x^43+1 (for which reason, as I stated in my e-mail from last week, I too am leaning towards not including it). That is because CRC-32 will detect all 1-, 2- and 3-bit errors and all error bursts up to 31 bits (and of course virtually all other errors too). So single-errors will be multiplied to either 2 or 3 and will be within the 31-bit burst anyway. So we are left with comparing two second-order effects: I don't have a strong attachment to one or the other, though I lean a little towards the 3-term scrambler for better protection for direct-over-fiber applications (even though it has not actually been shown that x^29+1 is inadequate). At any rate, I wanted to put the all-zeros scrambler scenario on the table too. > I would have preferred to make the padding self-describing. That is, > always pad with fixed values, e.g. I actually like that approach. The idle packet can then just be a 4-byte-pad-only packet (with CRC). > You've pointed out some things about SDL you don't like, many of which > I agree with. Let me suggest an alternative that hasn't had much thought, > but which attempts to address some of the issues with it. In particular, One issue that was not addressed, and is my primary one, is the dependency on the packet length (allowing continuation frames only helps a little in that it trades off knowing the packet length a priori vs. not being inherently limited to a 16-bit length field). But it doesn't fix the main problem, which is that it (a) requires knowledge of the packet length and (b) requires it at the PHY interface. Of course, you may have to know the packet length within your system anyway for other reasons, but now you are forcing this knowledge at the PHY. At best, this is architecture- and format-limiting (or complicating, depending on how you look at it) as it requires propagation of this information to parts of the system that may not need it, and/or constrains the format to work only when the packet length can be known. (If you are concerned about scalability, then this is a very unscalable solution in an architectural sense.) At worst, this will require unnecessary buffering of the entire packet, just so that you can count the length and insert it in the front. There will be systems that wouldn't otherwise need to do this, and there will be future packet formats where you won't want to do it (because of excessively long packets, for instance). That is one major advantage of o-s HDLC (that it is a "streaming" format), which HDLC-32 retains, but which is lost in SDL and could uncover untold complications and limitations in the future. Shahrukh -- Shahrukh Merchant Director, Systems Engineering and Verification Cimaron Communications Corporation Phone: +1 978 623-0009 Ext 3020 Fax: +1 978 623-0024 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jan 8 11:39:14 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id LAA13043; Fri, 8 Jan 1999 11:36:53 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 8 Jan 1999 11:27:26 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA12840 for ietf-ppp-outgoing; Fri, 8 Jan 1999 11:27:26 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA12836 for ; Fri, 8 Jan 1999 11:27:22 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id LAA15075 for ietf-ppp@merit.edu; Fri, 8 Jan 1999 11:27:21 -0500 (EST) Received: from smokie00.eti.pg.gda.pl (smokie.eti.pg.gda.pl [153.19.48.100]) by merit.edu (8.9.1a/8.9.1) with ESMTP id HAA08914 for ; Fri, 8 Jan 1999 07:41:35 -0500 (EST) Received: from roger09.eti.pg.gda.pl (roger09.eti.pg.gda.pl [153.19.50.41]) by smokie00.eti.pg.gda.pl (8.8.8+Sun/8.8.8) with ESMTP id NAA00902 for ; Fri, 8 Jan 1999 13:41:11 +0100 (MET) Received: from localhost (csb063bl@localhost) by roger09.eti.pg.gda.pl (8.8.8+Sun/8.8.8) with ESMTP id NAA09949 for ; Fri, 8 Jan 1999 13:41:08 +0100 (MET) X-Authentication-Warning: roger09.eti.pg.gda.pl: csb063bl owned process doing -bs Date: Fri, 8 Jan 1999 13:41:02 +0100 (MET) From: Bartosz /Lakomiec X-Sender: csb063bl@roger09.eti.pg.gda.pl To: ietf-ppp@merit.edu Subject: PPP EAP packet type 0 ? (developer's question) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Hello PPP experts, This is developer's question about EAP authentication protocol presented in [RFC 2284]: IS IT AGREEABLE TO DEFINE PROPRIETARY EAP PACKETS TYPES TO INTRODUCE PROPRIETARY AUTHENTICATION MECHANISMS (using the same convention that is used for proprietary configuration options [RFC1570], i.e identifier '0' plus OUI number) ? Although [RFC 2284] doesn't reserve packet type 0, it doesn't say about WHAT TO DO IF ONE WANT TO IMPLEMENT THEIR OWN AUTHENTICATION SCHEME WITHOUT OBTAINING A NUMBER FOR IT FROM IANA ? Thanks in advance for your comments. ------------------------------------------------------------------------- Bartek /Lakomiec csb063bl@cs-boglab.eti.pg.gda.pl ------------------------------------------------------------------------- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Jan 9 09:40:30 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id JAA02377; Sat, 9 Jan 1999 09:38:02 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Sat, 9 Jan 1999 09:32:13 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id JAA02301 for ietf-ppp-outgoing; Sat, 9 Jan 1999 09:32:12 -0500 (EST) Received: from thenut.eti.pg.gda.pl (root@thenut.eti.pg.gda.pl [153.19.48.151]) by merit.edu (8.9.1a/8.9.1) with ESMTP id JAA02297 for ; Sat, 9 Jan 1999 09:31:45 -0500 (EST) Received: from localhost by thenut.eti.pg.gda.pl via sendmail with smtp id (Debian Smail3.2.0.101) for ; Sat, 9 Jan 1999 15:31:49 +0100 (EET) Date: Sat, 9 Jan 1999 15:31:48 +0100 (EET) From: Bartek /Lakomiec To: ietf-ppp@merit.edu Subject: Proprietary EAP Request/Response types ? (once more). Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Hello everybody once more, I'm very sorry for the logical mistake and bad RFC reference in my previous question. The issue is described correctly below. I would like to define a proprietary authentication mechanism within EAP without obtaining a number from IANA, and I need a proprietary EAP Request/Response type (not EAP packet type). EAP definition [RFC 2284] doesn't say how to define proprietary EAP Request/Response types. This is neither a LCP/NCP packet type or PPP configuration option so it doesn't fall within the scope of the "PPP Vendor Extensions" specification [RFC 2153]. What is the way to introduce a proprietary authentication mechanism within EAP? Is it O'K to use EAP Request type '0' followed by 3-byte OUI identifier field? Thanks for your comments. ------------------------------------------------------------------- Bartek /Lakomiec barlak@thenut.eti.pg.gda.pl ------------------------------------------------------------------- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jan 13 16:24:07 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id QAA04680; Wed, 13 Jan 1999 16:23:08 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 13 Jan 1999 16:14:40 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id QAA04322 for ietf-ppp-outgoing; Wed, 13 Jan 1999 16:14:40 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id QAA04316 for ; Wed, 13 Jan 1999 16:14:27 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id QAA24710 for ietf-ppp@merit.edu; Wed, 13 Jan 1999 16:14:26 -0500 (EST) Received: from CE.SHARIF.AC.IR (ce.Sharif.AC.IR [194.225.40.100]) by merit.edu (8.9.1a/8.9.1) with SMTP id IAA23261 for ; Wed, 13 Jan 1999 08:47:15 -0500 (EST) From: bamesian@ce.sharif.ac.ir Received: by ce.sharif.ac.ir (MX V4.1 VAX) id 1; Wed, 13 Jan 1999 17:08:21 EST Date: Wed, 13 Jan 1999 17:08:20 EST To: ietf-ppp@merit.edu Message-ID: <009D229F.C89DC420.1@ce.sharif.ac.ir> Subject: PPP questions Sender: owner-ietf-ppp@merit.edu Dear Sir, It is K. Bamasian the computer engineering student of Sharif University of Iran. I want to know that how can I perform flow control on PPP ? My protocol stack is IP over PPP over physical layer. Also I am looking for a source code of PPP implementation in C. Would you please help me? thanks, Katayoun Bamasian, E_mail : bamesian@ce.sharif.ac.ir - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Jan 13 21:45:24 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id VAA10902; Wed, 13 Jan 1999 21:44:39 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 13 Jan 1999 21:39:30 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id VAA10812 for ietf-ppp-outgoing; Wed, 13 Jan 1999 21:39:29 -0500 (EST) Received: from hotmail.com (f129.hotmail.com [207.82.251.8]) by merit.edu (8.9.1a/8.9.1) with SMTP id VAA10808 for ; Wed, 13 Jan 1999 21:39:22 -0500 (EST) Received: (qmail 21753 invoked by uid 0); 14 Jan 1999 02:38:50 -0000 Message-ID: <19990114023850.21752.qmail@hotmail.com> Received: from 171.71.100.210 by www.hotmail.com with HTTP; Wed, 13 Jan 1999 18:38:50 PST X-Originating-IP: [171.71.100.210] From: "Ehab Hadi" To: ietf-ppp@merit.edu, bamesian@ce.sharif.ac.ir Subject: Re: PPP questions Date: Wed, 13 Jan 1999 18:38:50 PST Mime-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu I advice you to read the PPP implementation in the book intiteled: TCP/IP Illustrated, Vilume 2-The Implementation by Gary R. Wright & Richard Stevens. ISBN 0-201-63354-X. Good luck, --Ehab >From: bamesian@ce.sharif.ac.ir >Date: Wed, 13 Jan 1999 17:08:20 EST >To: ietf-ppp@merit.edu >Subject: PPP questions > >Dear Sir, >It is K. Bamasian the computer engineering student of Sharif University of >Iran. >I want to know that how can I perform flow control on PPP ? My protocol stack >is IP over PPP over physical layer. Also I am looking for a source code of PPP >implementation in C. Would you please help me? > thanks, > Katayoun Bamasian, > E_mail : bamesian@ce.sharif.ac.ir > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Jan 22 12:39:02 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id MAA09557; Fri, 22 Jan 1999 12:37:41 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 22 Jan 1999 12:31:15 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id MAA09367 for ietf-ppp-outgoing; Fri, 22 Jan 1999 12:31:14 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA09363 for ; Fri, 22 Jan 1999 12:31:10 -0500 (EST) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id MAA07808 for ietf-ppp@merit.edu; Fri, 22 Jan 1999 12:31:10 -0500 (EST) Received: from relay1.marconi.it (relay1.marconi.it [192.106.52.1]) by merit.edu (8.9.1a/8.9.1) with ESMTP id MAA09346 for ; Fri, 22 Jan 1999 12:30:29 -0500 (EST) Received: from gemail.marconi.it (gemail.marconi.it [192.106.32.10]) by relay1.marconi.it (8.9.1a/8.9.1) with ESMTP id SAA12216 for ; Fri, 22 Jan 1999 18:25:10 +0100 (MET) Received: from mr.marconi.it by gemail.marconi.it (PMDF V5.1-7 #26163) id <01J6UNCKTMB40002HV@gemail.marconi.it> for ietf-ppp@merit.edu; Fri, 22 Jan 1999 18:28:31 GMT Received: with PMDF-MR; Fri, 22 Jan 1999 18:15:22 +0000 (GMT) MR-Received: by mta GEMAIL.MUAS; Relayed; Fri, 22 Jan 1999 18:15:22 +0000 MR-Received: by mta GEMAIL; Relayed; Fri, 22 Jan 1999 18:28:26 +0000 Disclose-recipients: prohibited Date: Fri, 22 Jan 1999 18:15:22 +0000 (GMT) From: Sergio Torassa Subject: RSVP & L2TP To: ietf-ppp@merit.edu Message-id: <1122151822011999/A12677/GEMAIL/11D1B48F1500*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Sensitivity: Company-Confidential UA-content-id: 11D1B48F1500 X400-MTS-identifier: [;1122151822011999/A12677/GEMAIL] Hop-count: 1 Sender: owner-ietf-ppp@merit.edu Hi everyone, Is there a draft regarding the interworking between RSVP and L2TP? In particular I'm referring to the case where QoS guarantees are requested and a LAC is involved in the route: how can bandwidth be guaranteed in the link between the LAC and the LNS if the LAC is not conscious of RSVP messages passing through it? Sergio ------------------------------------------ Sergio Torassa Marconi Communications Phone: +39 010 6002916 Fax: +39 010 6508698 e-mail: sergio.torassa@marconicomms.com ------------------------------------------ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Jan 26 12:03:59 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id MAA21281; Tue, 26 Jan 1999 12:02:52 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 26 Jan 1999 11:56:24 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id LAA21116 for ietf-ppp-outgoing; Tue, 26 Jan 1999 11:56:24 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.9.1a/8.9.1) with ESMTP id LAA21112 for ; Tue, 26 Jan 1999 11:56:17 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA19113; Tue, 26 Jan 1999 11:55:40 -0500 (EST) Message-Id: <199901261655.LAA19113@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-fr-01.txt Date: Tue, 26 Jan 1999 11:55:40 -0500 Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Layer Two Tunneling Protocol (L2TP) over Frame Relay Author(s) : V. Rawat, R. Tio, R. verma Filename : draft-ietf-pppext-l2tp-fr-01.txt Pages : 7 Date : 25-Jan-99 Layer Two Tunneling Protocol describes a mechanism to tunnel PPP sessions. The protocol has been designed to be independent of the media it runs over. The base specification describes how it should be implemented to run over UDP and IP. This document describes how the Layer Two Tunneling Protocol MUST be implemented over Frame Relay PVCs and SVCs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-l2tp-fr-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-l2tp-fr-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-fr-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990125161246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-fr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-fr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990125161246.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Jan 28 19:31:31 1999 Received: from localhost (daemon@localhost) by merit.edu (8.9.1a/8.9.1) with SMTP id TAA29158; Thu, 28 Jan 1999 19:30:30 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 28 Jan 1999 19:23:10 -0500 Received: (from majordom@localhost) by merit.edu (8.9.1a/8.9.1) id TAA28988 for ietf-ppp-outgoing; Thu, 28 Jan 1999 19:23:10 -0500 (EST) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by merit.edu (8.9.1a/8.9.1) with ESMTP id TAA28983 for ; Thu, 28 Jan 1999 19:23:04 -0500 (EST) Received: from anfreema-pc.cisco.com (dhcp-71-139-224.cisco.com [171.71.139.224]) by mailman.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.SERVER.1.2) with SMTP id QAA23460; Thu, 28 Jan 1999 16:14:13 -0800 (PST) Message-Id: <199901290014.QAA23460@mailman.cisco.com> X-Sender: anfreema@sj-email X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 28 Apr 1999 16:20:57 -0700 To: ipsec@tis.com, ietf-ppp@merit.edu From: Anita Freeman Subject: April IPSec and PPP Interoperability Workshop Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Greetings, We are preparing to sign a hotel contract for the next IPSec and PPP Interoperability Workshop for the week of April 19-23, 1999, in Santa Barbara, CA, with arrival and set up on April 18. It has been brought to our attention there is an Internet Security Conference taking place April 19-22, 1999, in San Jose, CA. The details are listed below. This email is sent for the participants of the interoperability workshop. Will this conference present a conflict in your company's resources to attend the IPSec and PPP interoperability workshop? Please respond at your earliest opportunity as this is the only week in April the hotel accommodations are available in Santa Barbara and we would like to complete our contract negotiations promptly if this is a viable week for the workshop. Thank you, Anita Freeman ------------------------------------ For Immediate Release Media Contact Paul Kent Mactivity, Inc (408) 354-2500 paul@mactivity.com The Internet Security Conference Making the Internet a Safer Place for Corporate Information Assets. Los Gatos, CA Dec 17, 1998 - Internet computing has become a critical component of corporate computing, but threats to electronic assets and information integrity are real, and information and communications privacy are difficult to achieve. The second presentation of The Internet Security Conference, to be held April 19-22 at the Fairmont Hotel in San Jose, California, promises to provide a wealth of solutions for the IT manager looking to find his way through the maze of threats that face the Internet-enabled corporation. The Internet Security Conference (TISC) presents a comprehensive curriculum on secure computing. Attendees can choose from sessions on anti-virus strategies, virtual private network deployment, IPSEC and IP v6 issues, secure mail and messaging options, secure ecommerce, databases and multicast security considerations. Eleven full day workshops, 30 conference sessions and two half-day seminars will be presented. A world reknown faculty of Internet security scientists, researchers and educators will conduct the sessions. Key presenters include: - Dr. Stephen Kent, Chief Scientist, Information Security, BBN Technologies - Marcus Ranum, CEO and Founder, Network Flight Recorder & author of several major Internet firewall products including DEC SEAL, TIS Gauntlet and TIS Internet Firewall Toolkit - Fred Avolio, independent consultant specializing in Internet security & former product manager for TIS Gauntlet Internet Firewall - Dr. Radia Perlman, Distinguished Engineer, Sun Microsystems, co- author of"Network Security: Private Communication in a Public World" - Rik Farrow, Internet Security consultant and trainer & author of "UNIX System Security" - Charlie Kaufman, Security Architect for Lotus Notes, IBM & co- author of "Network Security: Private Communication in a Public World" - Phil Carden, Managing Consultant, Renaissance Worldwide & author, "Internet Security for Windows NT" The faculty is complemented by fifty of the industry's leading security practitioners, including Char Sample, Tina Darmohray, John Rochlis, Daniel Geer, John Pescatore, Ian Poynter, Ray Kaplan and Joseph Saul. The conference is hosted by Dave Piscitello, president of Core Competence, a 20 year veteran of the Internet technical community and conference chairperson of Networld+Interop. "The purpose of The Internet Security Conference is to expose corporate computing professionals who have an urgent 'need to know' to the folks who designed or contributed to some of the most significant security technologies in the world," explains Piscitello. "I designed this to be a conference I would want to attend, one with a program so intensely interesting I'd have difficulty deciding what to attend myself." Industry publication Network Computing Magazine returns as the event's media sponsor. "Security is an important issue to the market and our readers," said Jill Thiry Bowers, publisher of Network Computing. "Because of our editorial coverage of Internet Security the past few years, Dave chose to partner with our editors to create compelling content for the conference. We also look forward to extending our Real World Labs (r) into the TISC Interoperability Lab to demonstrate enterprise-tested solutions to attendees." A unique feature of TISC is the Interoperabilty Lab - a working computer lab that demonstrates how an organization can combine solutions to create a secure environment. The TISC Interoperability Lab will feature interoperability demonstrations and unique presentations of policy management, intrusion detection and monitoring, virtual private networking and ethical hacking. Consultants from Ernst and Young will attempt to hack into the Lab while intrusion detection and monitoring experts attempt to catch them in a kind of high tech war game that attendees can observe. "Our Interoperability Lab is a throw-back to the days when technical staff demonstrated products at trade shows," explains Piscitello, "I view it as an extension of our education program. I want attendees to learn about security from experts in workshops and symposium sessions, then see it put to work in our Lab." The Internet Security Conference is sponsored by the key organizations driving the security industry. Corporate sponsorship is provided by Network Computing, Ernst and Young, Compatible Systems, Checkpoint Software, Microsoft, RSA Data Security, Aventail Corporation, InternetWeek, Internet Devices, Netscreen, enCommerce, Xedia, TimeStep, Exodus Communications, Xcert, Radguard, Network Flight Recorder and RedCreek with more sponsors being announced each week. Covad Communications Company is providing DSL Internet access at the conference. For more information contact (408) 354-2500 or browse http://tisc.corecom.com The Internet Security Conference is co-produced by Core Competence and Mactivity, Inc. Core Competence is a full service internetworking, fast packet and network management consulting firm located in Dresher, PA. Mactivity, located in Los Gatos, CA produces some of the most influential technology conferences in the high-tech industry including Voice on the Net, Loop'98, The Internet Service Providers Forum, Java Business Expo, Macworld Expo, Interop DotCom and the Mactivity conference series. Network Computing is the premier technology solutions magazine driving IT purchasing decisions. Every two weeks it delivers enterprise-tested technology solutions from its unique Real-World Labs to 220,000 information-technology buyers in print and online (http://www.networkcomputing.com). In addition, the publication consistently has the largest average-issue audience among all networking publications, according to Simmons and IntelliQuest. Network Computing received the 1997 Maggie Award for Best Computer & Telecommunications (trade) Publication. CMP Media Inc. (Nasdaq: CMPX) is the leading high-tech media company providing essential information and marketing services to the entire technology spectrum: the builders, sellers and users of technology worldwide. With its portfolio of newspapers, magazines, custom publishing, Internet products, research, consulting and conferences, CMP is uniquely positioned to offer marketers comprehensive, integrated solutions tailored to meet their individual needs. Online editions of the company's print publications, along with products and services created exclusively for the Internet, can be found on CMPnet at http://www.CMPnet.com. NSTL, the company's independent testing lab and consulting organization, serves government, corporate and technology vendor clients around the world. - - - - - - - - - - - - - - - - -