Subject: RE: about Wedgelayer 3.5 / Fat IP approaches

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 1 Jul 2004 16:37:58 -0700

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Thursday, July 01, 2004 11:47 AM
> To: marcelo bagnulo braun
> Cc: Erik Nordmark; Henderson, Thomas R; Jukka Ylitalo; Multi6 List
> Subject: Re: about Wedgelayer 3.5 / Fat IP approaches
> 
> 
> > > Example: busy server receives a context from a client 
> with large ID = X
> > > and AID=P1 | hash(X)
> > > Server later receives a context from a client with large ID = Y
> > > and AID=P1 | hash(Y)
> > > and the hash values are identical.
> > >
> > > Even though the multihoming layer can disambiguate the 
> two contexts, it
> > > can not handle both at the same time because the ULP can 
> not tell them 
> > > apart.
> > >
> > 
> > I think that Tom was considering the case were apps have 
> been upgraded 
> > and they are HIP aware (using a new api), so they can actually deal 
> > with the full HIT or even directly with the HI, so they can benefit 
> > from enhanced security.
> 
> But even if the application can do that it doesn't help the 
> TCP from telling
> the two peers with the same AID apart.
> 

If the locators are the AIDs, then there is indeed a problem because
two hosts have the same locator.  Administratively, this might be 
preventable in most cases by forcing a host to pick a new key if 
truncate(hash(key)) matches with another host within that prefix.
However, not in the mobility case, where a host might roam into
a prefix where there is an AID collision.

Anyway, if my m6 layer can differentiate between the two hosts, and
my applications have provided me with more than the AIDs, I don't
see why my transport couldn't work also (perhaps not by the AIDs 
alone, but by some context information passed in the implementation).    

If there is no exchange of larger IDs prior to conversation, then
yes, I agree that one can construct ambiguity scenarios where an
application intends to talk to one host but instead talks to 
another.  The CB64 draft seems to argue that applications can provide
the additional verification if desired (Sec. 4.1 point 7).

So in summary, if the (larger) IDs collide, there is potential for 
ambiguity.  If the IDs do not collide, there is still potential for 
ambiguity if AIDs collide and:
i) applications use AIDs only
ii) applications use larger IDs, but the handshake is delayed or
concurrent, causing the hosts to not be differentiated at the m6
layer by their IDs

Tom

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 2 Jul 2004 06:50:09 -0700 (PDT)

> alone, but by some context information passed in the implementation).    

Yes, with enough thrust pigs can fly :-)

It might not be a good idea to assume that all transports and all middleware
layers of software will be modified to carry some additional context where
they today only carry a FQDN or an IP address.

But since such collisions are supposed to be infrequent,
it might actually make a lot more sense to guard against them.
What harm would be caused in the context of a CGA-like scheme
if a host couldn't at the same time communicate with
two (or more) hosts which have the same 64 bit hash
even though the public keys are different?
As long as the nodes with the same 64-bit hash do not communicate
with the same peer at the same time this would have no ill effect at all.

> the additional verification if desired (Sec. 4.1 point 7).

Section 4.1 point 7 talks about something different; doing the PK crypto check
before any locator change. As specified cb64 relies on the RR check for
the initial setup, and not until there is a locator change does it
end up using public-key crypto. 

   Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 04 Jul 2004 11:16:22 +0200

Some discussion on this thread refers to dependency on HIP.

Question to the WG: given the current state of HIP, do we
want to consider dependency on HIP as

a) acceptable
b) unacceptable?

   Brian (co-chair hat on)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 4 Jul 2004 12:03:58 +0200

> b) unacceptable?

Unless I'm mistaken HIP is still work in progress so that doesn't help. 
Apart from that I have two concerns: the identifier space is flat, 
which can create problems such as with referrals, and HIP as it is 
today requires the use of IPsec, which adds processing and bandwidth 
overhead whether or not this is desired or appropriate for a certain 
communication session.

This leads me to believe that using HIP as-is isn't a very good idea 
for multi6, but it's certainly conceivable that a good multihoming 
solution could be created based largely on HIP.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 05 Jul 2004 09:44:16 +0300

I did not realize we were already in the vote-for-the-solution
stage.

Anyway, I would be OK with the use of HIP as the solution
(or as some component or upgrade path of another solution).

I do agree with Iljitsch that a "light weight HIP" approach
might be something to think about. I believe HIP with ESP
replaced by a flow id (like in some of the other multi6
proposals?) should be doable.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 05 Jul 2004 09:44:20 +0300

> Unless I'm mistaken HIP is still work in progress so that doesn't help. 

Is your intent to choose the multi6 protocol from only those
solution candidates which have already been defined and
completed? Please point me to the RFCs ;-)

--Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Jul 2004 10:39:30 +0200

Jari,

(This also responds to your other message.)

We're not voting on solutions; my question was about
dependencies. Building on an undeployed dependency is a serious
decision for any WG to take, especially one in the Operations
Area.

     Brian

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 5 Jul 2004 02:13:36 -0700 (PDT)

> solution could be created based largely on HIP.

Agree fully.

HIP does provide worked out pieces for some of the components that might be
needed, hence I certainly look at it very closely.
But for the two technical reasons Iljitsch mentions, I don't think
HIP as currently specified fits what we need. I want a multihoming solution
that can allow existing applications to do referrals, and I don't
want to require that every packet be encrypted.

  Erik

   Erik

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 6 Jul 2004 11:49:48 +0200

(co-chair hat off)

> want to consider dependency on HIP as

I have always been under the impression that HIP is aiming for 
experimental. In that case, I think it would be in-appropriate to 
depend on HIP.

- - kurtis -

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jul 2004 16:31:39 +0200

> want to consider dependency on HIP as

There really wasn't much response to this one, but my reading of the
sparse consensus was against solutions that depend on the deployment
of HIP (but that does not exclude taking ideas or components of HIP).

    Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 24 Jul 2004 00:36:43 -0400

Hi Brian,

I saw this question:

>of HIP (but that does not exclude taking ideas or components of HIP).

But, I am not really sure what you were asking or what the answer means...

I do not think that we should, a priori, assume that a multi6 solution will
depend on HIP, NOID, MAST or any other specific mechanism/proposal.
However, I also don't think that HIP should be considered out-of-scope for
consideration as a solution (any more than NOID, MAST or others).

So which way would I answer the question?

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Jul 2004 10:11:24 +0200

> So which way would I answer the question?

Well, that's exactly why I summarized as I did - as so often, the question
was too binary.

     Brian

---

From: Jari Arkko <[email-masked]>
Date: Sun, 25 Jul 2004 21:36:28 +0300

> Well, that's exactly why I summarized as I did - as so often, the question

I agree that the question was too binary. [But I also think
that posing the question at this time is a bit unfair on HIP.
The responses that you got were that its either OK to
use HIP or that HIP lacks feature X or Y which make
it problematic to use it. The problem is, most if not
all proposals in the category of solutions we are
considering have such deficiencies; our task is to
compose or develop a solution which overcomes these
difficulties.]

So, I think we should adopt ideas from HIP/NOID/WIMP/etc
and/or develop one of them further to fulfill all our
requirements. So, in a sense I agree with the second
part of Brian's summary -- but it applies for all of
the potential solutions we have.

But I'm not sure I understand the deployment part. I
mean I agree that we should not hold our breath in
Multi6 while HIP gets deployed. But this is again
similar in all of the solutions. Most of them (with
the possible exception of HIP and maybe some others)
would get deployed only when people install the
multi6 feature on their nodes.

--Jari

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 Jul 2004 00:14:58 +0200

On 25-jul-04, at 20:36, Jari Arkko wrote:

> I also think that posing the question at this time is a bit unfair on 
> HIP. The responses that you got were that its either OK to use HIP or 
> that HIP lacks feature X or Y which make it problematic to use it. The 
> problem is, most if not all proposals in the category of solutions we 
> are considering have such deficiencies; our task is to compose or 
> develop a solution which overcomes these difficulties.

The way I understood Brian's question is: would it be ok to build on 
HIP the same way some proposed solutions build on the DNS, ie., just 
assume that it's there and that it works.

My answer to this was that there are two issues: the first is that HIP 
isn't deployed yet. This will/can be solved in time and propbably isn't 
all that important in the long run. Still, building on HIP _now_ would 
probably make our life more difficult. The second is that HIP as it is 
today has certain properties that are undesirable for a generic 
multihoming solution. (Larger packets and mandatory crypto.) This would 
be like using the DNS but the DNS takes 15 minutes to resolve a query: 
you can build such a solution, but it doesn't address the user needs 
very well..

So basically what we're saying is that we only want to use HIP if it's 
modified to our liking.  :-)  This isn't unfair as we want all the 
solutions to be modified to our liking.  (-:

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 26 Jul 2004 13:38:22 +0300

[Catching up e-mail]

Brian and others,

> of HIP (but that does not exclude taking ideas or components of HIP).

Personally, and as far as I understand the goals for multi6, I don't
think that HIP -- as it is currently being defined -- fulfils the
multi6 goals.  (Some people claim that none of the other solutions on
the table do that either; I refrain to comment since I am too far back
in reading the drafts.)  But anyway, if I do understand your question
correctly, IMHO it is "unacceptable" to "depend" on HIP.

However, I do believe that HIP has a number of components and ideas
that could, if so desired, be reused for the multi6 solution.  I also do
believe that it is possible, again if so desired, to make the eventual
multi6 solution "forward compatible" with HIP.  The latter would
probably required some changes to HIP, but I don't see that as a 
problem.
Anyway, I believe that HIP will necessarily undergo a number of 
incompatible
changes from Experimental to PS, if it ever gets that far.

More importantly, there are a number of important architectural issues
lurking here behind.  These relate to
   a) the nature of EIDs
   b) API evolution
   c) performance penalty and nature of multi-homed applications

a) Firstly, HIP is not only about id/loc split, and
thereby facilitating end-host mobility and multi-homing.  It is also
about moving from using "ordinary" non-crypto-based identifiers towards
using cryptographically strong identifiers, i.e., public keys.
 From an architectural point of view, one can consider this as a
potentially far more important change than moving from IPv4 to IPv6.
This is one of the primary reasons why I do believe that HIP warrants
development of its own, independent of multi6, mobike, etc.

b) Secondly, it starts to look like that we really should start to
think about the API issues more seriously.  As an example, HIP does
support multiple different APIs (IPv4 LSI and IPv6 HIT based currently,
native HIP fairly soon).  Furthermore, it does support (limited)
application interoperability, i.e., simple applications can talk to
each other independent of the API they use.  At the HIP list, we have
been discussing about adding support for IPv6 non-HIT based API to this
list, but a security analysis of that solution is still to be seen.

Looking at the multi6 goals and recent discussion, it looks like that
any acceptable solutions MUST support unmodified IPv6 API, using
routable IPv6 addresses as API level identifiers.  Only that way we
can fully support all existing applications.

To me, it remains an interesting question how to support API evolution.
One architectural possibility would be to use HIP as an example:
  - convert AIDs into EIDs at the API level
  - use EIDs to establish the end-to-end context
  - map EIDs to IP addresses when sending packets out
and, of course, vice versa at the receiving end.  This using of internal
EIDs that are not IP addresses in the protocol layer seems to
offer an evolution path for the API.  (See also the HIP architecture
draft, draft-moskowitz-hip-arch-06.txt, Section 4.1.  Badly formatted,
sorry, but I was in hurry when submitting -06, and xml2rfc was changed.)

c) Thirdly, but perhaps less importantly, it looks like that we should
also take an architectural stance at the performance implications.
Some people seem to have an opinion that requiring one to perform an
authenticating D-H exchange each and every time one wants to use
multi-homing is unacceptable.  But is it really so?  If your application
needs the multi-homing benefits, doesn't that usually mean that it
expects to continue  communication over some time span?  If so, does the
less-than-second delay caused by authenticated D-H really matter?

Related to this, it does look like that we could develop a protocol
where the hosts have a very light weight piggybacked exchange
initially, with reasonable initial security and the possibility to
"upgrade" the context security into authenticated D-H level.  However,
such a protocol is inherently more complex than one where one
always performs authenticated D-H initially.

Hence, to me the question is whether the performance benefit from
the delayed state set up is really worth the added complexity, taking
the nature of multi-homed applications into consideration?

----

Just looking at the multi6 goals and things to think about is of
course right in the multi6 context.  However, to me the "larger"
questions about EID nature and API evolution are perhaps more
important.

--Pekka Nikander

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 26 Jul 2004 12:58:14 +0200

Hi Pekka,

I agree with most of your comments, just a clarification question 
here....

>  - map EIDs to IP addresses when sending packets out

This is how hip works today, right?
i mean in the HIP case:
AID==HIT
EID==HI

I guess that what it seems that we need is to support routable AIDs, 
and provide the means to securely bind them to the corresponding EID, 
right?

regards, marcelo

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 26 Jul 2004 14:41:27 +0300

> This is how hip works today, right?

Yes, more or less.  However, the details in various implementations
are different.

> EID==HI

Yes, with the addition that the AID can also be an LSI instead of a HIT,
and there has been some discussions of allowing the AID to be a
routable IP address of the peer host.

> and provide the means to securely bind them to the corresponding EID,

Well, I think so.  But, at least for the time being, I remain puzzled
about what does the "secure binding" mean, exactly.  Anyway, the AID
is primarily a thing that is internal to the host.  For simple
applications, the AID never leaves the host since the IP address in
the wire is conceptually different from the AID, even if they happen
to have the same binary value.

The problems are created by the desire to be backwards compatible
with referrals and with non-RFC1958-conformant applications.  For them,
the AID needs to be a routable IP address that can be used to reach
the peer.  Hence, for them the AID does appear outside of the host, both
conceptually and in practise.

The security problem is created when the host that uses the AID does
not have a corresponding EID-level association with the peer identified
with the AID.  One needs to have a secure enough way to tell whether the
peer has an EID or not, and if it does, what its EID is.  There are
obviously various approaches in providing assurance, such as using CGA
(and some bit in the address to indicate whether CGA is used or not),
using WIMP, using opportunistic HIP, etc.

I tend to believe that just using some end-to-end protocol might be
secure enough.  That would obviously be vulnerable to man-in-the-middle
attackers, but so is current IP.  However, I am worried about the case
where a MitM attacker hands over a different EID to the initiating host,
thereby creating a false AID-to-EID mapping at that host, and then using
the multi6 protocol to claim that the AID-IP-address is no longer 
reachable.
Such an attack can potentially cause quite a lot of harm, but of course
only if the host can be lured to try to make a contact to the AID.
However, that is easy enough in many cases.

Using CGA based AIDs seems to provide enough security.  However, if
we want to pursue that further, we would have to consider the IPR.

--Pekka Nikander

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 26 Jul 2004 17:06:42 +0200

Hi Pekka,

I include some comments mostly about the reasoning behind your 
conclusions, since i agree with your conclusions

> to have the same binary value.

I am not sure i understand this statement, about AID never leaving the 
host.
I mean, suppose the Host A is communicating with Host B, then Host A 
identifies Host B through its AID i.e. AIDB. So as matter of fact, AIDB 
is not internal to host B, since it is used by Host A (even though 
packets from Host A to Host B don't really carry AIDB in the address 
field of the IP header)
But i guess that you meant something different by that AID never leave 
the hosts...

[Side Note: Also, i think that the AID should be used as IP address 
(i.e. locator) for the initial packets, since i believe it would allow 
to delay the security checks to the moment you need to start using an 
alternative address.
I mean, initial packets just use the AID as the IP address contained in 
the received packet (no additional security checks are required) and 
then if you need to change locators, you start performing more complex.
But this is one step ahead i guess and it doesn't really belong to this 
part of the reasoning]

> using WIMP, using opportunistic HIP, etc.

I think i agree with you, but my reasoning is more focused on the AID 
rather than the EID. I see the EID as being a security tool while the 
AID being the actual identity token. I mean, at the end of the day, 
what we really care is that apps communicate with they think they are 
communicating with.

I am concerned about an attack that would be something along these lines

consider the following situation:

Suppose that we have host A and host B and each one has its EIDA, EIDB 
and AIDA and AIDB

Now suppose they have a mean to securely authenticate the EIDs so Host 
A knows for sure that it is communicating with the owner of EIDB and 
also Host B knows that it is communicating with the owner of EIDA

Now, the point is that the applications only knows the other party of 
the communication through the AIDs, so they will act upon this. for 
instance the application level ACLs will be based on AID, right?

Now a secure binding between the AID and the EID is required here, 
since if not i can easily steal someone's AID (which is AFAICS the 
valid application level identity) as long as i have a valid EID (which 
i can prove ownership of)

That is why i think the problem as providing a secure binding between 
the AID and the EID (assuming that the EID ownership can be easily 
proven because the inherent crypto features of the EID)

As you mention lower, this secure binding can be provided be CGAs or 
other means (like using as AID the IP address used as locator, as long 
no other locator is used)

> However, that is easy enough in many cases.

I fail to see what that mitm role adds to this scenario..  i mean 
couldn't just a random attacker launch this attack? why does the 
attacker need to intercept existing packets for doing this? can he just 
start a new communication with the goal of stealing a given (well 
known) AID?

>
> Using CGA based AIDs seems to provide enough security.

Well, i reach the same conclusion  :-)
CGAs seems a good approach to deal with these issues

>  However, if

Yes.

regards, marcelo

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 26 Jul 2004 21:47:19 +0300

>> ...  Anyway, the AID

Well, as you suggest, lets consider A talking to B.  To be exact, let B
be associated with AID_B, EID_B and IP_B.  Now, in order to be able to
communicate with B, A needs values for the three items.  In the 
_generic_
case, AID_B *may* be locally generated by A, is used only with the API 
in A,
and never leaves A.  As long as we only consider simple applications 
hosted
at A, this works, even if the binary value of AID_B had not whatsoever
relationship with the binary values of EID_B and IP_B.

Hence, from the above PoV, AID_B is internal to A, and never leaves A.
If so, there are no security problems.

Now, if we return to the suggested case where AID_B = IP_B, we bump
into the (security) problems.  We have to be very careful about the
exact details of the semantics.  For example, what does it mean if
a host performs a connect(AID_B) system call,
   a) when B is a Multi6 supporting host, but A has no multi6 
