Re: Bottom feeders

[John Beck]

Keith> I honestly don't know how many of the 'lurkers' in any particular room
Keith> are actively participating in some WG versus how many are lurking in
Keith> all of them. but I do know that a large number of lurkers is harmful
Keith> to a WG's ability to conduct a useful meeting.

How so?  If they're just lurking, the only harm I could see is taking up
space in the room.  I started out more or less lurking, mainly just to make
sure people didn't try to do something stupid in my areas of interest.  But
gradually over time I found I was able to participate at a more meaningful
level.  So lurking can be a Good Thing, from a certain point of view.

-- John

RE: IETF logistics

[Paul Hoffman / IMC]

Just to be clear, Pete's idea does not preclude giving newcomers to 
the meeting context. Instead of the 5 minutes for agenda bashing and 
then straight into presentations, the WG chair can spend 15 minutes 
saying what the group is doing, where the WG is and is not meeting 
its charter, and the status of the drafts in front of the group. At 
that point, viewers (as compared to participants) will know better 
whether or not they want to stay and will also have some idea of why 
the agenda looks like it does.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: Bottom feeders

[Keith Moore]

let me say that I'm fully in agreement with those who think that our WGs
need broad input, and who want to encourage more cross-group fertilization.  
I just don't happen to believe that merely paying the meeting fees 
entitles one to a seat in the room.  

I honestly don't know how many of the 'lurkers' in any particular
room are actively participating in some WG versus how many are lurking
in all of them.  but I do know that a large number of lurkers is
harmful to a WG's ability to conduct a useful meeting.

Keith

Re: IETF logistics

[Keith Moore]

> Chairs serve at the discretion of the AD's.

good chairs can be *extremely* difficult to find.  especially if you
want someone to replace an existing chair and inherit a group which
is off in the weeds due to a previous lack of leadership.

Keith

Re: IETF logistics

[Keith Moore]

> It did indeed seem that the significant majority of
> time was spent 'viewing presentations/tutorials',
> while the WG chairs frequently employed RED/discard
> on the folks that occupied the queues at the
> microphones in order to more promptly begin the
> next tutorial and finish within the alloted time.

for many groups, the number of active participants is so small
that there's really no need for a microphone ... except that
due to the large number of passive observers they have to meet in 
a room which is so large and so noisy that amplification becomes
necessary.  and the medium access time for a microphone queue 
is sufficiently large that having a microphone drastically 
reduces available bandwidth at a meeting.

Keith

Re: 49th-IETF conf room planning

[Keith Moore]

Said another way, I do not believe that
the increased number of people has harmed the S/N ratio in any
of my WGs, nor any that I attended. The people who participate
participate and the people who don't don't. I don't have
a problem with that.

It seems like there is some sort of psychological effect of large rooms
and/or large numbers of people - people seem less likely to speak their 
minds in a room full of mostly passive observers, than when in a room 
full of people who are mostly participating in the discussion.

If this is true then having large numbers of passive observers at a 
meeting does indeed lower the S/N, by reducing the signal level.

Finally, adopting draconian measures that make the IETF some
kind of secret/privileged society will mark the beginning of
the end of the its usefulness. I would hate to see that
happen.

I think we have two choices: we can either try to discourage lurkers
who don't do their homework, or we can increase the current tendency 
for decisions to be made by (often closed) design teams for later rubber 
stamping by the WG.  The latter seems much more like a secret/privileged
society than the former.

Keith

Re: 49th-IETF conf room planning

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, RJ Atkinson writ
es:
>Someone else noted:
>>Participation by mail before participation in person.
>
>EXAMPLE
>
>I was an active participant (e.g. ask folks in Denmark
>who were involved with early MIME stuff) via email long
>before I showed up in person.  To this day, I don't make
>every meeting.  Before ever showing up in person, I was able
>to make major impacts on MIME's support for multi-lingual
>environments.
>
>I've seen others do similarly.  For example, I've
>never run into Valdis at an IETF meeting, but he has an
>impact.
>
>ASSERTION
>So one need not attend to have an impact.

Indeed.  I was in the same situation -- for family reasons, I couldn't 
travel, but I was an active participant in a number of mailing lists 
and working groups.  I was asked to be on the IPng directorate before 
I'd attended a single IETF meeting -- and that was based on my 
publications on security, and my electronic participation.

--Steve Bellovin

RE: IETF logistics

[Ian King]

IMHO that's an excellent suggestion.  It's been my experience that when you
state that the draft is itself an agenda item, previously resolved issues
often get rehashed, sometimes contrary to the clear consensus of the list.
This strategy would also allow less opportunity for those who haven't read
the draft to turn the session into a tutorial.  -- Ian 

