The message below majordomo accepted and forwarded to a "closed" list,
even though the posting address was not a subscriber or on the extended
"autoapprove" list.
My guess is that this happened because ab.com's got some kind of funky
forwarder which changed the envelope (return-path?), but did not change
the From:. Majordomo must have valided the From:, and resent it but
substituted the return-path address in the From: field.
If this can be prevented, it should be. Some six hundred people on
the list were forced to endure >50 (so far?) re-postings, despite the
list being configured to prevent outside postings. I had prohibited
outside postings exactly because of problems like this.
Ugh.
~sparker
------- Forwarded Message
Return-Path: IPNG@WORLD.REMNET.AB.COM
Return-Path: <IPNG@WORLD.REMNET.AB.COM>
Received: from sunroof2.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id LAA19199; Sun, 26 Feb 1995 11:30:28 -0800
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
id AA09175; Sun, 26 Feb 95 11:37:27 PST
Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA19797; Sun, 26 Feb 1995 11:28:48 -0800
Received: from ns1.mke.ab.com by Sun.COM (sun-barr.Sun.COM)
id AA18029; Sun, 26 Feb 95 11:28:48 PST
Received: from ABSSW.REMNET.AB.COM (mkeibm.mke.ab.com) by ns1.mke.ab.com (4.1/SMI-4.1)
id AA10995; Sun, 26 Feb 95 13:30:07 CST
Received: from WORLD.REMNET.AB.COM by ABSSW.REMNET.AB.COM
(Soft*Switch Central V4L380P5) id 340548170095055FWORLD;
24 Feb 1995 17:48:17 CST
Message-Id: <WORLD.IPNG.340548170095055FWORLD@REMNET.AB.COM>
Date: 24 Feb 1995 17:48:17 CST
From: "IPNG" <IPNG@WORLD.REMNET.AB.COM>
Subject: Re: (IPng) Re: out-of-band key management is like virtual c
To: ipng@SUNROOF.Eng.Sun.COM
Cc: "Dan Nessett" <Danny.Nessett@Eng>, ipng@sunroof2.Eng.Sun.COM,
ipsec@ans.net
Comment: MEMO 02.24.95 17.48
Content-Type: text
Content-Length: 2146
Ran,
I still await your response to my concerns in general the way the spec
is written I sent out Monday Feb 20th.
> I find your analogy to be highly misleading. I strongly disagree
>with your assertion that in-band key mgmt is better for a datagram
>network. All of the capability that you assert is unique to in-band
>can be done by simply sending key mgmt packets at the same time one
>sends the datagrams. Since SAIDs are receiver-oriented, a sender can't
>force a key upon the receiver without the receiver's involvement in
And where are these key mgmt packets in relation to the IPv6 packet?
I can't parse what your thinking here?
So far Danny has not been misleading and its obvious to me? You have
not convinced me it is misleading, but I am sure Danny will reply too.
>any case. If we remove that receiver-orientation, then IP multicasting
>will not work well with security (and multicasting is a 1st order
>service of IPv6).
I don't agree with this is at all. Multicast for system discovery or
autoconfiguration absolutely. Not for applications. The bulk of
applications will still use unicast addresses for datagrams at least for
the next 5 years.
> Out of band keying does NOT mean "on average, very poor performance".
>Your assertion just is not true.
The assertion is intuitively true.
> We should continue to avoid coupling key mgmt and the security
>mechanisms and hence should continue to avoid in-band key mgmt in
>standards-track specifications within the IETF.
Better yet we need more people finally like Danny to come to IPNG and
send us a wake up call before we make something a proposed standard that
will cost so much in performance no one will use no matter how much
security they need.
Danny please continue your input on this we needed this kind of drilling
of the security specs.
/jim
- ------------------------------------------------------------------------------
IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng
Unsubscribe: unsubscribe ipng (as message body, not subject)
Direct all administrative requests to majordomo@sunroof.eng.sun.com
------- End of Forwarded Message
|
|
