Subject: Re: Fwd: Minutes / Notes

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 17 Jul 2003 12:16:41 -0400

> From: Kurt Erik Lindqvist <[email-masked]>

    > Please find attached Geoff minutes from yesterday. Please send comments
    > to me _off list_ and I will add them.

I have a few technical (not editorial) comments on some points in the minutes,
which are therefore of general interest...

    > Iljitsch van Beijnum: the focus is on TCP and you can't have a TCP
    >  that switches addresses mid-flow because you don't have API support
    > Christian Huitema: The reason here is the protocol specification of TCP,
    >  not the API

This is only important if you want TCP connections to be able to survive
having an incoming link fail (i.e. the address on the local end becomes
unreachable to the rest of the network). This may not be an important goal
(e.g. the typical web site wouldn't care).

    > Iljitsch van Beijnum: Obviously we can modify TCP without the API but
    >  we see modifying the network layer
    > Christian Huitema: The socket API constrains the solution you are
    >  saying that the socket API is the problem.

Well, actually you could modify the protocol without modifying the API: the
"address" handed back and forth across between the application and network
layer(s) would be a "token" using the same syntax as an IP address, which
translates internally in the network layer to the appropriate address(es) for
the far end. The problem, of course, is that the "token" is of only local
scope to the host, and thus can't be handed to third parties to allow them to
contact the other end (think the same problem as NAT). That's easy to fix -
you only hand around the name you start with (e.g. DNS - again, same fix as
to this problem in NAT).

There is one issue with modifying TCP (it's a pretty easy upgrade - you
define a TCP option which allows you to specify additional addresses and/or
switch to a different address), which is that with an unmodified TCP on the
other end, you then don't have this capability. But you may not care (see
preceding point).

	Noel

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 18 Jul 2003 15:40:01 +0859 ()

Noel;

> which are therefore of general interest...

A problem is that the minutes lacks discussioin on so many errors of
Iljitsch's proposal that yo are repeating my points at the meeting
(save TCP survivability as I said TCP is not IP, the Internet Protocol).

> Well, actually you could modify the protocol without modifying the API:

Yes.

LIN6 was and still is implemented so, though it has other APIs.

I said so at the meeting but the statement is missing from the draft
minutes.

> other end, you then don't have this capability. But you may not care (see

It is a little more hard. If you have several addresses, TCP limitation
on option length makes it not interoperable with unmodified TCP.

You may use multiple exchanges of packets for carrying more addresses or
for option length negotiation, which means extra amount of delay and
additional complexity.

An easy solution is to use separate address spaces (within 128 bit
space of IPv6) for leagacy and new IPv6 hosts. Then, you can use
larger header between new hosts. It is implemented and running.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2003 15:11:41 +0200

On vrijdag, jul 18, 2003, at 08:41 Europe/Amsterdam, Masataka Ohta 

> Iljitsch's proposal that yo are repeating my points at the meeting

Well, let's hear it then. What are those errors?

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jul 2003 17:43:52 +0859 ()

Iljitsch;

> Well, let's hear it then. What are those errors?

1) On slide of "loc/id separation", the mapping from FQDN should not be

	FQDN -> ID -> Locators

but should be

	FQDN -> (ID, Locators)

to avoid extra mapping and possible security problem.

2) On slide of pros and cons of "small", all the "cons" are wrong as follows.

	2.1) Work with unaggregatable MAC namespace
	or break autoconfiguration

	Structured ID can be autoconfigured by DHCP.

	2.2) Can't trust incoming id-loc association

	Association between an ID and locators is secure if they
	are contained in a single packet.

	2.3) If not break, certainly bend transports

	With LIN6 trick, API for TCP stays same.

	2.4) Changes to both hosts and routers

	There is no changes to routers

There are other errors I didn't bothered to correct.

							Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 24 Jul 2003 12:42:39 +0200

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Masataka Ohta
> Enviado el: jueves, 24 de julio de 2003 10:45
> Para: Iljitsch van Beijnum
> CC: [email-masked]
> Asunto: Re: Minutes / Notes
>
>
> Iljitsch;
>
> > >> I have a few technical (not editorial) comments on some
> points in the
> > >> minutes,

Are you claiming that an ID to locator mapping is not needed?

> 	Structured ID can be autoconfigured by DHCP.

I guess Iljitsch was talking about stateless autoconfig RFC 2462

> 	are contained in a single packet.

No. It is less secure than today usage of IP addresses (not talking about
DNS)
(see previous mail)