-Original Message-
From: Randy Bush [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 19, 2000 9:26 AM
To: Scott Brim
Cc: ietf
Subject: Re: IETF logistics


> I would suggest that chairs try setting the agenda around issues, not
> around drafts themselves.  The main point of the face-to-face meetings
> is to resolve issues that cannot be resolved by mail.  Put those on the
> agenda, and let the combatants present as much tutorial information as
> they feel is necessary to make their point -- but don't set up the
> editor of a particular draft to give a presentation first, followed by
> discussion.  Don't even put the draft title on the agenda, just in the
> preliminary mail sent out before the meeting.  Thoughts?

sounds good to me!

randy

Re: IETF logistics

[Matt Holdrege]

At 05:10 PM 12/19/2000, Scott Bradner wrote:
> > Nothing personal Frank, but in a general sense I'd say you weren't doing
> > your job well enough.
>
>easy to say if you have not been and AD
>Frank was a good AD and managed WGs as well as any of us (and better than 
>many)
>yet getting people out of presentation mode is hard and takes previewing
>the actual presentations - not something that an AD can do (nor should
>an AD be THAT involved) - Alliosn & I sent mail to teh TSV WG chairs
>before the SD IETF meeting reminding the chairs that technology
>presentations were notthe best use of session time and yet many
>of the TSV WGs still had that type of presentations (including
>the tsvwg which we chair)

Yes, Frank was a very good AD and as I said, nothing personal. But as AD's 
you all have the power to shape the meeting and choose or replace chairs. 
And as I've said in other forums, AD's have way too much to handle these 
days and the IETF is suffering a bit because of that.

Something said in the SEAMOBY meeting was especially disturbing. The chair 
said that "it wasn't fair to the presenters" to cut them off. This came 
after the room gave resounding applause to cutting them off. Why do we have 
to be fair to the presenters? Why can't we be fair to the WG as a whole? 
I'll note a disclaimer that SEAMOBY was scheduled and formed as a WG very 
late in the game and the chairs perhaps didn't have enough time to organize 
better. But the same complaint could be made at many other WG meetings.

-Matt(cc'ing the IESG since this is directed primarily to them)

Re: IETF logistics

[John C Klensin]

--On Tuesday, December 19, 2000 3:49 PM -0700 Danny McPherson
<[EMAIL PROTECTED]> wrote:

> It did indeed seem that the significant majority of 
> time was spent 'viewing presentations/tutorials', 
> while the WG chairs frequently employed RED/discard 
> on the folks that occupied the queues at the 
> microphones in order to more promptly begin the 
> next tutorial and finish within the alloted time.
> 
> This is unfortunate, as the main idea behind meeting 
> is to hash out design issues, not to get overly 
> verbose presentations that typically aren't required
> by those that read the drafts.

Just some personal thoughts...

FWIW, I suggested to a couple of WG/BOF chairs last week that,
if they _must_ have presentations (and I really like Pete
Resnick's idea), they consider insisting on

(i) Getting the materials in advance

(ii) Consolidating all of the presentations onto a single
machine, to be controlled by the Chair.

(iii) Warning presenters that the presentations will be
appropriately "accelerated" if they contain too much
marketing hype, drift off-topic, or go wandering into the
weeds.  

I would also favor equipping Chairs with long poles with hooks
at the end for dragging performers offstage, or at least on/oiff
switches for microphones :-)

I think we have several different problems that are reinforcing
each other, but we can probably attack at least some of them
even if we don't have comprehensive solutions.

   john

Re: IETF logistics

[Scott Bradner]

> Nothing personal Frank, but in a general sense I'd say you weren't doing
> your job well enough. 

easy to say if you have not been and AD
Frank was a good AD and managed WGs as well as any of us (and better than many)
yet getting people out of presentation mode is hard and takes previewing
the actual presentations - not something that an AD can do (nor should
an AD be THAT involved) - Alliosn & I sent mail to teh TSV WG chairs
before the SD IETF meeting reminding the chairs that technology 
presentations were notthe best use of session time and yet many
of the TSV WGs still had that type of presentations (including
the tsvwg which we chair)

Scott

Re: WLAN

[Fred Baker]

At 11:03 AM 12/19/00 +0200, Teemu Rinta-aho wrote:
>Thank you. That was nice service from Qualcomm, just too
>bad there was no information of the wireless coverage
>on the meeting web pages.

for the record, apart from Qualcomm's HDR service, the Wireless was Cisco 
Aironet.

Re: IETF logistics

[Randy Bush]

> How about a first step: In WG sessions that I chair, there are going 
> to be no more presentations. From now on, one week before the IETF 
> meeting, document editors will be required to send me a list of 
> outstanding issues they wish to discuss in the WG session for their 
> particular drafts. I will make up the slides for all of the editors 
> with the lists that they propose and their discussion during the WG 
> meeting will be limited to those lists (with some wiggle room for 
> last minute additions by the WG). These lists can be posted to the WG 
> mailing list before the meeting so that if others need explanation, 
> they can ask (either on the list or directly to the document editor) 
> what those issues entail.

one half of dnsext will join you

randy

RE: 49th-IETF conf room planning

[RJ Atkinson]

Someone else noted:
>Participation by mail before participation in person.

EXAMPLE

I was an active participant (e.g. ask folks in Denmark
who were involved with early MIME stuff) via email long
before I showed up in person.  To this day, I don't make
every meeting.  Before ever showing up in person, I was able
to make major impacts on MIME's support for multi-lingual
environments.

I've seen others do similarly.  For example, I've
never run into Valdis at an IETF meeting, but he has an
impact.

ASSERTION
So one need not attend to have an impact.

Ran

Re: IETF logistics

[Danny McPherson]

It did indeed seem that the significant majority of 
time was spent 'viewing presentations/tutorials', 
while the WG chairs frequently employed RED/discard 
on the folks that occupied the queues at the 
microphones in order to more promptly begin the 
next tutorial and finish within the alloted time.

This is unfortunate, as the main idea behind meeting 
is to hash out design issues, not to get overly 
verbose presentations that typically aren't required
by those that read the drafts.

-danny

>   Some compare/contrast about then and now, followed by
> some (perhaps radical) thoughts to ponder.  I'm NOT interested
> in quibbles about the timeframe for THEN or minor differences
> in perception about either THEN or NOW, so I'll ignore any
> troll-like responses.  This is intended as a very high-level
> set of comments -- high-level necessarily implies a certain
> lack of crispness.

Re: IETF logistics

[hardie]

I respect both Pete and Paul's position here, but I believe this
frustration is endemic to our efforts rather than specific to how the
working group meeting agendas are set.  I also believe that the
frustration is worth the result.

One of the things which sets the IETF apart from other efforts to
produce standards is the breadth of perspective it brings to the
problems which it chooses to tackle.  Where it is fairly easy to get a
group of like-minded people together to tackle a specific network
problem, it is much harder to get a group of people together who can
see how the proposed solution will impact the other parts of the
network.  From my perspective, one of the chief values of the IETF
face-to-face meetings is the opportunity they present to have folks
from different parts of the Internet engineering community provide
input into the solutions which have been proposed by the communities
of interest which the working groups represent.  Sometimes that
results in those communities of interest growing, as individuals
recognize their need to participate.  Sometimes a new perspective
cogently expressed at a face to face meeting is all it takes to move a
working group in a new direction.

In either case, without the participation of the larger IETF community
in the working group meetings, those perspectives do not get expressed
to the working group at early stages of the process.  That means much
more work for the IESG in managing the inter-area issues when drafts
are ready to move forward.  It can also mean delay as things which
might have been caught early have to be unraveled after other elements
of the design depend on them.

Whether the agenda of a working group takes the shape of draft
presentations or issue lists, I believe it is important for working
groups to be open to new voices during the IETF meetings, for they
don't have that many other opportunities to hear them.  This certainly
engenders frustration when the new voices rehash old problems, and it
requires skill on the part of the presenters and chair to keep the
resurgence of old problems from eating all the time.  It also competes
with the use of the meetings to handle pressing technical issues which
benefit from focused face-to-face work.  Balancing those competing
interests, again, requires work and skill on the part of the chair.
As thankless and unsung as that work often is, it is worth it.  We may
not get perfect standards from the process, but we do get engineering
solutions which do a pretty good job of balancing the needs of the
different parts of the network infrastructure.

I believe we can all agree that we need better ways of scaling the
input to IETF working groups.  I hope we can also agree that we need
them because we need to retain the skills and perspective of our
participants, not simply because some group sizes are unwieldy or some
meeting resources constrained.

regards,
Ted Hardie



> 
> At 11:20 AM -0600 12/19/00, Pete Resnick wrote:
> >How about it? Other chairs wish to join me in this mission?
> 
> Yup. As someone who chaired a meeting where we had three 
> presentations on three drafts that had already been on the list, and 
> the discussion was all around topics that could have been brought to 
> the list, I share your frustration.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 

Re: IETF logistics

[Matt Holdrege]

At 08:07 AM 12/19/2000, Frank Kastenholz wrote:
>At 09:28 AM 12/19/00 -0500, RJ Atkinson wrote:
> >We can also end the de facto practice of
> >using the sessions as tutorials and discontinue fancy prepared
> >presentations of the material already in the I-Ds.  While
> >tutorials are a fine thing, they are appropriate for USENIX
> >or Interop, not IETF WG sessions, IMHO.
>
>I tried doing this in my area when I was on the IESG.
>It didn't work. The chairs and attendees want this stuff.

Nothing personal Frank, but in a general sense I'd say you weren't doing 
your job well enough. Chairs serve at the discretion of the AD's. The AD's 
need to choose their chairs wisely and if the chairs feel that they need to 
have tutorials, then the chairs need better guidance or need replacement. 
And one of the points to this thread is that we shouldn't care what the 
attendees want as the IETF is not a tutorial conference. It's a working 
conference and only the people who are working on the drafts should be 
catered to. Others can certainly hang around and learn, but they shouldn't 
be catered to.

As a chair myself I've occasionally fallen into this trap of thinking the 
"audience" needs to be "presented" with the material. But I'm usually 
quickly reminded that we are not there for tutorials. I think the best use 
of a viewgraph is to display a list of to-do items to the group. If the 
people in the room do not understand the overall architecture, they need to 
read the drafts more or find out elsewhere.

Re: IETF logistics

[Danny McPherson]

It did indeed seem that the significant majority of 
time was spent 'viewing presentations/tutorials', 
while the WG chairs frequently employed RED/discard 
on the folks that occupied the queues at the 
microphones in order to more promptly begin the 
next tutorial and finish within the alloted time.

This is unfortunate, as the main idea behind meeting 
is to hash out design issues, not to get overly 
verbose presentations that typically aren't required
by those that read the drafts.

-danny

>   Some compare/contrast about then and now, followed by
> some (perhaps radical) thoughts to ponder.  I'm NOT interested
> in quibbles about the timeframe for THEN or minor differences
> in perception about either THEN or NOW, so I'll ignore any
> troll-like responses.  This is intended as a very high-level
> set of comments -- high-level necessarily implies a certain
> lack of crispness.
> 
> THEN:
>   - Presentations at IETF normally did NOT rehash 
> material available in the I-Ds in tutorial style.
>   - Viewgraphs were hand-scribbled the night before,
>   often after some lobby bof before the meeting.
>   - More people read the I-Ds before the meeting, though there
> was griping about inadequate preparation then also.
>   - Working Group sessions actually did work, designing
> in real-time, discussing technical issues in real-time,
> resolving open technical issues in a higher bandwidth
> environment.
>   - Interim WG meetings were rare.
>   - Folks who had read the drafts could generally get into
> and participate in meetings of interest.
> 
> NOW:
>   - Presentations mostly do rehash material in the I-Ds
>   - Viewgraphs with fancy cartoon graphics, company logos,
> that required lots of time to create the week before
> the meeting are shown.
>   - Few people (as a percentage of WG attendees) have actually
> read the I-Ds beforehand, relying instead on thepresentations.
>   - Working Group sessions are mostly educational overviews,
> without significant real-time discussion or resolution
> of technical issues.
>   - Interim WG meetings are much more frequent, in part 
> because only people deeply interested in the topic
> bother to travel for such meetings.
>   - Folks who have read the drafts often cannot get into
> the meetings they have prepared for.  I had abysmal luck
> at actually attending sessions where I had read the drafts
> and am actually involved in implementation or use of
> a specification.
> 
>   In the short term, IETF have signed contracts for
> 3 meetings per year.  We don't want to break any existing
> contracts.  What we can do for future IETFs is make the current
> sporadic practice of reserving the front few rows of seats for
> folks who have actually read the drafts and are involved in
> implementation.  We can also end the de facto practice of 
> using the sessions as tutorials and discontinue fancy prepared
> presentations of the material already in the I-Ds.  While 
> tutorials are a fine thing, they are appropriate for USENIX
> or Interop, not IETF WG sessions, IMHO.
> 
>   However, I'd like to propose that we experiment 
> with only having 2 all-area IETF meetings per year when we
> can do so without breaking any contracts.
> 
>   Further, I'd suggest that each area would have the
> option (discretion of the relevant ADs) of having a single 
> Area Meeting someplace.  This would last only perhaps 2 days.
> It could be held at a rather larger number of venues
> (due to smaller attendance) -- a college/university or large
> corporate location might well be a very good choice for such
> a meeting.  In addition, WGs ought to be encouraged to hold
> at least one WG interim meeting per year, to provide a vehicle
> for meaty discussion of technical issues by folks who are 
> current in the WG, involved in implementation or deployment
> of that WG's material, and so forth.  
> 
> Sincerely,
> 
> Ran
> [EMAIL PROTECTED]
> 

Re: IETF logistics

[Kurt D. Zeilenga]

At 03:15 PM 12/19/00 -0600, Timothy J. Salo wrote:
>What happened to the proven and time-honored technique of getting
>to a meeting early if you want a seat?

Don't you mean a seat AND electrical power?  :-)

BTW, much thanks to Steve and his crew for providing a generous
amount of electrical power outlets.

As far as finding a seat for someone who has read all the
materials for the session, that's what the front two rows
are for.  These rows should be open to others only after
those who have read everything have had a chance to sit
down.  Note that the chance comes prior to start time
of the meeting.

Kurt

Bottom feeders

[Bob Braden]

  *> 
  *> why don't we reserve all *except* the last three rows for those
  *> who have read the drafts, leaving the last three rows for bottom
  *> feeders?
  *> 
  *> Keith
  *> 
  *> 

Keith,

The problem is that sll who attend IETF meetings and care about the
Internet are "bottom feeders", at one time or other.  There is no way
that any of us can keep current with more than a few working groups.
However, a broad understanding of what is happening is vital if we are to
avoid severe fragmentation of the Internet technology.  Attending
at least related WG sessions in our area seems like a minimum
requirement to keep some general understadning of how things fit
together.  The ADs do a fantastic job of keeping some coherence,
but they need an informed membership too.

Bob Braden

Re: NATs *ARE* evil!

[John Stracke]

V Guruprasad wrote:

> > of virtual memory is that it makes it easier for the user (well,
> > programmer) by hiding the nasty details of which physical address your
>
> IMHO, hiding is not the primary function of virtual memory addressing,

On the contrary.  Hiding the details from the programmer means that the OS can
move data around without bothering the application; that's *precisely* the
point of VM.  Without that, you can't have swap space.

Similarly, DNS hides the details of IP addresses, so that servers can be moved
around without bothering the users.

> although it does spin off as a powerful means of security (Section 2.1.3
> - security by invisibility).

Otherwise known as "security through obscurity".

--
/===\
|John Stracke| http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==|
|eCal Corp.  |"Dinner Special: Turkey $2.35; Chicken or Beef|
|[EMAIL PROTECTED]|$2.25; Children $2.00."   |
\===/

Re: NATs *ARE* evil!

[V Guruprasad]

On Tue, 19 Dec 2000, Mike Fisk wrote:

> It's one thing to hand out addresses or names.  It's another thing to run
> a top-level routing server that all of your children customers have to
> route through to get to other top-level providers.  Your mapping between
> the two would imply that, for instance, all traffic between europe and
> japan would have to transit across a RIPE top server and a JPNIC top
> server?

Only in principle. No more than typing http://www.nokia.com from Finland
would route the lookup to the .com root server in Washington D.C. Also,
you're misreading it as "all traffic" - it should be "all connection
request traffic".


> Again, the hierarchical addressing is nothing new, but the fact that
> you're tying routing to the same hierarchy will have new side-effects on
> routing that need to be understood.

Spanning tree, faster but suboptimal logical path. You wouldn't want your
data to go that way.


> Right now, routing is orthogonal to addressing and DNS naming.  You're

The orthogonality comes from the translation. The translation goes sideways
from the name service spanning tree. Secondly, it does not need to know
the global network topology or addresses. You still need IGP (or equivalent)
to supply the translation rulebase, but no BGP, so to speak.


> removing addressing and tying routing to naming.  Now your name servers
> have to route packets and be aware of peering relationships.  That has

No. Their job is only to compile connection requests, distributed fashion,
into the data paths. Peering relations would be presumably compiled by
IGPs for them, but that's as much as they need to have to get the connections
going.


Btw, I'm still working on some aspects of translation optimisation and
failure recovery, which will be critical if and when we try to apply it
on the Internet scale, and which I expect will reach a conclusive level
within the next few months. On the other hand, these aspects are not
critical for deploying over the existing Internet, or even for "addressless"
cellular Internet connectivity, for example, since the latter will be
routed through transcoding gateways for the foreseeable future in any case.


thanks,
-p.

Ietf meeting in Italy?

[alessio porcacchia]

Dear Collegues and Friends,
When the Ietf must decide to prepare a meeting in Italy
I hope that see all of you "de visu" for talk to my "tech friends"
Ciao Alessio
Sys Adim 
Rome Italy

Re: 49th-IETF conf room planning

[David Meyer]

What I have observed is that the discussions in the face to
face WG meetings are very useful, and frequently result in
resolution (to be ratified by the WG's mailing list) of both
technical and procedural issues (if the meetings are not
useful for these purposes, why are we doing this in the first
place).  

In addition, the number of people present certainly poses a 
logistical problem (ie. the rooms/hallways were too small),
and in this way might have hurt WG progress (i.e., you
couldn't get in). However, as I noted, the damage is due to
logistical factors which are within our (IETF) control (i.e.,
get a bigger hotel). Said another way, I do not believe that
the increased number of people has harmed the S/N ratio in any
of my WGs, nor any that I attended. The people who participate
participate and the people who don't don't. I don't have
a problem with that.

Finally, adopting draconian measures that make the IETF some
kind of secret/privileged society will mark the beginning of
the end of the its usefulness. I would hate to see that
happen. 

Dave

[BTW, none of this addresses the value of what happens in
the hallways and bars]



According to Scott Brim:
> 
> On 19 Dec 2000 at 11:08 -0800, Matthew Goldman apparently wrote:
> > Speaking for myself, but I'm sure this applies to more than just me: I read
> > the relevant RFCs and drafts ("did my homework"), but I am not "active" by
> > the strict definitions some have used in this thread (at least not yet). I
> > pre-paid the meeting fee (in good faith that in return for accepting my
> > meeting fee, the IETF would provide meeting facilities commensurate to
> > enable my participation), I paid for travel and went. I followed all IETF
> > policies and procedures. Therefore, do I not have the "right" to be able to
> > sit comfortably in a meeting room and be able to hear the speakers, and
> > participate if I chose to, as much as anyone else?
> 
> Why did you go?  What did you get out of it that you didn't get out of
> the mailing list?  Results of in-person meetings are never final, and
> can be challenged by mail if you have good engineering reasons to do so.
> (I admit this is sometimes mostly theory, but you can appeal to the IESG
> if you think practice is deviating too much from theory.)
> 
> > If you strictly limit attendance to a meeting room based on previous
> > participation, you will have no new participation, or "cross fertilization"
> > of ideas (as someone stated).
> 
> Participation by mail before participation in person.
> 
> ...Scott
> 
> 

Re: Default free zone

[Valdis . Kletnieks]

On Tue, 19 Dec 2000 15:12:31 EST, Dave Robinson <[EMAIL PROTECTED]>  said:
>   Can anybody explain what the "default free" zone of the Internet is
> or provide some documentation on what it is? 

It's the parts of the Internet core where the topology is sufficiently
convoluted that a default route is a bad idea.  Out towards the edges
of the Internet, you can safely use a default route "this is going Out There,
so feed it to our upstream connectivity provider and let THEM route it".

When you don't have an upstream anymore (usually because you're a long-haul
provider whos business is being an upstream for others, or a site sufficiently
multi-homed that routing becomes interesting), you have to drop the default
route and actually deal with a routing table.

Valdis Kletnieks
Operating Systems Analyst
Virginia Tech

Re: NATs *ARE* evil!

[V Guruprasad]

On Tue, 19 Dec 2000, Mike Fisk wrote:

> explosion.  So over time there becomes an established club of roots and
> everybody else has to be a child.  That creates a monopolistic situation
> where you have to pay a root node for transit.  It could work, but it
> sounds worse than the existing DNS root mess.
>
> How do you preserve the decentralized resilience of the Internet with such
> a hierarchy?

We do have such a thing in the Internet today. It used to be DARPA, and now
it's IANA, and is still very much US-centric; we have regional bodies
spec'd out for IPv6 that will control not only names but also addresses.

In the proposed framework, you would only ask your immediate provider for
connectivity - (s)he doesn't have to coordinate nationally and internationally
to give you an address, and it's enough if your chosen name doesn't clash
with something already registered at the provider's name server. So I'd think
it's less of a mess than the DNS and IP are today in that regard.


> maintain a reasonable number (< 100k?) of peers.  For efficient table
> lookup, there would be a push to standardize on a length limitation.  So
> You've just created a situation where the root club will enforce
> sufficient hierarchy so as to limit the size of route tables.

Like //com/ibm/watson/affine/tmp/vinet.pdf?  Seems to be working ok for now.
What I'm wondering is why/whether the residual defects, which are common
to the DNS, should detract from the improvements/alternatives/differences
that you haven't commented on.



thanks,
-p.

Re: IETF logistics

[Paul Hoffman / VPNC]

At 11:20 AM -0600 12/19/00, Pete Resnick wrote:
>How about it? Other chairs wish to join me in this mission?

Yup. As someone who chaired a meeting where we had three 
presentations on three drafts that had already been on the list, and 
the discussion was all around topics that could have been brought to 
the list, I share your frustration.

--Paul Hoffman, Director
--VPN Consortium

Re: IETF logistics

[Timothy J. Salo]

> From: Keith Moore <[EMAIL PROTECTED]>
> cc: [EMAIL PROTECTED]
> Subject: Re: IETF logistics 
> Date: Tue, 19 Dec 2000 14:49:47 -0500
> 
> > What we can do for future IETFs is make the current
> > sporadic practice of reserving the front few rows of seats for
> > folks who have actually read the drafts and are involved in
> > implementation.
> 
> why don't we reserve all *except* the last three rows for those
> who have read the drafts, leaving the last three rows for bottom
> feeders?

What happened to the proven and time-honored technique of getting
to a meeting early if you want a seat?  I know the argument is that
we want to hang out in the hallways until the last minute and still
get a seat (because we are more "important" than a bunch of the people
that did get there early), but still...

-tjs

RE: 49th-IETF conf room planning

[Scott Brim]

On 19 Dec 2000 at 11:08 -0800, Matthew Goldman apparently wrote:
> Speaking for myself, but I'm sure this applies to more than just me: I read
> the relevant RFCs and drafts ("did my homework"), but I am not "active" by
> the strict definitions some have used in this thread (at least not yet). I
> pre-paid the meeting fee (in good faith that in return for accepting my
> meeting fee, the IETF would provide meeting facilities commensurate to
> enable my participation), I paid for travel and went. I followed all IETF
> policies and procedures. Therefore, do I not have the "right" to be able to
> sit comfortably in a meeting room and be able to hear the speakers, and
> participate if I chose to, as much as anyone else?

Why did you go?  What did you get out of it that you didn't get out of
the mailing list?  Results of in-person meetings are never final, and
can be challenged by mail if you have good engineering reasons to do so.
(I admit this is sometimes mostly theory, but you can appeal to the IESG
if you think practice is deviating too much from theory.)

> If you strictly limit attendance to a meeting room based on previous
> participation, you will have no new participation, or "cross fertilization"
> of ideas (as someone stated).

Participation by mail before participation in person.

...Scott

Re: NATs *ARE* evil!

[V Guruprasad]

On Tue, 19 Dec 2000, Jon Knight wrote:

> are on and what the address of their gateway router is.  Not exactly what
> I'd call omniscience.

All right, I confess, I'm not perfect in summarising the existing art and
relating to it (yet). I promise to gratefully acknowledge comments such as
these that will doubtless help make the next revision more readable :)


> Surely DNS addresses are more equivalent to the virtual memory

No, in the sense I was arguing about, the DNS hostname points to a physical
host (or interface, etc.), and is therefore a physical address.


> of virtual memory is that it makes it easier for the user (well,
> programmer) by hiding the nasty details of which physical address your

IMHO, hiding is not the primary function of virtual memory addressing,
although it does spin off as a powerful means of security (Section 2.1.3
- security by invisibility).


> code and data live at.  The whole point of the DNS is that it makes it
> easier for the user by hiding the nasty details of what IP address you
> need to talk to.  And that's without getting into the situations where a

That's high level programming language, not virtual addressing... This
point is particularly brought out in my proposal, as the routing is
literally accomplished as a (distributed) compilation (see attribute
grammar examples in Section 2.4.4, page 28).


> mention URNs at all and yet alot of what it seems to do appears similar to
> the ideas behind the URN efforts of the IETF in the past.

Similar sounding ideas, but no semantics match, really, since the
underlying premises are fundamentally different.


-p.

Default free zone

[Dave Robinson]

Can anybody explain what the "default free" zone of the Internet is
or provide some documentation on what it is? 

Thanks,
Dave

Re: IETF logistics

[Keith Moore]

> What we can do for future IETFs is make the current
> sporadic practice of reserving the front few rows of seats for
> folks who have actually read the drafts and are involved in
> implementation.

why don't we reserve all *except* the last three rows for those
who have read the drafts, leaving the last three rows for bottom
feeders?

Keith

Re: levels of end-to-end; lack thereof

[Keith Moore]

> Unfortunately, the production Internet (ie, since 1983) has never been
> fully end-to-end at the IP layer.  Never.

this depends largely on what you call "the Internet".  
 
> It's fine to create a clean architecture, but not very helpful to ignore or
> complain about market-driven extensions (or work-arounds, or...) to it.

so we should pretend that everything is rosy then?

(I can see it now...
"Doctor Strangenet, or How I Learned to Stop Worrying and Love the NAT")

> Folks -- people would not be making those extensions unless they
> experienced benefit in them.

understood.  there is no question that NATs provide some localized,
short-term benefit.  just like burning rainforests, or producing toxic waste.

> We claim to believe that the market is the ultimate venue for resolving
> choice among standards.  We need to acknowledge that that applies to
> missing standards, as well as competing standards.

The market may be the ultimate venue, but it isn't exactly blessed with 
foresight.  We most certainly need to acknowledge that when markets
develop "solutions" which damage the net, that it's often due to a lack
of facilities in what the net provides.  But that doesn't mean that we
should axiomatically accept "market-driven 'solutions'" as viable in
the long term.

Keith

Re: 49th-IETF conf room planning

[Keith Moore]

> Speaking for myself, but I'm sure this applies to more than just me: I read
> the relevant RFCs and drafts ("did my homework"), but I am not "active" by
> the strict definitions some have used in this thread (at least not yet). I
> pre-paid the meeting fee (in good faith that in return for accepting my
> meeting fee, the IETF would provide meeting facilities commensurate to
> enable my participation), I paid for travel and went. I followed all IETF
> policies and procedures. Therefore, do I not have the "right" to be able to
> sit comfortably in a meeting room and be able to hear the speakers, and
> participate if I chose to, as much as anyone else?

You did your homework, so I don't see why not.

What I was objecting to is the notion that merely paying the meeting
fees and travelling to the conference location entitles one to participate,
or even to attend.

> What happened in San Diego happened. Oops. What we are talking about is
> future meeting planning.

right.  and perhaps the planning for future meetings should consider how to 
discourage attendance for those who are not willing to come prepared.

> If you strictly limit attendance to a meeting room based on previous
> participation, you will have no new participation, or "cross fertilization"
> of ideas (as someone stated).

of course.  I agree that lack of "previous participation" is not a good 
reason to limit attendance.

> Plus, who defines the strict attendance laws? 

I think it will be difficult to *prevent* anyone from attending, but it 
might be possible to *discourage* attendance from bottom-feeders.
(or similarly, to encourage prospective attendees to do their homework)

> Will the IETF refuse to accept pre-paid applications
> based on these rules

I think it might be sufficient to warn applicants that they are expected
to be prepared for the meetings by reading the drafts, and that those who
do not demonstrate familiarity with the material may be asked to leave 
in order to make room for those who came prepared to get work done.

> Nothing other than fair, open access is practical. 

what you call "open access" is not "fair" to those who invest their time
and money attempting to accomplish useful work and find their efforts
thwarted due to those who think that merely paying money entitles them 
to a seat in the room.

Keith

Re: IETF logistics

[Pete Resnick]

On 12/19/00 at 12:04 PM -0500, Scott Brim wrote:

>I would suggest that chairs try setting the agenda around issues, not
>around drafts themselves.  The main point of the face-to-face meetings
>is to resolve issues that cannot be resolved by mail.  Put those on the
>agenda, and let the combatants present as much tutorial information as
>they feel is necessary to make their point -- but don't set up the
>editor of a particular draft to give a presentation first, followed by
>discussion.  Don't even put the draft title on the agenda, just in the
>preliminary mail sent out before the meeting.  Thoughts?

I think you have this backwards. The job of an IETF WG is not to 
resolve issues per se; it's to write Internet-Drafts. Now, I do agree 
that the editors should NOT be presenting the draft; that's silly. 
However, the issues that the face-to-face meetings should be dealing 
with are *only* those that pertain to a particular draft. If noone 
has written down at least a straw-man I-D, then I don't think it's 
worth discussing the issue at all.

So, have the editors cull out the open issues from their drafts, and 
put only those issues on the agenda. No tutorials at all should be 
needed if there is sufficient text in the I-D (or suggested 
replacement text posted to the mailing list) to define the issue.

pr

-- 
Pete Resnick 
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Re: IETF logistics

[Pete Resnick]

On 12/19/00 at 11:07 AM -0500, Frank Kastenholz wrote:

>At 09:28 AM 12/19/00 -0500, RJ Atkinson wrote:
>  >We can also end the de facto practice of
>  >using the sessions as tutorials and discontinue fancy prepared
>  >presentations of the material already in the I-Ds.  While
>  >tutorials are a fine thing, they are appropriate for USENIX
>  >or Interop, not IETF WG sessions, IMHO.
>
>I tried doing this in my area when I was on the IESG.
>It didn't work. The chairs and attendees want this stuff.

Maybe I'm the odd exception, but not only don't I want this stuff, I 
try to enforce this as best I can in the sessions I chair. In BOFs, 
there are bound to be some presentations, but in WG sessions, there 
is really very little reason for it.

How about a first step: In WG sessions that I chair, there are going 
to be no more presentations. From now on, one week before the IETF 
meeting, document editors will be required to send me a list of 
outstanding issues they wish to discuss in the WG session for their 
particular drafts. I will make up the slides for all of the editors 
with the lists that they propose and their discussion during the WG 
meeting will be limited to those lists (with some wiggle room for 
last minute additions by the WG). These lists can be posted to the WG 
mailing list before the meeting so that if others need explanation, 
they can ask (either on the list or directly to the document editor) 
what those issues entail.

How about it? Other chairs wish to join me in this mission?

pr

-- 
Pete Resnick 
Eudora Engineering - QUALCOMM Incorporated

Re: NATs *ARE* evil!

[Keith Moore]

> Steve Bellovin, on IPSEC, not-AH:
> 
> | [A] host's identity is represented by its certificate (I'm speaking a bit 
> | loosely here); its IP address is merely the way that packets reach it.  
> 
> This is an example of two separate namespaces that allow one
> to distinguish between "who" and "where".   That the network
> layer can be rewritten to the point of total protocol substitution
> without interfering with the identification of who sent it
> is a feature, adding enormous flexibility into the development
> of network features.

agreed, *provided* there is a fast and reliable service for mapping
between one kind of identity and another.  arguments of the form
"separate identities are better" tend to gloss over the difficulty
of providing an adequate mapping service.

(Hint: DNS is neither sufficiently fast nor sufficiently reliable)

the other problem with separating the layers is that the ability to
drill down through layers is essential for diagnostic purposes, 
for tracking down miscreants, and to allow prototyping new kinds 
of services that need to operate with knowledge of layer 3.  So 
we will always have a need for some kinds of "applications" to 
operate with knowledge of network addresses.   

Keith

RE: 49th-IETF conf room planning

[Matthew Goldman]

Ok, so the issue now is not about Vegas as an acceptable location, but
rather about which participants have the "right" and "priviledge" to attend
a meeting?

Speaking for myself, but I'm sure this applies to more than just me: I read
the relevant RFCs and drafts ("did my homework"), but I am not "active" by
the strict definitions some have used in this thread (at least not yet). I
pre-paid the meeting fee (in good faith that in return for accepting my
meeting fee, the IETF would provide meeting facilities commensurate to
enable my participation), I paid for travel and went. I followed all IETF
policies and procedures. Therefore, do I not have the "right" to be able to
sit comfortably in a meeting room and be able to hear the speakers, and
participate if I chose to, as much as anyone else?

What happened in San Diego happened. Oops. What we are talking about is
future meeting planning.

If you strictly limit attendance to a meeting room based on previous
participation, you will have no new participation, or "cross fertilization"
of ideas (as someone stated).

Plus, who defines the strict attendance laws? Who enforces them? Who checks
that this enforcement is fair and equal? I submit that this is impossible to
manage, particularly given the demographics of the attendees. Will new IETF
bylaws be created to define this special class (which of course will not
violate public laws)? Will the IETF refuse to accept pre-paid applications
based on these rules, or will they re-emburse delegates their meeting fee
and travel expenses, if delegates are "asked to leave" a meeting for no
other purpose other than because there is insufficient space provided? How
will the IETF handle possible lawsuits stemming from disenfranchised
delegates? The whole idea of even attempting to implement any of this is
simply ludicrous.

Nothing other than fair, open access is practical. Attendance numbers from
past meetings can easily be used to project future attendance levels and
plan accordingly. Attempting to setup "classes" or levels of participants
while collecting meeting fees in advance (in good faith that those paying
the fees will be able to attend the meetings), is foolhardy and fraught with
legal implications. 

My last many $$$ worth on this subject.
Matthew Goldman

> -Original Message-
> From: Keith Moore [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 18, 2000 8:55 PM
> To: Matthew Goldman
> Cc: 'Keith Moore'; 'Randall Gellens'; Daniel Senie; Michael 
> Richardson;
> [EMAIL PROTECTED]
> Subject: Re: 49th-IETF conf room planning 
> 
> 
> > It makes absolutely no sense to have someone pre-pay a 
> meeting fee, pay to
> > travel to a location, attempt to attend a meeting, and be 
> turned-away.
> 
> I disagree in the strongest possible terms.
> 
> it makes a great deal of sense if the purpose of the meeting 
> is to get 
> technical work done, rather than to spoonfeed people who 
> can't be bothered 
> to read the background material. and we're seeing entirely too much 
> spoonfeeding in meetings these days - witness the tremendous amount of
> precious meeting time that is devoted to presentations of *material
> already explained in the relevant drafts*, rather than discussion.
> 
> OTOH I happen to feel that it's quite useful if IETF folks who 
> actively participate in some WGs, drop in on the meetings of other
> WGs.  we need to encourage cross-pollenation between groups.
> 
> but we don't need to encourage non-participants to attend 
> IETF meetings.
> 
> > In addition, turning away people who wish to attend seems 
> counter to the
> > IETF spirit.
> 
> the IETF spirit has always been to include anyone *who does 
> his/her homework*
> 
> Keith
> 

Re: IETF logistics

[John Stracke]

Scott Brim wrote:

> On 19 Dec 2000 at 11:07 -0500, Frank Kastenholz apparently wrote:
> > I believe that the only choices are
> > - limit attendance to "the right people" or
> > - accept the tourists and panda-watchers and
> >   that the IETF meeting has evolved.
>
> The right people include "monitors" these days.

Perhaps.  But consider: there were 128 WG/BOF/area meetings (I think).  A
typical working group has a relatively small number of active participants
(let's say 10--more than that usually gets unwieldy).  So that's 1,280
active participants (fewer, since there's overlap) out of 2,768 attendees
in San Diego.  Were there 1400 monitors?

This is different from active participants in one group who sit in on
another group.  This is people who don't actively participate in any
group--and they appear to be in the majority.

And, no, I don't have a solution.  I'm not even positive it's a problem.
It's just that, if it is a problem, it's a bigger one than I previously
realized.

--
/===\
|John Stracke| http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==|
|eCal Corp.  |Whose cruel idea was it for the word "lisp" to|
|[EMAIL PROTECTED]|have an "S" in it?|
\===/

Re: Looking for Lyrics to the IETF Xmas song

[Theodore Y. Ts'o]

   Date: Tue, 19 Dec 2000 12:07:32 EST
   From: Jeffrey Altman <[EMAIL PROTECTED]>

   Sorry for the wasted bandwidth.  But could someone please post the
   lyrics to the IETF Christmas song, the video that was shown at the
   Plenary. 

Is the video itself available anywhere? 

- Ted

Re: NATs *ARE* evil!

[Theodore Y. Ts'o]

   Date: Tue, 19 Dec 2000 11:20:23 -0500
   From: V Guruprasad <[EMAIL PROTECTED]>

   On Tue, 19 Dec 2000, Keith Moore wrote:

   > mumble.  as far as I can tell, both DNS names and IP addresses
   > are hopelessly overloaded and are likely to stay that way until
   > we figure out how to make a major architectural change.

   Could you please take a look at
   draft-guruprasad-addressless-internet-00.txt

I just took a look at it, and it makes the following interesting
assumption: "Internet == Web ---> URL's are the only form of addresses
which matter".

It also seems to be espousing a form of address path which looks
remarkably similar to UUCP bang-path routing, using optimizations very
similar to which were encoded in a UUCP pathalias file.

Am I missing something or is that in essense your proposal?   

- Ted

Re: NATs *ARE* evil!

[Jon Knight]

On Tue, 19 Dec 2000, V Guruprasad wrote:
> Could you please take a look at
>   draft-guruprasad-addressless-internet-00.txt
> ?

I've just started to read it and in 1.1 it says:

  "- requiring e2e network knowledge (omniscience) at each node in the  
 form of e2e routing tables (Section 1.3);"

Erm, now I might be misunderstanding something here but our end nodes
(workstations, servers, PCs, etc) certainly don't have full e2e routing
knowledge.  They know what their address(es) is/are, what network(s) they
are on and what the address of their gateway router is.  Not exactly what
I'd call omniscience.

Also I note in section 1.2 it says:

  "Even if better dressed as IP addresses, network addresses are
   real addresses in that they locate physical destinations in the
   network, unlike memory addresses, which are routinely virtualised by
   host operating systems."

Surely DNS addresses are more equivalent to the virtual memory
addresses in host if you're going to take that analogy?  The whole point
of virtual memory is that it makes it easier for the user (well,
programmer) by hiding the nasty details of which physical address your
code and data live at.  The whole point of the DNS is that it makes it
easier for the user by hiding the nasty details of what IP address you
need to talk to.  And that's without getting into the situations where a
single IP address locates multiple hosts (broadcast addresses, multicast
addresses, etc).

Reading further into the draft I was left think "URNs".  The draft does
mention URNs at all and yet alot of what it seems to do appears similar to
the ideas behind the URN efforts of the IETF in the past.

Tatty bye,

Jim'll

Re: NATs *ARE* evil!

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Mike Fi
sk writes:

>
>The marginal value I see in IPsec is that it is useful for protocols other
>than TCP.  For TCP applications, I confess that I don't see much value in
>IPsec (not that TLS has any particular merits, it just became more common
>first).
>

Why do I think I'm having this discussion for the Nth time?  IPsec has 
two other advantages:  it protects *all* transmissions without touching 
the applications, which would otherwise need to be converted one at a 
time; it also protects TCP against one-packet denial-of-service 
attacks.  All I have to do to tear down a TLS session is send one 
packet with the correct port and sequence numbers.  TLS will notice 
that the packet doesn't belong, and will tear down the session.  With 
IPsec, TCP will never even see the garbage packet, since it will fail 
the integrity check before it gets to that layer.


--Steve Bellovin

Re: NATs *ARE* evil!

[Mike Fisk]

On Tue, 19 Dec 2000, Theodore Y. Ts'o wrote:

>Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST)
>From: Mike Fisk <[EMAIL PROTECTED]>
> 
>Gateways that surreptitiously modify packets can break ANY end-to-end
>protocol no matter what layer it's at.  Assume that we sacrifice IP
>addresses as not necessarily end-to-end.  Fine, there are gateways that
>need to modify your TCP ports too.  Okay, sacrifice make it so ports
>aren't covered by e2e assumptions like IPsec.  Fine, there are gateways
>that do ACK spoofing.  Okay, sacrifice all header data and assume that
>only payload is e2e.  Whoops, even the payload has to be modified by some
>gateways.  The hypothesis that you can have these gateways and have
>any part of the packet be guaranteed to be e2e is false.
> 
>Given our inability to rule out the need for gateways that change IP
>addresses (or other routing headers), this leads to the conclusion that
>applications shouldn't use any header field (IP address, port, etc.) for
>authentication.
> 
> OK, in that case, we've completely thrown out the end-to-end principle

It's an argument of semantics, but I prefer to say that we're separating
transport-layer end-to-end from application-layer end-to-end.  Make
applications explicitly terminate transport connections at gateways.  So
what is now a connection from me to you across a NAT and a proxy-ing
firewall would be come a session-layer connection from me to you served by
transport connections from me to the NAT, from the NAT to the proxy, and
from the proxy to you.

Just as layer two frames don't cross routers, layer three and four frames
don't cross these upper-layer gateways.  I want to get rid of
surreptitious proxies and gateways, but to get there you have to provide
similar services somewhere in the stack.  Today we maintain route tables,
ARP for the router's layer two addresses, and form a packet.  We need
something equivalent to handle the discovery and addressing of upper-layer
gateways.

The presentation I gave at the midcom BOF covers some of this:
http://public.lanl.gov/mfisk/papers/midcom-bof.pdf

> and completely wiped out any possibility of IPSEC.  If that's the world
> we live in, where any part of the IP header can be subject to attack by
> an intermediate attacker err, "service provider", then you shouldn't
> be using IPSEC.  You should be using TLS instead.

That's the crux.  If I live in an institution with a NAT or firewall,
there is a policy that I will use that network "service".  There may be
other policies regarding what other intermediate gateways you trust.  
Many people will favor trusting as few (zero) gateways as possible.  
Hopefully these policies will drive people away from the use of these
gateways, but I don't think we can assume that gateways will never exist.  
We need good protocol mechanisms that allow those policies.

The marginal value I see in IPsec is that it is useful for protocols other
than TCP.  For TCP applications, I confess that I don't see much value in
IPsec (not that TLS has any particular merits, it just became more common
first).

> It of course also means that no part of the IP header can be
> authenticated in anyway, since it's of course all subject to change by
> such gateways.

Yes, I assert that that is an architectural assumption (concession) that
needs to be made.  You might be able to authenticate the IP header of the
gateway, but that doesn't help you much with application-level e2e
authentication.

> Is that really the architecture that we should be building in the
> Internet.  I know some extremists would say yes, absolutely, and others
> would be say that this would be a horror.  The problem though is that
> we're designing that assume (and depend upon) both architectural 
> philosophies.  Is it any wonder that we're having disconnects?

Agreed.  We have to agree on what assumptions we can make.  We need more
questions like "can we sign in blood that the IP address will not be
modified".  Unfortunately, I don't think we can make that particular
assumption (between application end-points).

Yes, some of us are proposing a departure from some current architectural
assumptions, but I think that there is sufficient evidence that there are
legitimate (if unfortunate and messy) needs for this agility.  You're
correct in fearing that we can't just put a stake in the sand and swear
them away.

-- 
Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab
See http://home.lanl.gov/mfisk/ for contact information

Re: IETF logistics

[Henning G. Schulzrinne]

Frank Kastenholz wrote:
> 
> At 09:28 AM 12/19/00 -0500, RJ Atkinson wrote:
> >We can also end the de facto practice of
> >using the sessions as tutorials and discontinue fancy prepared
> >presentations of the material already in the I-Ds.  While
> >tutorials are a fine thing, they are appropriate for USENIX
> >or Interop, not IETF WG sessions, IMHO.
> 
> I tried doing this in my area when I was on the IESG.
> It didn't work. The chairs and attendees want this stuff.

One can also argue that with 400+ people in a room, having discussions
about minute protocol details is a less efficient use of time than
providing a concise summary of where the authors think the draft is at.
This gives everyone a chance to synchronize and emerge from the usual
"please fix the wording in table 3" minutiae to the bigger picture - is
this generally good/interesting stuff, is it sufficiently ready to move
forwards, is the scope clear, what are the big open issues, etc?. These
types of presentations do serve as a "tutorial" to the vast majority of
people that can't track every wording change in a draft.

A good overview that triggers a "you're going off the rails" remark is
much more useful than the common "shall we use upper case or lower case"
discussion with the same ten participants who are already particpating
in the mailing list discussion.

> 
> >Further, I'd suggest that each area would have the
> >option (discretion of the relevant ADs) of having a single
> >Area Meeting someplace.  This would last only perhaps 2 days.
> >It could be held at a rather larger number of venues
> >(due to smaller attendance)
> 
> I do not believe that this would work. Too many people
> just go to see what's going on and be there in case
> "something important" happens. If you have a
> meeting, they will go.

It also tends to disenfranchise those who are not on infinite travel
budgets.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

Re: NATs *ARE* evil!

[Theodore Y. Ts'o]

   From: Ken Raeburn <[EMAIL PROTECTED]>
   Date: 19 Dec 2000 09:02:52 -0500

   "Theodore Y. Ts'o" <[EMAIL PROTECTED]> writes:
   > Kerberos tried to deal with this problem by talking about "canonical
   > domain name", which it tried to define as being the name that you got
   > when you took a DNS name, forward resolved it to get an A address, and
   > then reverse-resolved it to get a DNS name.  But this didn't work in
   > many cases, sometimes we got back an unqualified name, and in many cases
   > this scheme totally failed due to load balancing DNS servers, etc.  I

   The MIT implementation does that, but I always thought that was just
   because certain gethostbyname implementations wouldn't return the
   canonical name (in the CNAME-processing sense) without doing this
   dance.  Because of the server-cluster or load-balancing case, I've
   been thinking we should change it.  The spec has never been quite that
   precise on this point; probably something we should fix for
   RFC1510bis.

RFC-1510bis always ignored this issue, and at some level, it strikes at
the heart of the whole name canonicalization mess.   RFC-1510 assumes
that you know the authentication name of the service.  The problem is
that it's silent on that the issue of how you discover said
authentication name.  What was implemented in the MIT implementation
isn't actually specified anywhere; it's a local implementation hack.  
And, as Microsoft rightly points out, because we rely on the DNS, it's
not really secure, either.  Unfortunately, fixing this problem is hard!

The problem with using the CNAME target as the authentication name is
that that while it works for some load-balancers, it fails for others.
It all depends on whether the load-balancers return a CNAME or an A
address.   Simply just using the CNAME also means that you need to also
replicate the domain name search rules.  If I type "telnet tsx-prime", and
I have a domain name search rule of "valinux.com mit.edu", then the name
which should be used is tsx-prime.mit.edu.  Yet if I type "telnet
shells", I should get the name shells.valinux.com.   This reason is
historically the reason why we played the forwards and backwards dance
--- because we wanted to get that case right.   

So when checking gethostbyname implementations, if you have to check to
see whether they return the FQDN both in the CNAME case, and in the case
where an unqualified domain name is typed by the client.  Many
gethostbyname implementations will fail on one or the other

   > suspect the reason is that as our domain name friends would tell us,
   > there is no such thing as a "canonical domain name" for a host.
   > Kerberos tried to invent such a concept, but it didn't work all that
   > well.  I would much rather have some real IP-level endpoint identifier.
   > If that's what we're securing, that's what we should be using.

   If you get hosts with multiple addresses (or, under IPv6, multiple
   prefixes), an address-based identifier is still not unique.  (And,
   unpleasantly enough, there are server implementations that split a
   single IP address across multiple machines.)

True enough.  (Although some people actually want to be able to
authenticate and distinguish between specific ethernet interfaces; they
mostly fall into the category of "sick puppies", but it's indicative of
the naming problem that we have.  We don't have general agreement on
what the semantics of the names that we do have, and as a result the
semantics are overloaded as all hell, with different people taking
advantage of different aspects of the overloaded semantics, making it
extremely difficult to separate them out cleanly.  Ack!)

- Ted

Re: IETF logistics

[Randy Bush]

> I would suggest that chairs try setting the agenda around issues, not
> around drafts themselves.  The main point of the face-to-face meetings
> is to resolve issues that cannot be resolved by mail.  Put those on the
> agenda, and let the combatants present as much tutorial information as
> they feel is necessary to make their point -- but don't set up the
> editor of a particular draft to give a presentation first, followed by
> discussion.  Don't even put the draft title on the agenda, just in the
> preliminary mail sent out before the meeting.  Thoughts?

sounds good to me!

randy

Looking for Lyrics to the IETF Xmas song

[Jeffrey Altman]

Sorry for the wasted bandwidth.  But could someone please post the
lyrics to the IETF Christmas song, the video that was shown at the
Plenary. 

Thanks.



 Jeffrey Altman * Sr.Software Designer  C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/ using Kerberos, SRP, and 
 [EMAIL PROTECTED]  OpenSSL.  SSH soon to follow.

Re: IETF logistics

[Scott Brim]

On 19 Dec 2000 at 11:07 -0500, Frank Kastenholz apparently wrote:
> I believe that the only choices are
> - limit attendance to "the right people" or
> - accept the tourists and panda-watchers and
>   that the IETF meeting has evolved.

The right people include "monitors" these days.  For example there were
newly attending voice people who were there making sure the IETF didn't
do anything which would make their lives miserable.  Now that IP is
critical to almost everything you're going to see more of these people
who aren't there just for tutorials.  They deserve to get in before the
panda-watchers (I love it -- but who's the panda?  Don't answer that),
and after the active engineers.

I would suggest that chairs try setting the agenda around issues, not
around drafts themselves.  The main point of the face-to-face meetings
is to resolve issues that cannot be resolved by mail.  Put those on the
agenda, and let the combatants present as much tutorial information as
they feel is necessary to make their point -- but don't set up the
editor of a particular draft to give a presentation first, followed by
discussion.  Don't even put the draft title on the agenda, just in the
preliminary mail sent out before the meeting.  Thoughts?

...Scott

Re: IETF logistics

[Bob Braden]

Ran,

Everything you say contains truth, but to be optimistic in this holiday
season, in some ways we are doing much better than one might expect.
Here is a larger context...


THEN:
- The WWW had not been created, or was just in its infancy.

- Commercialization of the Internet was just beginning.  The
  major users of the Internet were from the academic community,
  as a result of NSFnet.  The .com part of the DNS space was
  not much used.  The DNS was used only for host names.

- The major vendors represented in IETF were mostly small
  companies --e.g., Cisco, Proteon, FTP Software, ...  The big
  guys like IBM and DEC were treating the Internet something
  like a rare disease -- to be tolerated and watched from afar,
  in case something unexpected (like continued growth) should
  happen.  IETF was not even on the radar screens of the Bell
  heads.

- The Internet researchers who had developed TCP/IP and
  friends were still significant players in the IETF.
  The heirs of this group, the IAB, set Internet standards


NOW:
(Left as an exercise to the reader, but here's a clue: it's
a different world out there!)


Given this context, it actually seems somewhat remarkable to me that
the IETF has so far been able to adapt to changing circumstances
(without becoming another ISO or ITU).

Bob Braden

Re: NATs *ARE* evil!

[V Guruprasad]

Hi Keith!

On Tue, 19 Dec 2000, Keith Moore wrote:

> mumble.  as far as I can tell, both DNS names and IP addresses
> are hopelessly overloaded and are likely to stay that way until
> we figure out how to make a major architectural change.

Could you please take a look at
draft-guruprasad-addressless-internet-00.txt
?

It's been done, and at least one conference PC rated it a best paper
(online at http://affine.watson.ibm.com/tmp/vinet.pdf), so it couldn't
be so bad as to be left in total oblivion while everyone continues
in endless inane discussions :-(

More to the point, everyone I did manage to present it to in the
hallways at the 49th IETF did like the idea. I'd hate to list the
nodders, but the list includes at least one IAB member, one W3C
person, and an important contributor to IS-IS and OSPF, as I recall.

"only an asteroid can clear the dinosaurs..."

-p.

Re: WLAN

[Marcus Leech]

Additionally, after network shutdown on Friday, Jeff Schiller cross-connected
his
  his Apple AirPort to his HDR/Hornet box, and was providing NATed wireless
service
  to folks still hanging out in the lobby of the east tower of the Hotel.

Re: IETF logistics

[Frank Kastenholz]

At 09:28 AM 12/19/00 -0500, RJ Atkinson wrote:
>We can also end the de facto practice of 
>using the sessions as tutorials and discontinue fancy prepared
>presentations of the material already in the I-Ds.  While 
>tutorials are a fine thing, they are appropriate for USENIX
>or Interop, not IETF WG sessions, IMHO.

I tried doing this in my area when I was on the IESG.
It didn't work. The chairs and attendees want this stuff.

>Further, I'd suggest that each area would have the
>option (discretion of the relevant ADs) of having a single 
>Area Meeting someplace.  This would last only perhaps 2 days.
>It could be held at a rather larger number of venues
>(due to smaller attendance)

I do not believe that this would work. Too many people
just go to see what's going on and be there in case
"something important" happens. If you have a 
meeting, they will go.

I believe that the only choices are
- limit attendance to "the right people" or
- accept the tourists and panda-watchers and
  that the IETF meeting has evolved.

Frank Kastenholz

Re: NATs *ARE* evil!

[Francis Dupont]

 In your previous mail you wrote:

   While I wouldn't go quite that far, I've been saying for years that the 
   IP header doesn't need any authentication if we have IPsec.

=> this is not true for IPv6 extension headers or IPv4 options.

   ... in a note explaining why I thought AH was useless

=> you can argue this for IPv4, not for IPv6 where extension headers
are really used. Many times some of us tried to remove AH, many times
we vote to keep it: this topics should be in the "oh not this again" list
of IETF and IPsec mailing lists.

Regards

[EMAIL PROTECTED]

PS: "NATs are evil" should be in too (:-)!

Re: naming

[Sean Doran]

Ran Atkinson writes:

| The semantics of an FQDN is not crisp and clear
| these days as is once was.  

Wow, your memory must be better than mine if you remember
crispness & clarity. :-)

| For example, www.cnn.com names a set of content 
| rather than naming a single given host.  
|
| Unicast ESP/AH SAs have to be between pairs of hosts.

It's down to what kind of "who" you want to represent;
I think it is reasonable to have more than one "who" namespace,
allowing one to find a particular application (the web server
that will cough up CNN's news, or the mail server that will
receive mail for Ran Atkinson) as well as a particular host.
This, moreover, makes application migration easier to deal with.

Again, the trick is to be able to do a symmetrical mapping
between "who-application" and "who-host".

Here's a question for you: given these two namespaces (one
being hypothetical), which one will find more common use by _you_?   

| So FQDNs can't quite do the trick, even with DNSSEC

I think the argument goes that a DNS-like distributed database
is a good idea, and that the DNS can be munged into doing the
work initially without enormous effort.   Yes, this means a
different namespace or two beyond the "IN" one, but is that a big deal?

| (NB: my analysis above assumes that DNSSEC is widely deployed 
| and ubiquitously available; in the current reality of very limited
| DNSSEC deployment, things aren't quite as nice as what
| I outline above).

Well, so who wants to write a resolver that makes use of
Jon Crowcroft's idea on replacing the existing DNS lookup mechanism?

Sean.

levels of end-to-end; lack thereof

[Dave Crocker]

At 01:08 AM 12/19/00 -0500, Theodore Y. Ts'o wrote:
>OK, in that case, we've completely thrown out the end-to-end principle,
>... then you shouldn't
>be using IPSEC.  You should be using TLS instead.

Unfortunately, the production Internet (ie, since 1983) has never been 
fully end-to-end at the IP layer.  Never.

Arguably it has never been end-to-end at the application layer, either, nor 
even application-layer data.

Gateways have always been a part of the Internet.  We have simply chosen to 
ignore them, except for the case of email (smtp/x.400).

It's fine to create a clean architecture, but not very helpful to ignore or 
complain about market-driven extensions (or work-arounds, or...) to it.

Folks -- people would not be making those extensions unless they 
experienced benefit in them.

We claim to believe that the market is the ultimate venue for resolving 
choice among standards.  We need to acknowledge that that applies to 
missing standards, as well as competing standards.


=-=-=-=-=
Dave Crocker  <[EMAIL PROTECTED]>
Brandenburg Consulting  
Tel: +1.408.246.8253,  Fax: +1.408.273.6464

Re: NATs *ARE* evil!

[Sean Doran]

Steve Bellovin, on IPSEC, not-AH:

| [A] host's identity is represented by its certificate (I'm speaking a bit 
| loosely here); its IP address is merely the way that packets reach it.  

This is an example of two separate namespaces that allow one
to distinguish between "who" and "where".   That the network
layer can be rewritten to the point of total protocol substitution
without interfering with the identification of who sent it
is a feature, adding enormous flexibility into the development
of network features.

That IPSEC can preserve the end-to-end integrity of the the
application-to-application data even in a rabidly-rewriting
environment makes one wonder why people are so fanatical
about preventing that rewriting at all!

(The important thing is that one knows that "Steve's Machine"
sent a packet that happened to arrive with a particular source
address, which for a while can be used to send replies back to
"Steve's Machine").

The only tricky thing here is having a "who" <-> "where" translation
readily available to the host.

Sean.

P.S.: Incidentally, I have no trouble whatsoever with the concept
  of a last-hop-router before a host that can distinguish "who" 
  "where" being presented with a permanent, deterministic association
  between the two.  I also have no problem with the last-hop-router
  moving "corewards" even several hops.  The thing I want to prevent
  is the requirement that ALL routers provide such a deterministic
  permanent mapping between the two, because ultimately that makes
  the Internet more expensive for everyone to use over time.  
  (It also makes a non-dual-stack transition to a new Internet protocol 
  much harder on the host side, and a non-ships-in-the-night deployment
  in routers nearly impossible).

Re: NATs *ARE* evil!

[Bill Sommerfeld]

>If DNSSEC were deployed, I see no reason why SAs could not be
>bound to domain names.
> 
> I disagree.  IPSEC is about Security at the IP layer, and that means we
> need a security association which is tied to an object which is
> addressable at the IP layer --- an IP address.

except that, 99% of the time, the address is obtained from DNS, and,
realistically, you care more about the authenticated identity of the
peer than its address..

> A DNS name doesn't qualify; a single DNS name can resolve to many
> different IP addresses, potentially representing multiple different
> hosts.  Some people do this for load-balancing purposes (to Randy Bushes
> infinite digust, but this is the reality).
> 
> Also, riddle me this: What host is addressed by the DNS name
> a456.g.akamai.net?  For me at home, it happens to be 207.87.18.169.
> Except when I'm logged into MIT, when it's *either* 18.7.0.12 *or*
> 18.7.0.10.  Betcha it's different for you.  :-)

"any problem in CS can be solved by adding another level of
indirection".  If we were to use the DNS name as the identity at each
end of the SA, a456.g.akamai.net could turn into a CNAME pointing at
the "real" server...

And it might not matter ... from the point of view of the *services*
provided, regardless of *which* instance of a456.g.akamai.net you
connect to, you get the same data...  it's just another face of the
greater akamai distributed hive mind.  [I assume that for
operational/management purposes, akamai has per-replica names which
are different from the ones given out in akamaized url's].

- Bill

Re: NATs *ARE* evil!

[Keith Moore]

> there is no such thing as a "canonical domain name" for a host.
> Kerberos tried to invent such a concept, but it didn't work all that
> well.  I would much rather have some real IP-level endpoint identifier.
> If that's what we're securing, that's what we should be using.

mumble.  as far as I can tell, both DNS names and IP addresses
are hopelessly overloaded and are likely to stay that way until
we figure out how to make a major architectural change.
I get amused when layer 3 folks tell me that overloading of IP
addresses is bad and that we therefore need to overload DNS names
even more.  But it doesn't make any more sense to me to increase the 
overloading of IP addresses (which are fundamentally names of 
locations of network attachment points - all other uses are in
some sense overloading) in order to reduce overloading of DNS names.

it seems to me that if you want to authenticate to a specific host 
then you need to use an identifier that is uniquely associated with 
that host, like the hosts's serial number, so I'd want to have 
certificates that could associate that serial number with a key.  
but in most cases (at least from an apps guy's view of the world) 
I don't care about any particular host - what I want to authenticate
is a service, and it could be on any hosts.  in such cases I want
to use the service name (which in today's world is usually a DNS name)
as the authentication identifier.  I could probably make a case for 
authenticating to IP addresses also, but for me this is the most 
difficult one to justify.

bottom line is I think we have a need for SAs to be bindable to 
several different kinds of identifiers.  I question the notion
that IPsec should be "security at the IP layer" because to me 
IP is only a way of moving payload from one place to another - it 
has little to do with the services that humans care about
and in whose identities they need to trust.

Keith

Re: 49th-IETF conf room planning

[Henning G. Schulzrinne]

Tripp Lilley wrote:
> 
> On Mon, 18 Dec 2000, Matthew Goldman wrote:
> 
> > I also disagree with you regarding hotel rates. Pre-negotiated block rates
> > for meetings are around the same price as we paid in San Diego for a similar
> > type of hotel (clearly, Vegas hotels are both much better than and much
> > worse than the Sheraton San Diego). The only time hotel rooms are extremely
> > high is for major expositions -- like Comdex, Consumer Electronics Show, etc
> > -- because those rooms are not booked as blocks. The hotels jack up the
> > prices for those weeks. I've been to Vegas on a non-convention week and got
> > a hotel room for $70/night vs. $180/night for the same room during Comdex.
> > It would be up to the IETF to negotiate for 2000-3000 rooms; that's a lot of
> > buying power. If they can't get reasonable rates, then we don't go there.
> 
> Actually, geek conferences get the shaft in Vegas, because Vegas is wise
> to the fact that geeks, knowing the odds, are much less likely to gamble.
> That's why Comdex, Interop, and so forth, get such high hotel rates. Now,
> if we assured them that IETF stands for "International Eaters of Tasty
> Food", or similar, we might get a break... And we can point to the
> frequent mention of "many fine lunches and dinners" in _Exploring the
> Internet_ as substantiation.

Or we explain to them that we're updating RFC 1750 to include roulette,
blackjack and one-armed bandits as sources of randomness. 


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

IETF logistics

[RJ Atkinson]

Folks,

Some compare/contrast about then and now, followed by
some (perhaps radical) thoughts to ponder.  I'm NOT interested
in quibbles about the timeframe for THEN or minor differences
in perception about either THEN or NOW, so I'll ignore any
troll-like responses.  This is intended as a very high-level
set of comments -- high-level necessarily implies a certain
lack of crispness.

THEN:
- Presentations at IETF normally did NOT rehash 
  material available in the I-Ds in tutorial style.
- Viewgraphs were hand-scribbled the night before,
often after some lobby bof before the meeting.
- More people read the I-Ds before the meeting, though there
  was griping about inadequate preparation then also.
- Working Group sessions actually did work, designing
  in real-time, discussing technical issues in real-time,
  resolving open technical issues in a higher bandwidth
  environment.
- Interim WG meetings were rare.
- Folks who had read the drafts could generally get into
  and participate in meetings of interest.

NOW:
- Presentations mostly do rehash material in the I-Ds
- Viewgraphs with fancy cartoon graphics, company logos,
  that required lots of time to create the week before
  the meeting are shown.
- Few people (as a percentage of WG attendees) have actually
  read the I-Ds beforehand, relying instead on thepresentations.
- Working Group sessions are mostly educational overviews,
  without significant real-time discussion or resolution
  of technical issues.
- Interim WG meetings are much more frequent, in part 
  because only people deeply interested in the topic
  bother to travel for such meetings.
- Folks who have read the drafts often cannot get into
  the meetings they have prepared for.  I had abysmal luck
  at actually attending sessions where I had read the drafts
  and am actually involved in implementation or use of
  a specification.

In the short term, IETF have signed contracts for
3 meetings per year.  We don't want to break any existing
contracts.  What we can do for future IETFs is make the current
sporadic practice of reserving the front few rows of seats for
folks who have actually read the drafts and are involved in
implementation.  We can also end the de facto practice of 
using the sessions as tutorials and discontinue fancy prepared
presentations of the material already in the I-Ds.  While 
tutorials are a fine thing, they are appropriate for USENIX
or Interop, not IETF WG sessions, IMHO.

However, I'd like to propose that we experiment 
with only having 2 all-area IETF meetings per year when we
can do so without breaking any contracts.

Further, I'd suggest that each area would have the
option (discretion of the relevant ADs) of having a single 
Area Meeting someplace.  This would last only perhaps 2 days.
It could be held at a rather larger number of venues
(due to smaller attendance) -- a college/university or large
corporate location might well be a very good choice for such
a meeting.  In addition, WGs ought to be encouraged to hold
at least one WG interim meeting per year, to provide a vehicle
for meaty discussion of technical issues by folks who are 
current in the WG, involved in implementation or deployment
of that WG's material, and so forth.  

Sincerely,

Ran
[EMAIL PROTECTED]

Re: NATs *ARE* evil!

[Matt Crawford]

> If DNSSEC were deployed, I see no reason why SAs could not be
> bound to domain names.

Well, there are all those load-distributing hacks -- Akamai and
others.  But I bet they could come up with a huge flesh-tone bandaid
so you would continue not to notice.  On a good day.

Re: naming

[RJ Atkinson]

At 22:54 18/12/00, Donald E. Eastlake 3rd wrote:
>If DNSSEC were deployed, I see no reason why SAs 
>could not be bound to domain names.

The semantics of an FQDN is not crisp and clear
these days as is once was.  

For example, www.cnn.com names a set of content 
(served by an array of different server hosts with a 
front-end web widget), rather than naming a single given host.  

Unicast ESP/AH SAs have to be between pairs of hosts.
So FQDNs can't quite do the trick, even with DNSSEC, in
the general case.  In certain special cases, where an FQDN
does happen to map 1:1 to a host, then it might be used
iff there were a way to distinguish that case from the murky
case.

(NB: my analysis above assumes that DNSSEC is widely deployed 
and ubiquitously available; in the current reality of very limited
DNSSEC deployment, things aren't quite as nice as what
I outline above).

Cheers,

Ran
[EMAIL PROTECTED]

Re: NATs *ARE* evil!

[Ken Raeburn]

"Theodore Y. Ts'o" <[EMAIL PROTECTED]> writes:
> Kerberos tried to deal with this problem by talking about "canonical
> domain name", which it tried to define as being the name that you got
> when you took a DNS name, forward resolved it to get an A address, and
> then reverse-resolved it to get a DNS name.  But this didn't work in
> many cases, sometimes we got back an unqualified name, and in many cases
> this scheme totally failed due to load balancing DNS servers, etc.  I

The MIT implementation does that, but I always thought that was just
because certain gethostbyname implementations wouldn't return the
canonical name (in the CNAME-processing sense) without doing this
dance.  Because of the server-cluster or load-balancing case, I've
been thinking we should change it.  The spec has never been quite that
precise on this point; probably something we should fix for
RFC1510bis.

> suspect the reason is that as our domain name friends would tell us,
> there is no such thing as a "canonical domain name" for a host.
> Kerberos tried to invent such a concept, but it didn't work all that
> well.  I would much rather have some real IP-level endpoint identifier.
> If that's what we're securing, that's what we should be using.

If you get hosts with multiple addresses (or, under IPv6, multiple
prefixes), an address-based identifier is still not unique.  (And,
unpleasantly enough, there are server implementations that split a
single IP address across multiple machines.)

Ken

Re: NATs *ARE* evil!

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, "Theodore Y. Ts'o" writes
:
>   Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST)
>   From: Mike Fisk <[EMAIL PROTECTED]>
>
>   Gateways that surreptitiously modify packets can break ANY end-to-end
>   protocol no matter what layer it's at.  Assume that we sacrifice IP
>   addresses as not necessarily end-to-end.  Fine, there are gateways that
>   need to modify your TCP ports too.  Okay, sacrifice make it so ports
>   aren't covered by e2e assumptions like IPsec.  Fine, there are gateways
>   that do ACK spoofing.  Okay, sacrifice all header data and assume that
>   only payload is e2e.  Whoops, even the payload has to be modified by some
>   gateways.  The hypothesis that you can have these gateways and have
>   any part of the packet be guaranteed to be e2e is false.
>
>   Given our inability to rule out the need for gateways that change IP
>   addresses (or other routing headers), this leads to the conclusion that
>   applications shouldn't use any header field (IP address, port, etc.) for
>   authentication.
>
>OK, in that case, we've completely thrown out the end-to-end principle,
>and completely wiped out any possibility of IPSEC.  If that's the world
>we live in, where any part of the IP header can be subject to attack by
>an intermediate attacker err, "service provider", then you shouldn't
>be using IPSEC.  You should be using TLS instead.
>
>It of course also means that no part of the IP header can be
>authenticated in anyway, since it's of course all subject to change by
>such gateways.

While I wouldn't go quite that far, I've been saying for years that the 
IP header doesn't need any authentication if we have IPsec.  To me, a 
host's identity is represented by its certificate (I'm speaking a bit 
loosely here); its IP address is merely the way that packets reach it.  
I could post my analysis of this again (it was originally written 
during the Stockholm IETF, in a note explaining why I thought AH was 
useless), but I don't think that this is the place for it.

--Steve Bellovin

Re: WLAN

[John Stracke]

Teemu Rinta-aho wrote:

> Thank you. That was nice service from Qualcomm, just too
> bad there was no information of the wireless coverage
> on the meeting web pages.

It wasn't kept secret, though; they had a table set up in the Sheraton
(opposite the social event/LAN card desk) with information.

--
/=\
|John Stracke| http://www.ecal.com |My opinions are my own.   |
|Chief Scientist ||
|eCal Corp.  |"The struggle is always worthwhile, if the end  |
|[EMAIL PROTECTED]|be worthwhile and the means honorable;  |
||foreknowledge of defeat is not sufficient reason|
||to withdraw from the contest." -- Adron |
||e'Kieron, by Steven Brust   |
\=/

Re: WLAN

[Teemu Rinta-aho]

On Mon, 18 Dec 2000, Harald Koch wrote:

> There was an access point in the Embassy Suites Hotel. It was not
> connected to the rest of the IETF LAN. It was instead connected to the
> Internet via a Qualcomm HDR, a high-speed cellular data connection being
> tested by Qualcomm.
> 
> An enterprising engineer installed an 802.11 access point and an HDR
> modem, and connected the two via an ethernet cable. Voila, instant
> internet.

Thank you. That was nice service from Qualcomm, just too
bad there was no information of the wireless coverage
on the meeting web pages.

---
Teemu Rinta-aho[EMAIL PROTECTED]
NomadicLab, Ericsson Research   +358 9 299 3078
FIN-02420 Jorvas, Finland  +358 40 562 3066
---