Subject: Re: Comments on draft-crocker-mast-proposal-00.txt

From: Dave Crocker <[email-masked]>
Date: Sat, 6 Sep 2003 19:58:15 -0700

Folks,

Thanks for the comments.  Keep them coming.  Some responses:

This realm encompasses three bits of functionality:

1. Rendezvous -- finding someone without existing context between the finder
and the findee. In classic client-server scenarios, that is what we use the
DNS for. Clearly, some mobility scenarios create challenges that existing DNS
mechanisms do not cover.

2. Multi-address support -- or rather, making it possible for a specific
host-pair transport context to be able to use more than one address over the
life of the association.

3. Multi-address use -- intelligently choosing among multiple available
addresses.

MAST defers #1, focuses on #2, and treats #3 simplistically. This is
intentional, of course.

HIP and LIN6 are more ambitious.

SD> - I like the possibility of using MAST with IPv4.

HIP and LIN6 are tied to IPv6 and involve notable enhancements to the Internet
architecture.  Both seem pretty clean to me, architecturally.  MAST does not
take such an approach for two major reasons.  One is installed base, and the
support thereof.  I like to be friendly to millions of hosts, when possible.

The other issue is administrative overhead. MAST does not create any
interesting administrative load HIP and LIN6 impose some significant new
administration. MAST currently involves none. If MAST tackled mutual mobility
(specifically, anytime a caller needs to find a callee for the first time)
then some sort of third-party mechanism is needed and no existing Internet
mechanism is sufficient to the task, I believe. See #3, next segment, below,
re: LIN6.

SD> I took a quick look at LIN6,

Glad to see the reference to it.  I will fold consideration of it into the MAST
proposal.  Here are some initial thoughts:

I think that comparison of HIP, LIN6 and MAST will be helpful.  There are some
pretty interesting differences among them.  I'm planning on doing something
more detailed, but for now:

1. The MAST proposal has a discussion of HIP.  I'm hoping that a HIP savant
will tell me of any errors, so I can fix them.

2. LIN6 appears to be a transport-layer host identifier paradigm, with new
administration of the addresses and then a mapping between the transport-layer
id and one or more classic IP-layer addresses.  By contrast, MAST
introduces *no* new addresses on the wire.  New addresses within the end-nodes
are not required, though internal use of private IP addresses is discussed as
an implementation choice.

3. The LIN6 specification also provides for the rendezvous function, using
DNS, which MAST chooses to defer. The LIN6 rendezvous mechanism appears to be
two-stage.  Stage one is a domain name, with a new, MA record.  Stage two is a
dynamic mapping service, using the transport-level id and any IP-level
addresses that are currently operational.

Without worrying about the fine-grained details of this mechanism, I'll say
that I think it is generally the right approach, when the initiator of an
association must find a mobile host. My guess is that DNS is better for
"sticky" values and that anything that is more dynamic should use something
else. To this end, I find myself thinking in terms of a "presence" service, a
la instant messaging.

SD> - I like your awareness of NATs in IPv4 networks as a deployment
SD> issue.

Be friendly to the installed base and minimize adoption dependencies (ie,
number of changes to make and number of new mechanisms required.) Also, avoid
changing the infrastructure if at all possible.

Adoption of a new mechanism will be a lot easier.

SD> - I understand why you are thinking "end hosts only". You might also
SD> want to think about MAST proxies to allow MAST mobility against an
SD> unmodified correspondent host (to use the MIP term).

Section 8.3 of the MAST proposal is relevant, here. It does not use quite the
same language, but I think the functionality is exactly what you are
describing, or only needs a bit more. If not, please elaborate.

SD> - MAST seems to be very agnostic about the "bootstrap" IP address.
...
SD> mobile-initiated, but much less on how two mobile hosts find each
SD> other.

See above. DNS + distributed, dynamic bulletin boards (presence) function
seems like the right approach to me.

Basically, I think such a mechanism is very important and involves major
effort. It deserves its own focus.

MAST defers this type of mobility out of respect for its difficulty. I think
we do not need to put solving the rendezvous problem into the critical path of
the multi-homing and "client mobility" uses.