Regards, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jul 2003 20:53:51 +0859 ()

Marcelo;

> Are you claiming that an ID to locator mapping is not needed?

No. See (hopefully revised) minutes.

> I guess Iljitsch was talking about stateless autoconfig RFC 2462

RFC2462 does not give any useful definition of autoconfiguration.

For example, in DNSOP WG, people, including those of IPv6 ones,
are discussing autoconfiguration with DHCP.

> No. It is less secure than today usage of IP addresses (not talking about

It is as secure as the Internet today with an address binded both to
an ID and an locator.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Jul 2003 20:50:52 +0200

On donderdag, jul 24, 2003, at 10:44 Europe/Amsterdam, Masataka Ohta 

> to avoid extra mapping and possible security problem.

That's not an error. There is no way to pass all locators to the socket 
API.

> 	Structured ID can be autoconfigured by DHCP.

DHCP doesn't exist (yet) in IPv6. And for good reason: it is very hard 
to operate this in a useful way.

> 	are contained in a single packet.

So if I call you and say my name is George W. Bush and give you my 
phone number, you believe the mapping between Bush' identity and my 
phone number is correct because it all happened in one exchange?

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2003 08:35:43 +0859 ()

Iljitsch;

> That's not an error. There is no way to pass all locators to the socket 

It means that there are additional errors.

First, it is not an API issue that, if multihoming can be handled
by the transport layer like TCP case, you can keep the current API.

Second, it is trivially easy to add a new address family to the socket
API to pass multiple addresses to it.

> DHCP doesn't exist (yet) in IPv6.

Wrong.

What does not exist in IPv6 is useful definition of autoconfiguration.

> And for good reason: it is very hard 

It is merely that it is very hard to operate IPv6 autoconfiguration
in a useful way.

But, that is not my problem.

> phone number is correct because it all happened in one exchange?

Not at all.

Instead, mapping between a phone number as an ID and a phone number
as a locator is secure.

							Masataka Ohta.

---

From: FUJIKAWA Kenji <[email-masked]>
Date: Fri, 25 Jul 2003 12:23:46 +0900

At Thu, 24 Jul 2003 20:53:51 +0859 (),
> > > 	are contained in a single packet.

Yes, it is.

However, the following notification should be mentioned together.

If ID/locator association is once established,
the association cannot be changed without another checking mechanism,
even when receiving a packet implying different association.

ID/locator association should be managed in each connection 
separately if another checking mechanism is not provided.

> It is as secure as the Internet today with an address binded both to
---------------------------------------------------------------
FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan
 WWW: http://www.lab1.kuis.kyoto-u.ac.jp/~fujikawa/index-e.html
                        TEL +81 75-753-5387 FAX +81 75-751-0482
                              E-mail [email-masked]

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 25 Jul 2003 07:21:59 +0200

> are discussing autoconfiguration with DHCP.

Yes. But in the meeting it was pointed out after your question that 
this was referring to the features described in 2462.

> It is as secure as the Internet today with an address binded both to

a) I don't think that maintaining the security level of todays Internet 
is a goal
b) Introducing loc / id separation will require mapping, one way or the 
other. Even in LIN6 there is mapping between the layers. This 
introduces new bindings that needs to be secured.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 25 Jul 2003 08:00:04 +0200

>> DHCP doesn't exist (yet) in IPv6.

AFAIK there is no published standard for DHVPv6

> What does not exist in IPv6 is useful definition of autoconfiguration.

Noone is arguing against you. It's just that the rest of us are talking 
about a very specific case of autoconfiguration.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2003 17:33:58 +0859 ()

Kurt;

> this was referring to the features described in 2462.

And, then, it was pointed out that RFC 2462 is useless to define
autoconfiguration.

> a) I don't think that maintaining the security level of todays Internet 

I have never seen such requirement nor proposal.

Note, for example, that HIP, having no cryptographic security on
initial identity, merely maintains the security level of todays
Internet.

> other.

Wrong. The separation requires that a host know id and locators of
its peer with reasonable security.

> Even in LIN6 there is mapping between the layers.

It's LIN6 mobility.

> This introduces new bindings that needs to be secured.

The separation requires that a host know id and locators of its
peer with reasonable security. An initial packet of a connection
containing all of them is just secure.

LIN6 mobility, of course, needs other forms of security.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2003 17:52:12 +0859 ()

Kurt;

> AFAIK there is no published standard for DHVPv6

And there is no published standard for LIN6, though LIN6 does
exist in IPv6.

