Subject: RE: NATs *ARE* evil!

From: [email-masked] (Sean Doran)
Date: Fri, 15 Dec 2000 19:44:18 +0100 (CET)

| It's already happening.  Try running IPSec from one 10 network to another 10
| network.  Much pain.

Surely the "much pain" is because, as Melinda Shore indicates, 
some "anti-NAT fanatics" cannot understand the distinction
between "who" and "where"?   

NAT merely exposes and exacerbates the perceptual problem,
leading to bruised knees.

	Sean.

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Dec 2000 22:42:52 -0500

> between "who" and "where"?

sounds like a Peter Pan theory....

okay, everbody, close your eyes and try *real hard* to make believe 
that you can route between networks using overlapping address space,
and that you can run distributed large scale distributed applications 
without a shared space for endpoint identifiers... 

if it doesn't work, you're not trying hard enough to believe!

excuse me while I puke.

Keith

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Mon, 18 Dec 2000 12:48:06 -0500

Date: Fri, 15 Dec 2000 19:44:18 +0100 (CET)
   From: [email-masked] (Sean Doran)

   | It's already happening.  Try running IPSec from one 10 network to
   | another 10 network.  Much pain.

Historically, the IPv4 address specified "who", and not necessarily
"where".  NAT, for better or for worse, represents an attempt to change
that historical understanding.  Some would say that it is a fiat
acompli, and we should just live with it.  Others would say it's NAT's
fault for trying to change the rules in the middle of the game.

Regardless of who's "right" with respect to that argument, I'd argue
that it's not productive to dwell on it.  I am personally much more
interested in making sure this ambiguity doesn't arise with IPv6, since
even though it's fairly late in the game, we have more of a chance of
fixing things here since there's much less of a deployed base.

It would be *awfully* convenient if we declare up front that something
is the "end point identifier" (i.e., "who"), and is forever exempt from
being changed by intermediate routing entities, and if necessary,
something is else the routing component (i.e., "where"), which can
change.  This "end point identifer" should have a canonical form, which
means that using the DNS name, as some have suggested, probably isn't
ideal.  For better or worse, people are too used to playing DNS games
where foo.g.akamai.com (for example) isn't necessarily the same host,
regardless of where you are in the network.

The buttom line is that we need *something* which can unambiguously
serve as an end point identifier.  Is it the IPV6 address?  It's big
enough that we probably won't have to play NAT games to gain address
space.  On the other hand, I've heard claims that the routing folks want
to reserve the right to muck with parts of the IPV6 address to make
their job easier --- which is fine, but tell us which part in advance,
so we can only protect the end-point identifier part of the address in
protocols like IPSEC.  Other people claim that the DNS address should be
the unambiguous end point identifier.  But that has problems, as
discussed above.