SD> - One HIP issue I've wondered about, but have not mentioned in public,
SD> is how an application might make of "whatever it THINKS is the IP
SD> address" (because a mobile address/identifier looks like any other
SD> address). What happens if an application expects to do a reverse DNS
SD> lookup of a HIP HI, for instance? Per your 8.1, I THINK any IP
SD> addresses your transports/applications see are really IP addresses,
SD> but they may not be routable or reachable at any given moment... I'm
SD> not the application guy here, I'm just wondering out loud.

Any application that uses IP addresses is a problem for any translation
function. To handle it, something has to change. The mapping code needs to
know about the application, or the application needs to know about the new
address, or the "address" needs to be something newly assigned thing (end
point identifier) that stays constant. Whatever the choice, it is a big deal.

SD> - I agree with Matataka's note that selecting an interface is not an
SD> easy problem.

I agree.  That's why MAST says a) it's a hard problem, worthy of study, and b)
until we understand it better, be simplistic and conservative.

SD> When I've asked about this in places like DNA, the pushback is that this
SD> decision is internal to a host, and need not/should not be standardized in
SD> IETF.

That is like saying that the TCP retransmission algorithm is internal to a
host and need not/should not be standardized in the IETF.

This is something that has a direct impact on the rest of the Internet. A bad
scheme, implemented in lots of hosts, is going to do a lot of operational
damage.

It needs to be standardized.

SD> You might want to think about
SD> this, and mention your position on this explicitly.

Section 7 tries to do this.  While the current text might seem like a cop-out,
it is not meant to be.

Again, I have too much respect for the complexity and sensitivity of this bit
of mechanism to believe it should be set into concrete too soon, other than
for a simple, safe mechanism just to get things started. More interesting
address selection -- I'm not fond of calling it path selection -- mechanisms
are needed, but again, this can be taken out of the initial critical path for
development and deployment.

SD> - I'm wondering if you have looked at RSIP lately (Experimental
SD> protocol), re: NAT traversal, or at STUN - it looks like you're
SD> including some STUN functionality in PROBE.

I haven't.  Suggestions for what to change, in the PROBE function, would be
welcome.

SD> - I'm wondering how much you have thought about the use of PROBEs to
SD> verify path connectivity from time to time.

Second bullet of the first list under 5.4.  Yes?

SD> The transport view of the
SD> world is that this is really an application-level responsibility,
SD> because the transport (hence, the MAST) doesn't know how often to

My original thinking was that the module that knows about the multiple
addresses should check for their continued validity, especially since the
higher levels do not even know that the multiple addresses exist (in the MAST
proposal). In that sense, I think we need to distinguish things like
application-level aliveness tests from link-level keep-alives. In that sense,
MAST's PROBE is a lower-layers function.

SD> verify path connectivity - too often risks punting on paths that are
SD> broken now but will be healed before they are needed, and too seldom
SD> forces the application to probe,

This is all standard routing-table maintenance stuff, isn't it?  Hence we
should be able to re-use the learning from that task, in terms of balancing
switchover delay, versus flapping.

I don't have any religion on this, other than appreciating the challenge of
getting it right.

SD> - When you're moving forward from proposal to specification, you'll
SD> need someone smarter than I am about security on the design team.

I had not known about the Purpose-Built Key internet-draft.  It seems perfect
for the security MAST needs to provide, specifically to avoid hijacking the
MAST association.

IvB> But is it realistic to expect to deploy a technology in IPv4 that uses
IvB> up additional address space?

MAST does not use up new address space in IPv4 or IPv6.  None.

This point appears to be easy to miss, so let me summarize this aspect of
MAST again:

     MAST uses simple domain names as public, unique end-point identifiers.
     Oddly, MAST doesn't do much with them, yet, for the portion of the
     problem space that MAST attacks.

     MAST creates no new addresses.  None.  Internal to a MAST host, there
     might be a mapping of the changing IP addresses to a stable one that is
     private to that host.  Again oddly, this is like having a NAT function
     just inside the host, between transport and IP.

