Re: Internet SYN Flooding, spoofing attacks

[Robert Elz]

Date:Wed, 16 Feb 2000 18:20:43 -0800
From:Phil Karn <[EMAIL PROTECTED]>
Message-ID:  <[EMAIL PROTECTED]>

  | Even if I could find somebody at their help desk
  | who understood a request to open up their filter to my own IP addresses,
  | they would have no incentive to do so.

In an earlier message you just told us that ingress filtering would
never become widespread enough to really matter - but it seems to
have managed to trap you...

  | This all boils down to a basic issue of who controls the Internet
  | address space -- the users, or the monopolies who have long controlled

The address space is controlled by the routing system - that's
what the addresses are for.

  | Fortunately, secure tunneling protocols will always make it possible
  | for knowledgeable users to overcome these administrative restrictions
  | and to keep the carriers down at the physical level where they belong,
  | albeit with a loss in efficiency.

Well not always - it is possible to imagine an ISP that only permits
connections via their proxies, and blocks everything else.  They could
even market it as a "premium extra secure internet service - no nasty
packets from outside will ever reach your system" ...

But aside from that nonsense, tunneling is not a problem for ingres
filtering, it isn't defeating it (or not its purpose) at all.
To tunnel, you need a remote tunnel endpoint - and then you can only
send source addresses through the tunnel (and from there to the
universe) with addresses from the remote-endpoint's address range
(assuming ingress filtering is being done there as well).

That's all fine then, you're just acting as if you were a node
at their location (which is the point, more or less), and packets
you send that way are attributed to them, just the same as any
other packet sent from there.

If some site is willing to decapsulate packets from any random source
and forward them, then they take the heat for any packets that are
sent that way.

kre

Re: Internet SYN Flooding, spoofing attacks

[Phil Karn]

>I think we recognize this may be politically infeasable for many
>people to do, because tunneling is often used to circumvent
>administrative restrictions, but that really is a different degree of
>the problem.

Bingo. I tunnel because my cable modem provider requires residential
users to use DHCP to get IP addresses that can change at any time.  If
you want a static IP address, or additional IP addresses, you must pay
a considerable premium.

It's not because fixed addresses actually cost them more. Indeed,
another cable modem provider in the other part of town allocates fixed
addresses in an otherwise identical service that's $5/mo cheaper. No,
my provider does it simply because they can. They're a monopoly in
their service area.  Even if I could find somebody at their help desk
who understood a request to open up their filter to my own IP addresses,
they would have no incentive to do so.

This all boils down to a basic issue of who controls the Internet
address space -- the users, or the monopolies who have long controlled
the Internet's underlying transmission media and who are now moving up
the stack to aggressively control the IP layer and are imposing
restrictions on the content of their user's traffic.

Fortunately, secure tunneling protocols will always make it possible
for knowledgeable users to overcome these administrative restrictions
and to keep the carriers down at the physical level where they belong,
albeit with a loss in efficiency.

The question, then, is not whether users will be able to send packets
with arbitrary source addresses. They will. The question is whether we
get rid of the inefficiencies associated with a failed attempt to keep
them from doing so, and redirect our energies to better alternatives
for dealing with denial of service attacks.

Phil

Re: Internet SYN Flooding, spoofing attacks

[Phil Karn]

>Yes, and you chose the CORRECT solution. Think about it... VPN in most
>cases also means encryption, and at that probably back to a central
>site.

Yes, I often use encryption, but not to a central site. Generally I
apply it at the application layer (SSH/SSL) so the peer is whoever I happen
to be talking to. However, this is irrelevant to the issue of upstream
IP address filtering.

>Sorry. You're at the point where technology meets policy. Fact is, your
>host identifier in the IP stack is the source IP address. Enforcing the
>validity of that identifier has become necessary.

This makes no sense at all. I've shown both that there are legitimate
reasons to send packets that the ISP might consider "alien", and also
how easy it is to circumvent ingress filtering if you are so motivated.

