EIDs and Security

1 view
Skip to first unread message

Ran Atkinson

unread,
Apr 5, 1993, 8:51:35 PM4/5/93
to

We can do security _fine_ without EIDs and having only something
similar to an IPv4/IPv6/IPv7 address (I don't really understand PIP
yet, despite Paul's best efforts, so am not commenting on PIP.)

I personally think it is high time that an Internet Draft appeared
explaining why EIDs are needed. It should be written so that normal
IETF folks can understand. I've seen lots of words pass by on this
list and I haven't seen the need for a separate EID yet. Now I'm not
a routing/addressing person so maybe there is a good reason to have
EIDs. All I'm saying is that this justification and explanation
(including a working definition of an EID) really needs to be set down
in detail in something like Internet Draft format so the rest of us
can read/review/understand why some folks think they are needed.

Ran
atki...@itd.nrl.navy.mil

Noel Chiappa

unread,
Apr 5, 1993, 9:40:28 PM4/5/93
to
I personally think it is high time that an Internet Draft appeared
explaining why EIDs are needed. It should be written so that normal
IETF folks can understand.

As I indicated in my long reply today to Dave Crocker, having a document is
probably a good idea. However, I seriously doubt that the existence of this
document is going to make a difference, in terms of changing many minds about
whether EID's are needed.

I've seen lots of words pass by on this list and I haven't seen the need
for a separate EID yet.

If you've read those words, and still aren't convinced, I am frankly doubtful
that a document is going to make you change your mind.

Now I'm not a routing/addressing person so maybe there is a good reason to
have EIDs.

EID's have very little to do with routing and addressing; it's more an issue
of naming of end-end entities.

Noel

C. Harald Koch

unread,
Apr 6, 1993, 4:38:01 PM4/6/93
to
MetaComment:

For every sample issue that comes up here, there are two solutions offered
by the list membership. One uses EIDs and the other uses some other existing
system, or some sort of kludge.

Personally, I would rather have *one* solution to many problems, rather than
many solutions to many problems.

Especially given that EIDs seem useful enough to be applicable to problems
we haven't even thought of yet.

My $0.02,

--
Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON
action, there is an equal | c...@alias.com (work-related mail)
and opposite goverment | c...@gpu.utcs.utoronto.ca (permanent address)
program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet)

Paul Francis formally Paul Tsuchiya

unread,
Apr 6, 1993, 4:37:56 PM4/6/93
to
>
> For every sample issue that comes up here, there are two solutions offered
> by the list membership. One uses EIDs and the other uses some other existing
> system, or some sort of kludge.
>

I agree with this. It does appear that one can do anything without
EIDs that one can do with EIDs. In many cases doing it "without" an
EID involves adding what essentially is an EID....

For me, the issue is not to avoid EIDs if there is any other way
to do it, but rather to consider what is the benefit and cost
of an EID versus various custom solutions. In designing various
features into Pip, I have found time and time that the EID makes
things easier. A general statement I can make is that it gives
me complete freedom to play around with the "addressing" information
(that is, the routing directive).

What are the costs of an EID? In the case of Pip, the main cost
is including them in every packet. This isn't a forwarding cost,
since the router doesn't look at the EID unless it has to. Rather,
it is a header size cost. Given that we have to do header compression
for slow links anyway, I don't see the larger header as prohibitive.

Another cost that has come up is the cost of administering another
number space. But, it seems that this cost must be borne to
administer the multicast group IDs anyway, so I'm not sure that
this represents additional cost over the non-EID case. Also, the
same organizations that assign addresses can assign EIDs, so it
is not as though you are duplicating every aspect of administration.

Then, there is the general cost of dealing with the EID--in DNS, in
routers, and so on. My intuition is that this cost is worth the
benefit......

PX

Paul Francis formally Paul Tsuchiya

unread,
Apr 6, 1993, 6:08:06 PM4/6/93
to
>
> Ah, but if PIP had flows, then you could leave out the addresses and do cache
> lookups using the EID as a tag, and as KRE pointed out, the EID will usually
> be *shorter* than the address (and the EID is fixed length to boot :-). I
> know, I know, you don't agree, but I couldn't resist the chance to hassle
> you! :-)
>

Well, I do agree......just not 100%.....

But, for scaling reasons you want to be able to manage flows both
with per-flow tracking and with "flow-buckets" tracking. For the
latter, you still need the hierarchical address....

PX

