Re: can vpn's extended to mobility
> The "P" in > "VPN" stands for "privacy", which requires encryption ... I expected the term or concept of "data confidentiality" (the "p" is silent) to be bundled into this service model, not "privacy". Eric
Re: can vpn's extended to mobility
> The most popular IETF standard for VPNs is IPsec using ESP. IPsec could be improved for wireless: http://pilc.grc.nasa.gov/pilc/list/archive/1012.html http://pilc.grc.nasa.gov/pilc/list/archive/1022.html Now PPP-over-SSH isn't any better, just a lot easier and much less expensive for most people on both Unix and Windows. Either would probably be an acceptable mobile VPN solution. IPsec would probably add less latency, but not much compared to what existing wireless customers are used to. If I ever get 128kbps Ricochet on my neighborhood lamp-post, I'll try and see what the round trip time for ppp-over-ssh ends up. I'm not thrilled with the 0.7s first-hop round-trip of plain Richochet wireless service to begin with, nor with the fact that the location of that first hop is New Jersey when the modem is in California. Cheers, James
RE: can vpn's extended to mobility
At 2:19 PM -0700 9/26/00, Dave Crocker wrote: >At 07:56 PM 9/26/00 +0100, Lloyd Wood wrote: >>Beg to differ. Encapsulation makes the VPN virtual. >>Encryption ensures that the VPN is private. >> >>All networks are privately managed, whether virtual or not; referring >>to that explicitly seems a bit pointless to me... > > >while your explanation is entirely logical and reasonable, it does >not match the actual history of the term. The "actual history" is not what is important here; what the "actual customers" expect is important. We are seeing more an more ISPs offering VPNs, some using IPsec, some not. >the term vpn has always been independent use of encryption. That was true up to about three years ago, but it shifted when IPsec became widely deployed. VPN-as-frame-relay pretty much fell out of the public mind. Now some ISPs are trying to resurrect the old "private management" definition because it is much cheaper for them than to offer actual privacy. >historically there was -- and pretty much still is -- a distinction >between public (open) and private networks. When the network runs >on top of another network, rather than using its own wires, it is >called virtual. hence the composed term "virtual private". This sounds a whole lot closer to Steve Kent's "virtually private". It makes sense in the old "we own the wires" world, but not in today's "we care about someone seeing our data" world. --Paul Hoffman, Director --Internet Mail Consortium
Re: can vpn's extended to mobility
> Usage of language does change and meaning does evolve. (has anyone set > up a VPN sans encryption recently?) Well, does it count if the encryption doesn't cover the whole path? I'm aware of a number of ipsec "vpn" hardware vendors out there who are looking to put encryption in ISP edge "concentrator" boxes rather than at the customer site, for some reason which completely escapes me -- the traffic ends up in the clear on the last hop to the customer! - Bill
RE: can vpn's extended to mobility
At 07:56 PM 9/26/00 +0100, Lloyd Wood wrote: >Beg to differ. Encapsulation makes the VPN virtual. >Encryption ensures that the VPN is private. > >All networks are privately managed, whether virtual or not; referring >to that explicitly seems a bit pointless to me... while your explanation is entirely logical and reasonable, it does not match the actual history of the term. the term vpn has always been independent use of encryption. although ISPs, and their cohorts, are legally private, the thing referred to as "The Internet" is considered to be a public network. (not in the ITU or legal sense, but in terms of broad, open access.) historically there was -- and pretty much still is -- a distinction between public (open) and private networks. When the network runs on top of another network, rather than using its own wires, it is called virtual. hence the composed term "virtual private". again, encryption is an important function, but it has always been an added feature to vpn's, rather than an inherent component. d/
Re: Topic drift Re: An Internet Draft as reference material
> As someone who was around when the notion of an I-D was created, let > me disagree somewhat. There was a very definite intent to cause I-Ds > to "officially" disappear after a limited time frame. I don't doubt that at all. But did folks really think that I-Ds would completely vanish from the face of the earth? And did they consider that I-D expiration might be useful even if I-Ds did not completely vanish? we've got people arguing that since we can't make I-Ds vanish completely, that the expiration is pointless. my argument is that the combination of the expiration and the fact that old I-Ds can be found if you look hard enough, turns out to be useful. Keith
Re: Topic drift Re: An Internet Draft as reference material
As someone who was around when the notion of an I-D was created, let me disagree somewhat. There was a very definite intent to cause I-Ds to "officially" disappear after a limited time frame. Steve
RE: can vpn's extended to mobility
For a number of years I have joking referred to VPNs without encryption as "virtually private networks" as opposed to "virtual private networks," to emphasize the difference. But, I agree, the historical use of the acronym VPN did not imply crypto security, just "private" management. Steve
Re: Topic drift Re: An Internet Draft as reference material
> > IETF's current policy makes the I-D series more valuable than it would > > be if [...] I-Ds did not expire at all > > I see your point, but there's an easy solution. If there are two > interfaces (or one, with a checkbox), and the default is to search only the > I-Ds under 6 months old, then the noise level doesn't go up unless you > decide you need it to. actually my point isn't about the noise level associated with having additional documents returned in a search - it's about the I-D series being more useful for particular purposes *precisely because of mechanisms that are designed to limit, but not totally prevent, use of old I-Ds*. Keith
RE: can vpn's extended to mobility
>>Others might have a very different definition of VPN. The "P" in "VPN" >>stands for "privacy", which >I thought the word was "private" rather than "privacy". "Private" has two >different meanings, one for shutting out others from seeing, but the other >referring to restricted management, as in being under private control. That is correct. A "Virtual Private Network" is a network that utilizes a public medium, but is privately managed. Encapsulation is what makes a VPN private, not encryption. I think that encryption is a tremendously important component of an Internet-based VPN, and I wouldn't use a VPN over the Internet without encryption. Nevertheless, the term VPN does NOT necessitate encryption.
Re: can vpn's extended to mobility
At 09:42 AM 9/26/00 -0700, Paul Hoffman / VPNC wrote: >Others might have a very different definition of VPN. The "P" in "VPN" >stands for "privacy", which I thought the word was "private" rather than "privacy". "Private" has two different meanings, one for shutting out others from seeing, but the other referring to restricted management, as in being under private control. Over the public Internet, clearly privacy is an important for some applications. However the earlier uses of the term VPN simply referred to a network that was under private administration, but is operated over a public one. d/
Re: Topic drift Re: An Internet Draft as reference material
Keith Moore wrote: > IETF's current policy makes the I-D series more valuable than it would > be if [...] I-Ds did not expire at all I see your point, but there's an easy solution. If there are two interfaces (or one, with a checkbox), and the default is to search only the I-Ds under 6 months old, then the noise level doesn't go up unless you decide you need it to. -- /==\ |John Stracke| http://www.ecal.com |My opinions are my own.| |Chief Scientist |=| |eCal Corp. |Earth: love it or leave it. | |[EMAIL PROTECTED]| | \==/
Re: can vpn's extended to mobility
At 4:09 AM +0200 9/24/00, Fred Baker wrote: >A VPN is, by my definition, any case where one overlays the global >Internet with another private Internet using tunneling. Tunneling >procedures today include MPLS, IPSEC, IP/IP, GRE/IP, and probably >several others. Others might have a very different definition of VPN. The "P" in "VPN" stands for "privacy", which requires encryption. Without a lower layer of encryption, it is trivial for someone to snoop on your MPLS or IP/IP or GRE/IP tunnel. The things described above are VINs, or Virtual Isolated Networks (thanks to Tero Kivenen for the term). VINs have useful features, but privacy is not one of them. The most popular IETF standard for VPNs is IPsec using ESP. --Paul Hoffman, Director --VPN Consortium
Re: Topic drift Re: An Internet Draft as reference material
Keith Moore wrote: [..] > It just means > that IETF is removing the most widely known and most authoritative > source of an I-D after six months. I think that was my point. [..] > IETF's current policy makes the I-D series more valuable than it would > be if either I-Ds did not expire at all, or if they somehow disappeared > from existence. We clearly differ. This thread isn't about whether IETF's policy makes I-Ds more or less valuable. It started with the circumstances under which citation of I-Ds is warranted (there are some), and moved to whether longevity of I-D archives would be a good thing for IPR searches (it would be). Arguing that anyone can stop such archiving - especially since the IETF has been doing it indirectly with CD-ROM proceedings - is what I'm finding pointless about this entire thread now. Asserting that somehow somehow any of this will make I-D citations any more or less prevalent is naieve. cheers, gja
Re: Topic drift Re: An Internet Draft as reference material
> I just love this mythology that "expires in 6 months" > means expunged from all retrievable record in 6 months. nobody believes that, nor has anybody said they really want that. just because IETF has a policy of not making I-Ds available after 6 months does not mean that IETF's goal is to suppress these documents after that length of time, or ever.It just means that IETF is removing the most widely known and most authoritative source of an I-D after six months. don't confuse the policy with the goal, they are not the same. the relationship of the value of information according to the degree of its exposure is rarely monotonic. specifically for internet drafts, IETF's current policy makes the I-D series more valuable than it would be if either I-Ds did not expire at all, or if they somehow disappeared from existence. Keith
Re: An Internet Draft as reference material
Tim Salo wrote: > > > Date: Mon, 25 Sep 2000 23:36:00 -0700 > > From: Joe Touch <[EMAIL PROTECTED]> > > Subject: Re: An Internet Draft as reference material > > > > > >From RFC 2026, Section 10.3.1. All Contributions: > > > > There are many IDs (a couple of which I also wrote) which > > predate that RFC which are being proposed. > > > > It is not the archival of post-2026 IDs that is of concern, > > nor the basic idea of keeping an archive. However, it seems > > reasonable to expect, as copyright OWNER of the material of > > those pre-2026 IDs, that we be _asked_ for permission to post. > > >From RFC 1602: > > 5.4. Rights and Permissions > > In the course of standards work, ISOC receives contributions in > various forms and from many persons. To facilitate the wide > dissemination of these contributions, it is necessary to establish > specific understandings concerning any copyrights, patents, patent > applications, or other rights in the contribution. The procedures > set forth in this section apply to contributions submitted after 1 > April 1994. For Internet standards documents published before > this date (the RFC series has been published continuously since > April 1969), information on rights and permissions must be sought > directly from persons claiming rights therein. > Note that your claims highlight the importance of one of the major > motivations for the creation of the ISOC and the formalization of the > intellectual property rights to documents submitted to the IETF, > namely the difficulty faced by those wishing to create compilations of > RFCs. Compilations of RFCs are different from IDs. IDs were designed to disappear; that is a condition under which they were (and are) written. That's why RFC2026 explicitly indicates the conditions under which ID material will be made available after the 6-mos limit. And why it may have a chilling effect to do otherwise. Joe
Re: An Internet Draft as reference material
> From: Keith Moore <[EMAIL PROTECTED]> > Subject: Re: An Internet Draft as reference material > Date: Mon, 25 Sep 2000 18:34:54 -0400 > > > To the contrary, I believe that you granted broad permissions when you > > submitted a document as an Internet Draft. > > a. not everybody uses the "anything goes" form of the boilerplate, >nor are they required to do so. > > b. some internet drafts predate that boilerplate >From RFC 2026: 10.3.1. All Contributions By submission of a contribution, each person actually submitting the contribution is deemed to agree to the following terms and conditions... >From RFC 1602: 5.4.1. All Contributions By submission of a contribution to ISOC, and in consideration of possible dissemination of the contribution to the Internet community, a contributor is deemed to agree to the following terms and conditions: ... I believe that the requirement that authors include the boilerplate was added fairly recently in response to some authors submitting documents that explicitly stated that the author was not granting the rights specified in RFC 1602 and RFC 2026. I understand that only specific exceptions to this grant of rights are currently permitted, to avoid each author creating their own exceptions (e.g., "My document can't be distributed on Tuesdays"). (The current discussion _may_ raise the issue of whether any exceptions to these grants of rights should be permitted.) This grant of rights has been in effect since April 1, 1994. I understand that the function of the boilerplate is to reduce quibbling by requiring the author to make this grant of rights explicit. Yes, some Internet Drafts pre-date April 1, 1994, and I assume their status is less clear. -tjs
Re: Topic drift Re: An Internet Draft as reference material
Keith Moore wrote: > > I just checked - my browser bookmarks include at least 5 bookmarked references > > to the output of search pages. People are going to do it. ;) > > I'm not at all sure that we want to go the search engine route, but > it's a trivial matter to make a search engine return URLs that can only > be referenced for a short time. Unless your search engine's form handler rejects GET (most Web programming APIs try to hide the difference between GET and POST), it's an even more trivial matter to construct URLs that invoke the search engine with specified parameters. If the form handler does reject GET, it's...not trivial, maybe, but easy...to build a handler someplace else that accepts GET and POSTs the query to the search engine. All in all, blocking like this just isn't worth the trouble. -- /===\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist |==| |eCal Corp. |"Hastur was paranoid, which was simply a | |[EMAIL PROTECTED]|sensible...well-adjusted reaction to living in| ||Hell." --_Good Omens_ | \===/
Re: An Internet Draft as reference material
> Date: Mon, 25 Sep 2000 23:36:00 -0700 > From: Joe Touch <[EMAIL PROTECTED]> > Subject: Re: An Internet Draft as reference material > > > >From RFC 2026, Section 10.3.1. All Contributions: > > There are many IDs (a couple of which I also wrote) which > predate that RFC which are being proposed. > > It is not the archival of post-2026 IDs that is of concern, > nor the basic idea of keeping an archive. However, it seems > reasonable to expect, as copyright OWNER of the material of > those pre-2026 IDs, that we be _asked_ for permission to post. >From RFC 1602: 5.4. Rights and Permissions In the course of standards work, ISOC receives contributions in various forms and from many persons. To facilitate the wide dissemination of these contributions, it is necessary to establish specific understandings concerning any copyrights, patents, patent applications, or other rights in the contribution. The procedures set forth in this section apply to contributions submitted after 1 April 1994. For Internet standards documents published before this date (the RFC series has been published continuously since April 1969), information on rights and permissions must be sought directly from persons claiming rights therein. The following section of RFC 1602 contains a grant of rights to the ISOC similar to what is contained in RFC 2026. > (that goes for so-called 'community interest' archives as well) Note that your claims highlight the importance of one of the major motivations for the creation of the ISOC and the formalization of the intellectual property rights to documents submitted to the IETF, namely the difficulty faced by those wishing to create compilations of RFCs. -tjs
Re: Topic drift Re: An Internet Draft as reference material
good. so this thread can be closed now? gja Randy Bush wrote: > > > I just love this mythology that "expires in 6 months" > > so do i. it makes it clear that, if you keep it, it's your game > not ours. we don't support it beyond six months. > > randy -- Grenville Armitagehttp://members.home.net/garmitage/ Bell Labs Research Silicon Valley
Re: An Internet Draft as reference material
Tim Salo wrote: > > > Date: Mon, 25 Sep 2000 09:56:02 -0700 > > From: Joe Touch <[EMAIL PROTECTED]> > > Subject: Re: An Internet Draft as reference material > > [...] > > PS - is no one else alarmed by the re-publishing of material > > submitted under an explicit agreement for 'removal after 6 mos'? > > I know _I_ have not been asked for such permission. > > To the contrary, I believe that you granted broad permissions when you > submitted a document as an Internet Draft. For example, in > draft-touch-ipsec-vpn-00.txt you write: > > [...] >This document is an Internet-Draft and is in full conformance with >all provisions of Section 10 of RFC2026 except for the right to >produce derivative works. > [...] > > >From RFC 2026, Section 10.3.1. All Contributions: > >l. ... However, to the extent that the submission is or may > be subject to copyright, the contributor, the organization he > represents (if any) and the owners of any proprietary rights in > the contribution, grant an unlimited perpetual, non-exclusive, > royalty-free, world-wide right and license to the ISOC and the > IETF under any copyrights in the contribution. This license > includes the right to copy, publish and distribute the > contribution in any way, and to prepare derivative works that are > based on or incorporate all or part of the contribution, the > license to such derivative works to be of the same scope as the > license of the original contribution. > > On a bad day, I might be inclined to ask: Am I the only one concerned about > authors "forgetting" that they have granted broad rights to the > ISOC and IETF? Reading along further in the same document: >... Internet Drafts that >have been removed (for any reason) from the Internet-Drafts >directories shall be archived by the IETF Secretariat for the sole >purpose of preserving an historical record of Internet standards >activity and thus are not retrievable except in special >circumstances. It isn't so clear that the rights in Sec 10.3.1 supercede the implicit agreement in Sec. 8. Joe