Indeed.  And regardless of who's at "fault" for creating this particular
problem, the scary part is that it's not at all obvious to me that we've
fixed it for IPV6.  As near as I can tell the ambiguity of what everyone
will agree is something we can use as an endpoint identifer remains.
The only question is (and I don't have an answer), are we too late to
try fixing it now?

						- Ted

---

From: John Collis <[email-masked]>
Date: 19 Dec 2000 11:39:19 +1300

> regardless of where you are in the network.

This is true. To do this though really requires some re-architecting
of the current Internet model, based on "first principles". In
particular, there is not a sufficient "name space" for what we are
often currently trying to do - hence the "akamai" type of trick.

Currently we have a situation where the defined name spaces are not
sufficient for truly identifying the end points of a routed
connection. IP addresses are therefore there for routing
purposes. However a number of situations can now occur so that the IP
address is not sufficient to name all situations. A host can be
multi-homed, partially disconnected or mobile and then things start
getting ugly.

We need to look at this. I believe that we are now already overloading
the useful set of meanings that one can attach to an IP address (somewhat
analogous to the presentation from Randy Bush at the plenary session on
DNS).

One can see actually, that some of the current issues to do with Mobility,
Multi-homing, NATs and the DNS are all related to an architectural
complexity that was never considered in the original architecting of the
Internet. (This is not a criticism, merely an observation based on a
view 20 years later). 

Cheers,
-- 
John Collis - Director Technology Development
IndraNet Technologies Ltd.
Email: [email-masked]
Web: http://www.indranet-technologies.com/

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 18 Dec 2000 20:45:43 -0500

>between "who" and "where"?   

        I fancy that I know one or two things about ESP
and AH.  Your analysis is Wrong.   The pain has nothing
to do with fanatics of any sort. 

        The root issue with ESP/AH and NAT is that the Internet
Architecture does not currently have a sufficiently rich set 
of namespaces.  In the world of the current Internet Architecture, 
ESP and AH are forced to bind SAs to addresses.  In a different
world, they might be able to bind SAs to a different name.  Some 
folks are exploring which, if any, additional namespaces might 
make sense to add to the architecture.  As this is research, 
not engineering, it is largely happening in the IRTF for now.  
If something comes of it, no doubt an I-D or two will appear 
online for perusal...  

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 18 Dec 2000 20:49:35 -0500

At 17:39 18/12/00, John Collis wrote:

>of the current Internet model, based on "first principles". 

        Yes.

>In particular, there is not a sufficient "name space" for what we are

        Yes.

>Currently we have a situation where the defined name spaces are 
>not sufficient for truly identifying the end points of a routed
>purposes. However a number of situations can now occur so that 
>the IP address is not sufficient to name all situations. A host 
>can be multi-homed, partially disconnected or mobile and then 
>things start getting ugly.

        Quite right.

>We need to look at this. I believe that we are now already overloading the useful set of meanings that one can attach 
>to an IP address (somewhat analogous to the presentation 
>from Randy Bush at the plenary session on DNS).

        IRTF NSRG is looking at this.  Research from folks
not involved in the NSRG would also be time well spent, IMHO.
I suspect there are some theses lurking in this area, for those
who might be of an academic bent.

Cheers,

Ran
[email-masked]

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Mon, 18 Dec 2000 22:54:47 -0500

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

Donald

From:  RJ Atkinson <[email-masked]>
Message-Id:  <[email-masked]>
Date:  Mon, 18 Dec 2000 20:45:43 -0500
To:  [email-masked] (Sean Doran)
Cc:  [email-masked]
In-Reply-To:  <[email-masked]>

---

From: [email-masked]
Date: Mon, 18 Dec 2000 22:58:06 -0500

> If DNSSEC were deployed, I see no reason why SAs could not be

I admit to not having read the DNSSEC RFCs.  I however do hope that they
are immune to the same sort of attacks against SSL and SSHv1 that are currently
getting a lot of publicity.

Anybody got a pointer to where in the RFC it discusses how the resolver on
my workstation initially verifies that it's not being man-in-the-middle'ed
from a spoof of our local nameserver?
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 19 Dec 2000 00:10:15 -0500

DNSSEC is still evolving, it isn't deployed yet, and the right mailing
lists to discuss it are the DNSEXT and DNSOP working groups.  However,
to give a really brief answer, if your local revolver is unwilling to
do the full blown DNSSEC cryptography and just wants to trust that the
local nameserver is doing it right (a reasonable scanario), it would
likely secure its transactions with that namesever with TSIG [RFC
2845].  And one way in which TSIG keying material could be set up is
TKEY [RFC 2940].

Donald

From:  [email-masked]
Message-Id:  <[email-masked]>
To:  "Donald E. Eastlake 3rd" <[email-masked]>
Cc:  [email-masked]
In-Reply-To:  Your message of "Mon, 18 Dec 2000 22:54:47 EST."
	                  <[email-masked]> 
References:  <[email-masked]>

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 19 Dec 2000 00:52:35 -0500

Date: Mon, 18 Dec 2000 22:54:47 -0500
   From: "Donald E. Eastlake 3rd" <[email-masked]>

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.

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.  :-)

When you add to this the problem that forwards and reverse name
resolution are not always the same, and that sometimes the in-addr names
don't even exist (for example, at the IETF terminal room in San Diego
initially), I believe that trying to use DNS names for SA binding just
isn't going to work in real life.

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
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.

						- Ted

---

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

> 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.

> 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

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 19 Dec 2000 09:04:56 -0500

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-masked]

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 19 Dec 2000 08:36:05 -0600

> If DNSSEC were deployed, I see no reason why SAs could not be

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.

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Dec 2000 09:39:00 -0500

> 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

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 19 Dec 2000 09:41:15 -0500

> 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..

> 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

---

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

Hi Keith!

> 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.

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 19 Dec 2000 12:26:12 -0500

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

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....

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

---

From: Jon Knight <[email-masked]>
Date: Tue, 19 Dec 2000 18:04:52 +0000 (GMT)

> 	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

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 19 Dec 2000 13:06:45 -0500

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

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

---

From: V Guruprasad <[email-masked]>
Date: Tue, 19 Dec 2000 15:53:50 -0500

> are on and what the address of their gateway router is.  Not exactly what

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.

> 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).

> 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).

> 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.

---

From: V Guruprasad <[email-masked]>
Date: Tue, 19 Dec 2000 16:28:29 -0500

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.

---

From: V Guruprasad <[email-masked]>
Date: Tue, 19 Dec 2000 17:29:50 -0500

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.

---

From: John Stracke <[email-masked]>
Date: Tue, 19 Dec 2000 17:36:18 -0500

> 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.

> - 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-masked]|$2.25; Children $2.00."                       |
\===============================================================/

---

From: V Guruprasad <[email-masked]>
Date: Wed, 20 Dec 2000 13:23:42 -0500

On Wed, 20 Dec 2000, John Stracke wrote:

> > Why don't you read the I-D
> 
> I did.

Then you'd see that the invisibility refers to that of the server
host, as follows: The client sees only the service name binding
in the form of the URL, but what it gets as the data path is
a virtual path (or LSP) handle. Since the label changes at each
hop, the path index visible to the client host relates only to
its own handle or file descriptor for the path, and is not
enough to identify the server host. (The server host gets revealed
only if there's only one hop.)

----
Obscurity would mean that a unique server host address exists but
is not advertised.

Invisibility means that a unique server host address does not exist
at all. This is a harder condition.
----

If my approach is implemented *in addition to* end-to-end IP, you
do get compromised because the IP layer supplies the host address.
But the defect would be due to the IP layer, NOT my framework,
which is happy as long as it can do MPLS end-to-end for transport.

In particular, one does not need IP per se under my framework, and
in that aspect, one can continue to use the higher IP protocols,
like TCP, UDP, SCTP, etc. e2e because they'd run on top of the
virtual path endings.

One question that was unclear till the IETF meeting was whether these
higher protocols could indeed be fooled to work independently of IP:
the proof of principle exists - in Cheritan's Triad project at Stanford,
the 32 b IP address is faked in similar fashion. Incidentally, Triad
was substantially what I had initially proposed within IBM in 1995-1996,
and we didn't see it as being of more than academic interest
at that time.

best regards,
-p.

---

From: John Stracke <[email-masked]>
Date: Wed, 20 Dec 2000 13:39:11 -0500

> at all. This is a harder condition.

No.  Security through obscurity means any approach that attempts to protect
network resources (in this case, the server) by making them hard to find.
Your approach, then, has a weak form of security through obscurity.  It
still permits clients to contact the server, which means that the server
needs to be hardened against malicious clients, which is why security
through obscurity is so poorly thought of.

I say it's a weak form because I believe you are wrong in stating that "a
unique server host address does not exist".  The URL (ick) is an address
for the server; it's just a higher-level address than an IP address.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Campbell's has it wrong--it's "Never         |
[email-masked]|underestimate the power of *chocolate*".     |
\==============================================================/

---

From: V Guruprasad <[email-masked]>
Date: Wed, 20 Dec 2000 16:22:32 -0500

> for the server; it's just a higher-level address than an IP address.

The "URLs" in my approach do not identify the server host, and it's NOT
a higher-level version of the IP address. See Section 2.1, which states
the extent of weakness, and 2.3.9 which charts the conditions under which
the information can be leaked to the client.

The fact that my "URLs" are not high-level host addresses was specifically
brought out at the ECUMN'2000 workshop-like conference, where the impact of
this development was so strongly felt that attention was drawn to this
right from the introductory plenary session.

The purpose of the architecture is not to provide security, however.

[ btw, what's (ick)? ]

thanks,
-p.

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 20 Dec 2000 22:30:11 +0000

one of nature's great dualities: statedulness will take root in the
most barren soil, even though datagrams will try to route around it

j

though if nat speak unto nat, then ipv6 be born....

---

From: Denis Mcmahon <[email-masked]>
Date: Thu, 21 Dec 2000 19:26:57 +0100

>network resources (in this case, the server) by making them hard to find.

VG gave a specific example of which you give the general case, seems
to me that, at least in this area, you're "disagreeing to agree". :-)

Rgds
Denis
-- 
Denis McMahon              Usenet: Trim quotes
Mobile: +44 7802 468949            Reply at the end
Email: [email-masked]   Don't use html
I trim ng when posting! Email domain blocking in use