>> - I'm wondering how much you have thought about the use of PROBEs to
>> verify path connectivity from time to time.
IvB> If you only have two paths you're going to try the second one anyway
IvB> when the first fails because there is no reasonable alternative course 
IvB> of action. If you have more paths there is a signicant chance that 
IvB> several of them will fail because of the same underlying problem.

Round-robin is sometimes a fine approach.  Sometimes it has problems.  Just
because a re-try is necessary does not automatically making trying an
alternative address the right thing to do.

IvB> If you really want to be cool, _use_ the different paths concurrently.
IvB> I'm convinced that as soon as we've got the basic multiadressing 
IvB> mechanisms in place, load balancing single TCP sessions over multiple 
IvB> paths will be the next big thing.

I've always felt that the fastest way to switchover to an alternate path is to
already be using it.  Still, this is sensitive stuff and needs to be
approached carefully.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 8 Sep 2003 05:42:07 +0859 ()

Dave;

> HIP and LIN6 are more ambitious.

Original LIN6 proposal was primarily for mobility and was not
so ambitious. Use of ID is a way to avoid MTU problems of
mobile tunneling.

> administration. MAST currently involves none.

LIN6 does not require any new administration than that for IPv4,
either.

The difference between LIN6 and MAST is efficiency, which is why
our team is working on LIN6 for multihoming support.

> until we understand it better, be simplistic and conservative.

Dave, it is *THE* problem (though it is a selection of an address
not an interface).

If you think you don't understand it very well, it would be wise to
be simplistic and conservative not to make any proposal.

Solving a new problem is not a conservative way of life.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 7 Sep 2003 23:44:15 +0200

> DNS for. Clearly, some mobility scenarios create challenges that 

I would argue that MAST doesn't perform the initial rendezvous, but 
rather just adds additional addresses to an existing context.

> 3. Multi-address use -- intelligently choosing among multiple available

Yes, this is obviously something we shouldn't overlook.  :-)

However unless I missed it twice, the MAST draft doesn't really discuss 
this. What is the idea here? Are transports supposed to know how to 
handle the additional addresses? Or does MAST sit between IP and the 
transport and adjust the addresses one uses to the addresses the other 
needs? If the latter is the case, then you need to decide your course 
of action with regard to the transport checksums. If you leave them 
alone there shouldn't be any problems as when the addresses are 
restored at the receiver, the checksum becomes valid again. Unless you 
use NAT, that is. I'm sure most NATs use incremental updates too the 
checksum so this would still work but I'm equally sure there are one or 
two out there that simply recompute the whole checksum, which isn't 
what you want here.

While we're talking about NATs: how is a host behind NAT going to be 
successfully multiaddressed? Does it make sense to address the corner 
case where this is possible, or should a NATted host just be a single 
homed correspondent to a multihomed system?

How are you going to decide when an address jump is in order?

How does MAST fit in the current communication model? Do you do MAST 
first and then a three way handshake? Set up TCP first and then do MAST?

> I agree.  That's why MAST says a) it's a hard problem, worthy of 
> study, and b) until we understand it better, be simplistic and 
> conservative.

Actually if you can jump addresses this is no longer a big issue. 
Unfortunately, if you negotiate in-band, you can't jump addresses when 
you need it most: after you notice that the first packet didn't make it 
to the other side.

Even cooler is letting the routers rewrite the source addresses so:

1. You always have a "good" source address in order to pass ingress 
filtering by your ISP
2. The other side gets to see it automatically when your view of the 
path to it changes

> MAST does not use up new address space in IPv4 or IPv6.  None.

Except that you need more than one address to get some use out of MAST, 
which is neither unusual nor a big deal for IPv6, but certainly the 
former and possibly the latter in IPv4.

> alternative address the right thing to do.

I was talking about the first address being dead, in that case it is.  
:-)   Unfortunately it isn't easy to see whether an address is dead, 
which I think is your point.

> I've always felt that the fastest way to switchover to an alternate 
> path is to already be using it.  Still, this is sensitive stuff and 
> needs to be
> approached carefully.

