Re: interception proxies
> A copy of the note, admittedly very rough (just an outline, and a very > rough one at that) is at: > > http://www.isi.edu/touch/pubs/hazards-outline.txt This doesn't list what I thought was an obvious issue. If multiple nodes are originating packets with the same source IP address it will be rather hard for them to ensure the required uniqueness on the IP ID field (unique for the combination of source IP, destination IP and protocol). I suspect that most of boxes that play these games don't worry about IP ID which might cause garbage reassembly should the same IP ID be used when multiple such boxes are sending to the same IP address. Erik
Re: breaking the IP model (or not)
Greg Skinner wrote: > My general (cynical) opinion of NAT and other proxy technology is that > the marketplace spoke louder than the voices of the architectural > purists. (No offense intended.) However, given recent changes in the > economic climate, perhaps things will head in the opposite direction. > Looks like the IPv6.com IPO is on hold until the market picks up .
Re: breaking the IP model (or not)
Keith Moore <[EMAIL PROTECTED]> wrote: > there's something odd to my ear about people needing to > *be presented* with better alternatives than doing harm to the > architecture as opposed to those people *developing* better alternatives. With my scientist/engineer hat on, I like to develop architecturally pure solutions. They tend to have fewer awkward cases. The code evolves straightforwardly from the design. The boundary conditions are easier to test. With my pragmatist hat on, I realize I occasionally need to do things that will enable me to pay the bills. :( > I suspect there's something about the current economic climate that > favors development of quick fixes over development of sane ones. > but the apparent shortsightedness still bothers me. My general (cynical) opinion of NAT and other proxy technology is that the marketplace spoke louder than the voices of the architectural purists. (No offense intended.) However, given recent changes in the economic climate, perhaps things will head in the opposite direction. --gregbo, enjoying this thread
Re: breaking the IP model (or not)
Keith Moore wrote: > perhaps architectural impurity alone shouldn't keep you from doing > something, but the fact that something violates fundamental design > assumptions should cause you to do some analysis and hard thinking > about the likely consequences of using them. and if you are in the > business of selling boxes that violate the design assumptions you > shouldn't misrepresent these to your customers. True, however I think at least some of the customers are also to blame. In their haste to get on the Internet they went out and bought NAT boxes without understanding their limitations. I hear about this sort of thing even outside of the context of NAT, e.g. with people who have non-globally routable IP address blocks and don't understand why they can't reach certain sites. They then complain to their ISPs, who point out that their service does not guarantee global routing. --gregbo
Re: breaking the IP model (or not)
Keith Moore wrote: > it's not at all clear whether NAT provided additional time for > IPng development or whether such time was really needed. IPv6 was > largely developed before NAT enjoyed significant deployment, and > arguably NAT has delayed adoption of IPv6. and because of the NAT > deployment it is now somewhat "untimely" to deploy applications like > IP telephony. whereas if IPv6 had been adopted a bit earlier > (because NAT had not filled the vacuum, so to speak) IP telephony > would work just fine with it. True, but you also have to take into account that IPv4 is mature technology (and was so at the time of NAT deployment). The user demand for Internet access made NAT a more attractive avenue because the industry had confidence that it would work without them having to make changes. If you could sell a NAT-compliant box you had an eager market; not quite so with an IPv6 compliant box. > of course, IPv6 might have moved along slowly even without NAT. > but it would probably have moved faster had NATs not existed. Maybe. Hard to say. Depends on how comfortable the industry would have been with it. > best thing I can say about NAT is that it motivated me to work on 6to4. :) --gregbo
RE: recommendation against publication of draft-cerpa-necp-02.txt
Title: RE: recommendation against publication of draft-cerpa-necp-02.txt Keith Moore wrote: > > . . . > > > > > 3. Aside from the technical implications of intercepting traffic, > > > > > redirecting it to unintended destinations, or forging traffic from > > > > > someone else's IP address - there are also legal, social, moral and > > > > > commercial implications of doing so. > > > > > > > > You will need to be far more specific here. I see absolutely nothing that > > > > is not legal, is not social, or is not moral. > > > > > > Okay, I'll offer a few specific examples, by no means the only ones: > > > > > > 1. an Internet service provider which deliberately intercepts traffic > > > (say, an IP packet) which was intended for one address or service, > > > and delivers it to another address or service (say that of an interception > > > proxy) may be misrepresenting the service it provides (it's not really > > > providing IP datagram delivery service because IP doesn't work this way). > > > > Okay, I think I see the mistake you're making. You're crossing > > abstraction layers and conflating two different things (the name of > > a service with the end point of the connection to that service). You > > are criticizing the moving of an endpoint when what you really > > object to is the misrepresentation of a service. Or do you also > > object to HTTP redirects, dynamic URL rewriting, CNAMEs, telephone > > Call Forwarding, or post office redirecting of mail after you move? > > I don't object to redirects at all, as long as they are carefully > designed. I do object to misrepresenting the service. As I've > said elsewhere, if the service wants to set up an interception proxy > on its own network to help make its service more scalable, I have > no problem with that. I do have a problem with unauthorized third > parties setting up interception proxies. (which is according to > my understanding all the most common application of such devices) I, too, have been watching this conversation from the sidelines, primarily to see the general opinions of the IETF on this topic. However, as one who is considering deploying such devices both topologically close to servers (so-called "Web accelerators") and topologically close to clients of the servers (as an owner of the servers -- so-called "content distribution"), this is of vital interest to me. In both cases that we are considering, the devices are within the same administrative domain as the servers (effectively administered by the content owner). This is, as a number of people mentioned, a key differentiator in this discussion. For Internet network-based applications such as streaming media and rich content, both of these technique provide significant advantages for the administrators of the delivery, hence the intent of NECP is important. And, as Bill Sommerfeld wrote: > A quick read through draft-cerpa-necp-02.txt suggests that it's > primarily targeted at forms of redirection which occur at the request > of service operators. Such systems are best thought of as a funny > kind of application-layer proxy, and are far less damaging to the > end-to-end internet model than the transparent proxies cited above. > > I think it's important to carefully distinguish between these sorts of > redirection. Some clarifying text in the draft to this effect would > be helpful. I agree that this is important, as well. Patrik Fältström said > I have no problem whatsoever to have proxies being part of the > web-model, but I am strongly opposing someone in the middle of the > communication path intercepting and redirecting IP-packages, as the > client will not communicate with whoever he wanted. With which I also agree. However, I do not see an appropriate documentation of NECP as incompatible with those two views. ssh -- Steve Hultquist VP Ops Accumedia, Boulder, CO USA
RE: rfc-editor?
At 04:46 PM 4/14/00 +, Bob Braden wrote: >There IS no dark conspiracy here, just people devoting CONSIDERABLE >time and energy (without stock options, I might add) to making the >internet work. A great idea! Stock options in the RFC Editor function! - A hot startup of about 25 years (in real time, not Internet time) - Geekier than Slashdot - Can change the definition of the Internet by themselves overnight - Content is created for them by industry leaders for free - Just look at the demographics of the people who come to their "standards portal" - Imagine how much Cisco or Microsoft would spend to buy them
Re: rfc-editor?
A grace note on John's reply:
It is *precisely* because of the complexity of the organizational relationships
that we now have a contract and an MoU defining our relations with the
RFC Editor and the IANA respectively. As long as the contract and the MoU
are respected, it is no concern of ours how the staff concerned divide
their time.
Brian
John C Klensin - IAB Chair wrote:
>
> --On Friday, April 14, 2000 14:41 +0200 "Shaw, Robert"
> <[EMAIL PROTECTED]> wrote:
>
> > O.K., help me understand this. ISOC paid ISI a few hundred
> > thousand dollars (?) for the RFC-Editor functions (wasn't it
> > really funding for the entire IANA role?).
>
> No. It is important to understand that the IANA role and the
> RFC Editor one were _always_ separate, although some of the same
> people were historically involved in both and, again
> historically, both operated under Jon Postel's management.
>
> > However, since
> > Joyce Reynolds is now listed both as a staff member of ICANN
> > ("Manager of Publications") at
> > http://www.icann.org/general/abouticann.htm and "liaison" to
> > the RFC editor on the IAB pages at
> > http://www.iab.org/members.html the ISOC funding seems to have
> > been used/absorbed for ICANN staff?
>
> Again, no. Many of us find ourselves wearing multiple hats. I
> don't know the financial arrangements between ISI and ICANN that
> support the two arrangements for Joyce's time, but she is less
> than full time on either of them. I.e., part of her time
> involves RFC Editor work (and the related liaison to IAB),
> another involves some efforts on ICANN's part. As described in
> the most recent IAB Charter, there is also provision for a
> liaison from the IANA: while that position is now vacant, we
> assume it will soon be filled and do not expect that Joyce be
> the person filling that role.
>
> > However, since there is a recent MoU between IETF and ICANN
> > "Concerning the Technical Work of the Internet Assigned
> > Numbers Authority" at
> > http://www.icann.org/general/ietf-icann-mou-01mar00.htm, I'm
> > puzzled why the scope of this did not include the RFC-Editor
> > function? If the the absence is supposed to indicate some
> > IETF independence from ICANN, it's certainly not clear this
> > is reality if the IAB RFC-Editor liaison contact is working
> > for ICANN.
>
> If she were working full time for ICANN, and not at all for ISI,
> or if the RFC Editor function consisted of ICANN (and not ISI)
> staff, this would be an interesting observation and conclusion.
> But neither is the case.
>
> Again, the RFC Editor and IANA functions are separate and always
> have been. There are useful synergies between the two
> activites, which is why we have welcomed close coordination, but
> your confusion is due to assuming that the two are really the
> same.
>
> > The above MoU recognizes that the "IANA technical team is now
> > part of ICANN" and that the "IAB is chartered to designate
> > the IANA on behalf of the IETF". But isn't this agreement
> > only ad hoc recognition of reality since the IAB really
> > doesn't have any ability to (re)designate the IANA functions?
> > That's because there's this strong rumour going around that
> > the US Department of Commerce believes it is transferring the
> > IANA functions to ICANN
>
> IANA has traditionally had several functions, and some of the
> boundaries periodically create confusion. We are satisfied with
> the present relationships and hence see no prospect for having
> to change then. However, we believe that there is a fairly
> general understanding among IAB, ICANN, and US DoC that the IAB
> could, indeed, transfer the portions of the IANA efforts that
> relate to IETF work elsewhere if that were necessary or
> desirable.
>
> John Klensin
> IAB Chair
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Program Director, Internet Standards & Technology, IBM
On assignment for IBM at http://www.iCAIR.org
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: [EMAIL PROTECTED]
RE: rfc-editor?
*>
*> O.K., help me understand this. ISOC paid ISI a few hundred
*> thousand dollars (?) for the RFC-Editor functions (wasn't it really
*> funding for the entire IANA role?). However, since Joyce Reynolds is
*> now listed both as a staff member of ICANN ("Manager of Publications")
*> at http://www.icann.org/general/abouticann.htm and "liaison" to
*> the RFC editor on the IAB pages at http://www.iab.org/members.html
*> the ISOC funding seems to have been used/absorbed for ICANN staff?
Bob:
Let me be very clear about this: none of the ISOC funding that is
supporting the RFC Editor function at ISI has gone, or will go,
for ICANN functions. One member of the RFC Editor team is principally
supported by DARPA, but that does not mean that DARPA is supporting
RFC Editor functions. People can perform multiple functions, and
accountants can do the arithmetic, and it all works.
There IS no dark conspiracy here, just people devoting CONSIDERABLE
time and energy (without stock options, I might add) to making the
internet work.
Bob Braden
RE: rfc-editor?
--On Friday, April 14, 2000 14:41 +0200 "Shaw, Robert"
<[EMAIL PROTECTED]> wrote:
> O.K., help me understand this. ISOC paid ISI a few hundred
> thousand dollars (?) for the RFC-Editor functions (wasn't it
> really funding for the entire IANA role?).
No. It is important to understand that the IANA role and the
RFC Editor one were _always_ separate, although some of the same
people were historically involved in both and, again
historically, both operated under Jon Postel's management.
> However, since
> Joyce Reynolds is now listed both as a staff member of ICANN
> ("Manager of Publications") at
> http://www.icann.org/general/abouticann.htm and "liaison" to
> the RFC editor on the IAB pages at
> http://www.iab.org/members.html the ISOC funding seems to have
> been used/absorbed for ICANN staff?
Again, no. Many of us find ourselves wearing multiple hats. I
don't know the financial arrangements between ISI and ICANN that
support the two arrangements for Joyce's time, but she is less
than full time on either of them. I.e., part of her time
involves RFC Editor work (and the related liaison to IAB),
another involves some efforts on ICANN's part. As described in
the most recent IAB Charter, there is also provision for a
liaison from the IANA: while that position is now vacant, we
assume it will soon be filled and do not expect that Joyce be
the person filling that role.
> However, since there is a recent MoU between IETF and ICANN
> "Concerning the Technical Work of the Internet Assigned
> Numbers Authority" at
> http://www.icann.org/general/ietf-icann-mou-01mar00.htm, I'm
> puzzled why the scope of this did not include the RFC-Editor
> function? If the the absence is supposed to indicate some
> IETF independence from ICANN, it's certainly not clear this
> is reality if the IAB RFC-Editor liaison contact is working
> for ICANN.
If she were working full time for ICANN, and not at all for ISI,
or if the RFC Editor function consisted of ICANN (and not ISI)
staff, this would be an interesting observation and conclusion.
But neither is the case.
Again, the RFC Editor and IANA functions are separate and always
have been. There are useful synergies between the two
activites, which is why we have welcomed close coordination, but
your confusion is due to assuming that the two are really the
same.
> The above MoU recognizes that the "IANA technical team is now
> part of ICANN" and that the "IAB is chartered to designate
> the IANA on behalf of the IETF". But isn't this agreement
> only ad hoc recognition of reality since the IAB really
> doesn't have any ability to (re)designate the IANA functions?
> That's because there's this strong rumour going around that
> the US Department of Commerce believes it is transferring the
> IANA functions to ICANN
IANA has traditionally had several functions, and some of the
boundaries periodically create confusion. We are satisfied with
the present relationships and hence see no prospect for having
to change then. However, we believe that there is a fairly
general understanding among IAB, ICANN, and US DoC that the IAB
could, indeed, transfer the portions of the IANA efforts that
relate to IETF work elsewhere if that were necessary or
desirable.
John Klensin
IAB Chair
RE: rfc-editor?
> -Original Message-
> From: Brian E Carpenter [mailto:[EMAIL PROTECTED]]
>
> Jeff,
>
> The RFC Editor function is the subject of a contract, paid for and
> issued by the Internet Society on behalf of the IETF. The IAB, which
> I chaired until 2 weeks ago, by its latest charter "must approve the
[snip]
>
> The current contractor is the Information Sciences Institute of the
> University of Southern California, where the late Jon Postel worked.
>
> There is no individual human acting as RFC Editor; it's a team effort
> at ISI.
>
Brian,
O.K., help me understand this. ISOC paid ISI a few hundred
thousand dollars (?) for the RFC-Editor functions (wasn't it really
funding for the entire IANA role?). However, since Joyce Reynolds is
now listed both as a staff member of ICANN ("Manager of Publications")
at http://www.icann.org/general/abouticann.htm and "liaison" to
the RFC editor on the IAB pages at http://www.iab.org/members.html
the ISOC funding seems to have been used/absorbed for ICANN staff?
However, since there is a recent MoU between IETF and ICANN "Concerning
the Technical Work of the Internet Assigned Numbers Authority" at
http://www.icann.org/general/ietf-icann-mou-01mar00.htm, I'm puzzled
why the scope of this did not include the RFC-Editor function? If the
the absence is supposed to indicate some IETF independence from
ICANN, it's certainly not clear this is reality if the IAB RFC-Editor
liaison contact is working for ICANN.
The above MoU recognizes that the "IANA technical team is now part
of ICANN" and that the "IAB is chartered to designate the IANA on
behalf of the IETF". But isn't this agreement only ad hoc recognition
of reality since the IAB really doesn't have any ability to
(re)designate the IANA functions? That's because there's this
strong rumour going around that the US Department of Commerce
believes it is transferring the IANA functions to ICANN
Bob
--
Robert Shaw <[EMAIL PROTECTED]>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union
Place des Nations, 1211 Geneva, Switzerland
