Subject: [rrg] Rejecting all but Strategy A

From: Robin Whittle <[email-masked]>
Date: Sat, 03 Jan 2009 17:54:34 +1100

Short version:     We should reject Strategy B.  (I think no-one
                   argues against rejecting C and above.)

                   It would make no sense to recommend the IETF
                   actively develop such a scheme, even if we
                   thought it was desirable to push responsibility
                   for multihoming etc. to hosts, since:

                   1 - There are no substantial Strategy B proposals
                       while there are several substantial Strategy A
                       proposals.

                   2 - All possible Strategy B solutions have much
                       steeper barriers to widespread adoption than
                       any Strategy A solution, since all Strategy
                       B solutions involve changes to host stacks
                       and applications (as well as most or all
                       networks abandoning IPv4 in favour of IPv6)
                       and because Strategy B solutions only provide
                       multihoming etc. when both hosts are upgraded.

Our task is to recommend one (or more than one?) architectural
solutions to the routing scaling problem, to be developed further by
the IETF.

I believe we should recommend one or more architectural solutions
which both:

1 - Show good promise of being able to solve the problem, if widely
    adopted.

2 - Show good promise of being very widely adopted.

    We need close to 100% adoption.  50% or 95% isn't good enough,
    since those end-user networks which want multihoming and don't
    adopt the solution will continue to use the PI and BGP approaches
    to multihoming.  We can't enforce a solution - it has to be
    attractive to virtually all end-user networks which want
    multihoming, TE and portability.  This means end-user networks of
    all types and sizes.  These networks don't necessarily care about
    routing scaling - so the solution must provide immediate,
    substantial benefits over whatever costs, risks and disruption
    the solution involves.

Strategy A solutions are all "core-edge separation schemes".  Apart
from Six/One Router's inability to work with IPv4, they all have a
chance of meeting these two criteria - although opinions vary on
which proposal meets them both best.

I believe there is such a sharp distinction between the Strategy A
and Strategy B proposals that we should only seriously consider
Strategy A proposals for recommendation to the IETF.

How well could Strategies A and B resolve the only scaling problem we
currently have - IPv4's?

  Most of the Strategy A proposals (LISP-NERD, LISP-ALT, APT, Ivip
  and TRRP) are intended to work with IPv4.

  Strategy B proposals cannot help with the IPv4 routing scaling
  problem because there is not enough space for each multihomed
  end-user  network to be given a prefix by each of its two or more
  ISPs.

How many reasonably well documented proposals are there?

  Strategy A:   Six: LISP-NERD, LISP-ALT, APT, Ivip, TRRP and Six/One
                     Router.

                (However, I am not sure that Six/One Router is still
                being actively developed.  There have been no
                updates since my critique in July 2008.  The last
                update to the LISP-NERD I-D was April 2008.
                Six/One Router has no mapping system and TRRP
                documentation is minimal.)

   Strategy B:  There are no properly documented proposals.

                ILNP may be a Strategy B approach but it is not
                properly documented as a scalable routing solution.
                There is no Summary and Analysis in the RRG wiki.

                HIP has been mentioned, but no-one seems to be
                proposing it as a scalable routing solution.

Every possible Strategy B approach would be vastly harder to have
adopted by the majority of end-user networks which want multihoming,
TE and portability (or its functional equivalent) than any Strategy A
approach, for at least two reasons:

  1 - Strategy B solutions require most or all current Internet users
      to adopt IPv6 - and furthermore IPv6 with a modified host
      stack, API and applications.

  2 - Strategy B solutions provides benefits to adoptors only when
      the other host in a session (stack and relevant applications)
      has been upgraded too.  So until almost all networks and their
      hosts adopted it, the scheme could only provide multihoming for
      a fraction of communication sessions.

Also, I argue that any approach which involves pushing
responsibilities and management traffic to all hosts (all potential
Strategy B approaches) is fundamentally flawed:

  http://www.irtf.org/pipermail/rrg/2008-November/000233.html

I find it impossible to imagine how a Strategy B solution could
succeed if we fail to solve the problem via the best one or more
Strategy A solutions being properly developed and offered for adoption.

RRG rejection of Strategy B solutions is not to suggest that people
shouldn't work on such schemes.  Just that we have no confidence that
any such scheme could turn out to be technically better and/or easier
to have widely adopted than a well developed version of the best of
the Strategy A schemes.

Of course, if the best efforts with Strategy A schemes fails, then
everything would be up for reconsideration.  However, that is a
potential scenario in the post-2020 future.  Then, any Strategy B
solution would still involve much higher barriers to development and
adoption than any Strategy A solution.

 - Robin
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Jan 2009 09:39:31 +1300

On 2009-01-03 19:54, Robin Whittle wrote:
> Short version:     We should reject Strategy B.  

For the record, I disagree, for reasons given earlier.
However, that doesn't mean we shouldn't recommend that a
strategy A approach be brought to fruition. There's no
reason why this group is limited to a binary choice.

<snip>

>   end-user  network to be given a prefix by each of its two or more

Correct. And is it unthinkable that the fix for IPv4 (which is running out
of addresses) should be different from the architecture for IPv6 (which
isn't)? On the contrary, it would be very strange if the solution was the
same.

<snip>

>                 There is no Summary and Analysis in the RRG wiki.

It's unclear to me that ILNP belongs in B since it has characteristics
of A as well. Whether it's jumped through the hoops of the wiki strikes
me as uninteresting; it seems to be well documented.

>                 proposing it as a scalable routing solution.

I think Pekka observed that this wasn't even a goal. (My quick answer
is that it only becomes a routing solution if it solves the same
mapping problem that strategy A generates.)

Shim6 has also been mentioned, as a mitigation of some the issues
with the multiprefix PA model. That is already chartered IETF work
with full documentation.

>       stack, API and applications.

The first half of this is increasingly likely to happen anyway. It isn't
certain that the API and apps have to be touched; rolling out new stacks
over five to ten years really isn't a valid objection.

But I fully agree: strategy B == IPv6.

>       a fraction of communication sessions.

This is true. The question is whether this (piecemeal incentives, highly
distributed low costs) is really less effective than the incentives to pay
the highly concentrated per-network costs of strategy A.

>   http://www.irtf.org/pipermail/rrg/2008-November/000233.html

Highly distributed = scaleable. And in any cases, hosts have always
been responsible for traffic management (that's called TCP)
and approaches like SCTP and the proposed multipath TCP extend that.
So I don't think we should condemn this in the abstract.

> adoption than any Strategy A solution.

Exactly. Which is why my preference is to recommend development work
on strategy A and continued R&D on strategy B; I'd be very concerned
if we shrugged our shoulders and dropped it for 12 years.

    Brian

---

From: Robin Whittle <[email-masked]>
Date: Mon, 05 Jan 2009 20:16:03 +1100

Short version:   I broadly agree with Brian's "... my preference is
                 to recommend development work on strategy A and
                 continued R&D on strategy B."

Hi Brian,

Thanks for your detailed response.

> mapping problem that strategy A generates.)

I don't understand your comment, but if the HIP proponents do not see
it as a solution to the routing scaling problem, then unless someone
on the RRG feels strongly that it is, then HIP is out of scope for
discussion and for matching against any of Bill's architectures.

> with the multiprefix PA model. That is already chartered IETF work

Yes - and Shim6 matches Bill's Strategy G:

  http://bill.herrin.us/network/rrgarchitectures.html
  http://www.firstpr.com.au/ip/ivip/rrgarch/

> The first half of this is increasingly likely to happen anyway. 

So people have been saying since 1996.  I will believe it when I see it.

> It isn't certain that the API and apps have to be touched; rolling out new 
> stacks over five to ten years really isn't a valid objection.

I agree that if only the stacks need to be changed, then that would
be a much lower impediment - especially with IPv6 which is hardly
used at present.

ILNP supposedly requires no API or application changes - but as far
as I can see, it won't handle referrals, or at least won't provide
multihoming for referrals.  Ran suggests rewriting apps to avoid the
need for referrals.  I think this would be a major barrier to
adoption.  My next two messages concern ILNP.

Would SIP need to be changed to avoid referrals or to do the same
thing in ILNP-friendly ways?

> But I fully agree: strategy B == IPv6.

OK.

> the highly concentrated per-network costs of strategy A.

With Ivip, I anticipate that the businesses which provide the mapping
service and who rent out Mapped Address Blocks, splitting them up
into thousands of smaller pieces for end-user networks to split
further into micronets (EIDs) will be offering a valuable service
from the start.  This is because Ivip supports multihoming, TE and
portability, including for all packets coming from hosts in
non-upgraded networks.  I expect this to be a profitable business,
not some cold, dead, thing we reluctantly put millions of dollars
into in order to avoid a future DFZ meltdown.