By the way, ingress filtering breaks things other than Mobile IP.
Consider the DirecPC service, which gives you a one-way (forward)
satellite channel at 400 kb/s. Your return link is via local dialup
service provider. If the local ISP (or its upstream provider) does
source filtering, you can't send your perfectly legitimate packets
into the network over that ISP without tunneling them all through
DirecPC's own network connection, which may be on the other side of
the continent.

>The case for "legitimate use" of source spoofing has not been
>sufficiently made. Operational reality is such that it's not
>sustainable.

The operational reality is that you'll never be able to implement
ingress filtering widely enough to provide much of a benefit. Even if
you do, it'll be circumventable (consider the many Linux and Unix
boxes out there that support IP-in-IP tunneling). And the energy you
spend doing so will be energy that could have been better spent
implementing other mechanisms to defend the Internet against MS-DOS
(multiple source denial of service) attacks.

Phil

Re: Question re: an Internet-Draft and testing/deployment

[Masataka Ohta]

Dave;

> >I hope not, This will be the first IETF where this WG meets. This is -one-
> >of several methods being discussed. We haven't even reached closure on
> >the appropriate scope. This draft is an attempt to walk one vector of
> >the problem space.
> 
> Not just "discussed".  Tin Tan Wee has been working on this publicly for a 
> couple of years and now has a well-supported, fully operational service.

The problem is that the problem to be solved (or discussed) is not
well defined.

You can still have well-supported, fully operational, but, purposeless
services.

Masataka Ohta

Re: Question re: an Internet-Draft and testing/deployment

[Keith Moore]

> Not just "discussed".  Tin Tan Wee has been working on this publicly for a 
> couple of years and now has a well-supported, fully operational service.

which doesn't even begin to address a large number of problems.

anyone who believes they have running code for iDNS is deluding themselves.

Keith

Re: Internet SYN Flooding, spoofing attacks

[Stephen Kent]

Dan,

I'll suggest one course of action, but I keep emphasizing the issue 
is not one of alternates, but of recognizing the limitations of 
proposals now on the table and considering approaches that may work 
irrespective of whether everyone performs filtering.

With regard to a wide range of DoS or DDoS attacks, it seems quite 
feasible to monitor traffic to the web site to detect such attacks 
irrespective of whether source addresses are spoofed or not.  (this 
differs from IDS for broader attacks, where the recognition problem 
is much harder and the false negative rate is on the order of 20%.) 
Such monitoring can be done by a web hosting facility through purely 
passive monitoring, so as not to adversely affect the performance of 
the network used by a web hosting site.  Once an attack is detected, 
one can trigger a semi-automated response.  If one believes that the 
source addresses are not spoofed, then one can use this to direct 
filtering to selected ingress points, but the filtering can now be 
very focused, based o the characteristics of the detected DoS 
traffic. If one believes that source addressed might be spoofed, then 
one needs to activate the selective filtering on a much wider range 
of ingress points.  Since the true sources may be outside of the 
ISP's sphere of control, filtering at connections to other ISPs may 
be required in either case.

If the response is rapid enough, the attack may not have significant 
impact, which reduces the attraction of mounting such an attack in 
the first place.  One can begin disabling the filters once the 
offending traffic flows have diminished, which provides another means 
of determining the sources of traffic, as others have noted in 
previous published work on this topic.

An advantage of this style of approach is that while it can be even 
more effective if source address filtering is widespread, it also 
would work if such filtering is not completely effective, which is 
the sort of self-defense approach I prefer  It supports what the 
security community refers to as the Principle of Least Privilege.

Steve

Re: Question re: an Internet-Draft and testing/deployment

[Bill Manning]

% At 09:03 AM 2/16/2000 -0800, Bill Manning wrote:
% >I hope not, This will be the first IETF where this WG meets. This is -one-
% >of several methods being discussed. We haven't even reached closure on
% >the appropriate scope. This draft is an attempt to walk one vector of
% >the problem space.
% 
% Not just "discussed".  Tin Tan Wee has been working on this publicly for a 
% couple of years and now has a well-supported, fully operational service.
% 
% Dave Crocker  <[EMAIL PROTECTED]>

I am very aware of the APNG work on iDNS. However within the
context of the IETF and the IDN wg, there remain a number of
methods under discussion, including Tin Tan Wee's work. 

-- 
--bill