association,
   b) when B is a Multi6 supporting host, but A does have multi6 
association,
   c) when B is not a Multi6 supporting host.
[And the same considerations for all other socket system calls.]

Then you need to consider the attack scenarios, and I think that there 
is
at least    2 * 1.5 * 2 = 6   possibilities, corresponding to
   1: a) B supports multi6          b) B does not support multi6
   2: a) A has multi 6 association, b) A does not have multi6 association
   3: a) attacker simulates multi6  b) attacker simulates non-multi6 host

> I see the EID as being a security tool while the AID being the actual
> identity token.

Well, to me AID is merely a hack to support old badly designed apps.
In the longer run, I would like to see all apps to migrate to use
explicit, public key based or otherwise secure EIDs.

> I mean, at the end of the day, what we really care is
> that apps communicate with they think they are communicating with.

Sure.  But our views do differ in what is our main focus, supporting
current applications securely or supporting future and upgraded apps.
I think we need to do both, but we may need to do compromises on one
class in order to better support the other class.

> [C]onsider the following situation:
>
> Suppose that we have host A and host B and each one has its EIDA,
> EIDB and AIDA and AIDB
>
> Now suppose they have a mean to securely authenticate the EIDs so
> Host A knows for sure that it is communicating with the owner of
> EIDB and also Host B knows that it is communicating with the owner
> of EIDA
>
> Now, the point is that the applications only knows the other party
> of the communication through the AIDs, so they will act upon this.

Sure, but ...

> for instance the application level ACLs will be based on AID, right?

... relying on IP addresses for access control is silly.  Hence, I would
not worry *too* much about it.

> valid application level identity) as long as i have a valid EID
> (which i can prove ownership of)

For simple applications, the AIDs could be generated locally.  In that
case the problem would not exist.  For the case where AID = IP, you
can use return routability, and you get the security to match the
current one, expect that there are future attacks.

> That is why i think the problem as providing a secure binding
> between the AID and the EID (assuming that the EID ownership can
> be easily proven because the inherent crypto features of the EID)

I guess we basically agree, but just look at the problem from slightly
different angles.  As I wrote above, I tend to take the AIDs as 
ephemeral
and locally generated, and consider the AID = IP as a special case.
Maybe that stance is plainly wrong.  You consider the case of AID = IP
being the base line, and argue from there.  For multi6, maybe your
point of view is more fruitful.

> I fail to see what that mitm role adds to this scenario..

The attacks I worry about are various kinds of future attacks; i.e.,
I assume that there will necessarily be an initial return routability
test in the case where  AID = IP.  In order to pass that test, you
have to be a MitM, or at least eavesdrop traffic.

--Pekka

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 27 Jul 2004 04:46:37 +0200

On 2004-07-26, at 17.06, marcelo bagnulo braun wrote:

> I mean, initial packets just use the AID as the IP address contained 
> in the received packet (no additional security checks are required) 
> and then if you need to change locators, you start performing more 
> complex.
> But this is one step ahead i guess and it doesn't really belong to 
> this part of the reasoning]

While you might not have to have the alternative locators verified with 
the initials, having them pre-computed seems more optimal performance 
wise, instead of waiting for failure detection to start the 
verification process. Having to do that if the previously verified 
locators fails at the time of attempted usage seems like something you 
will hae to live with in any case.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 27 Jul 2004 04:24:35 +0200

On 2004-07-26, at 00.14, Iljitsch van Beijnum wrote:

>> that HIP lacks feature X or Y which make it problematic to use it. 
>> The problem is, most if not all proposals in the category of 
>> solutions we are considering have such deficiencies; our task is to 
>> compose or develop a solution which overcomes these difficulties.
>
> isn't deployed yet. This will/can be solved in time and propbably 
> isn't all that important in the long run. Still, building on HIP _now_ 
> would probably make our life more difficult. The second is that HIP as 
> it is today has certain properties that are undesirable for a generic 
> multihoming solution. (Larger packets and mandatory crypto.) This 
> would be like using the DNS but the DNS takes 15 minutes to resolve a 
> query: you can build such a solution, but it doesn't address the user 
> needs very well..
>

I  agree with what Iljitsch is saying, but it might also be important 
to note if we want to give HIP special consideration compared to other 
proposals, as HIP is actually a independent standard being built. I 
don't think that either though.

- - kurtis -

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 27 Jul 2004 11:33:22 +0200

Hi Kurtis,

El 27/07/2004, a las 4:46, Kurt Erik Lindqvist escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>

Yes i see your point.
The tradeoff that we have to consider is:

imposing additional load when no failure occurs (i.e. verification of 
alternative locators and the crypto is before you know you need them)

versus

delaying the recovery the time required for the verification when the 
outage really occurs

An observation:
we can build a solution that supports both modes and leave it up to the 
user policy to decide which mode to use
imho the common situation would be that no failure occurs, so i would 
argue that the default behavior should be performing the verification 
when needed.

regards, marcelo

> - - kurtis -
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.0.3
>
> iQA/AwUBQQXCEKarNKXTPFCVEQLqTgCeKyWAczHATMrTA8GKMCNG59prucEAoNY2
> nQ2fTQZ7ziCf7aNURWxNY1Rd
> =F3Gn
> -----END PGP SIGNATURE-----
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 27 Jul 2004 13:08:52 +0200

El 26/07/2004, a las 20:47, Pekka Nikander escribió:

>> I am not sure i understand this statement, about AID never leaving 
>> the host.
>

I think i see what you mean.
But this locally generated AID does not support referrals of any kind, 
right?

[...]

> explicit, public key based or otherwise secure EIDs.

okey, it is important to define if this is a long term goal that we are 
pursuing

> not worry *too* much about it.

Okey, but suppose that we the multihoming solution is based in cgas, in 
order to be secure and backward compatible at the same time. then 
wouldn't it make sense to make ACLs based on CGAs?

I guess we are back to the long term goal issue here.

If we design a solution that provides CGAs, we are providing the apps 
with a secure-enough AID, so they can start using it as an identifier 
to authorization and so on. This doesn't seems very aligned with the 
goal of having apps deal with the EID directly

[I mean if we move to the hip plane, HITs are suitable to be used as 
identity tokens to perform authorization by apps, do you think that 
appd will start using the HIT or they will move to the HI directly?]

Bottom line, is that if we provide a transition tool such as the CGA 
(which provides security to some degree), this may be an obstacle to 
moving towards the "real" identifier later on.

FWIW i still don't know if a 64 bit long hash is good enough for a long 
term solution, so i kind of like the POV of having a long term ids that 
provide additional security for the future. I am concerned that 
adopting CGAs as a transition mechanism may cause that later on it may 
be difficult to get rid of them.

Regards, marcelo

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 27 Jul 2004 14:19:47 +0300

> But this locally generated AID does not support referrals of any kind, 

Right.

> Okey, but suppose that we the multihoming solution is based in cgas,
> in order to be secure and backward compatible at the same time. then

Well, only for backwards compatibility.  CGAs will be inherently less
secure than the public keys themselves.  Hence, most probably it would
make sense to store either the public keys or longer-than-CGA hashes
of the public keys to the ACL.

> to authorization and so on. ...

I think the goal and means you mention is fine for backwards 
compatibility,
provided that the CGA related IPR issues can be resolved.  Personally,
I'd like to see that happening, but I am not ready to again fight the
IPR battle within Ericsson.  Somebody else must take care of that this
time if the WG would like to see that happen.

> apps will start using the HIT or they will move to the HI directly?]

That questions belongs to the HIP-RG list, not here, and I'll redirect
my answer to that there.

> moving towards the "real" identifier later on.

Well, everything finally depends on your time scale.  I don't believe
a few years or even 10 years delay is necessarily a bad thing...
And as long as CGAs remain secure enough (and there will be a time
when they are no longer) I'm happy if people use them.

--Pekka

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 Jul 2004 12:55:41 +0200

On 26-jul-04, at 12:38, Pekka Nikander wrote:

> think about the API issues more seriously.

Yes. Hence the call for apps feedback earlier.

> can fully support all existing applications.

Unfortunately, this way we also perpetuate the brokenness of the 
current API philosophy.

What I'd like to see is a dual track approach: we do what we can to 
support multihoming for existing IPv6 applications, and we also create 
new, less limited ways to do the same and more.

By also allowing identifiers that aren't routable IPv6 addresses, our 
stuff is much more powerful and futureproof. This means we need some 
more type fields and make some more stuff variable length, but that's 
not very hard. However, security is harder for nonroutable identifiers. 
I don't think we necessarily want to solve that, but if we can create 
hooks for solving this in user space then this is quite easy to add 
later on. (The same way that IPsec needs kernel support for some of its 
stuff but the Racoon IKE daemon is basically a user-level process.)

>  - convert AIDs into EIDs at the API level

I forget what the A and E stand for...

> This using of internal
> offer an evolution path for the API.

Another level of indirection?

I don't think that's the solution. The problem is that applications see 
values that they think are IP adddresses. The first order of business 
is removing the assumption that these are actual IP addresses. This 
can't be done by adding stuff lower in the stack.

> multi-homing is unacceptable.

Please define "use multihoming". If this means once when ISPs are 
connected or once a day or something like that, that's very different 
from having to do it for every TCP session.

> But is it really so?  If your application
> expects to continue  communication over some time span?

The users want to control multihoming, having the application 
specifically ask for it is probably unworkable.

> If so, does the less-than-second delay caused by authenticated D-H 
> really matter?

Maybe yes, maybe no. I'm also worried about the CPU usage, BTW.

At this juncture, I'll observe that we have T/TCP (TCP for 
transactions) which pretty much eliminates the delay caused by the TCP 
three way handshake, but T/TCP is often badly implemented, and, as far 
as I can tell, extremely rarely used. Same goes for HTTP session 
keepalive/reuse.

> always performs authenticated D-H initially.

I'm not worried about this kind of "complexity". Having a bunch of 
simple things is "complex" but workable. It's having a single thing 
that is hard to understand, or a buch of things that interact in 
complex ways that cause problems.

> the nature of multi-homed applications into consideration?

How many different implementations of this kind of stuff are there 
going to be? 10? 25? 100? And how much time is the human race going to 
lose by having to wait for 50 ms for EVERY new session on EVERY 
computer for the next 20 years?

It seems to be in vogue to publish half baked products and then clean 
up the mess later, but nobody ever got fired for getting it right the 
first time...

-- 
The trouble with doing something right the first time is that nobody 
appreciates how difficult it was. - Walt West

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 29 Jul 2004 06:32:11 -0500

Hi, Iljitsch

My confusion remains constant across threads, apparently...
> as I can tell, extremely rarely used. Same goes for HTTP session

Agree on T/TCP, confused on HTTP persistent connections. I'm just
caught on "badly implemented and extremely rarely used".

T/TCP was a brilliant idea that fell into the Grand Canyon of
security - the lack of a three-way initialization handshake opened
T/TCP up to sequence number guessing attacks. I don't have a
mathematical proof of this, but the security community basically
considered T/TCP impossible to secure. So, definitely, "extremely
rarely used".

My experience with HTTP browsers and servers is that early
implementations had problems (off-by-one errors in object sizes that
deadlocked transfers, bad interactions with HTTP/1.0 proxies that
didn't support persistent connections), and after these problems were
fixed, some server operators continued to run "Connection: close" mode
to free up resources for new connections, but the biggest issue I've
seen the last few years is that content may be spread across so many
servers that browsers don't try to keep all the connections open.

Got a pointer to other current problems?

Spencer

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 Jul 2004 14:44:57 +0200

> caught on "badly implemented and extremely rarely used".

I mainly meant that HTTP persistence is also rarely used, I'm not to 
sure about the details. As for T/TCP, don't know about the security 
problems (and don't care for the most part, it's not like I'm going to 
use T/TCP for BGP sessions or anything) but the Linux or BSD 
implementation (I forget which) basically treats T/TCP as a single 
datagram in both directions on steroids rather than regular TCP that 
establishes very quickly, thereby making it impossible to use T/TCP in 
practice for many applications.

> Got a pointer to other current problems?

In this area or in general?

I just wish we could ditch IP altogether and start from scratch...

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 29 Jul 2004 16:10:48 +0300

> current
> API philosophy.

Note, Iljitsch, that I was only referring to existing applications.
I didn't say anything about future or modified applications.
That I took as a separate point.

> I forget what the A and E stand for...

A = Application, i.e., API level and inside applications
E = End-point (in the sense that Noel Chiappa and/or NSRG
     use/used the term)

>> This using of internal EIDs that are not IP addresses
>> in the protocol layer seems to offer an evolution path for the API.
>

Yes, two layers of indirection, in some sense.  AID -> EID -> IP.
In the initial case, for referrals etc, this is used so that
at the beginning of a multi6 association, AID = IP.  However,
understanding that _conceptually_ AID and IP are different things
paves way to API evolution, allowing one to change the nature
of AIDs as the infrastructure evolves.

> I don't think that's the solution.

I don't know whether that is _the_ solution or not, and I am
not arguing either for or against, in that sense.  However,
AFAIK, Tom et al at Boeing have implemented in their HIP code
that particular strategy, and it works.  Hence, it may
be _a_ solution.  It is to the WG to decide, later, what is
_the_ solution.

> Please define "use multihoming".

To me (and I may well be wrong), it looks natural for wedge/layer 3.5
solutions to maintain a host-to-host (or end-point-to-end-point)
state that is relatively independent on transport state.  That is,
such state is probably created on demand on first TCP connection
(or SCTP or UDP or ...) and it stays around some time after all
connections are known to be closed, just in case that there would be
more communication.

But, of course, that does not define "use multi-homing".  With
all respect, I refrain from defining it, as I was using it quite
loosely, on purpose.

> Maybe yes, maybe no. I'm also worried about the CPU usage, BTW.

I agree with you that for some busy servers the CPU load might
be a concern.  Otherwise, I wouldn't be too worried.  Anyway, if
you are using authenticated D-H and you are only worried about
the relative security of your current session, you can choose to
use fairly short keys.

> appreciates how difficult it was. - Walt West

Some people say that there there are two schools in CS in the US.
One is the MIT way, "do the right thing".  The other one is the
UCB way, "just do it".  I don't know whether the saying is true or
not.

In other words, I also see some value on incremental and partial
solutions.  Trying to do it right the first time, in a committee,
may well be pretty impossible.

--Pekka Nikander

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jul 2004 15:40:36 +0200

Actually I think our terminology is tripping us up here.

"Applications"? The network stack is rarely called by
applications. It's called by network adaptation code
built into "lower middleware" such as the Java run time
system, whose job is to hide all this stuff from actual
applications. That's an opportunity - because this lower
middleware can be a super-shim that can do all kinds of
smart things.

"API" has the same confusing implication. We should be
thinking about a more sophisticated network programming
model, indeed, but calling it an API is likely to
restrict our thinking too much.

There is work going on in ICSC (IT-API, http://www.opengroup.org/icsc/)
and DAT (uDAPL, http://www.datcollaborative.org/uDAPLv11.pdf)
which shows that sockets are not sacred.

However, like it or not, multi6 *does* have to deal with
the real world of ULPs that call the current socket API.
That may only be stage 1, but it has to work.

    Brian

Iljitsch van Beijnum wrote:
> Unfortunately, this way we also perpetuate the brokenness of the current 
> API philosophy.
> 
> values that they think are IP adddresses. The first order of business is 
> removing the assumption that these are actual IP addresses. This can't 
> be done by adding stuff lower in the stack.
> 
> At this juncture, I'll observe that we have T/TCP (TCP for transactions) 
> which pretty much eliminates the delay caused by the TCP three way 
> handshake, but T/TCP is often badly implemented, and, as far as I can 
> tell, extremely rarely used. Same goes for HTTP session keepalive/reuse.
> 
> simple things is "complex" but workable. It's having a single thing that 
> is hard to understand, or a buch of things that interact in complex ways 
> that cause problems.
> 
> How many different implementations of this kind of stuff are there going 
> to be? 10? 25? 100? And how much time is the human race going to lose by 
> having to wait for 50 ms for EVERY new session on EVERY computer for the 
> next 20 years?
> 
> It seems to be in vogue to publish half baked products and then clean up 
> the mess later, but nobody ever got fired for getting it right the first 
> time...
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Jul 2004 16:25:42 +0200

Stepping out of the "things to think about" mode...

The only reasonable approach at the API level is to provide a new API 
for any multihomed functionality that would be exposed to the host.  You 
can't simply provide a "compatability API" if you change the identifier 
because the identifier has a semantic meaning to applications today that 
would be misinterpretted if we overloaded it.  For example, think about 
a web log parser that attempts to do a reverse lookup on a HIP 
identifier as a case and point.  Not so hot, right?

Regards,

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 Jul 2004 18:56:54 +0200

> connections are known to be closed, just in case that there would be

I think Marcelo has made it clear that something like this can only 
work securely when there is a strong binding between the identifier and 
the locators, if not the risk of long-time redirection is too big.

But even in a scenario like this and not a per-session one, I'm not 
very comfortable with mandating extra initial delays if they are 
avoidable. (I believe they are in a routable identifier setup (where 
strong bindings aren't easy to come by) but not with unroutable 
identifiers (which need the strong binding anyway).)

> may well be pretty impossible.

The thing is, if you try to do something perfect you're likely to fail, 
but if you try to do something imperfect you're likely to succeed. The 
questions is whether the failed result from the former is better than 
the successful result from the latter.

There are very real costs involved with the additional steps in going 
back to add stuff later. There is no excuse for creating a standard 
with known and fixable (circumstances permitting) flaws, as this 
creates new legacy problems when the problems are fixed in a later 
version.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 Jul 2004 19:00:36 +0200

On 29-jul-04, at 15:40, Brian E Carpenter wrote:

> applications.

Yes, Christian has brought up this point in the past as well.

Still, looking up from layer 3 it doesn't matter much whether we have 
to be compatible with actual applications or Java run time environments 
and Win32 internals. (There is less of that stuff than actual 
applications which makes it a bit easier though.)

> That may only be stage 1, but it has to work.

Agree. We need to think about stages 1+ too is all I'm saying.

> Iljitsch van Beijnum wrote:

Yes I know I wrote it earlier today. No need to repeat the whole thing.