Date: Sun, 20 Jun 93 04:30:07 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #159
To: tcp-group-digest


TCP-Group Digest            Sun, 20 Jun 93       Volume 93 : Issue  159

Today's Topics:
                    ampr.org DNS problem (2 msgs)
         Cslip (NOS) routing problem with bad TCP option ???
                      Password security (2 msgs)

Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
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 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: Sat, 19 Jun 93 14:37:13 PDT
From: rosenaue@mprgate.mpr.ca (Dennis Rosenauer)
Subject: ampr.org DNS problem
To: tcp-group@ucsd.edu

Brian Kantor said:
> 
> I've rebuilt the AMPR.ORG nameserver database from the ground up, once again.
> 
> I really wish people would take more care in what they send the robot; I don't
> have time to make the robot smart enough to keep every single error out of the
> input files.  Arrgh!
>  - Brian
> 
Maybe someone who is familiar with the robot would be kind enough to post the
correct instructions on how to talk to the AMPR.ORG robot.  I don't
remember ever having seen anything on how to talk to the robot.  (Maybe I
don't read tcp-group enough :-)).

-- 
Dennis Rosenauer VE7BPE                  rosenaue@mprgate.mpr.ca
MPR Teltech Ltd.
Radio & Satellite Network Development    "For every vision there is an
Burnaby, B. C.                            equal and opposite revision"

------------------------------

Date: Sun, 20 Jun 93 12:44:03 +1000
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: ampr.org DNS problem
To: rosenaue@mprgate.mpr.ca (Dennis Rosenauer), tcp-group@ucsd.edu

In atricle by Dennis Rosenauer:
> Maybe someone who is familiar with the robot would be kind enough to post the
> correct instructions on how to talk to the AMPR.ORG robot.  I don't
> remember ever having seen anything on how to talk to the robot.  (Maybe I
> don't read tcp-group enough :-)).

[From Brian a while back...]

UCSD runs a mail robot that can update the master domain server for ampr.org.
To submit entries to the robot, e-mail to     ampraddr@ucsd.edu
with the data in the body of the message.  You will receive a confirmation
by return mail, unless your mailer puts buggered return addresses in your
mail.

Updates are added to the memo database immediately.  Each morning at about
4 am UCSD time, the memo database is processed to make a new version of
the ampr.org domain, the net-44 PTR domain, and the amprnet.hosts files
that are available from UCSD's anonymous FTP area.  Usually within a day
or two the nameserver process here is restarted and the changes take
effect.

Entries consist of three or four key fields and one data field.  For example,

 wb6cyt in a 44.8.0.1
 wb6cyt in mx 10 wb6cyt
 wb6cyt in mx 20 cyberpunk.ucsd.edu.
 wb6kdt in cname wb6cyt

Observe carefully:

1. '.ampr.org' is assumed and should never appear in any entry.
2. names that appear in the ampr.org domain do NOT end with a dot.
3. names that are external to the ampr.org domain MUST end with a dot.
4. you may NOT have a cname if ANY other data for that name appears.

----
 Warren

------------------------------

Date: Sat, 19 Jun 93 05:49 PDT
From: Denis DeLaRoca (310) 825-4580        <CSP1DWD@MVS.OAC.UCLA.EDU>
Subject: Cslip (NOS) routing problem with bad TCP option ???
To: Phil Karn                           <karn@servo.Qualcomm.com>

In doing anonymous FTP to wuarchive.wustl.edu (a DEC Alpha) at the
end of a cslip link (via a ka9q ether/slip router) I noticed that
the wustl host was unable to open data connections back to me...
turns out that he's sending a SYN pkt with the usual MSS tcp option
followed by 3 octets that don't look to me like a valid option...

When routing, the packet gets mangled slightly and a bad checksum
computed when going thru the cslip header compression routines, if
you turn tcp header compression off then the packet gets thru...
I enclose trace entries showing the before/after versions of the
pkt... if there's something obvious in the tcp header compression
code that you see fixing the problem could you post it?

Regards,

-- Denis

--------------------- ORIGINAL PACKET ------------------------------
Sat Jun 19 01:36:38 1993 - eth0 recv:
Ether: len 62 00:dd:01:02:79:d1->00:00:c0:33:f3:13 type IP
IP: len 48 128.252.135.4->128.97.62.128 ihl 20 ttl 46 tos 8 prot TCP
TCP: 20->1026 Seq x7dbe6e00 SYN Wnd 32768 MSS 536
0000  00 00 c0 33 f3 13 00 dd 01 02 79 d1 08 00 45 08  ...3......y...E.
0010  00 30 03 47 00 00 2e 06 c2 97 80 fc 87 04 80 61  .0.G...........a
0020  3e 80 00 14 04 02 7d be 6e 00 00 00 00 00 70 02  >.....}.n.....p.
0030  80 00 51 04 00 00 02 04 02 18 01 03 03 00        ..Q...........

--------------------- ROUTED PACKET --------------------------------
Sat Jun 19 01:36:38 1993 - sl0 sent:
serial line IP: len:  48
IP: len 48 128.252.135.4->128.97.62.128 ihl 20 ttl 45 tos 8 prot TCP
TCP: 20->1026 Seq x7dbe6e00 SYN Wnd 32768 MSS 536 CHECKSUM ERROR (41986)
0000  45 08 00 30 03 47 00 00 2d 06 c3 97 80 fc 87 04  E..0.G..-.......
0010  80 61 3e 80 00 14 04 02 7d be 6e 00 00 00 00 00  .a>.....}.n.....
0020  70 02 80 00 51 04 00 00 02 04 02 18 00 00 60 00  p...Q.........`.

------------------------------

Date: Sat, 19 Jun 93 09:13:21 PDT
From: enge@almaden.ibm.com
Subject: Password security
To: TCP-GROUP@UCSD.EDU

In <1254.bill.simpson@um.cc.umich.edu> "William Allen Simpson" <bill.simpson@um.cc.umich.edu> writes:
>The method of sending a Challenge value, and returning a MD5 hash
>response based on a the challenge, a message number, and a
>secret/password, is well documented in RFC-1334, PPP Authentication
>Protocols.
>
>No passwords are sent over the link.  It's easy to use and maintain as
>long as there are a small number of users.
>
>I am working on extending this to Kerberos and PEM certificates, for
>sites with tens of thousands of users.
>
>Bill.Simpson@um.cc.umich.edu
>

OK.. I will try it.  Now, where do I find MD5 in either assembler
or Turbo Pascal?

Roy, AA4RE

------------------------------

Date: Sun, 20 Jun 1993 03:56:41 +0300 (EED)
From: mea@Mea.cc.utu.fi ("Matti E. Aarnio [OH1MQK]")
Subject: Password security
To: enge@almaden.ibm.com

> OK.. I will try it.  Now, where do I find MD5 in either assembler
> or Turbo Pascal?
> 
> Roy, AA4RE

  In C and partial assembly in latest NOS sources.
I was able to port NOS ftp-server's MD5 "file-signaturing"
on a SPARC system.

  Assuming you have TP5 or later (with 32bit signed/unsigned
integers), it should not be a problem at all to port is.
However, do make "cut, and paste" copy of several vast
arrays of data in the MD5.  They are impossible to get
right if you type by hand..

 /Matti Aarnio <mea@utu.fi> OH1MQK

------------------------------

End of TCP-Group Digest V93 #159
******************************
******************************