Re: Common Indexing Protocol (CIP)

[Jon Knight]

On Tue, 15 Feb 2000, Rick H Wesson wrote:
> does anyone know of any implementations of CIP? 

ROADS http://www.roads.lut.ac.uk/>.

Tatty bye,

Jim'll

Re: Internet SYN Flooding, spoofing attacks

[Steven M. Bellovin]

In message , Stephen Kent writes:
> Steve,
> 
> The AT&T experiences might be different, but at GTE-I, a SYN flood 
> was the primary attack mechanism for one major web site that we host. 
> Also, it is not at all clear that our network had a problem handling 
> the other flooded traffic (ICMP Echo Reply and UDP traffic) that was 
> sent to 3 other targets on our net, but the web hosts that were 
> targets certainly did suffer from processing the traffic.

Right.  Yahoo, though, was flooded mostly by the volume.  I worry about 
high-volume TCP garbage sent to port 80, which you can't filter.
> 
> Steve
> 
> P.S.  Nice photo and quotes in Newsweek!
> 
Thanks.

--Steve Bellovin

Re: Question re: an Internet-Draft and testing/deployment

[Valdis . Kletnieks]

On Wed, 16 Feb 2000 09:57:45 PST, Paul Hoffman / IMC <[EMAIL PROTECTED]>  said:
> The note shouldn't be needed, given the definition of an Internet Draft, 
> but it appears that many folks have forgotten that definition.

Ahh.. .  I was reading it as being even *more*
cautionary than the usual paranoia that should be created just from
its I-D status.  If the intent was just to remind people "Hey, it's
just an I-D, don't do this unless you're testing it", that's another
story.

/Valdis

Re: Question re: an Internet-Draft and testing/deployment

[Dave Crocker]

At 09:03 AM 2/16/2000 -0800, Bill Manning wrote:
>I hope not, This will be the first IETF where this WG meets. This is -one-
>of several methods being discussed. We haven't even reached closure on
>the appropriate scope. This draft is an attempt to walk one vector of
>the problem space.

Not just "discussed".  Tin Tan Wee has been working on this publicly for a 
couple of years and now has a well-supported, fully operational service.

d/

=-=-=-=-=
Dave Crocker  <[EMAIL PROTECTED]>
Brandenburg Consulting  
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

Gong Xi Fa Cai   /  Selamat Tahun Baru Cina

Re: IETF Adelaide and interim meetings for APPS WGs

[Dave Crocker]

At 10:55 AM 2/16/2000 -0500, Steven M. Bellovin wrote:
>Given airline load factors, I don't seem to be able to qualify for discounts
>on my trips to San Francisco from New Jersey -- which means that my 
>tickets to
>Adelaide are only very slightly more expensive.


only San Francisco? I thought the airline loading factor was because so 
many people want to leave New Jersey...

On the other hand, it would be amusing to imagine that high mortgage costs, 
or whatever, has people wanting to leave San Francisco... for New Jersey?

d/


=-=-=-=-=
Dave Crocker  <[EMAIL PROTECTED]>
Brandenburg Consulting  
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

Gong Xi Fa Cai   /  Selamat Tahun Baru Cina

Re: Internet SYN Flooding, spoofing attacks

[Stephen Kent]

Steve,

The AT&T experiences might be different, but at GTE-I, a SYN flood 
was the primary attack mechanism for one major web site that we host. 
Also, it is not at all clear that our network had a problem handling 
the other flooded traffic (ICMP Echo Reply and UDP traffic) that was 
sent to 3 other targets on our net, but the web hosts that were 
targets certainly did suffer from processing the traffic.

Steve

P.S.  Nice photo and quotes in Newsweek!

Re: IETF Adelaide and interim meetings for APPS WGs

[Thomas Narten]

> It is not the case that few WGs are holding meetings. The published agenda
> just isn't complete yet; it never is at this stage.

This is very true. Looking at the Internet Area, I expect all but one
of the WGs that normally have face-to-face meetings to meet in
Adelaide. Plus, there are three potential BOFs in the works, none of
which have been approved yet, and thus, also do not yet appear on the
agenda.

Thomas

Re: Question re: an Internet-Draft and testing/deployment

[Paul Hoffman / IMC]

At 10:49 AM 2/16/00 -0500, [EMAIL PROTECTED] wrote:
>Note: this protocol is quite experimental and should not be deployed in
>the Internet until it reaches standards track in the IETF.
>--- end excerpt
>
>Regarding the Note: - is there any coherent plan regarding testing/deployement
>in regards to moving this from Experimental to Standards Track?

As the draft author, let me assure you that it is far from being an 
Experimental RFC. I put these words in so that, if someone tripped across 
the draft and said "hey, let's implement this", they wouldn't think anyone 
else was. As others have said, there are a variety of IDN proposals at this 
time, and it would be downright silly for anyone to assume which, if any, 
of them will even look like the one that might be chosen down the line.

The note shouldn't be needed, given the definition of an Internet Draft, 
but it appears that many folks have forgotten that definition.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Internet SYN Flooding, spoofing attacks

[Steven M. Bellovin]

In message , Stephen Kent writes:
> Eliot,
> 
> Some of the DoS attacks we saw last week were good, old-fashioned SYN 
> floods.  Hosts do have a responsibility here, more than ISPs, since 
> it is quite feasible to tie up a host's pool of TCBs with a small 
> number of packets, even if the attack tool does not use spoofed 
> sourced addresses (or if the spoofed addresses are from a legitimate 
> pool allocated to a subscriber site).

Yes, though it isn't clear to me that most of those forged SYNs got through...
> 
> The point I have tried to make, unsuccessfully, is not that 
> performing ingress filtering is bad, and thus should not be 
> performed.  Rather, I am pointing out that it is a bad idea to rely 
> on such filtering as a primary means of defense. There are several 
> reasons for saying this:
>   - not all ISPs will find it feasible to provide such filtering
>   - not all ISPs are trusted to do the filtering (in the global Internet)
>   - a number of DDoS attacks can be launched without using 
> spoofed addresses outside of those "appropriate" to the subscriber 
> site
>   - some applications may legitimately make use of non-local 
> addresses, as others have suggested
> 

The problem here is that flooding attacks target the network, not the host.  
The host is thus not capable of mounting a defense -- it's not the victim, in 
some sense.

Conventional security methodology would say that the aggrieved party should do 
the authentication.  Of course, that's hard on the Internet -- in fact, we 
don't *want* people to have to authenticate themselves to the network elements 
in order to transmit.  (There are, of course, networks that do have such 
requirements.  The most common form is known as the telephone system.  I don't 
think we want to reinvent that.)  Filtering is a very coarse form of 
address-based authentication to the first outside hop; I don't see a better 
choice.

Perhaps the network can use beefed-up congestion control mechanisms to stop 
such floods.  I hope so, but it seems to be a research issue; I'd be surprised 
if such new mechanisms could be deployed sooner than 2002.  What do we do in 
the meantime?  (Trying to secure all of the myriad endpoints is even more 
hopeless than trying to get all ISPs to do proper filtering.)  Do you have any 
specific suggestions?  Seriously -- what do you recommend as a defense against 
flooding attacks?

--Steve Bellovin

Re: Internet SYN Flooding, spoofing attacks

[Daniel Senie]

Stephen Kent wrote:
> 
> Eliot,
> 
> Some of the DoS attacks we saw last week were good, old-fashioned SYN
> floods.  Hosts do have a responsibility here, more than ISPs, since
> it is quite feasible to tie up a host's pool of TCBs with a small
> number of packets, even if the attack tool does not use spoofed
> sourced addresses (or if the spoofed addresses are from a legitimate
> pool allocated to a subscriber site).

And at least one of the attacks last week indeed was a smurf. Filters
would have helped in some cases and not others.

> 
> The point I have tried to make, unsuccessfully, is not that
> performing ingress filtering is bad, and thus should not be
> performed.  Rather, I am pointing out that it is a bad idea to rely
> on such filtering as a primary means of defense. There are several
> reasons for saying this:

Reliance on any single method will be insufficient. It will take several
methods.

> - not all ISPs will find it feasible to provide such filtering

This needs to be addressed. Feasible due to expense of equipment,
loading, what? ISPs need to implement this now or soon. When purchasing
new gear, the ability to do filtering without affecting performance
should be on the list of features given to manufacturers.

When we first started the drafts for RFC 2267, back in 1996, concerns
were raised that equipment couldn't handle the load. The suggestion then
was the same. NEXT TIME you order equipment, make it a requirement. It
is possible to build the gear to do the filtering. If ISPs don't demand
it of their vendors, they won't get it, though.

> - not all ISPs are trusted to do the filtering (in the global Internet)

This issue can be addressed by their upstream providers with terms of
service agreements. Will it be perfect? Unlikely.

> - a number of DDoS attacks can be launched without using
> spoofed addresses outside of those "appropriate" to the subscriber
> site

Which is NO reason to permit attacks which DO spoof. Filtering is going
to limit the types of attacks which can be launched, and permits
idenitification of the systems and networks where the packets come from.
It may still be necessary to chase down those sites and get action, but
at least it's possible to know WHICH SITES are the sources.

> - some applications may legitimately make use of non-local
> addresses, as others have suggested

A point which is in dispute. Beyond that, operational reality is that
filtering DOES occur, and may occur somewhere neither you nor your
upstream ISP can control. To at least some extent it's useful to
understand present operational reality in choosing methodologies.

> 
> I have seen a long history of suggested solutions to security
> problems which are only partially effective against current forms of
> attacks, vs. providing protection against a larger class of attacks.
> I'm trying to suggest that we not follow this pattern.

Please suggest another course of action. To date, the IETF has spent a
considerable amount of its security mindshare on IPSec. While developing
that functionality, operational reality resulted in the deployment of
huge numbers of NAT boxes, and IPSec and NAT aren't interoperable.
Another case of operational reality and design colliding.

Ingress filtering does not provide a complete solution. Neither did the
patches to operating systems to guard against SYN flooding. By using
both of those, we limit the effectiveness of those types of attacks. I
expect we will have to add a whole suite of techniques to bring the
problems under some reasonable level of control. What is unclear is why
some think we could or should do nothing in the short term.



-- 
-
Daniel Senie[EMAIL PROTECTED]
Amaranth Networks Inc.http://www.amaranthnetworks.com

Re: Question re: an Internet-Draft and testing/deployment

[Marc Blanchet]

At 10:49 2000-02-16 -0500, [EMAIL PROTECTED] wrote:
>Noticed this one this morning:
>
>--- start excerpt
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
> Title   : Compatible Internationalized Domain Names Using
>   Compression
> Author(s)   : P. Hoffman
> Filename: draft-hoffman-idn-cidnuc-02.txt
> Pages   : 12
> Date: 15-Feb-00
>
>This protocol describes a transformation method for representing non-
>ASCII characters in domain names in a fashion that is completely
>compatible with the current DNS. It meets the many requirements for
>internationalization of domain names.
>
>Note: this protocol is quite experimental and should not be deployed in
>the Internet until it reaches standards track in the IETF.
>--- end excerpt
>
>Regarding the Note: - is there any coherent plan regarding testing/deployement
>in regards to moving this from Experimental to Standards Track?

- this is an individual submission, not a idn wg draft
- this is interesting work that is currently discussed in idn wg mailing 
list, while the current charter do not cover new protocols. the wg charter 
is currently on requirements and documenting current implementations.
- while there is a wide interest and rough concensus (my own opinion) that 
an idn solution has to be engineered and deployed, it is premature at this 
stage to identify which proposal(s) is going to be on standards 
track.  And, unless the IESG would accept that individual submission and 
put it on standard track, the proposal who will go on standard track should 
be discussed in a wg (my own opinion), since the impact of deploying idn 
will be important. The idn wg is probably today the only one in the IETF 
related to that topic.
- I would suggest you to join our wg mailing list:  [EMAIL PROTECTED]

Marc, co-chair of idn wg.




>--
> Valdis Kletnieks
> Operating Systems Analyst
> Virginia Tech

Re: Question re: an Internet-Draft and testing/deployment

[Bill Manning]

