Subject: Re: The rights of email senders and IETF rough consensus

From: [email-masked] (Noel Chiappa)
Date: Tue, 20 Dec 2005 14:34:37 -0500 (EST)

> From: Bob Braden <[email-masked]>

    >>>> IETF should not make it more difficult for the Internet to adapt to
    >>>> changing conditions by standardizing protocols that only work in a
    >>>> narrow set of conditions

    >>> Like ARP?

    >> I wasn't around when the ARP decision was made, so I don't know how
    >> widely it was realized at the time that the approach was shortsighted.

    > This is a strange discussion. Broadcast networks are an important class
    > of link layer technologies, and I would say that by any measure ARP was
    > a huge technical success. It may well have been responsible for the
    > great popularity of Ethernet and its followons. ... I don't understand
    > the suggestion that it was "shortsighted".

I suspect they are talking about two things, one of which is true, and one of
which isn't.

The thing that's true is that ARP contains basically zero security. So,
someone who has access to the local shared medium can spoof you - and even if
you're using end-end authentication, they can mount a DoS attack. However, I
should point out that i) fixing this correctly requires one heck of a lot of
work, since it basically involves creation of some sort of authentication
system, and ii) when ARP was defined, the Internet was so small that the
human/design/programming resources simply weren't available to do such a
design.

The thing that's not true is that all sorts of kludges use it (well, it's
true, but it's not ARP's fault). People have taken advantage of the fact that
there's a layer of binding there ("all problems in computer science can be
solved by another layer of indirection") to do a number of things they'd like
to be able to do (e.g. server pools), but which the architecture *as a whole*
is too impoverished to do, because *as a whole* it doesn't have enough
namespaces and/or layers of binding. (I.e. it's a case of "When the only tool
you have is a hammer..." disease.) This is not ARP's fault. When used to do
*only* what it was *intended* to do, ARP is reasonably good, the biggest
problem being the security one mentioned above.

I would also point out that ARP was thought-forward enough to support other
protocol families and/or hardware types - and implementations which supported
that generality (instead of the usual corner-cutting step of hardcoding in
support for IP and Ether) were able to do so *with no code changes*, which
I thought was reasonably impressive.

    > ARP also established an important architectural technique. 

Now I'm curious, because I can't work out what you're referring to!

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Dec 2005 14:56:37 -0800

Folks,

>     >     It may well have been responsible for the
...
> The thing that's true is that ARP contains basically zero security. 
...
  > I would also point out that ARP was thought-forward enough to 
support other

Well, this is a better sequence of notes than I had hoped for, given 
that it reflects exactly the line of meta-issues I meant to suggest.

My own summary:

ARP is simple and specific.  It solves a particular problem -- albeit a 
very constrained one -- quite nicely.  It has a specific bit of 
flexibility, but really only a small amount.  The flexibility has been 
quite useful, but overall functionality of arp is pretty rigid.

It most certainly would have been possible to envision all sorts of 
more-general mechanisms.  One might have killed the arp development 
effort, in favor of the more general effort.

Luckily, narrow, short-sighted design thinking carried the day.

We have developed a tendency in the IETF to fail to distinguish between 
"it won't work" and "it could/should work better". Worse, the latter 
tends to reflect idealism from those who are tasked neither with doing 
the work nor delivering the output to the market.  So they tend to 
assert their views with great force but no balance against delay/benefit 
trade-offs.

"It won't work" must be a show-stopper. It is valid to assert it at any 
time, of course.

"It could/should work better" is always reasonable to express, almost 
never appropriate for that assertion to be the basis of stopping forward 
progress.  During the actual design process, it is of course appropriate 
to try to recruit rough consensus for a superior design.  But 
recruitment efforts are not the same as blocking efforts.

When a constituency comes to the IETF, trying to solve a problem, they 
represent a portion of the market that is motivated for near-term output.

What has become the norm in the IETF is to impose massive startup costs 
for the working group, massive commentary-documenting costs in the 
writing, and open-ended delay in trying to satisfy every demand of every 
person who expresses unhappiness with any aspect of the work, at any 
point in the process.

The IETF used to *facilitate* collaboration on timely specifications. 
One of the ways it achieved was to distinguish between technical failure 
and technical preference.

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net