Subject: Should connecting to the Internet be Optional?

From: "Tony Hain" <[email-masked]>
Date: Mon, 4 Mar 2002 09:06:47 -0800

Margret has raised several valuable questions about
draft-ietf-ipv6-cellular-host-00.txt, which show it is clearly is not
ready for last call. While I am willing to believe that there are valid
reasons to make adjustments based on characteristics of the link, this
document is fundamentally flawed because it is based around the pretense
that small footprint devices are somehow special. We MUST NOT allow
ourselves to modify well thought out architectural fundamentals based on
point-in-time engineering constraints that are dubious at best. If a
device wants to participate as an Internet node, there are basic
requirements. Of course, participating in the Internet is optional, so
if a device would prefer to avoid the requirements, it may choose to
create its own universe.

The argument that small devices have limited processors or memory
overlooks the fact that the processor and memory of many hand-held
devices today is significantly greater than the workstations that were
available when IPv4 was defined. Interesting point; there was no problem
getting the stack and an array of applications to fit then. Another
interesting point; there are frequently rumors that laptops will include
cellular interfaces, so where does the processing and memory constraint
fit in that case?

On the subject of applications, the absolute BS about limiting the
application set to avoid an IPsec requirement is something that belongs
in a product development discussion, NOT a standards discussion. The one
point that should be clear is that over time the number of applications
used via wireless (cellular or otherwise) will grow, and that we can't
predict what they are, much less what they will need from the stack. To
that point, we MUST reiterate that ***ALL IPv6 IMPLEMENTATIONS MUST
INCLUDE SUPPORT FOR IPSEC***. If we relax that requirement, applications
will never be able to expect support, therefore will have to keep
inventing their own mechanisms. The only way to prevent new applications
from appearing on computing devices is to put the executable code in
non-rewritable, non-replaceable, rom.

If a document on cellular requirements makes any sense, it has to be
based on differences in fundamental characteristics of the air link, not
the device on either end. Avoiding DAD simply due to expense is not a
valid justification, but if the loss characteristics of the link make it
more problematic than valuable, there may be an argument. Keep in mind
that doing so precludes the use of RFC3041 addresses, so the
applications where anonymity is most valuable (as one moves around and
doesn't movement traced) are precluded. A non-zero probability of
collision requires a mechanism to resolve duplicates, and DAD is the
currently defined one. If another one exists that makes more sense over
a lossy air-link, we should consider replacing DAD because it will
probably be more reliable in the general case as well.

Tony

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Feico Dillema <[email-masked]>
Date: Mon, 4 Mar 2002 18:33:26 +0100

> non-rewritable, non-replaceable, rom.
And require these devices to be tamper-proof ;-}.

Feico.

---

From: Keith Moore <[email-masked]>
Date: Mon, 04 Mar 2002 13:21:25 -0500

> non-rewritable, non-replaceable, rom.

actually, I disagree, slightly.  I think we designed these rules for
general-purpose hosts and it's not necessarily a good idea to make them
apply to fixed-function devices.  if none of the applications on a host
can make use of IPsec, and the host is inherently not configurable to
set policy based on IPsec then I don't see why the host should have to
implement IPsec.

OTOH as soon as you make the host programmable, or make it possible
to set policy on the host then it's worth considering whether IPsec 
should be a requirement again.

similarly, a host that is strictly an endpoint and has no way of routing
messages to other hosts doesn't need to support routing protocols.  but 
as soon as the host can route messages to other hosts (such as via the
data port of a cell phone) then it needs to be able to act as a router.

(I also think the requirement to impose IPsec on hosts is of dubious value
unless IPsec is usable by applications, but that's a separate discussion.)

I think the cell phone requirements document would do well to break
down the different cases:

- cell phone with fixed functions vs.
- cell phone that can host applications

- cell phone that is strictly an endpoint vs.
- cell phone that can provide net connectivity to other devices

and examine requirements separately for each case.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 4 Mar 2002 11:04:10 -0800

I agree with one comment:
> > The only way to prevent new applications

Tony

Actually another thought; what is the difference between a handset and a
laptop that has an embedded 3G radio? Are they both cellular hosts?

---

From: "Jari Arkko" <[email-masked]>
Date: Mon, 4 Mar 2002 21:38:43 +0200

> - cell phone that can host applications

This is an interesting division and perhaps an
important one. There's by the way different kinds
of 'fixedness' -- complete burn-in fixed systems and
upgrade-at-the-dealer systems. In the latter case
typically all of the software gets changed at the same
time, so for the purposes of requiring something from
the IP stack it's pretty similar to completely fixed systems.

Hosts that can run new apps per user request are a
different class from these as you point out.

> - cell phone that can provide net connectivity to other devices

On this one I think we have made the case very clear
by talking about _host_ requirements document. The
router case is important, but left as a future exercise.

Jari

---

From: "Jari Arkko" <[email-masked]>
Date: Mon, 4 Mar 2002 22:24:00 +0200

> Given that *existing* cell phones already act as (two-port) IP routers,
> I don't think it's a good idea to defer that case to the future. 

(Are you sure you don't refer to link-layer / bridging capability?)
Anyway, we agree on the importance of the router case because
at least I personally believe the interesting stuff gets here when
we have Personal Area Networks and such.

Could do that in a separate document, though, seems there's
enough to discuss even if only hosts are mentioned ;-)

Jari

---

From: Keith Moore <[email-masked]>
Date: Mon, 04 Mar 2002 15:26:08 -0500

> enough to discuss even if only hosts are mentioned ;-)

a separate document is fine w/me; 
deferring work on such a document isn't.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 04 Mar 2002 15:09:17 -0500

Keith

---

From: Pekka Savola <[email-masked]>
Date: Tue, 5 Mar 2002 10:30:55 +0200 (EET)

On Mon, 4 Mar 2002, Tony Hain wrote:

(Half-) seriously.. I think connecting to the Internet MAY be optional.

I discussed in lcna-minreq thread; I think that if a node like that can
not implement IPSEC or security in general, it MUST NOT have a global
address.  Under some cornercases, link-local and/or site-local _might_ be
remotely acceptable.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: OKABE Nobuo <[email-masked]>
Date: Wed, 06 Mar 2002 10:14:19 +0900 (JST)

From: Pekka Savola <[email-masked]>
Subject: Re: Should connecting to the Internet be Optional? (Half-serious!)
Date: Tue, 5 Mar 2002 10:30:55 +0200 (EET)

> address.  Under some cornercases, link-local and/or site-local _might_ be

The authors decided to change security related part of our LCNA draft.

We can not show exact wording yet.
But we hope that this can be comprehensive answer
for the WG's security concern.

1) The ID must not permit null security LNCA.
   
2) The ID treats IPsec as a MUST requrirement.

3) When we introduce IPsec to LCNAs
   we will face practical issues.
   If so, we will feedback our issues to the WG
   as our current practice with somehow (ex. another draft or so).

The heart of the decision is not to harm
"well thought out architectural fundamentals" (as Tony Hain said),
but to respect the one.

At the same time, we also concern feasibility 
about LCNA security.

Therefore, it seems better way to feedback
our practices to the WG than to compromise
the fundamentals.

We hope our effort contribute the WG.

thanks,

---- nobuo