> So I don't think we should condemn this in the abstract.

Yes - but the existing host functions (with the possible exception of
some of SCTP's functions) are all coping with things which must be
handled in the hosts.

Multihoming, TE and portability can be handled in the network,
without touching the hosts or burdening them with the resulting
management traffic.

I think ILNP is not an exact match for Bill's Strategy B, but it is
close enough for general discussion.  That adds a lot of state to
each host for every IP address the host communicates with.  There is
extra management traffic, in the form of longer DNS responses and
sending and receiving Nonce Destination Options.  That requires more
code to handle the resulting PMTUD problems, and as far as I can see,
will restrict the maximum packet length any application can send to
20 bytes less than whatever it would otherwise be.

I think ILNP is an absolutely minimal proposal.  If fully developed,
it would need to be more complex, I am sure.

HIP is another potential host-based approach, though it too does not
seem to match Strategy B directly.  HIP is much more complicated,
with every host being required to do fancy cryptography, and there
being several RTTs of exchanges between two hosts before any real
work can be done.

  http://infrahip.hiit.fi/index.php?index=how

A fully developed HIP would involve multiple cryptography options,
further increasing complexity.

I stand by my objections to forcing such complexity and extra traffic
onto every host in the future IPv6 Net - for things which happen in
the network and can best be handled there: multihoming, TE and the
need for portability as the only reasonable way (for all but the
smallest networks) of selecting a new ISP without major costs and risks.

> if we shrugged our shoulders and dropped it for 12 years.

OK.  I agree - except I guess we will recommend something more
specific than any architecture which fits Bill's Strategy A definition.

My notion of the RRG rejecting Strategy B - and any other comparable
elimination schemes which involve new host functionality and
management traffic - is that we are rejecting the notion of
considering any such scheme for recommendation to the IETF for
development in order to solve the routing scaling problem in the
foreseeable future.

The RRG not recommending any such architecture for IETF development
is not a message to developers to stop working on such things.

  - Robin

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 5 Jan 2009 19:40:49 +0200

> discussion and for matching against any of Bill's architectures.

To clarify what I have already stated:  As far as I can see, HIP was  
never meant to be a solution to the RRG problem (HIP started in 1999,  
RRG around 2006 IIRC).  HIP is an architectural change, and its  
official IETF status is, if I understand correctly, "ongoing  
experiment".  People are encouraged to run HIP in the Internet and  
report any experiences to the HIP-RG.  There are open source  
implementations for Linux, FreeBSD, Windows, and Mac OS X.

As a protocol and architecture, HIP is basically ready; it has been so  
for 1-2 years now.  There are a few open loops, such as the details of  
NAT traversals, but they are gradually being closed. There has also  
been some discussions on reopening the discussion of whether it should  
re-chartered for standards track, but I have only heard rumours, not  
been active myself.

What comes to HIP and RRG, I do believe that HIP *could* help in  
solving the RRG problem.  It *could* form a core for what people now  
call "Strategy B" solutions, and a HIP-proxy based solution *could* be  
deployed as a "Strategy A" solution.  I don't know the details of  
LISP, but the recent discussion between Dino and me seem to indicate  
that HIP proxy and LISP xTRs are functionally close enough so that a  
HIP proxy could be "plugged in" to the LISP architecture, yielding a  
"Strategy A" HIP-based network-level solution that could eventually  
lead to full HIP deployment at all hosts, which *could* lead to an  
architecture where renumbering is never needed due to full transparent  
support of multiple IP addresses at all hosts.

But, obviously, developing a HIP-based RRG solution would require  
work.  Few if any HIP folks are active at the RRG, AFAIK.  So, there  
doesn't seem to be anyone who would be interested enough to invest the  
time and effort.  (For example, I don't normally have enough of time  
to browse the RRG ML...)

--Pekka

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Jan 2009 09:44:24 -0800

> call "Strategy B" solutions, and a HIP-proxy based solution *could*  
> be deployed as a "Strategy A" solution.  I don't know the details of  
> architecture where renumbering is never needed due to full  
> transparent support of multiple IP addresses at all hosts.

And since I don't know the details of HIP-proxy, saying LISP and HIP- 
proxy are functionally equivalent only occurs at a conversational  
level. The devil is in the details of course.

Dino

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 5 Jan 2009 12:13:20 -0800

>From: Dino Farinacci [mailto:[email-masked]] 
>>From: Pekka Nikander
be 
>> architecture where renumbering is never needed due to full
transparent 

>proxy are functionally equivalent only occurs at a conversational
level. 
>The devil is in the details of course.

I strongly resonate with Pekka's posting.

Speaking solely for myself, I view LISP's original claims to be a
locator-identifier split to be a redefinition of what those terms have
historically meant (i.e., to be marketing -- not reality). By contrast,
HIP is a true locator-identifier split technology in every sense of the
historic meaning.

LISP, by contrast, is a map-and-encaps solution to the RRG problem.

There is no necessary relationship between HIP (or any other
locator-identifier split) and LISP (or any other map-and-encaps).
Specifically, I believe that locator-identifier splits are a session
layer concept and therefore are primarily host-related. I believe that
map-and-encaps is primarily a network layer concept.

By combining a true locator-identifier split (i.e., HIP) with a
map-and-encaps (e.g., LISP) one gets the combined benefits of both
approaches. Those benefits are

*  For HIP-based applications (i.e., hosts) this creates a full
decoupling of application issues from network issues. This
simultaneously solves many different problems including the following: a
transparent solution to application multihoming; complete agnosticism
concerning network issues including IPv4 or IPv6; strong session
coherence in the face of substantial mobility; solution to the "IP
identity problem", thereby solving a great many festering security
issues including a clean integration with IPsec, providing
best-current-practice Denial-of-service (DoS) attack resistance,
exponentially increasing the ability to identify and defend against
spoofing attacks, substantially increased protection against session
hijacking, and (by solving the identity problem) making existing
application authentication and authorization systems become more viable.
*  HIP also provides a formal (secure) delegation capability that
permits HIP users (e.g., hosts) to delegate authority to other entities
to act on their behalf. This would, for instance, allow a host that
wants to hide its current location to use network proxies to forward its
traffic. For example, DoS attacks could also be deflected to network
proxies.

*  For map-and-encaps based systems this provides a scalable network
integration capability to resolve a wide variety of different network
scalability and integration challenges including: 
1) IPv4-IPv6 coexistence: ISATAP, Teredo, IPvLX, etc.
2) Military Communications Security (COMSEC)
3) IPsec's ESP in tunnel mode
4) L3VPN (including how my employer relates to our ISPs (please note the
plural))
5) ecommerce
6) ARINC 664 enclave protections
7) Architectures that leverage IP to join together distributed legacy
(i.e., non-IP) protocol systems. It is also used to merge legacy
populations into IP networks (e.g., RFC 1006).
 
--Eric

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 Jan 2009 13:27:18 -0800

>-----Original Message-----
>From: Fleischman, Eric
>Sent: Monday, January 05, 2009 12:13 PM
>To: Dino Farinacci; Pekka Nikander
>Cc: RRG; Robin Whittle
>Subject: Re: [rrg] Rejecting all but Strategy A
>
>
>

Pekka, is "HIP-proxy" and "HIP mobile router" one and the
same thing? If so, IMHO it is absolutely realistic that the
HIP-proxy and xTR could occur on exactly the same platform.
Note that they are complementary functions, however; not
competing ones. I think this also goes with what Eric was
saying below?

Fred
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Jan 2009 14:01:20 -0800

Before we get carried away with what looks like a convergence of "HIP- 
proxy and LISP", tell me what HIP offers to a LISP router that the  
LISP architecture does not already provide?

If is solely a add a pure definition to IDs and RLOCs, then I think  
it's not worth the cost of deployment to do so.

Dino

On Jan 5, 2009, at 1:27 PM, Templin, Fred L wrote:

>> simultaneously solves many different problems including the  
>> following:
> a

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 Jan 2009 14:05:52 -0800

Dino,

>Sent: Monday, January 05, 2009 2:01 PM
>To: Templin, Fred L
>Cc: Fleischman, Eric; Pekka Nikander; RRG; Robin Whittle

I was actually saying convergence of "HIP-proxy and xTR";
xTR does not necessarily mean LISP.

>it's not worth the cost of deployment to do so.

In my understanding there's a lot more to it than that,
but would welcome clarifications.

Fred

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Jan 2009 14:12:23 -0800