% --- start excerpt
% A New Internet-Draft is available from the on-line Internet-Drafts directories.
% 
% 
%   Title   : Compatible Internationalized Domain Names Using 
%   Compression
%   Author(s)   : P. Hoffman
%   Filename: draft-hoffman-idn-cidnuc-02.txt
%   Pages   : 12
%   Date: 15-Feb-00
%   
% This protocol describes a transformation method for representing non-
% ASCII characters in domain names in a fashion that is completely
% compatible with the current DNS. It meets the many requirements for
% internationalization of domain names.
% 
% Note: this protocol is quite experimental and should not be deployed in
% the Internet until it reaches standards track in the IETF.
% --- end excerpt
% 
% Regarding the Note: - is there any coherent plan regarding testing/deployement
% in regards to moving this from Experimental to Standards Track?
% 
% -- 
%   Valdis Kletnieks
%   Operating Systems Analyst
%   Virginia Tech

I hope not, This will be the first IETF where this WG meets. This is -one-
of several methods being discussed. We haven't even reached closure on
the appropriate scope. This draft is an attempt to walk one vector of 
the problem space. 

-- 
--bill

RE: IETF Adelaide and interim meetings for APPS WGs

[Stewart Nolan]

> -Original Message-
> From: John Stracke [mailto:[EMAIL PROTECTED]]

> Probably worse than nothing, unless there are much better 
> translators than babelfish out there.  WG discussions get
> down to really niggly points; a translator that doesn't
> work *perfectly* is likely to make things worse.  At
> least today, if we're talking through a language barrier, 
> there's a human brain doing the translation, able to
> recognize problems and rephrase as needed.

Via babelfish.altavista.com, and translated from English to German and back

Probably falsely than nothing, it is it many better compilers/translators
than babelfish gives out there. WG discussions down on really arrive niggly
points; a compiler/translator, that does not operate * perfectly * is
probable to form things falsely. At least today, if we speak by a language
barrier, a human brain give it, which does the translation, able, to detect
and again-formulate problems, how uses.  

And English/French/English:-

Probably worse than anything, unless there are translators much better than
the babelfish outside there. The discussions of WP descend really niggly at
the points; a translator who does not function * perfectly * is likely to
make things worse. At least today, if we speak by a linguistic barrier,
there let us be a human making translation, able brain identify problems and
reformulate them like necessary.

You can see the decay in the clarity of the original message. 
If I had received something similar purporting to be from an IETF member in
a country that I didn't speak the language of, I would assume someone had
reinitialized Mark V. Chaney.

cheers,
Stewart

RE: Internet SYN Flooding, spoofing attacks

[Stephen Kent]

Eliot,

Some of the DoS attacks we saw last week were good, old-fashioned SYN 
floods.  Hosts do have a responsibility here, more than ISPs, since 
it is quite feasible to tie up a host's pool of TCBs with a small 
number of packets, even if the attack tool does not use spoofed 
sourced addresses (or if the spoofed addresses are from a legitimate 
pool allocated to a subscriber site).

The point I have tried to make, unsuccessfully, is not that 
performing ingress filtering is bad, and thus should not be 
performed.  Rather, I am pointing out that it is a bad idea to rely 
on such filtering as a primary means of defense. There are several 
reasons for saying this:
- not all ISPs will find it feasible to provide such filtering
- not all ISPs are trusted to do the filtering (in the global Internet)
- a number of DDoS attacks can be launched without using 
spoofed addresses outside of those "appropriate" to the subscriber 
site
- some applications may legitimately make use of non-local 
addresses, as others have suggested

I have seen a long history of suggested solutions to security 
problems which are only partially effective against current forms of 
attacks, vs. providing protection against a larger class of attacks. 
I'm trying to suggest that we not follow this pattern.

Finally, there is a diminishing difference between what a script 
kiddie can do, vs. a clever attacker, because the clever attackers 
are freely distributing higher quality attack tools.  "Empowerment" 
is a hallmark of modern Internet attacks :-).

Steve

Re: IETF Adelaide and interim meetings for APPS WGs

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Jon Crowcroft writes:

