Newsgroups: ampr.ip.digest From: pa2aga@pi8vnw.nts Date: Wed, 3 Jan 96 02:58:00 GMT Subject: TCP-Group Digest 95/309D Message-ID: Path: nl0jor.nl.cbpr.org!sys2.pe1nhl!pa3ewk.ampr.org!pi8shb!pi8zaa!pi8gcb!pi8wfl!pi8vnw!pa2aga Distribution: bbs.eu BBS-Reply-To: R:960103/0258Z @:PI8VNW.#ZH2.NLD.EU #:28563 [Hoek v Holland] FBB5.15c BBS-Message-ID: BBS-Newsgroups: TCPDIG @ EU < PA2AGA BBS-Gateway: PA3EWK PA3EWK.#NBO.NLD.EU [LBBS 0.1.6A] Lines: 205 From: PA2AGA@PI8VNW.#ZH2.NLD.EU To : TCPDIG@EU Received: from pa2aga by pi8hvh with SMTP id AA64668 ; Wed, 03 Jan 96 02:36:10 UTC Received: from pa2aga by pa2aga (NET/Mac 2.3.57/7.5.3) with SMTP id AA00017861 ; Wed, 03 Jan 96 02:18:49 MET Received: from pa2aga-10 by pa2aga with SMTP id AA00017828 ; Wed, 03 Jan 96 02:07:31 MET Received: from pa2aga-10 by pa2aga-10 (NET/Mac 2.3.56/7.1) with SMTP id AA00003025 ; Wed, 03 Jan 96 02:07:25 MET Date: Tue, 02 Jan 96 09:03:53 MET Message-Id: From: pa2aga To: tcp_broadcast@pa2aga-10 Subject: TCP-Group Digest 95/309D X-BBS-Msg-Type: B Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from ftp.UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Tue, 26 Dec 95 09:18:13 UTC From: ve2har@mtlgw.ampr.org Subject: HELP Hello Dear, I wonder what is the best way to prevent a user not to be able to kill a message in JNOS program,while allowing other functions. Thanks in advance,73 ... de VE2HAR,Robert ------------------------------ End of TCP-Group Digest V95 #304 ****************************** ------------------------------ Date: Thu, 28 Dec 1995 03:30:56 GMT From: postmaster@3rd1000.com (Postmaster) Subject: Unknown address The user this message was addressed to does not exist at this site. Please verify the name and domain in the original message that follows. Message was addressed to: KB7FUN@3rd1000.com ----- Original Message follows ----- From: Advanced Amateur Radio Networking Group To: tcp-group-digest@UCSD.EDU Date: Thu, 28 Dec 1995 04:30:01 -0800 (PST) Subject: TCP-Group Digest V95 #305 TCP-Group Digest Thu, 28 Dec 95 Volume 95 : Issue 305 Today's Topics: ENCRYPTING logins over radio FTP site for Linux TTYLINK client? Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from ftp.UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Thu, 28 Dec 1995 03:00:21 -0800 (PST) From: Phil Karn Subject: ENCRYPTING logins over radio >I've been playing with these (and enSKIP) with Linux and having a bad time >of it. Unfortunately the Linux code is trying to do copy/checksum/fragment in >one pass (which doesnt suit ESP/AH), and also to do MTU discovery - I'd be >interested to know if you have any good algorithms for getting the MSS right >for TCP segments going over encrypted channels, especially with stuff like SKI P >that keeps wanting to change key lengths. This is a known Hard Problem, and has been discussed a bit on the ipsec mailing list (ipsec@ans.net). My own implementation for KA9Q NOS does adjust the interface MTU for locally originated/terminated TCP connections to avoid fragmentation due to the extra ESP or AH overhead, but this of course doesn't help somebody else using you as a security gateway. In the end, everybody will speak IPSEC and this problem will go away. But until then, some form of MTU discovery would be the best solution. I haven't implemented it yet, but I think I can do it if I'm careful. >Its actually still not clear in the UK that AH is ok, as the signature itself >is an encryption. There has been a big argument over PGP keys, although the >DTI (our regulatory body) seems to have seen the light on that bit. I'm not going to get into this one again. Under US rules I think it's clear that cryptographic authentication is perfectly OK. Nothing says the authenticator has to be intelligible to third parties; such a requirement would make per-packet authentication a la AH pretty much infeasible because it would require a public key operation on every packet. Phil ------------------------------ Date: Wed, 27 Dec 1995 17:00:15 -0800 (PST) From: mwestfal@csci.csusb.edu (Michael Westfall) Subject: FTP site for Linux TTYLINK client? -- Could someone please point me to a FTP site where I can obtain the Linux TTYLINK client source code? ------------------------------------------------------------------------------- 73 de Mike, ax.25net: N6KUY@W6JBT.#SOCA.CA.USA.NA amprnet: n6kuy@n6kuy.ampr.org [44.18.0.49] internet : mwestfal@csci.csusb.edu "Linux: The Gates of Hell shall not prevail." GCS/M { -d+ p+ c++ l u++ e+(*) m++(-) s/+ !n-(---) h-- !f g+ w+ t++ r-(--) y+ } ------------------------------------------------------------------------------- ------------------------------ End of TCP-Group Digest V95 #305 ****************************** ------------------------------ End of TCP-Group Digest V95 #306 ****************************** ------------------------------ Date: Sat, 30 Dec 1995 00:18:23 -0800 From: paul@UCSD.EDU >From POP3@is.usmo.com. Sat Dec 30 08:13:55 1995 X-POP3-Rcpt: bh@is Return-Path: tnos-topics-request@lantz.com Received: from lantz.com (lantz.com [163.125.16.1]) by is.usmo.com (8.6.12/8.6. 9) with SMTP id VAA03102 for ; Fri, 29 Dec 1995 21:49:40 -0600 Received: by lantz.com (Smail3.1.29.1 #1) id m0tVroP-00123ca; Fri, 29 Dec 95 22:18 EST Message-Id: <199512300318.TAA17498@precipice.shockwave.com> To: tcp-group@ucsd.edu cc: tnos-topics@lantz.com Subject: broken KA9Q tcp stack Date: Fri, 29 Dec 1995 19:17:59 -0800 Sender: Paul Traina From: Paul Traina Reply-To: tnos-topics@lantz.com Precedence: bulk It appears that the KA9Q TCP stack cannot handle a SYN packet with data and/or FIN's following. I've done some serious digging in tcpin.c to try to fix this and quite frankly, it's an ugly mess. Has someone else already looked at this in any NOS varient? Paul ------------------------------ End of TCP-Group Digest V95 #307 ****************************** ------------------------------ End of TCP-Group Digest V95 #308 ****************************** ------------------------------ End of TCP-Group Digest V95 #309 ****************************** You can send your message for this bulletin to: tcp-group@pa2aga on .AMPR.ORG-net or: tcpaga@pi8vnw.#zh2.nld.eu on BBS-net ------ NOT TO: pa2aga@pa2aga or pa2aga@pi8vnw.#zh2.nld.eu PLEASE!! It will get posted automatically within a few days