> HIP is a true locator-identifier split technology in every sense of  

Well IDs are used for TCP/UDP socket endpoint demuxing. And RLOCs are  
according to the original definition. But we extended to have IDs  
*also* be routable inside of a site. We had to for incremental  
deployability. We don't want to force renumbering of all site-based  
hosts, switches, routers, firewall devices, etc.

> LISP, by contrast, is a map-and-encaps solution to the RRG problem.

With LISP, you can move a host to a new RLOC while keeping a TCP  
connection up. That is the EID does not have to change for the host.

> map-and-encaps is primarily a network layer concept.

Definitely agree on session-layer concept.

> approaches. Those benefits are

But you add another layer of addressing that is probably more than the  
user wants. It could get this bad:

  HIT -> EID -> private-RLOC -> public-RLOC    when behind a NAT

or

  HIT -> private-EID -> public-EID -> RLOC     when behind a NAT

2-levels of mapping is plenty, adding 2 more probably is a non- 
starter. Remember folks, we have to incrementally deploy this with  
minimal cost, see Yakov's post early today, he makes good points.

> following: a

And it cleans your dirty dishes as well. ;-)

Eric, care to quantify the cost of deploying all this machinery?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Jan 2009 14:14:06 -0800

> xTR does not necessarily mean LISP.

Sorry, I'm not going to let you off that easy. If you don't define xTR  
then you can't way what or what not HIP-proxy can offer it. Because  
"it" might already have the feature, but since you don't want to be  
concrete, you leave it all open ended. Which makes for a non- 
productive conversation.

> but would welcome clarifications.

Well there really isn't. It's just this list that makes a mountain out  
of a mole-hill.

Dino

>>>> wants to hide its current location to use network proxies to  
>>>> forward
>>> its
>>>> 4) L3VPN (including how my employer relates to our ISPs (please  
>>>> note
>>> the
>>>> plural))
>>>> 5) ecommerce

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 5 Jan 2009 14:25:45 -0800

Dino,

>Sent: Monday, January 05, 2009 2:14 PM
>To: Templin, Fred L

All I am saying is that HIP can run over a tunnel virtual
interface (on an "xTR") just the same as it can run over
a physical interface. How the xTR makes its mapping and
encapping decisions to send things over a tunnel virtual
interface is largely orthogonal wrt what HIP brings.

>Well there really isn't. It's just this list that makes a mountain out

No; there really is. For example, that is why I asked
Pekka about HIP mobile router.

If a HIP proxy can do mobility signaling on behalf of
end systems, then that is beyond the capabilities being
offered by just the map-encaps solution.

Fred

>>>>> HIP is a true locator-identifier split technology in every sense
of

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 5 Jan 2009 15:17:19 -0800

Dino,

I don't know the operational cost of HIP in stable networked
environments because our many laboratory experiments have focused on
very high mobility environments where the HIP overheads are trivial
compared with the multiple advantages of using HIP (i.e., without HIP
the applications become very brittle). 

We have operationally deployed HIP as a basis for securing our
IP-connected SCADA machine controllers in our factories. This is the
most viable way to secure IP networked-attached SCADA devices that we
know about. Again, the operational costs of doing this are trivial
compared with the risks with leaving these machines inadequately
secured. 

I myself am not aware of the NAT impacts to HIP though I have noted (but
not yet read) the existence of a HIP I-D on that topic (see
http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-05.txt)
. I suspect that you are overstating the problems with NATs because HIP
has proven to be surprisingly clean and the HIP proxy capability is
powerful. However, I myself have not envisioned using HIP in
environments having NATs except for the narrow context of overcoming
ARINC 664-based limitations impacting aircraft's generic (public) IP
addresses.

By contrast, the more significant issue in civil aviation is whether the
aeronautical air-to-ground and air-to-air networking will occur within
the context of VPNs (i.e., hierarchical routing/addressing systems
perhaps resembling military COMSEC; e.g., each VPN domain perhaps
associated with a specific ARINC 664 intra-aircraft partition) or
whether the civil aviation addressing/routing will alternatively be a
common (flat) system with the intra-aircraft partitions accomplished by
air-gaps and firewalls.

--Eric

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Monday, January 05, 2009 2:12 PM
To: Fleischman, Eric
Cc: Pekka Nikander; RRG; Robin Whittle
Subject: Re: [rrg] Rejecting all but Strategy A

> historically meant (i.e., to be marketing -- not reality). By 
> contrast, HIP is a true locator-identifier split technology in every 
> sense of the historic meaning.

or

2-levels of mapping is plenty, adding 2 more probably is a non- starter.
Remember folks, we have to incrementally deploy this with minimal cost,
see Yakov's post early today, he makes good points.

Dino

> permits HIP users (e.g., hosts) to delegate authority to other 
> entities to act on their behalf. This would, for instance, allow a 
> host that wants to hide its current location to use network proxies to

> forward its traffic. For example, DoS attacks could also be deflected 
> to network proxies.
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Jan 2009 15:49:44 -0800

> ARINC 664-based limitations impacting aircraft's generic (public) IP

I am not making a claim or judgement call about HIP with NATs. I was  
making a statement about HIP coupled with a map-n-encap scheme with  
NATs.

Dino

> starter.

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 7 Jan 2009 13:29:48 +0200

I (Pekka) wrote:
>>>> I don't know the details of LISP, but the recent discussion  
>>>> between Dino and me seem to indicate that HIP proxy and LISP xTRs  
>>>> are functionally close enough so that a HIP proxy could be  
>>>> "plugged in" to the LISP architecture...

Dino replied:
>>> And since I don't know the details of HIP-proxy, saying LISP and  
>>> HIP-proxy are functionally equivalent only occurs at a  
>>> conversational level.  The devil is in the details of course.

Which make Fred to ask:
> Pekka, is "HIP-proxy" and "HIP mobile router" one and the same thing?

Briefly, a "HIP-proxy" (as I understand the term) could be implemented  
as a version of the "HIP mobile router" (draft-melen-hip-mr-01.txt)  
that has the additional feature of being able to support unmodified  
legacy IPv4 and IPv6 nodes in the mobile network.  For such legacy  
nodes, the MR node would create ephemeral HIP identities and assign an  
IP address in the moving network side for each identity.  Hence,  
typically, the legacy host would get a single stable the IP address  
through DHCP or ND, in which case the MR would act as the DHCP or ND  
server.  OTOH, there is no need for the MR to actually be mobile --  
the mobility aspect could simply refer to its ability to use  
interchangeably multiple PI addresses.

So, I guess my answer is a qualified "no".  They are not the same  
thing, though they could be close.

One old, outdated description of the HIP proxy functionality is  
available as Patrik's MSc thesis at http://www2.cs.hut.fi/~pmrg/index.cgi?id=148 
    But that is basically 4 years old and concerns only the case where  
there is a 3G legacy network, not generic legacy networks at both  
sides.  Quite obviously, the thinking has evolved quite a lot since  
then.

> If so, IMHO it is absolutely realistic that the HIP-proxy and xTR  
> could occur on exactly the same platform.  Note that they are  
> complementary functions, however; not competing ones. I think this  
> also goes with what Eric was saying below?

I don't see any problem at all in installing a HIP proxy and xTR at  
the same box -- they could even use the same mapping infrastructure to  
find out the RLOC of the peer HIP proxy/xTR, and then in parallel send  
an opportunistic HIP I1 and whatever LISP sends when an xTR contacts  
another xTR that it has no prior association with.  But that would be  
a (minor) waste of resources as two packets would be sent in parallel.

Initially, what I think would be interesting to understand is the  
possibility of two additional designs:

1. One where the LISP xTR-xTR protocol is replaced with the HIP  
protocol (providing the additional mobility and security features HIP  
provides).

2. One where the initial xTR->xTR opening message is a hybrid that  
indicates that the sender understands both LISP and HIP, allowing the  
receiver to pick which one to use.

And then I could imagine a few designs beyond either...

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 7 Jan 2009 13:47:04 +0200

On 6 Jan 2009, at 00:01, Dino Farinacci wrote:
> Before we get carried away with what looks like a convergence of  
> "HIP-proxy and LISP", tell me what HIP offers to a LISP router that  
> the LISP architecture does not already provide?

I don't know what LISP already provides, so the following are mere  
guesses.

- Security?  Both opportunistic, no-infrastructure-requiring security  
for multi-homing/mobility, and baseline-level signalling security for  
integrating any security infrastructure you want (such as PKI, AAA, ...)

