EIDs and Security
Ran Atkinson
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.
Noel Chiappa
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
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
> 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
> 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
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
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
EID involves adding what essentially is an EID....
to do it, but rather to consider what is the benefit and cost
features into Pip, I have found time and time that the EID makes
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
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
> 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