Noel Chiappa

unread,
Apr 6, 1993, 6:02:40 PM4/6/93
to
In many cases doing it "without" an EID involves adding what essentially
is an EID....

Exactly. As I mentioned, all the schemes which use the IP SR Option to do
mobility basically makes the destination IP 'address' in the packet an EID,
and the 'real' destination address is in the SR Option.

In designing various features into Pip, I have found time and time that
the EID makes things easier.

Again, no surprise here. As a general system design principle, the closer
you keep each mechanism to the purpose it was designed for, the better it
works. Addresses were designed to be used by the routing, not identify
moving hosts, etc, etc, etc.

This isn't a forwarding cost, since the router doesn't look at the EID
unless it has to.

Ah, but if PIP had flows, then you could leave out the addresses and do cache


lookups using the EID as a tag, and as KRE pointed out, the EID will usually
be *shorter* than the address (and the EID is fixed length to boot :-). I
know, I know, you don't agree, but I couldn't resist the chance to hassle
you! :-)

My intuition is that this cost is worth the benefit......

Me too, but it's hard to quantify for people who want things quantified.
Producing a good result using intuition based on long study of the art is is
the challenge of system design....


Noel

Dan Hitchcock

unread,
Apr 7, 1993, 10:49:54 AM4/7/93
to
From owner-Big...@munnari.oz.au Tue Apr 6 18:22:39 1993
Received: by munnari.oz.au (5.83--+1.3.1+0.50)
id AA23681; Wed, 7 Apr 1993 06:38:29 +1000 (from owner-Big-Internet)
Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA23678; Wed, 7 Apr 1993 06:38:21 +1000 (from fra...@thumper.bellcore.com)
Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7)
id <AA01732> for big-In...@munnari.oz.au; Tue, 6 Apr 93 16:38:11 EDT
Received: by tsuchiya.bellcore.com (4.1/4.7)
id <AA03223> for c...@alias.com; Tue, 6 Apr 93 16:38:10 EDT
Date: Tue, 6 Apr 93 16:38:10 EDT
From: fra...@thumper.bellcore.com (Paul Francis (formally Paul Tsuchiya))
Message-Id: <930406203...@tsuchiya.bellcore.com>
To: big-In...@munnari.oz.au, c...@alias.com
Subject: Re: EIDs and Security


>
> For every sample issue that comes up here, there are two solutions offered
> by the list membership. One uses EIDs and the other uses some other existing
> system, or some sort of kludge.
>

I agree with this. It does appear that one can do anything without
EIDs that one can do with EIDs. In many cases doing it "without" an

EID involves adding what essentially is an EID....

For me, the issue is not to avoid EIDs if there is any other way
to do it, but rather to consider what is the benefit and cost
of an EID versus various custom solutions. In designing various

features into Pip, I have found time and time that the EID makes
things easier. A general statement I can make is that it gives
me complete freedom to play around with the "addressing" information
(that is, the routing directive).

What are the costs of an EID? In the case of Pip, the main cost
is including them in every packet. This isn't a forwarding cost,
since the router doesn't look at the EID unless it has to. Rather,
it is a header size cost. Given that we have to do header compression
for slow links anyway, I don't see the larger header as prohibitive.

Another cost that has come up is the cost of administering another
number space. But, it seems that this cost must be borne to
administer the multicast group IDs anyway, so I'm not sure that
this represents additional cost over the non-EID case. Also, the
same organizations that assign addresses can assign EIDs, so it
is not as though you are duplicating every aspect of administration.

Then, there is the general cost of dealing with the EID--in DNS, in
routers, and so on. My intuition is that this cost is worth the
benefit......

PX

In fact one advantage of EID's is that they can be assigned in some sense
by different organizations... at least at some level in the hierarchy.

This avoids the battle between the network providers and the end sites over
control of the address/eid.
DH

Paul Francis formerly Paul Tsuchiya

unread,
Apr 7, 1993, 11:15:47 AM4/7/93
to
>
> In fact one advantage of EID's is that they can be assigned in some sense
> by different organizations... at least at some level in the hierarchy.
>
> This avoids the battle between the network providers and the end sites over
> control of the address/eid.
> DH
>

I agree, it may help. If an organization has it's own ID space, it
might lessen the sensitivity to non-organizational (provider-rooted)
addresses.

The plan is for Pip EIDs to be assigned organizationally.....

PX

Reply all
Reply to author
Forward
0 new messages