- Mobility?  As HIP proxy can be trivially integrated with the HIP  
mobile router (MR), the legacy networks can be mobile without any  
extra effort.  (Provided that the mapping infra has the required  
updating capability...)

- Ability to move more cleanly to a host-based solution, better  
serving mobile and multi-interface hosts.  This includes the ability  
to support upgraded hosts in the legacy networks.

Obviously, the next question is what the drawbacks would be.  Here is  
my initial list:

- Crypto.  Current HIP requires PK crypto (but no PKI!) and ESP.  LHIP  
(which uses only hash functions) is an option if people generally shun  
PK, and, as I already explained, ESP can be replaced with any  
tunnelling or flow-identifying protocol.

- Lack of operational experience.  AFAIK, only Boeing has operational  
experience on HIP.  I guess there is more operational experience  
available on LISP, even though I haven't seen any.

(I am sure there are others, but I cannot figure out any other  
drawbacks right now.)

> it's not worth the cost of deployment to do so.

Agreed.

Obviously, _for_me_ the main benefit would be the ability to cleanly  
move to a host-based solution, in such a way that the upgraded mobile  
hosts could work both stand-alone in the "new internet" (at the non- 
legacy side of xTRs) and in the legacy networks, without any extra  
overhead.  (That is, any upgraded hosts at the legacy networks would  
report their existence to the xTR, which would understand their  
presence, avoiding double encapsulation and signalling overhead).

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 7 Jan 2009 13:55:01 +0200

Dino replied:
>
> But you add another layer of addressing that is probably more than  
> the user wants. It could get this bad:
>

I don't think those mappings are right.

If there is a NAT between the xTR/HIP-proxy and the "new" internet,  
the mapping would be:

EID -> (HIT) -> private-RLOC -> public-RLOC

where the HIT would be invisible everywhere but inside the HIP proxies  
and within the signalling protocol between the HIP proxies.

If there is a NAT between the legacy host and the xTR/HIP-proxy, the  
mapping would be:

private-EID -> public-EID -> (HIT) -> RLOC

where again the HIT would be invisible, as explained above.

> minimal cost, see Yakov's post early today, he makes good points.

I don't see how replacing the xTR internal functionality with the HIP- 
proxy functionality would add much cost.  It would change the protocol  
between the xTRs, yes.  HIP as a protocol is probably more complex  
than the present xTR-xTR protocol, but it is well tested, been in  
operational use at Boeing for a few years, as has three open source  
implementations.

There is an extra mapping, i.e. replacing the EID->RLOC mapping with a  
EID->(HIT)->RLOC mapping.  But that mapping is internal to the proxies  
and the signalling protocol, and not visible outside.  In the simplest  
case the HITs would be ephemeral and opportunistic, requiring no  
configuration or storage anywhere.  (The benefit from them is in terms  
of security and mobility, especially in more complex scenarios than  
the simplest case.)

--Pekka

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 7 Jan 2009 12:51:58 -0800

> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Wednesday, January 07, 2009 3:30 AM
> To: Templin, Fred L
> Cc: RRG; Robin Whittle
> same thing?

I agree that HIP-proxy and xTR are not the same thing.  xTR tunnels,
mapping entries, cache entries can cover aggregates of hosts, while
HIP-proxy has per-host granularity.  xTR doesn't claim to represent any
host from a security point of view, while HIP-proxy seems to.

> available as Patrik's MSc thesis at 
> http://www2.cs.hut.fi/~pmrg/index.cgi?id=148 

This would probably increase the load on the mapping system and xTRs
considerably, because of the per-host granularity.

I'm not sure how it would work for multiple ITRs and ETRs, are there
multiple proxy host identities, one for each xTR?  How is that handled
with mobility or path unavailability events?

It changes the security model for HIP-- when I move behind some ITR, am
I going to want my packets to flow unprotected between my host interface
and the ITR? Am I going to trust arbitrary ITRs to proxy for my host?
Also, are ITRs going to have any incentives to give me good (or any) HIP
service?

> And then I could imagine a few designs beyond either...

Are you instead suggesting above to look at combining HIP with LISP, or
HIP-proxy with LISP?

I see the distinction being that HIP with LISP means that HIP keys are
used to name xTRs and to secure the xTR to xTR communications (and
possibly communications with the mapping system), but otherwise LISP
works as described.  Proxy-HIP keys would name individual hosts and
would play more of a role as an EID in the system.

- Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 7 Jan 2009 13:09:03 -0800

> compared with the risks with leaving these machines inadequately

If people are interested in the deployment that Eric cited above, we
made a presentation at the last HIP RG meeting in Minneapolis:
http://www.ietf.org/proceedings/08nov/slides/HIPRG-0.pdf

To briefly summarize it technically, it is an adaptation of HIP to
provide a layer-2 VPN for unmodified hosts. 

We have also separately experimented with a HIP proxy, but only a single
middlebox, on-link with the unmodified legacy host; not an off-link
proxy serving many hosts.

Tom

---

From: Scott Brim <[email-masked]>
Date: Wed, 7 Jan 2009 16:20:44 -0500

Excerpts from Brian E Carpenter on Mon, Jan 05, 2009 09:39:31AM +1300:
> >                 properly documented as a scalable routing
> >                 solution.  There is no Summary and Analysis in the
> >                 RRG wiki.
> 
> It's unclear to me that ILNP belongs in B since it has
> characteristics of A as well. Whether it's jumped through the hoops
> of the wiki strikes me as uninteresting; it seems to be well
> documented.

ILNP has multiple modes of operation.  One shouldn't be cataloging
entire "packages" because many of them cross taxonomic lines.  If you
must talk in terms of packages, allow a package to be in more than one
category.

> I think Pekka observed that this wasn't even a goal. 

It's not one of HIP's goals, but HIP can help create a routing
solution by making it possible for locators to be assigned
hierarchically.