It should be noted that people working on IPv6 autoconfiguration
now assumes DHCPv6.

> about a very specific case of autoconfiguration.

The problem is that there is no clear definition given on the
autoconfiguration neither by IPv6 RFCs nor by those who claims
to be talking about a very specific case of autoconfiguration.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 25 Jul 2003 11:18:17 +0200

On vrijdag, jul 25, 2003, at 10:53 Europe/Amsterdam, Masataka Ohta 

> It should be noted that people working on IPv6 autoconfiguration

They should talk to some operations people. After living without DHCP 
in IPv6, I doubt very many people want to go back to having to 
configure all this stuff on servers rather than having it happen 
automatically.

---

From: Tim Chown <[email-masked]>
Date: Fri, 25 Jul 2003 10:42:27 +0100

> configure all this stuff on servers rather than having it happen 

I agree.

But there is no automatic way to get DNS resolver info in IPv6.

In all proposals to date, somewhere something needs to be configured, 
be it in a DHCPv6 (Lite) server, in a router sending the RAs, by setting 
up site local routing (though that seems dead :) or by Masataka's method 
(where the routing entry is configured).

Tim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 25 Jul 2003 12:21:25 +0200

> (where the routing entry is configured).

If you think about it, having to find an address for a server that 
helps you find addresses is somehwat bizarre... I think it makes much 
more sense to hardcode these addresses in the OS (should be possible to 
override by the administrator of course). This goes both for the root 
servers which of course need regular address space and for on-site 
resolvers which then need site local addresses. So I guess we have a 
good use for site local addresses after all.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2003 20:02:07 +0859 ()

Iljitsch;

> helps you find addresses is somehwat bizarre...

Not so much.

It becomes really bizarre, when people start requesting
autoconfiguration of a lot more than that such as DNS dynamic
update which naturally requires configured shared secret.

> I think it makes much 
> override by the administrator of course).

FYI, that's my proposal to appear as draft-ohta-preconfigured-dns-00.txt,
though you misunderstand the important detail.

> This goes both for the root 
> servers which of course need regular address space

You should be more aggressive for root servers, as I described
in a separated ID.

> and for on-site resolvers which then need site local addresses.
> So I guess we have a 

No, scoped addresses make the proposal poor.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2003 20:16:37 +0859 ()

Tim;

> But there is no automatic way to get DNS resolver info in IPv6.

Operational people MUST still configure all that stuff on DNS
servers for their domain.

Or, do you want to live without DNS?

FYI, I was living without DNS in IPv4 that I don't want to do so
with addresses four times (or more with multihoming) more lengthy.

> (where the routing entry is configured).

Recursive servers, of course, need SBELT information configured,
unless fixed root server addresses are standardized.

But, that's all.

Recursive servers can be preconfigured too, by default, to have
an anycast address to be advertised by some default routing
protocol.

						Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 29 Jul 2003 12:28:10 +0200

> And, then, it was pointed out that RFC 2462 is useless to define

Noone said that 2462 gives the definition of autoconfiguration. We 
where talking about the technology described in 2462.

> I have never seen such requirement nor proposal.

I think that anything that can improve the security of todays Internet, 
tomorrows Internet and yesterdays Internet will be looked upon 
favorably.

> its peer with reasonable security.

That is a mapping state in it self.

> containing all of them is just secure.

That is as secure as the trust relationship of the creator of the 
packet.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 29 Jul 2003 12:30:12 +0200

> And there is no published standard for LIN6, though LIN6 does

There are a lot of things that exists and that is related to IP, TCP, 
UDP and the Internet that is not standard.

> It should be noted that people working on IPv6 autoconfiguration

 From what I have been reading people seems to be assuming DHCPv6 and 
2462.

> to be talking about a very specific case of autoconfiguration.

Noone is arguing against you.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Jul 2003 20:05:31 +0859 ()

> Noone said that 2462 gives the definition of autoconfiguration.

Wrong.

My question is on definition of autoconfiguration of the
presentation by Iljitsch.

Iljitsch could not provide any answer.

As I further asked, Erik said that 2462 gives the definition of
the autoconfiguration of the presentation.

> tomorrows Internet and yesterdays Internet will be looked upon 

An abstract nonsense.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Jul 2003 20:15:30 +0859 ()

Kurt;

>  From what I have been reading people seems to be assuming DHCPv6 and 

Are you now saying DHCPv6 defined? If you are saying it defined,
where, do you think, I can find your definition?

From what I have been reading some people seems to be assuming
DHCPv6 by ignoring 2462. Some other people seems to be simultaneously
assuming both DHCPv6 and 2462 ignoring the contradiction between them.

							Masataka Ohta

PS

While I can continue the argument, others may not. As an expert on
autoconfiguration issues, my advice on the WG is that multi6 WG
should ignore autoconfiguration entirely unless useful definition
of it could be defined by someone else.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 29 Jul 2003 07:34:47 -0400

Technically, no, there is no published standard for DHCPv6 because the RFC
isn't quite done.  The authros have been integrating results form
interoperability tests and correcting a couple of last bugs discovered
during the authors 48 hour final review period.

Practically speaking, the standard is sufficiently well-understood that
there are several (at least six) implementations that have been successfully
demonstrated interoperability in three rounds of open interoperability testing.

- Ralph

At 08:00 AM 7/25/2003 +0200, Kurt Erik Lindqvist wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGP 8.0.2
>
>iQA/AwUBPyDHZ6arNKXTPFCVEQLv4ACglmRgrDhl016UM3eFuoMJIeC8S4IAoOjZ
>rE+ua7aSX9WYbdzoKTkd2ZKA
>=88jJ
>-----END PGP SIGNATURE-----

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Jul 2003 20:24:31 +0859 ()

Kurt;

> That is a mapping state in it self.

It is a state. You can call it a mapped state. But, there is no
mapping service required.

That no service required means no additional security required.

> That is as secure as the trust relationship of the creator of the 

Exactly.

> >> This introduces new bindings that needs to be secured.

is wrong and the existing bindings has certain security which
is just enough for weak security.

HIP, having no trust relationship between the creators of the initial
packets, for example, means no better security, even though HIP
tries to, in vain, cryptographically maintain identify of the creators.

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 29 Jul 2003 14:08:52 +0200

> Iljitsch could not provide any answer.

 From what I remember Iljitsch said he didn't know the RFC number.

> the autoconfiguration of the presentation.

I remember this as Erik saying that 2462 was what was referred to with 
"autoconfiguration".

>> tomorrows Internet and yesterdays Internet will be looked upon

So you think that keeping security the way it is today is more 
desirable than improving it?

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 29 Jul 2003 14:11:42 +0200

> where, do you think, I can find your definition?

Ok, poor wording in the mail you quoted and the one before that. With 
defined I meant published as standard. As Ralph points out in his mail 
this is however close though.

> assuming both DHCPv6 and 2462 ignoring the contradiction between them.

This I agree with.

> of it could be defined by someone else.

Agreed. All this started with the discussion on what was said in the 
minutes, and this is way off-topic.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 29 Jul 2003 14:15:43 +0200

> mapping service required.

This depends on what you mean with mapping service.

> That no service required means no additional security required.

You suggested that the tokens be transfered OOB, that is a security and 
a state as well. Most likely a very costly one.

> is just enough for weak security.

The bindings will need some form of security. How you do this is part 
of the discussion.

> tries to, in vain, cryptographically maintain identify of the creators.

I think this has been discussed by Pekka already.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Jul 2003 21:42:05 +0859 ()

Kurt;

> I remember this as Erik saying that 2462 was what was referred to with 

So? What is your point?

Erik said that 2462 was what was referred to with "autoconfiguration"
of the presentation.

However, as I repeatedly said with evidences of confusions in other

> >>>>> RFC2462 does not give any useful definition of autoconfiguration.

Are you agreeing with me that RFC2462 is nothing?

> desirable than improving it?

It is not my statement but is a simple fact of life that the
best thing we can do on security is keeping security the way it
is today.

Any attempt to do otherwise is to degrade it.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Jul 2003 21:50:16 +0859 ()

Kurt;

> This depends on what you mean with mapping service.

OK, we have no disagreement here, save minor terminology issues.

> You suggested that the tokens be transfered OOB,

No, not in general.

However, it is requied for mobility though.

It should be noted that, when IPv4 mobility was developed, security
experts reviewed the protocol and modified it to reuire the security
with the shared secret transfered OOB.

> that is a security and 

So? Mobility costs, of course.

> The bindings will need some form of security. How you do this is part 

I have been saying that that they are contained in a single packet
means binding with just enough security.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Jul 2003 21:54:37 +0859 ()

Kurt;

> minutes, and this is way off-topic.

No.

My point started with the discussion on what was said in the 
slide of Iljitcsh.

I'm glad that you admit a point on "Cons" of "Small" is wrong.

							Masataka Ohta