If we get the basic multihoming part right then this part is up to the 
transport guys. I'm sure they'll come up with something great.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 8 Sep 2003 18:29:08 +0859 ()

Iljitsch;

Read the draft and think.

> I'm sure most NATs use incremental updates too the 

That is an uninteresting implementation detail.

> first and then a three way handshake? Set up TCP first and then do MAST?

It is documented in the draft.

     Hence a host may initiate and conduct a classic, single IP-
     pair TCP connection. It may then separately query for remote
     host support of MAST and initiate a MAST exchange to be used
     by that connectivity.  Either participant is then free to
     add or remove addresses. Of course use of MAST may instead
     be performed before a transport context is established, so
     that future contexts immediately have access to multiple IP
     addresses.
 
> Actually if you can jump addresses this is no longer a big issue. 

Wrong.

Why you don't give any definition on "jump", that MAST support
the mechanism to change addresses does not help to solve *THE*
problem.

							Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 08 Sep 2003 13:55:51 +0300

Dave,

[I defer my detailed comments on MAST until later, since I still
  haven't had time to *really* contemplate the proposal.]

Dave Crocker wrote:

> HIP and LIN6 are tied to IPv6 and involve notable enhancements to the
> Internet architecture.  Both seem pretty clean to me, architecturally.

Well, HIP does demonstratably work with IPv4.  There are three
implementations that support IPv4.  Our HIP implementation
even supports mobility between IPv4 and IPv6, today.

What HIP does not do that well is IPv4 API support.  That is,
while most current IPv4 applications will work just fine,
including the most common FTP scenarios, there are applications
and use cases where HIP may (mostly indeterministically) fail.

Actually, HIP is even slightly more ambitious here.  It aims
to provide application interoperability between the IPv4 and
IPv6 APIs.  That is, with HIP an IPv4 client can talk directly
to an IPv6 server, and usually also vice versa.  Only if the
IPv4 client sends IP "addresses" over the application level
data stream, does the IPv6 server learn that its peer is
actually using IPv4 addresses.  However, if the IPv6 server
is able to handle these IPv4 "addresses", the "addresses" will be
mapped to the corresponding host identifiers inside the API,
if possible.  The case that apparently will not work is an IPv6 
application sending an IPv6 "address" to an IPv4 only application.

What comes to the architecture, yes, HIP basically presents an
architectural enhancement.  However, we expliclitly try to
avoid the amount of necessary changes, and restrict them
to the end nodes.

> interesting administrative load HIP and LIN6 impose some significant
> new administration. MAST currently involves none.

The base HIP specification expects very little administrative
overhead.  Basically, what is needed is to store the host
identifiers (or HITs) to the DNS.  However, HIP is able to work
even without them, in the opportunistic mode.  In that sense,
HIP can be deployed without any administrative overhead, if
so desired.

> I think that comparison of HIP, LIN6 and MAST will be helpful.   There
> are some pretty interesting differences among them.  I'm planning on
> doing something more detailed, but for now:

I would be very glad to see such a comparison.

> 1. The MAST proposal has a discussion of HIP.  I'm hoping that a HIP
> savant will tell me of any errors, so I can fix them.

I think that you have got it mostly right in the proposal, but
I haven't had time to think of all the details.  OTOH, I tried
to offer some corrections above, some comments below.

> By contrast, MAST introduces *no* new addresses on the wire.  New
> addresses within the end-nodes are not required, though internal use
> of private IP addresses is discussed as an implementation choice.

HIP explicitly uses "private IP addresses" within the stack, in order
to help the kernel to differentiate between HITs/LSIs and normal
IP addresses.  However, that is an implementation detail, and most
probably one could build an HIP implementation that does not do that.
However, given that HIP introduces a new name space, I don't see
any reason for trying to mix the name spaces.  The applications
won't be any happier, since HITs are not IP addresses, even if they
do look like ones.

Some people have suggested that it might be possible to implement
HIP in an external box and using the HITs/LSIs in the place of
IP addresses even locally in the wire.  While there may be some
value in the the proposal, I personally don't like it.

> 3. The LIN6 specification also provides for the rendezvous function,
> using DNS, which MAST chooses to defer. 

We have removed rendezvous from the HIP base specifications, and
plan to address is separately for first time rendezvous
(using DNS) and for mobility (new infrastructure).

SD> - One HIP issue I've wondered about, but have not mentioned in
SD>   public, is how an application might make of "whatever it THINKS
SD>   is the IP address" (because a mobile address/identifier looks
SD>   like any other address). What happens if an application expects
SD>   to do a reverse DNS lookup of a HIP HI, for instance?

Right now, if an application attempts to do a reverse DNS lookup
on a HIP HIT or LSI, that will fail.

To make reverse lookup work, some serious work is needed.  For LSIs,
the DNS library needs to convert them to HITs, and then try to do
reverse lookup of the HITs.   What comes to HITs, the issue is
still open, with proposals ranging from using the first bits in a
HIT to identify an assigning authority to using distributed hash
tables.

--Pekka Nikander

---

From: Fumio Teraoka <[email-masked]>
Date: Tue, 09 Sep 2003 22:00:21 +0900

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Dave,

Sorry for late response. There are some comments about the
description of the LIN6 identifier in your artcle as a co-author
of the LIN6 i-d.

LIN6 introduces a 64-bit "node identifier (node id)" which is
assigned to a node. The node id is not only a transport layer
identifier. The node id in LIN6 is used in the application layer,
the transport layer, and the network layer (possibly, in the link
layer). In the network layer, the node id is concatinated with a
64-bit network prefix to generate a IPv6 address. In the application
layer and the transport layer,the node id is concatenated with a 64-bit
"fixed value" to generate an identifier which is compatible with
the IPv6 address format.

Unfortunately, I have not read the MAST i-d yet. I'll read the i-d and
post some comments on this list.

Best regards,

Fumio Teraoka

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Sep 2003 23:23:33 -0700

Pekka,

Many thanks for the comments.

PN> Well, HIP does demonstratably work with IPv4.

yes.  sorry for my confusion.

PN> What HIP does not do that well is IPv4 API support.  That is,
PN> while most current IPv4 applications will work just fine,
PN> including the most common FTP scenarios, there are applications
PN> and use cases where HIP may (mostly indeterministically) fail.

I assume the problematic applications are those that embed IP addresses in
them. What others are there?

PN> Actually, HIP is even slightly more ambitious here.  It aims
PN> to provide application interoperability between the IPv4 and
PN> IPv6 APIs.  That is, with HIP an IPv4 client can talk directly
PN> to an IPv6 server,

I do not recall seeing the HIP specification call for IPv4/IPv6 packet
translation.  So I do not see how an IPv4-only host can talk with an IPv6-only
host, as a consequence of their both using HIP.  Where is this described in
the specification?