> (My quick answer

I don't understand this.  Strategy A's "mapping problem" is to find a
mapping from a locally-routed locator to a (more) globally-routed one.

Perhaps what you're saying is that we need a mapping from HIP
identifier to locator?  If so, I don't believe that's true.  If I, a
session initiator, am starting from scratch, I could look up both your
location and your HI in parallel, or I could connect to you and
discover your HI during authentication, and so on.

> But I fully agree: strategy B == IPv6.

If identity is based in transport-layer-or-above, as in Trilogy
multipath, you can have a "B" that could work with IPv4 or v6 (even
both simultaneously).

> > responsibilities and management traffic to all hosts (all
> > potential Strategy B approaches) is fundamentally flawed:
> > 
> been responsible for traffic management (that's called TCP) and
> approaches like SCTP and the proposed multipath TCP extend that.  So
> I don't think we should condemn this in the abstract.

One of the places we clearly get into trouble pushing responsibility
to endpoints is path selection (with or without failures).  First you
may get a lot more control traffic.  Second, endpoint activities can
be at odds with SP activities -- each optimizing for the same thing
differently.  See previous discussion.

> if we shrugged our shoulders and dropped it for 12 years.

+1 on that.

Scott

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 7 Jan 2009 14:49:49 -0800

Regarding HIP + map/encaps, maybe it is obvious to everyone
else already but I think what that gives you is an endpoint
identity (the HIT), an inner routing locator (iRLOC), and an
outer RLOC (oRLOC). Up to now, LISP (and perhaps others) have
been using the term "EID" to refer to what I mean by "iRLOC",
and the term "RLOC" to refer to what I mean by "oRLOC".

In this sense, "oRLOC" is routable within the scope of an
interdomain region, while "iRLOC" is routable only within and
end site (or edge network, or whatever you want to call it).
The HIP HIT is not routable within any scope so it is purely
an identifier and not a locator.

Is this news to anyone, or already so obvious that it doesn't
even bear mention? (Will check back later; I really need to
be off doing other things...)

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Jan 2009 16:32:50 +1300

Fred,

That's my mental model, except that I think of the locators
as LOC0, LOC1, etc to allow for the inevitable hierarchy.
I had also assumed there would need to be a hierarchy of maps,
with HIT<->LOC0 as the lowest level map, but Scott Brim obviously
has another model in mind (I need to think a bit more before
replying to Scott).

   Brian

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 08 Jan 2009 11:48:22 +0800

> and the term "RLOC" to refer to what I mean by "oRLOC".

Since a pure id/locator split solution (e.g. HIP) could use multiple PA
address (locator) which are topologically aggregatable, there may be no need
to use the two layers of locator(iRLOC and oRLOC)

> an identifier and not a locator.

When a legecy host A initiates a communication with a HIP-enabled host B,  A
could send a packet to a nearby proxy (like ITR's role) by using B's HIT as
locator. Upon receiving the packet, the proxy will resolve B's HIT to B's
locator, and send the packet to B, while using its locator as the packet's
source locator and generating a temperay HIT for  A. B will then send
response packet to the above proxy. The proxy will do reverse mapping from
the temporary HIT of A to the IP address of A,  and then send the packet in
legacy IP format to A.  

It's just my assumption. 

Xiaohu

---

From: Scott Brim <[email-masked]>
Date: Wed, 07 Jan 2009 23:19:47 -0500

> has another model in mind (I need to think a bit more before

What HIP gives you is an identifier that may be used for many things.
An HI can be, but does not have to be, part of the process of initially
finding a locator for an endpoint. For example, I can go straight from
domain name to locator (which actually might be an agent / proxy /
rendezvous point), and then validate identities via some other means.

---

From: Scott Brim <[email-masked]>
Date: Wed, 07 Jan 2009 23:21:54 -0500

Xu Xiaohu allegedly wrote on 1/7/09 10:48 PM:
> locator. 

Would you replace host B's A record with a HIT?  Or would this require a
modification to host A?  If you're going to modify A, why not just
implement HIP?

Thanks ... Scott

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 7 Jan 2009 21:25:54 -0800

With respect to security in LHIP by using hash-chains, we consider  
them for LISP, but requires 3 to 4 packet exchanges, so a non-starter.

Dino

On Jan 7, 2009, at 3:47 AM, Pekka Nikander wrote:

> - Security?  Both opportunistic, no-infrastructure-requiring  
> security for multi-homing/mobility, and baseline-level signalling  
> security for integrating any security infrastructure you want (such  
> as PKI, AAA, ...)
>
> Obviously, the next question is what the drawbacks would be.  Here  
> is my initial list:
>
> - Crypto.  Current HIP requires PK crypto (but no PKI!) and ESP.   
> LHIP (which uses only hash functions) is an option if people  
> generally shun PK, and, as I already explained, ESP can be replaced  
> with any tunnelling or flow-identifying protocol.
>
> - Lack of operational experience.  AFAIK, only Boeing has  
> operational experience on HIP.  I guess there is more operational  
> experience available on LISP, even though I haven't seen any.
>
> move to a host-based solution, in such a way that the upgraded  
> mobile hosts could work both stand-alone in the "new internet" (at  
> the non-legacy side of xTRs) and in the legacy networks, without any  
> extra overhead.  (That is, any upgraded hosts at the legacy networks  
> would report their existence to the xTR, which would understand  
> their presence, avoiding double encapsulation and signalling  
> overhead).
>
> --Pekka
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 7 Jan 2009 21:27:32 -0800

I'm not seeing any compelling benefit here Pekka. Just that HIP is  
different and the stuff it does have that LISP currently doesn't is  
too heavy-weight. This is just my opinion and a judgement.

Dino

On Jan 7, 2009, at 3:55 AM, Pekka Nikander wrote:

> where the HIT would be invisible everywhere but inside the HIP  
> proxies and within the signalling protocol between the HIP proxies.
>
> I don't see how replacing the xTR internal functionality with the  
> HIP-proxy functionality would add much cost.  It would change the  
> protocol between the xTRs, yes.  HIP as a protocol is probably more  
> complex than the present xTR-xTR protocol, but it is well tested,  
> been in operational use at Boeing for a few years, as has three open  
> source implementations.
>
> There is an extra mapping, i.e. replacing the EID->RLOC mapping with  
> a EID->(HIT)->RLOC mapping.  But that mapping is internal to the  
> proxies and the signalling protocol, and not visible outside.  In  
> the simplest case the HITs would be ephemeral and opportunistic,  
> requiring no configuration or storage anywhere.  (The benefit from  
> them is in terms of security and mobility, especially in more  
> complex scenarios than the simplest case.)
>
> --Pekka
>

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 08 Jan 2009 13:29:42 +0800

> > When a legecy host A initiates a communication with a 
> HIP-enabled host 
> > B,  A could send a packet to a nearby proxy (like ITR's 
> role) by using 
> > B's HIT as locator.
> 
> Would you replace host B's A record with a HIT?  Or would 
> this require a modification to host A?  If you're going to 
> modify A, why not just implement HIP?

Replacing host B's AAAA record with a HIT is my thought. If a legacy host
got B's AAAA record from DNS, it will look that record as a IPv6 address
And the mapping between HIT and locator (IP address) can be maintained in a
seperate mapping system, e.g. a hierarchical DHT system. 
 
Xiaohu

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 8 Jan 2009 12:36:58 +0200

> [...] HIP-proxy and xTR are not the same thing.  xTR tunnels,  
> HIP-proxy has per-host granularity.  xTR doesn't claim to represent  
> any host from a security point of view, while HIP-proxy seems to.

While certainly so at the architectural level, the difference at the  
practical level does not need to be that big.  Everything depends on  
the details, which we obviously do not have.  (Shun me for empty talk,  
if you want.)

First, the packets between xTRs do have per-host granularity, as the  
EIDs are preserved in the inner header.  Hence, conceptually, if you  
want to look at the xTRs from this point of view, you could consider  
each pair of EIDs as a separate "state".  Those states are then  
aggregated to the per-site granularity.

Almost the same thing *could* be done with a HIP proxy, too.  The  
forwarding state could be at a per-site granularity.  (I go into very  
convoluted architectural thinking next, but bear with me to see the  
result).   The ideas is that the HIs representing proxied hosts would  
be expressed only as aggregated delegated state.  That is, from the  
HIP architecture point of view there would be a "virtual" HI for each  
proxied host, as well as for each proxied host at a remote site.   
However, each of the local "virtual" HIs would be "virtually"  
delegated to the HI of the local HIP-proxy; likewise for each remote  
site.  As a result, the HI of the HIP-proxy would represent all the  
"virtual" HIs of the hosts behind it.  In reality, no such "virtual"  
HIs would exist at all, the delegation being fully virtual (or even  
imaginary).  Then, I think, the state at the HIP-proxy would match, in  
terms of granularity, the state at an xTR.

The next obvious question is what's the point?  Why to have such  
virtual, ephemeral, opportunistic HIs for each host if they don't  
exist at all in practise?  The reason is that the architecture could,  
trivially, also allow real, non-virtual, HIs.  That is, in addition to  
representing the legacy hosts at the site through virtual delegation,  
the HIP-proxy could represent real HIP-enabled (mobile) hosts and  
subnetworks through real delegation.

To summarise the above:  In an imaginary world, there would be a HI  
for each legacy host at a site, all those HIs being delegated to the  
HI of the HIP-proxy.  In the real world, there would be only the HI of  
the HIP-proxy, representing the whole legacy site through the  
imaginary delegation.  For HIP-enabled hosts and subnetworks, there  
would of course be actual HIs and real delegation from the HIP-enabled  
host or subnetwork to the HIP-proxy.

>> the same box -- they could even use the same mapping infrastructure  
>> to find out the RLOC of the peer HIP proxy/xTR, and then in  
>> parallel send an opportunistic HIP I1 and whatever LISP sends when  
>> an xTR contacts another xTR that it has no prior association with.   
>> But that would be a (minor) waste of resources as two packets would  
>> be sent in parallel.
>

It does not necessarily increase the load, as should be obvious from  
the above.  First, even if the end-host HIs were real ones and not  
imaginary ones, there is no need to store them to the mapping system.   
Second, if they are imaginary ones, they don't even exist elsewhere  
but as a concept.  So, there is no operational cost and there are  
benefits you get if HIP becomes more common.

> multiple proxy host identities, one for each xTR?  How is that  
> handled with mobility or path unavailability events?

As long as you speak about mobility of the mobility HIP-proxy or path  
unavailability between HIP-proxies, it works just as if the proxies  
were individual HIP hosts hosting multiple HIs.  If you speak about  
legacy host mobility, obviously it doesn't work.  For the details of  
mobile HIP hosts moving from one HIP-proxy to another HIP-proxy, I  
don't know if anyone has written down the details.

> and the ITR?

If you are a legacy host, what else could you do?  If you are a HIP  
host, the ITR would look like a HIP MR to you.

> Am I going to trust arbitrary ITRs to proxy for my host?

That is an operational choice that you have to make.

> Also, are ITRs going to have any incentives to give me good (or any)  
> HIP service?

What incentive do they to give you any service in the first place?

>> protocol (providing the additional mobility and security features  
>> HIP provides).
>>
>> indicates that the sender understands both LISP and HIP, allowing  
>> the receiver to pick which one to use.
>>
> Are you instead suggesting above to look at combining HIP with LISP,  
> or HIP-proxy with LISP?

I'm suggesting them as potential starting points for looking at how to  
combine HIP-proxy with LISP.

> I see the distinction being that HIP with LISP means that HIP keys  
> are used to name xTRs and to secure the xTR to xTR communications  
> (and possibly communications with the mapping system), but otherwise  
> LISP works as described.  Proxy-HIP keys would name individual hosts  
> and would play more of a role as an EID in the system.

I see.  However, I don't see there a big difference, due to the  
imaginary HIs and imaginary delegation making the difference, well,  
imaginary.  :-)

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 8 Jan 2009 12:44:02 +0200

> and the term "RLOC" to refer to what I mean by "oRLOC".

That is my basic model as well.  Further, as Brian observed, that can  
be applied recursively.

But then there are a few variations.

1. In the case of pure host-based HIP, there is no iRLOC but only the  
HIT:

    HIT -> oRLOC.

2. In the case of host-based HIP and HIP MR, the mapping is HIT ->  
iRLOC -> oRLOC, which can be applied recursively leading to:

    HIT -> LOC0 -> LOCi -> LOCn.

3a. In the case of legacy hosts and HIP proxy, for IPv6 you *can* make  
iRLOC == HIT (which is what we did in the first HIP proxy work,  
described in Patrik's thesis):

    iRLOC == HIT -> oRLOC

3b. Alternatively, you can make HITs and iRLOCs separate, as you need  
for IPv4 anyway:

    iRLOC <-> HIT -> oRLOC

Generalising, we get two cases:

a) host-based HIP generalised:  HIT -> LOC0 -> LOCi -> LOCn

b) proxy HIP generalised:  iRLOC <-> HIT -> LOC0 -> LOCi -> LOCn

In the latter case, the HIT can be "virtual" or "imaginary", if so  
desired.  (See my previous message.)

> an identifier and not a locator.

That is the theory.  As I noted above, for IPv6 you can make HIT ==  
iRLOC if you want.  That is, the format allows that.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 8 Jan 2009 12:48:45 +0200

> them for LISP, but requires 3 to 4 packet exchanges, so a non-starter.

I don't think so, but I'm no longer an expert there.  (I used to know  
crypto protocols around 1998-2002, but I no longer can claim so.)  For  
unprotected opportunistic case, I think you can simply send your hash  
anchors in the opening packet.

But then association initiation is a very subtle business with lots of  
DoS and other security pitfalls.   You have to make a balance between  
resource exhausting DoS protection and the number of roundtrips.

--Pekka

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 08 Jan 2009 07:45:57 -0500

While there is room to discuss a lot of the other aspects, I at least 
consider the ability to migrate to a host based solution, which would 
easily support multi-interface hosts and site topology changes while 
preserving identity, to be a benefit.

Yours,
Joel

Dino Farinacci wrote:
> different and the stuff it does have that LISP currently doesn't is too 
> heavy-weight. This is just my opinion and a judgement.
> 
> Dino
> 
>>> 2-levels of mapping is plenty, adding 2 more probably is a 
>>> non-starter. Remember folks, we have to incrementally deploy this 
>>> with minimal cost, see Yakov's post early today, he makes good points.
>>
>> complex than the present xTR-xTR protocol, but it is well tested, been 
>> in operational use at Boeing for a few years, as has three open source 
>> implementations.
>>

---

From: Tobias Heer <[email-masked]>
Date: Thu, 08 Jan 2009 17:25:29 +0100

Am 08.01.2009 um 11:48 schrieb Pekka Nikander:

> I don't think so, but I'm no longer an expert there.  (I used to  
> know crypto protocols around 1998-2002, but I no longer can claim  
> so.)  For unprotected opportunistic case, I think you can simply  
> send your hash anchors in the opening packet.
>
Regarding LHIP and authentication delay: The question is if this is  
about the payload channel (1), the signaling (2), or the initial  
handshake (as done by HIP) (3).

1. LHIP does not protect payload. Hence, there is no added security as  
well as no penalty in terms of additional packets and delay (in  
comparison to plain IP).

2. For signaling messages, LHIP uses delayed secret disclosure and  
requires three packets to be sent. Signaling events are quite rare for  
HIP.

3. Regarding the initial handshake: If one doesn't care about  
compatibility/interoperability between LHIP and HIP hosts, one could  
probably reduce the number of required handshake packets. LHIP uses  
the 4-way handshake for being as close to HIP as possible. When moving  
away from HIP one could indeed just send the anchors in the first data  
packet and still have hash-chain-signature protected signaling later  
but that is not what LHIP does right now.

Tobias

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 Jan 2009 11:04:50 -0800

Pekka,

>Sent: Thursday, January 08, 2009 2:44 AM
>To: Templin, Fred L
>Cc: Henderson, Thomas R; RRG; Robin Whittle

Yes. One small but important distinction though is that recursion
is not meaning to say that there would be recursive encapsulations
(i.e., IP0-in-IP1-in-IP2-in ... in-IPN); else we would eat ourselves
out of MTU in a hurry.

Rather, we can talk about recursive RE-encapsulations. So, the
initial encapsulation would be: HIT-in-iRLOC-in-oRLOC0. The packet
would be forwarded within the scope within which oRLOC0 is routable,
then decapsulated and re-encapsulated as HIT-in-iRLOC-in-oRLOC1.
The packet is then forwarded within the oRLOC1 scope, then
re-encaps'd as HIT-in-iRLOC-in-oRLOC2, etc. etc.

It is exactly analogous to the way the L2 destination is changed
on each IP forwarding hop without the L3 destination address
changing. The only difference is that the outer IP protocol
is seen as L2 by the inner IP protocol. That is one of the
benefits of viewing the routing region in which oRLOCs are
valid as an NBMA link over which packets of the inner IP
protocol are forwarded, but there is much more to it than
just this.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 8 Jan 2009 11:11:22 -0800

Joel,

I am seeing HIP proxy as having value both as a near-term
connectivity capability for legacy hosts and as a longer
term transition mechanism that encourages more and more
end hosts to deploy a host-based solution. However, I
see this as complementary to the network-based solution
rather than a replacement for the network-based solution.

IMHO, the network based-solution provides the substrate
on which the end-to-end solution builds.

Fred

>From: Joel M. Halpern [mailto:[email-masked]]
>Sent: Thursday, January 08, 2009 4:46 AM
>To: RRG
too
>>> where the HIT would be invisible everywhere but inside the HIP
proxies
>>> complex than the present xTR-xTR protocol, but it is well tested,
been
a

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 9 Jan 2009 10:31:12 +0200

>>> Regarding HIP + map/encaps, maybe it is obvious to everyone else  
>>> already but I think what that gives you is an endpoint identity  
>>> (the HIT), an inner routing locator (iRLOC), and an outer RLOC  
>>> (oRLOC). Up to now, LISP (and perhaps others) have been using the  
>>> term "EID" to refer to what I mean by "iRLOC", and the term "RLOC"  
>>> to refer to what I mean by "oRLOC".
>>
>> That is my basic model as well.  Further, as Brian observed, that  
>> can be applied recursively.
>
> Yes. One small but important distinction though is that recursion is  
> not meaning to say that there would be recursive encapsulations  

I agree.

> then decapsulated and re-encapsulated as HIT-in-iRLOC-in-oRLOC1.

Well, I would expect 1-to-1 mapping between HITs and iRLOCs, allowing  
one to use just one encapsulation or even almost-null encapsulation.   
That is, e.g. iRLOC-in-oRLOCi, HIT-in-oRLOCi, or TAG-in-oRLOCi where  
TAG is whatever minimal encapsulation/tag is needed for demuxing at  
oRLOCi.

> It is exactly analogous to the way the L2 destination is changed on  
> each IP forwarding hop without the L3 destination address changing.  
> The only difference is that the outer IP protocol is seen as L2 by  
> the inner IP protocol.

I think that has been discussed more extensively in the following  
papers and drafts.  But I didn't check, I may be wrong.

Jukka Ylitalo, Patrik Salmela, and Hannes Tschofenig, "SPINAT:  
Integrating IPsec into Overlay Routing", in Proc. of the First  
International Conference on Security and Privacy for Emerging Areas in  
Communication Networks (SecureComm'05), pp. 315-326, Athens, Greece,  
September 5-9, 2005, ISBN 0-7695-2369-2

http://www.ietf.org/internet-drafts/draft-melen-spinat-01.txt

A. Eriksson and B. Ohlman, "Dynamic Internetworking Based on Late  
Locator Construction," IEEE Global Internet Symposium, 2007.

--Pekka

_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 9 Jan 2009 08:16:29 -0800

Pekka,

>Sent: Friday, January 09, 2009 12:31 AM
>To: Templin, Fred L
>Cc: RRG
>Subject: Recursive re-encapsulations
>

I may not have made myself clear. I am talking about HIP in
conjunction with the RANGER/VET/SEAL model, and specifically
about the over-the-wire encapsulation format.

iRLOC refers to the IP addresses HIP sees, while oRLOC refers
to the outer encapsulation applied by RANGER/VET/SEAL. Both
iRLOCs and oRLOCs name interfaces (not end systems) hence they
are routable within a certain limited scope. My understanding
is that HITs are true end system identifiers (EIDs) and not
routable within any scope.

My assumption is that HIP can deal with multihomed hosts (i.e.,
there may be one HIT to many iRLOCs), but let's say there is
just one interface for now. So, when a HIP-aware transport
inserts a HIT (and then does BEET-mode encapsulation, I guess)
the packet goes out as:

  +--------------+
  |     data     |
  +--------------+
  |   transport  |
  +--------------+
  |      HIT     |
  +--------------+
  |   IPsec/ESP  |
  +--------------+
  | Inner IP hdr |
  |   src=iSRC   |
  |   dst=iDST   |
  +--------------+

Then, somewhere in the path (it may or may not be on the same
platform that sourced the packet), an ITR performs an iRLOC to
oRLOC mapping and appends an outer IP header:

  +--------------+
  |     data     |
  +--------------+
  |   transport  |
  +--------------+
  |      HIT     |
  +--------------+
  |   IPsec/ESP  |
  +--------------+
  | Inner IP hdr |
  |   src=iSRC   |
  |   dst=iDST   |
  +--------------+
  | Outer IP hdr |
  | src=oSRC(0)  |
  | dst=oDST(0)  |
  +--------------+

The packet is then routed according to the outer IP protocol
within the scope within which oSRC(0) and oDST(0) are valid,
then hits an ETR/ITR that decapsulates and re-encapsulates as:

  +--------------+
  |     data     |
  +--------------+
  |   transport  |
  +--------------+
  |      HIT     |
  +--------------+
  |   IPsec/ESP  |
  +--------------+
  | Inner IP hdr |
  |   src=iSRC   |
  |   dst=iDST   |
  +--------------+
  | Outer IP hdr |
  | src=oSRC(1)  |
  | dst=oDST(1)  |
  +--------------+

and the chain can continue recursively with an indefinite
number of ITR(i)->ETR(i), ITR(i+1)->ETR(i+1), etc. transitions,
with the decapsulation and re-encapsulation occurring at each
transition. The iRLOCs in the inner IP header never change, but
the inner IP TTL/Hop limit is decremented upon each ETR->ITR
transition. This is what I mean by HIP being used in conjunction
with map/encaps. But, HIP simply sees map/encaps as an ordinary
interface over which packets can be sent.

Does this clarify?

Fred

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 9 Jan 2009 18:27:25 +0200

So HIT is routable IPv6 address to enable legacy to legacy
communication? Is that good?
 
 How about having a two faced DNS for upgraded nodes? HIT returned if
source is from EID space, AAAA if not?

- Hannu

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Xu Xiaohu
>Sent: Thursday, January 08, 2009 07:30
>To: 'Scott Brim'
>Cc: 'RRG'; 'Robin Whittle'
>this require 
>> a modification to host A?  If you're going to modify A, why not just 
>> implement HIP?
>
>Replacing host B's AAAA record with a HIT is my thought. If a 
>legacy host got B's AAAA record from DNS, it will look that 
>record as a IPv6 address And the mapping between HIT and 
>locator (IP address) can be maintained in a seperate mapping 
>system, e.g. a hierarchical DHT system. 
> 
>Xiaohu
>
>

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 10 Jan 2009 15:05:31 +0200

> about the over-the-wire encapsulation format.

I suggest that we take this off-line, as there are many details.  If  
someone else is interested, feel free to drop a note.  It may be worth  
to wrap the details into a draft, perhaps.

Anyway, from my point of view, what you described in the message

http://www.ietf.org/mail-archive/web/rrg/current/msg04312.html

is the case of using vanilla HIP on a HIP-enabled host, landing on a  
network behind a lisp xTR or a similar device.  In that case you  
indeed get the packet structures you described.

However, if we aim for the kind of hybrid LISP-HIP-proxy design that  
I've been suggesting, I believe that the packet formats could be much  
simpler.

AFAICS, the crux will always be on how much demultiplexing / security  
verification state you need at the receiving end, at the unwrapping  
xTR.  If your trust model allows you to decapsulate without  
verification, you can live without such state and include the inner  
locators or identifiers into the packet.  However, if the trust model  
requires one to verify the inner locators or identifiers, then there  
must be the state at the receiving end, meaning that you get smaller  
overhead if you don't include the full inner header in the packet but  
just index to the state + any bits not directly stored in the state.

--Pekka

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 12 Jan 2009 11:20:14 +0800

Hannu,

> communication? Is that good?

I'm not sure this is the case for HIP. However, in RANGI, the host ID is an
IPv6 PI address in CGA alike format ( the first part of this ID is
Administrative Domain (AD) ID, the latter part is the hash of the AD ID and
its public key ). This specific PI address could be routable in site where
legacy hosts exist (just as map&encaps approach). This is just my rough
thought of the proxy mechanism for RANGI, and I think this is also workable
for HIP.

>  How about having a two faced DNS for upgraded nodes? HIT 
> returned if source is from EID space, AAAA if not?

This is a very interesting idea. BTW, if the DNS server is upgraded, we can
also define another field for the HIT/host ID value in DNS request/reply
msgs which can be used between upgraded hosts and upgraded DNS servers.

Xiaohu

> Behalf Of 
> >ext Xu Xiaohu
> >Replacing host B's AAAA record with a HIT is my thought. If a legacy 
> >host got B's AAAA record from DNS, it will look that record 
> as a IPv6 
> >address And the mapping between HIT and locator (IP address) can be 
> >maintained in a seperate mapping system, e.g. a hierarchical DHT 
> >system.
> > 
> >Xiaohu
> >
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jan 2009 16:56:18 +1300

> rendezvous point), and then validate identities via some other means.

Assuming I deem the DNS trustworthy, it seems much more natural
to treat the DNS as the source of an HI, and then for the locator to be
looked up as a function of the HI. I'm not saying your model doesn't work,
but surely the HI is fundamental and has universal validity, and the locator
(any of the locators) is transient and has non-universal scope? So starting
with a locator lookup seems funny.

    Brian

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 12 Jan 2009 12:20:57 +0800

> > An HI can be, but does not have to be, part of the process of 
> > initially finding a locator for an endpoint. For example, I can go 
> > straight from domain name to locator (which actually might 
> be an agent 
> > / proxy / rendezvous point), and then validate identities 
> via some other means.
> 
> Assuming I deem the DNS trustworthy, it seems much more 
> natural to treat the DNS as the source of an HI, and then for 
> the locator to be looked up as a function of the HI. I'm not 
> saying your model doesn't work, but surely the HI is 
> fundamental and has universal validity, and the locator (any 
> of the locators) is transient and has non-universal scope? So 
> starting with a locator lookup seems funny.

I prefer Brain's opinion since there is no need for each host owns a FQDN
name. Once you tell me your host ID, I can resolve your locator from a
seperate ID/locator mapping system and then communicate with you. 

Xiaohu

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 12 Jan 2009 08:19:05 +0200

Summary:  One can initially deploy multiple layers of indirection  
initially by "architecturally cheating"  or "hiding" some of the  
indirection layers so that they are not visible to the resolution  
system nor in data plane packets.

>> Assuming I deem the DNS trustworthy, it seems much more natural to  
>> treat the DNS as the source of an HI, and then for the locator to  
>> be looked up as a function of the HI. I'm not saying your model  
>> doesn't work, but surely the HI is fundamental and has universal  
>> validity, and the locator (any of the locators) is transient and  
>> has non-universal scope? So starting with a locator lookup seems  
>> funny.
>
> I prefer Brain's opinion since there is no need for each host owns a  
> FQDN name. Once you tell me your host ID, I can resolve your locator  
> from a seperate ID/locator mapping system and then communicate with  
> you.

 From an architectural orthodoxy point of view, i.e. from the layering  
point of view, what you and Brian describe may well be the "right"  
way.  Indeed, what you describe is more-or-less what happens with HIP  
as standardised today.  You get the HIT and a set of initial locators  
from the DNS.  The initial locators are typically those of rendezvous  
servers, which in turn know the current locator(s) of a mobile host.   
For details, see RFC5204 and RFC5205.

However, if you consider the various early deployment scenarios, the  
situation is different.  The question is no longer what is "right",  
from the architectural point of view, but what is the best deployment  
strategy.  From that point of view, a good strategy may be to  
initially get only the locators from the DNS, as that requires no  
changes to the DNS.  The HIT (or the HITs) can then be learned form  
the peer, along the opportunistic HIP model.  See Section 4.1.6 of RFC  
5201.  But I can also imagine other deployment models.

IMHO, if we want to consider the deployability a HIP-based solution,  
or any solution, what Noel wrote before Christmas is well worth  
reading again:

http://www.ietf.org/mail-archive/web/rrg/current/msg04037.html

(Remember, that is the message to which I reacted, causing the current  
thread of messages about HIP, where I have mainly tried to explain  
that HIP-proxy could have a quite different deployment model than the  
plain HIP has.)

In general, the question is very much about deployment cost.  With  
proxy HIP, by initially "hiding" the HITs and using the opportunistic  
HIP model and ephemeral or even imaginary HITs, we can "fold" the HIP  
model into what is essentially the map-and-encaps model.

[[Generalising more, once again: one can deploy architecturally host- 
based solutions initially as network-based ones, and vice versa.   
Conversely, one can design architecturally host-bast solutions that  
are *hard* to deploy as network-based ones, and one can design  
architecturally network-based solutions that are *hard* to utilise in  
single hosts.  And vice versa.  Hence, paying attention to the  
details, both in selecting the architectural approach and thinking  
about the deployment flexibility, should pay off to the community in  
the large.

I've been trying to say that now for over two years, and nobody still  
seems to pay any attention.  Am I completely bogged and off the road  
in my thinking?]]

--Pekka

---

From: Oleg Ponomarev <[email-masked]>
Date: Mon, 12 Jan 2009 10:35:59 +0200 (EET)

> msgs which can be used between upgraded hosts and upgraded DNS servers.

Just in case, this is HIP RR defined in RFC5205 and given type 55 by IANA.

And yes, the DNS server / proxy replies with HIT in AAAA field for legacy 
applications. The locators can be found in records for 
5.7.d.1.c.c.8.d.0.6.3.b.a.4.6.2.5.0.5.2.e.4.7.5.e.1.0.0.1.0.0.2.hit-to-ip.net 
(when HIT is 2001:1e:574e:2505:264a:b360:d8cc:1d75)

-- 
Regards, Oleg.

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 12 Jan 2009 17:31:52 +0800

Oleg,

> > This is a very interesting idea. BTW, if the DNS server is 
> upgraded, 
> > we can also define another field for the HIT/host ID value in DNS 
> > request/reply msgs which can be used between upgraded hosts 
> and upgraded DNS servers.
> 
> And yes, the DNS server / proxy replies with HIT in AAAA 
> field for legacy applications. The locators can be found in 
> records for 

Perfect. The ID to locator mapping service can still use the DNS technology
just like what ENUM does. 

By the way, if the HIT can be modified to have some structure, the id to
locator mapping system will be more managable and scalable like current DNS.
^_^

Xiaohu.

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 12 Jan 2009 17:45:06 +0800

> (when HIT is 2001:1e:574e:2505:264a:b360:d8cc:1d75)

by the way,  is there any HIP related RFC or draft for the above method?

Thanks,

Xiaohu

---

From: Oleg Ponomarev <[email-masked]>
Date: Mon, 12 Jan 2009 11:56:11 +0200 (EET)

> by the way,  is there any HIP related RFC or draft for the above method?

Unfortunately there is only a chapter in HIPL manual and an old 
workshop paper at the moment, but I will submit some draft soon.

http://hipl.hiit.fi/hipl/manual/ch24.html
http://trustinet.org/papers/ponomarev-ring-2007.pdf

-- 
Regards, Oleg.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 12 Jan 2009 07:08:48 -0800

Hi Pekka,

>Sent: Saturday, January 10, 2009 5:06 AM
>To: Templin, Fred L
>Cc: RRG
>Subject: Re: Recursive re-encapsulations
>
is
>indeed get the packet structures you described.

I'm actually meaning to refer to a HIP-enabled proxy router
landing on the same platform as an xTR (although the model
would be the same if the HIP-enabled proxy landed on a link
downstream from the xTR).

>I've been suggesting, I believe that the packet formats could be much

I'm not exactly sure how; xTR means IP-in-IP encapsulation.
Were you meaning for it to mean something else?

>just index to the state + any bits not directly stored in the state.

With RANGER/VET/SEAL, I am looking for a way for the ITR to
establish sufficient securing state in the ETR through a single
message sent forward before any data messages are sent (i.e.,
a "1-way handshake"). Can HIP do that?

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 12 Jan 2009 07:09:06 -0800

Oleg and Xu,

There is clearly some synergy here with what is being
proposed in RANGER/VET/SEAL. Xu, you may in particular
be interested in looking at those documents for
parallels with RANGI.

Thanks - Fred

>From: Oleg Ponomarev [mailto:[email-masked]]
>Sent: Monday, January 12, 2009 1:56 AM
>To: Xu Xiaohu
>Cc: 'RRG'

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 12 Jan 2009 18:46:04 +0200

> Were you meaning for it to mean something else?

What I have been trying to describe is taking the LISP architecture  
and then replacing some parts of the xTR functionality with proxy-HIP.

> a "1-way handshake"). Can HIP do that?

Depends on your security requirements and what you store in your  
mapping system.

A very short answer is that if you care about all the security threats  
HIP cares about, then if the ETR stores the HIP puzzle into the  
mapping system so that the ITR gets the puzzle along the ETR RLOC,  
then HIP can do that.

--Pekka

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 12 Jan 2009 17:10:01 -0800

Pekka,

>Sent: Monday, January 12, 2009 8:46 AM
>To: Templin, Fred L
>Cc: RRG

With RANGER, I was thinking that the ITR could send an
IPv6 Router Advertisement using SEND forward to the ETR and
then just start admitting packets into the tunnel. The ETR
will verify the credentials in the RA (e.g., by checking in
the mapping system, by consulting a certificate authority,
etc.) and set an ingress filter entry if the credentials
check out. The ETR can then start accepting packets from
the ITR.

If the ITR's credentials don't check out, the ETR will
instead drop packets and send back rate-limited ICMP
"Destination Unreachable; Administratively Prohibited"
messages. The ITR can then use SEAL as a loose method of
authenticating the ICMP messages, and can try again to
establish the ingress filter if it thinks it has the
correct credentials.

Does that match the model you were thinking of?

Thanks - Fred

---

From: Scott Brim <[email-masked]>
Date: Wed, 21 Jan 2009 14:24:29 -0500

> 
> > > What HIP gives you is an identifier that may be used for many
> > > things.  An HI can be, but does not have to be, part of the
> > > process of initially finding a locator for an endpoint. For
> > > example, I can go straight from domain name to locator (which
> > > actually might be an agent / proxy / rendezvous point), and then
> > > validate identities via some other means.
> > 

This is an interesting point.  Thank you.
_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jan 2009 09:23:39 +1300

> Excerpts from Xu Xiaohu on Mon, Jan 12, 2009 12:20:57PM +0800:

It occurs to me that this would be particularly relevant to massive
server virtualization (where a pool of physical servers synthesizes
virtual servers as workload arrives). The virtual servers would each
need an HI to locator map entry but would not particularly need an FQDN.

   Brian

---

From: Scott Brim <[email-masked]>
Date: Thu, 22 Jan 2009 17:17:25 -0500

> On 2009-01-22 08:24, Scott Brim wrote:
> >>>> actually might be an agent / proxy / rendezvous point), and
> >>>> then validate identities via some other means.
> >>> to treat the DNS as the source of an HI, and then for the
> >>> locator to be looked up as a function of the HI. I'm not saying
> >>> your model doesn't work, but surely the HI is fundamental and
> >>> has universal validity, and the locator (any of the locators) is
> >>> transient and has non-universal scope? So starting with a
> >>> locator lookup seems funny.
> >> I prefer Brain's opinion since there is no need for each host
> >> owns a FQDN name. Once you tell me your host ID, I can resolve
> >> your locator from a seperate ID/locator mapping system and then
> >> communicate with you. 
> > 

Brian (aka Brain): While I agree with the original point, but on this
point: all you need here is a level of indirection when mapping from
name to interface.  "Name" can be anything -- I don't see the
difference if you start from a HI or a FQDN and take one step from it.  
_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg