Subject: [RAM] thoughts on draft-nikander-ram-generix-proxying-00.txt

From: Jari Arkko <[email-masked]>
Date: Sun, 04 Feb 2007 10:54:34 -0500

Pekka,

I read your draft.

Overall, I agree with your main message here. I think
we do need both network- and host based mechanisms
for deployment reasons, and they are indeed not all
that different from each other. Your draft helps us
understand the possible approaches better. However,
the devil is in the details and I'd really like to see some
of this worked out in more detail.

Some comments & questions below:

>
>    In this document, we take the stance that in order to be
>    architecturally sound, any layer-injecting solution must eventually
>    be implemented by all hosts, at least in an conceptual sense. ...
>    XXX Elaborate.
>
Perhaps you could elaborate this a bit here on the list.
Do you mean that it must be possible for the hosts to be
in control? Or that it must be possible for us to reach
a situation where the new system is in use by everyone?
What do these things have to do with architectural
soundness?

> 5.1.  Using locators at transport and IP layer
>
>    This approach has received relatively little study.
>
>    One fundamental problem is the need for TCP to resynchronise in the
>    case of locator change.  That is, if the layer above detects a need

Implementing this in a library has not received a lot of
attention, true. But there are of course many applications that
have been built with at least partial capabilities to deal with
changing locators.

>    If the host has
>    multiple interfaces, each interface should be logically configured
>    with the same local IP address, since the goal is to have just one
>    identifier for each host, and all the proxies at the various local
>    paths must perform compatible rewriting.

This seems non-trivial. How would the host know whether
the interfaces are part of the same area served by the
compatible proxies? How would the host select a particular
outgoing interface for its packets?

>    From a logical point of view, this approach can be illustrating by
>    'strething' the host stack to the new middle box.  That is, we split
>    the host stack at the rewriting function (whereever it happens to
>    be), leave everything above at the host itself, and move everything
>    below to the proxy.  This is illustrated in Figure XXX.  Physically,
>    of course, the host stack remains complete and the 'stretching' is
>    performed by the local subnetwork; see Figure XXX.

That you can do this is not very surprising, IPsec, for instance,
works this way. But how easy and clean this is depends
on where exactly the rewriting function is. In the IPsec
case, for instance, you end up having fragmentation in
two places in the stretched case whereas it was only
needed once in host mode.  I hope the proxies will
be very simple, so requiring them to take on some
transport functionality might not be such a great
idea, for instance.

>    We now consider the
>    situation where the goal is to connect a completely 'new' host, one
>    that no longer has direct 'old' connectivity, to a predominantly
>    'old' world.
>
>    ...
>
>    To provide connectivity from 'new' hosts to 'old' hosts, the proxy
>    must implement active DNS proxying.  That is, when a 'new' host makes
>    a DNS query asking for the identity and locators for an 'old' host,
>    the proxy answers with a fabricated identity and its own locators.
>    Correspondingly, when an 'old' host makes a DNS query asking for the
>    IP addresses of a 'new' host, the proxy provides with its own IP
>    addresses.

Right, but you made one big assumption above, namely
that the new hosts are completely disconnected from the
old Internet. If the identifier space is syntactically same
as the current IP space (e.g. orchids) then new hosts
should be able to use peer's address directly, similar to
what NATs do currently. The new host's own address,
however, is a different matter.

> 6.5.  Un-proxying in the 'in-the-network' approach
>
>    In the same spirit but in the reverse fashion, the 'in-the-network'
>    or jack up approaches can be implemented within the host instead of
>    in a separate box.  In this case, we 'squeeze' the local subnetwork
>    into the host itself, making it to physically disappear.

Interestingly, in this case the host would perhaps have
just one interface as far as the original IP stack is concerned,
but multiple interfaces below the jack-up shim. The host
would then be able to make multihoming decisions.

>       The easiest case is when the identifiers are fully routable, like
>       in SHIM6.  In that case there are few limitations where and how
>       the proxies can be located at, as long as they are on the default
>       path between the 'old' and 'new' hosts.  For example, each site
>       exist could be equipped with a SHIM6 proxy, knowledgeable about
>       all the other prefixes the site has, and being able to redirect
>       the traffic on demand.

This is interesting. Is there a draft or more details about this?

> 8.  Security considerations
>
>
> 9.  Discussion

Something missing here, obviously.

I would be particularly interested in hearing what the
details are for, say, HIP-like network-based implementation.
If hosts are given true identifier space to work on, wouldn't
that mean that they "own" the identifiers and associated
public keys? How would this enable the proxy to perform
operations on the identifiers, such as claiming that the
identifier is now reachable at a new locator? Or is there
some delegation involved? Or would the identifiers be
"owned" by the proxy, and the hosts see merely local
address space?

>    Respectively, 'network' based approaches grow from the assumption
>    that the hosts cannot be trusted (as, e.g., they may be compromised)
>    and therefore it is better for the network to provide the
> functionality.

I think we need to be a bit careful here. What we are talking
about is functionality that affects how packets for a given
host are delivered. Even when we implement everything
in the network, the host is still left with an ability to, for
instance, decide with who, when, and how much to
communicate, what interface to use, what identifier to
claim for itself. Is there a real difference in terms of
vulnerabilities?