Hmmm.  Thinking a bit more, I think you mean IPv4 _application_, running on a
host that has IPv6, or vice-versa.  This would be expected to work because HIP
maps all address to a common type, from the perspective of the application.
(Sounds like a NAT between IP and Transport, doesn't it?)

When an application opens a connection by specifying the target's domain name,
I can see this working.  When the application does the DNS query and then
hands to address to TCP to do the open, there will be a problem, no?  The
application has to carry the address for a brief time.

PN> The base HIP specification expects very little administrative
PN> overhead.  Basically, what is needed is to store the host
PN> identifiers (or HITs) to the DNS.

HITs are a new, global name space.  Hence there needs to be a new, global
administrative structure for managing HIT assignments.

PN>   However, HIP is able to work
PN> even without them, in the opportunistic mode.

And that's where things get confusing for me.  If HIP works with
randomly-generated HITs, then why are globally-assigned ones needed?

>> of private IP addresses is discussed as an implementation choice.

PN> HIP explicitly uses "private IP addresses" within the stack, in order
PN> to help the kernel to differentiate between HITs/LSIs and normal
PN> IP addresses.

Yes, it does seem to take care of the different scenarios.  I must admit that
a scheme that calls for up to 3 different strings, to refer to the same thing
-- in addition to domain name and IP address(es) -- strikes me as rather
daunting.

PN> Some people have suggested that it might be possible to implement
PN> HIP in an external box and using the HITs/LSIs in the place of
PN> IP addresses even locally in the wire.

Note the MAST section called "MAST in NAT".  It occurred to me, too, that it
might be possible to hide all of this from the hosts on a subnet, by placing
all the functionality on an access gateway.

>> using DNS, which MAST chooses to defer. 

PN> We have removed rendezvous from the HIP base specifications, and
PN> plan to address is separately for first time rendezvous
PN> (using DNS) and for mobility (new infrastructure).

ok.

PN> To make reverse lookup work, some serious work is needed.

mumble.  yes.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Sep 2003 23:33:01 -0700

Fumio-san,

Thank you for the quick response.  (It was not late at all.)

FT> LIN6 introduces a 64-bit "node identifier (node id)" which is
FT> assigned to a node. The node id is not only a transport layer
FT> identifier. The node id in LIN6 is used in the application layer,
FT> the transport layer, and the network layer (possibly, in the link
FT> layer).

Although the node id might come from the link layer id, it takes on its
property as a LIN6 node id in the LIN6 module. I did not see that it was used
in the IP layer. Have I missed something?

Let me explain why I am calling the LIN6 node id a transport-level value:

From my reading of the LIN6 specification, I believe that the primary purpose
of the node id is for the transport layer, so that the transport layer will
not see the changing IP addresses. Yes, it might also be passed up to the
application, but that is not its primary purpose or use. IP addresses also get
passed to application, but we consider them a Internet-layer value.

So, yes, one could call the node id a network-level value. Or a
transport-and-above value.  As I was reading LIN6, I found it more helpful
simply to think of it as a transport-level value.

d/

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 10 Sep 2003 16:12:06 +0859 ()

Dave;

> simply to think of it as a transport-level value.

You are arguing that one could call a host identification function of
a host address is at network-level or transport-and-above and that
it is more helpful simply to think of it at transport-level.

The argument is obviously wrong.

> I did not see that it was used

Yes, it is and you have.

							Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 10 Sep 2003 14:08:09 +0300

> them. What others are there?

There are two classes of IPv4 applications that will have problems
with HIP:

  1. Applications that embed addresses in application datagrams,
     e.g., FTP and SIP.  These will mostly work, but will in some
     fairly rare corner cases fail, sometimes "mysteriously".  (With
     "mysteriosly" I mean that the user is likely to be confused.)

  2. Applications that interpret the structure of IP addresses and
     try to understand it.  Many of these will work, too, since
     HIP LSIs look like vanilla IPv4 unicast address from 1.0.0.0/8
     subnet.

As far as I can see, all other IPv4 applications should just work.

What comes to IPv6 applications, the probability of the above
mentioned "mysterious" failures becomes so low that it can be
safely ignored.  (Less than the probablity of randomly picking
a given atom in the universe, or in the order of 2^-250.)  On the
other hand, administrative applications that do interpret the
structure of IP addresses probably need to be updated.

> host, as a consequence of their both using HIP.  Where is this described in

If you have a HIP aware IPv4-IPv6 NAT box, why not?  Such a
NAT box just NAPTs the IP headers, leaving the ESP and its
content untouched.  (No, this has not been explicitly defined
in the specifications yet, but it should be fairly trivial.  See also
http://www.tml.hut.fi/~pnr/HIP/draft-nikander-hip-nat-00.txt )

> maps all address to a common type, from the perspective of the application.

Exactly.  See draft-moskowitz-hip-07.txt, Section 3.5.

> (Sounds like a NAT between IP and Transport, doesn't it?)

Well, one view to HIP is that HIP contains a specialized form of
Bellovin's HostNAT.  See also
http://www.tml.hut.fi/~pnr/BEET/draft-nikander-esp-beet-mode-00.txt
(Another draft that I haven't submitted yet.)

> application has to carry the address for a brief time.

When an application does a DNS query, it gets an LSI or a HIT as
a result.  An easy change to the DNS library.

> randomly-generated HITs, then why are globally-assigned ones needed?

There are two types of HITs.  The randomly generated ones are those
that are specified in the current base spec.  A previous version of
the base spec also defined globally-assigned ones, but that has been
moved to a future specification due to dependencies with the DNS.
The base specification only contains a placeholder for the
globally-assigned ones.

I have to admit that I don't really remember the reason for having
globally-assigned ones.  Bob should be able to answer, though.
(Here I will just carry on Bob's ideas and make sure that
the HIP-DNS spec will define the globally-assigned ones in
a precise enough way.)

> ....  I must admit that

Sometimes you have to pay a price for backwards compatibility.  I have
a student working on a native AF_HIP socket API.

--Pekka Nikander

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2003 09:37:24 -0700

Pekka,

>> host, as a consequence of their both using HIP.  Where is this described in

PN> If you have a HIP aware IPv4-IPv6 NAT box, why not?

translating gateways that are aware of new services can usually cover a host
(small pun) of sins.

forgive me for suggesting that this is like saying that I can spend dollars in
EU countries.  all I need is to have a currency exchange in every EU store.

PN> Such a
PN> NAT box just NAPTs the IP headers, leaving the ESP and its
PN> content untouched.

The issue is how much change to the infrastructure is required, and when.

>> -- in addition to domain name and IP address(es) -- strikes me as rather

PN> Sometimes you have to pay a price for backwards compatibility.

And sometimes you don't.

This is yet-another reason MAST avoids a new public namespace,

d/

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 12 Sep 2003 10:38:46 -0700 (PDT)

> for the security MAST needs to provide, specifically to avoid hijacking the

A perhaps useful data point is that during the exercise of securing MIPv6
binding updates to arbitrary correspondents I originally thought that
something  like PBK would be the result, but some careful anaylsis resulted in
a simpler  scheme which just uses 3-way handshake to effictive establish a
cookie. (Both PBK and MIPv6 with this technique are subject to MiTM attacks
by somebody on the path over which the packets travel, so the
resulting security is close to the same.)

YMMV - multihoming locator switching might have some other factors to
take into account when doing the tradeoffs on how to provide security.

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 12 Sep 2003 21:02:31 +0300

Dave,

Dave Crocker wrote:

>>> So I do not see how an IPv4-only host can talk with an IPv6-only

Well, I would say that it is more like a service that allows us to
buy goods from US web stores using euros.  There just will be a box
in between which translates the dollar figures in euro figures,
and the bank will do the rest :-)  That is, you get the feeling that
you are using only euros, while you are not.  It is natural that
someone has to do something to make it work.

> The issue is how much change to the infrastructure is required, and when.

You have to pay a price for IPv4-IPv6 interoperability anyway.
If the HIP price is lower than the NATPT/SIIT/... price, it may
make HIP more acceptable or even lucrative at the market.

> PN> Sometimes you have to pay a price for backwards compatibility.

HIP may be slightly more expensive than something else, but you
get so much more in the box. :-) And better design quality, too :-)

Maybe HIP will be the mac while MAST the windows of this field :-)
You get what you pay for.  :-)

--Pekka

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2003 18:59:13 -0700

Erik,

EN>... I originally thought that
EN> something  like PBK would be the result, but some careful anaylsis resulted in
EN> a simpler  scheme which just uses 3-way handshake to effictive establish a

This is pretty interesting. I know enough about security issues to appreciate
their difficulty and to be able to compare different designs. I don't know
enough to be clever in designing one myself.

Still, I had originally thought that a basic 4-way notification/response sequence
-- each side notifies the other of the nonce it will use and the other side
confirms -- ought to provide enough security for this purpose.

In any event, what is clear is that there are a number of adequate choices
available. For the purposes of MAST's design approach, any of them is fine.

Whatever folks prefer -- as long as it does not require going to an outside
certificate authority, or the like -- is certainly acceptable to me.

d/