> note also, that provided the IETF doesnt start mimicing ITU in
> choosing
> meeting location, a lot of places outside the US offset travel costs
> by cheaper accomodation costs.significantly in some cases
> (i admit london england is not a good example for this, though it is
> pretty cheap to get to from just about anywhere on average:-)

And you may find that quirks in airfares can offset the distance factor.  
Given airline load factors, I don't seem to be able to qualify for discounts 
on my trips to San Francisco from New Jersey -- which means that my tickets to 
Adelaide are only very slightly more expensive.

--Steve Bellovin

Question re: an Internet-Draft and testing/deployment

[Valdis . Kletnieks]

Noticed this one this morning:

--- start excerpt
A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Compatible Internationalized Domain Names Using 
  Compression
Author(s)   : P. Hoffman
Filename: draft-hoffman-idn-cidnuc-02.txt
Pages   : 12
Date: 15-Feb-00

This protocol describes a transformation method for representing non-
ASCII characters in domain names in a fashion that is completely
compatible with the current DNS. It meets the many requirements for
internationalization of domain names.

Note: this protocol is quite experimental and should not be deployed in
the Internet until it reaches standards track in the IETF.
--- end excerpt

Regarding the Note: - is there any coherent plan regarding testing/deployement
in regards to moving this from Experimental to Standards Track?

-- 
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech

Re: IETF Adelaide and interim meetings for APPS WGs

[Brian E Carpenter]

It is not the case that few WGs are holding meetings. The published agenda
just isn't complete yet; it never is at this stage.

  Brian

Graham Klyne wrote:
> 
> At 01:30 PM 2/15/00 -0500, Jeffrey Altman wrote:
> >The problem I have with the Adelaide meeting is very simple.  With so
> >few working groups holding sessions, I can't justify making the trip.
> 
> I'd like to offer a personal observation.  Yes, the working group sessions
> are useful but, for me, the most valuable stuff happens between the sessions.
> 
> #g
> 
> 
> Graham Klyne
> ([EMAIL PROTECTED])

Re: Need HELP for SNMP

[Valdis . Kletnieks]

On Wed, 16 Feb 2000 18:41:53 +0530, Sriram Shanmugam <[EMAIL PROTECTED]>  said:
>   I would like to a develop the code do discover all the SNMP Agents
> present on the Network , how do i go abt it?.

Step 1: Send a ping to the subnet's broadcast address.

Step 2: For each machine that answers, contact its port 161, and see if
you get 'port unreachable'.

Step 3: For each machine that did ping, but doesn't say 'port unreachable',
try talking SNMP to the port.

Step 4: Make sure you've talked to the network/security administrator BEFORE
you do this, so you are not lynched by the admins of machines that have
tripwired port 161 to detect portscans

In other words, be *VERY* sure that you have management backing before trying
it.  Failing to ask first can be quite a Career Limiting Move

-- 
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech

Re: IETF Adelaide and interim meetings for APPS WGs

[John Stracke]

Austin Schutz wrote:

> It wouuld be possible to have all the mailing lists redistributed
> using some babelfish-like mechanism for translation, though obviously that
> wouldn't cover all languages and wouldn't do any well. Maybe better than
> nothing.

Probably worse than nothing, unless there are much better translators than
babelfish out there.  WG discussions get down to really niggly points; a
translator that doesn't work *perfectly* is likely to make things worse.  At
least today, if we're talking through a language barrier, there's a human
brain doing the translation, able to recognize problems and rephrase as
needed.

--
/==\
|John Stracke| http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=|
|eCal Corp.  |Never mind the GUIs--Unix won't be for the   |
|[EMAIL PROTECTED]|masses until we fix backspace & delete.  |
\==/

Re: IETF Adelaide and interim meetings for APPS WGs

[Jon Crowcroft]

to people that think that the internet is mostly US centric, and will
go on being so, and that this is relevant to the IETF anyhow -
wrong, wrong, and also wrong!

um the Internet is now mostly commercial - the Eu and Asia each have MORE
money than the US, and also have growth economies. if you work for a
vendor (s/w, h/w, services) and can't find a reason to visit, then yo
uare missing an opportunity to "enhance shareholder value" - as a
shareholder, i would be shocked and dismayedand think hard about
other vendors...

as an academic/researcher, too, generally, i can easly find good reasons to 
visit people with other viewpoints, and requirements and inventions...
 

note that microsoft and cisco (examples - there are lots more)
 both set up strong european presences
recently for these reasons. They also have strong asia/pacific
presence - 

using current IETF national representation as a marker for where to
hold meetings is going to lag, rather than lead the right thing to do
imho

note also, that provided the IETF doesnt start mimicing ITU in
choosing
meeting location, a lot of places outside the US offset travel costs
by cheaper accomodation costs.significantly in some cases
(i admit london england is not a good example for this, though it is
pretty cheap to get to from just about anywhere on average:-)


 cheers

   jon

Need HELP for SNMP

[Sriram Shanmugam]

Hai Everybody,

I am working on SNMP , i would like to know how to start the coding
for SNMP , is there any web site from where i can get an introductory
material (Code) , or any books which deal with coding ? . I have read many
books but most or in fact all of them deal with the theoretical part alone.

I would like to a develop the code do discover all the SNMP Agents
present on the Network , how do i go abt it?.

Eagerly waiting for the reply

S.Sriram

Re: IETF Adelaide and interim meetings for APPS WGs

[Graham Klyne]

At 01:30 PM 2/15/00 -0500, Jeffrey Altman wrote:
>The problem I have with the Adelaide meeting is very simple.  With so
>few working groups holding sessions, I can't justify making the trip.

I'd like to offer a personal observation.  Yes, the working group sessions 
are useful but, for me, the most valuable stuff happens between the sessions.

#g


Graham Klyne
([EMAIL PROTECTED])

Re: IETF Adelaide and interim meetings for APPS WGs

[Fred Baker]

At 12:20 PM 2/15/00 -0600, Mart Nurmet wrote:
>Keith:
>
>How do I go about geting the schedule for the meetings for the rest of the
>year?

If you go to the IETF web site, click on "Meetings", and click on "list of
future meetings", you will find a pointer the file
http://www.ietf.org/meetings/0mtg-sites.txt

RE: IETF Adelaide and interim meetings for APPS WGs

[Fred Baker]

At 09:44 PM 2/15/00 -0800, Ian King wrote:
>To those of you outside the US who don't think there are enough meetings
>outside the US: IF YOU SPONSOR THEM, WE WILL COME.  I've seen the open,
>standing invitations to sponsor meetings -- so step up and sponsor.  

for the record, we have quite a few potential sponsors outside the US. We
are considering future meetings in London and Tokyo, and have been offered
sites in Geneva, Naples, Beijing, and other places. What tends to be
interesting to find is the US sponsors, not the non-US ones.

>Bottom line: go if you can and wish to, don't whine if you can't or won't.
>And please quit with the "conspiracy theories" about US-centricity.

Agreed. It is readily argued that there is strong US involvement. Going
from there to some of the places this thread has taken it is quite a leap.

Re: IETF Adelaide and interim meetings for APPS WGs

[Valdis . Kletnieks]

On Wed, 16 Feb 2000 08:38:49 +0900, Masataka Ohta said:
> So, all the future IETF meetings should be held in areas far away
> from US and, in addition, where English is not the major language.

"My hovercraft is full of eels" -- J. Cleese

Re: IETF Adelaide and interim meetings for APPS WGs

[Hans Petter Holen]

- Original Message -
From: "Vernon Schryver" <[EMAIL PROTECTED]>
> In other words and politically correct pretense asside, the IETF is not
> an international organization.  Despite its posturing, the IETF is a U.S.
> or perhaps North American organization that welcomes non-U.S. participants
> and occasionally spends a lot of its U.S. participants' time and money to
> try to make people outside of North America feel welcome.  If the IETF
> did honestly aspire to be an international organization, it would need
> the characteristics of the ITU (e.g. translators and high prices for
> documents).  Do you think that would be a good thing?

Now if this were to be the case, we should definitely set up an
European Internet Engineering Task Force and so on.

In such a scenario, maybe different parts of the world would even
choose different working languages.

This would definitely be a win towards reducing US centricness.

But would it be a win to the Internet ?

-hph