Jari

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

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 8 Feb 2007 09:42:40 +0200

Jari,

Thanks for taking the effort to read the draft, even in its early form.

> What do these things have to do with architectural

Hmm.  I may not have completely cleared my mind here yet, so take the  
following with a grain of salt.

My thinking starts from the desirability of having identifiers for  
end-points, i.e., in the most typical case, nodes.  In my thinking,  
these identifiers should be location and interface independent.  So,  
with "architectural soundness" I intend to refer to a situation where  
this has been achieved, and where the hosts indeed are, or at least  
can be, in primary control of their identity, independent of their  
network attachment.

This comes from the standpoint of the draft, that implementing  
identifier/locator split is _the_ approach.

Now, there is certainly another possible approach to the routing  
scalability problem: hierarchy or recursion.  That is, you keep the  
TTLLAA that the application see as locators, but only as locators  
that have local locality.  I haven't read the LISP draft, but based  
on Brian's comments on it, it seems to go to that direction.  Hence,  
the main message of the generix draft may not apply to it.

> have been built with at least partial capabilities to deal with

Indeed.  But they all must make for the case that they may not know  
whether the last data sent on the previous TCP connection reached the  
destination or not.

> outgoing interface for its packets?

The text clearly needs here some clarification.  But you are right,  
that is hard in the generic case.

However, what I had in mind was a legacy host that assumedly sits in  
a corporate network.  In that case I don't think it unreasonable to  
expect compatible proxies.  I agree that if you consider a multi- 
interface mobile host (such as a laptop) the expectation would be  
unreasonable.  However, I fail to see how you could fit such a host,  
with a legacy stack, to the "new" world anyway.  That is, in such a  
case I cannot see how you can provide the upper layer protocols with  
a unique identifier without changing the stack.  Maybe there is a  
way, but it just evades me.

> transport functionality might not be such a great

I agree.

> old Internet.

Indeed.

> If the identifier space is syntactically same

Yes.  That case is covered later, in the "Stretching the wire" section.

> would then be able to make multihoming decisions.

Indeed.

> This is interesting. Is there a draft or more details about this?

I am not aware of any draft in that space.  However, to me, the only  
more complex problem seems to be security.  But maybe I just fail to  
see some routing or co-ordination problems there.  In the SHIM6 case  
security can be taken care of with CGAs and explicit public key based  
delegation.

> Something missing here, obviously.

Yep.  :-)  I indicated that in the beginning of the draft.

> details are for, say, HIP-like network-based implementation.

As you might remember, there is a spec for the 3GPP HIP proxying case  
from the work we did two years ago, but that's not in an I-D format.   
The same idea can be easily extended to other networks.  I guess  
Petri or someone could convert and generalise the text, if needed.

> public keys?
> How would this enable the proxy to perform

Both are possible, depending on your trust assumptions.  You can  
arrange it in such a way that the "proxy" "owns" the identifiers, and  
assigns them (e.g. via DHCP or PPP) to the hosts.  That was the  
method we used .

In the case the host "owns" the identifier, you indeed need delegation.

> claim for itself. Is there a real difference in terms of

I don't see any real difference in the vulnerabilities, but a) I  
haven't done any proper analysis and b) there are other people that  
see (or at least think they see) there a difference.

--Pekka

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 08 Feb 2007 07:19:04 -0600

Hi, Pekka,

I may be slightly confused here, but I'm seeing either imprecise words or an 
oncoming train, so I need to ask...

> whether the last data sent on the previous TCP connection reached the 

Umm, for all values of id/loc discussion I've been involved with, there 
might be a previous TCP PATH, that is now changing, but there is no previous 
TCP CONNECTION.

If this discussion goes in a direction where there is a different TCP 
connection, that's not good.

The idea behind SHIM6 was that the TCP might see amazing changes in path 
characteristics, and might even have to do what TCP does anyway (discard 
duplicate packets, process out-of-order packets, and request retransmission 
of packets that don't seem to be making it to the far end, for whatever 
reason), but there would not be another SYN-SyN-ACK-ACK exchange.

The idea was that the application using this connection would be either 
unaware of a change in path characteristics (most TCP-based applications 
would be), or at most mildly irritated that the path characteristics changed 
(but they are changing because there's no choice).

If there's a new TCP connection, we can do that today. The idea as I 
understood it was to keep path-change complexity in TCP, and not in the 
applications using TCP.

I'm probably overreacting, but I've spent way too many years talking to 
people who went through all kinds of contortions to make sure that "all the 
packets in-flight at cellular handover time are also handed off to the new 
path", etc. Given that we can't be perfect, the endpoints have to handle 
these problems anyway, and letting TCP do what TCP will do anyway is a lot 
easier than figuring out what packets actually got there on the other path, 
given that we can be changing networks, and changing link technologies (WiFi 
to GPRS being a classic example).

Like TCP itself, I'll shut up now, and let the network-layer guys go back to 
doing network-layer stuff :-)

Thanks,

Spencer

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Feb 2007 18:06:08 +0200

Spencer,

Pekka and I were merely making the observation
that there exists a body of applications that do
these kinds of things -- not making any statement
about how desirable that state of affairs is. I
agree with your analysis of the issues.

Jari