Subject: An architectural draft

From: Masataka Ohta <[email-masked]>
Date: Tue, 27 May 2003 21:29:04 +0859 ()

Attached is a very rough draft ID on what can, or actually
must, be changed with the current IPv6 specification.

						Masataka Ohta
--

INTERNET DRAFT                                                   M. Ohta
draft-ohta-sipa-00.txt                     Tokyo Institute of Technology
                                                                May 2003

                    Simple Internet Protocol, Again

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   IPv6 has failed to be deployed partly because of its complexity.

   IPv6 mostly is a descendant of SIP (Simple Internet Protocol) but has
   fatally bloated merging with other proposals and trying to make IPv6
   has better functionality than IPv4, which makes IPv6 unnecessarily
   complex and, thus, worse than IPv4.

   SIPA (Simple Internet Protocol, Again) is a proposal attempting to
   restore simplicity to IPv6 sticking to the real world operational
   requirements for the IPv4 Internet to make IPv6 more acceptable to
   ISPs and end users.

1. Introduction

   IPv6 has failed to be deployed partly because of its complexity.

   It is a complexity of not only coding but also operation.  It should
   be noted that, even though running code may be widely available, it
   is not because IPv6 is so simple that implementors enjoyed coding

M. Ohta               Expires on November 25, 2003              [Page 1]

INTERNET DRAFT      Simple Internet Protocol, Again             May 2003

   (which was why, in good old days, running code principle was a good
   measure of protocol quality) but because governments and vendors put
   large amount of effort and money on it.  Still, among so many IPv4
   ISPs, few operate it and ratio of IPv6 end users to IPv4 ones are
   even smaller.

   Deployment is an operational issue and IPv6 has failed and will
   continue to be failing to be deployed.

   IPv6 mostly is a descendant of SIP (Simple Internet Protocol) but has
   fatally bloated merging with other proposals and trying to make IPv6
   have better functionality than IPv4, which makes IPv6 unnecessarily
   complex and, thus, worse than IPv4.

   SIPA (Simple Internet Protocol, Again) is a proposal attempting to
   restore simplicity to IPv6 sticking to the real world operational
   requirements for the IPv4 Internet, to make IPv6 more acceptable to
   ISPs and end users.

   With SIPA, IPv6 should become easy to code and operate.

   In this memo, legacy IPv6 is called CIP (Complex IP), "the Internet"
   means one in the real world, that is, the IPv4 Internet, and a router
   is a host.

2. Requirements

   The original requirement for CIP was:

      Support large number of hosts large enough to make the IPv6
      Internet for everyone.

   which resulted in bloated CIP.

   The followings are the additional requirements to SIPA based on the
   operational reality of the Internet.

      Suppress the number of global routing table entries even if
      everyone are multihomed to the IPv6 Internet.

      Make packet format compatible to CIP to make SIPA work over legacy
      routers.

      Remove all the features of CIP against the end to end principle.

      Remove all the features of CIP not present in IPv4. No
      applications on the Internet use them.

M. Ohta               Expires on November 25, 2003              [Page 2]

INTERNET DRAFT      Simple Internet Protocol, Again             May 2003

      Remove all the features of CIP not used in IPv4 Internet. No
      applications on the Internet use them.

      Remove all the features of CIP not useful in IPv4 Internet. No
      applications on the Internet need them.

3. Removed Features

   The following subsections list features of IPv6 removed to make IPv6
   simpler and more deployable.

3.1 IP Header Options

   Optional headers are not used on the Internet and is forbidden.
   Except for an optional fragmentation header, which is used on the
   Internet, a transport header follows immediately after an IP header.

   Options visible to routers is a direct violation of the end to end
   principle and just harmful.

   Note that use of a routing header by MIPv6 is architecturally wrong,
   as a home agent is, like mail relays, an end system that it should be
   an destination option.

   In addition, except for a fragmentation header, destination option is
   still forbidden. It should be implemented at protocol (see section
   3.3, for example) or transport level.

3.2 ToS & Flow Labels

   ToS & flow labels are forbidden. RSVP is far less deployed than IPv6.
   Even if it is deployed, removal of IP header options makes it easy
   for routers access port numbers or SPI (see section 3.3) that flow
   labels are not unnecessary.

   While the field for ToS & flow labels is large enough to hold
   fragmentation information (because MTU is large) not as an optional
   header, it makes SIPA not compatible to CIP.

   So, for possible future extension (such as that ECN is proven to be
   useful over the Internet), the field should contain 0 at the source
   and ignored by routers and the destination.

3.3 IPSEC

   ESP is purely optional and should be implemented as Protocol 50. SPI
   works as port numbers for resource reservation (if any).  AH is
   forbidden because its functionality overridden by ESP and its SPI is

M. Ohta               Expires on November 25, 2003              [Page 3]

INTERNET DRAFT      Simple Internet Protocol, Again             May 2003

   not located at port number part.

3.4 Path MTU Discoverly

   Path MTU discoverly is forbidden.  It often does not work over the
   Internet for various reasons.  As the MTU of the Internet is mostly
   1500 that minimum MTU of 1280 is good enough.

   Routers are encouraged to silently drop packets lager than 1280 byte
   without generating ICMP.

3.5 Stateless Autoconfiguration

   IPv6 specific stateless autoconfiguration is ignored.  Use DHCP.

   All the possible autoconfiguration can be (and is already, for most
   of the case) implemented with DHCP over the Internet.

   The remaining autoconfiguration features may work in an isolated
   private LAN but is not meaningful over the Internet.  Note, for
   example, that both dentists' offices and cars have preconfigured
   locks and keys.

   Issues on autoconfiguration in an isolated private LAN may still be
   solved, but in a way not affecting the development of the Internet
   protocol nor, hopefully, IETF.

3.6 Automatic Renumbering

   Automatic renumbering of IP addresses of DNS glue is ignored.

   On the Internet, automatic renumbering is trivially easy, as long as
   domain names, not raw IP addresses, are used to designate hosts.
   However, automatic renumbering of DNS glue is impossible, because
   relationship between DNS servers has nothing to do with ISP topology.

3.7 Hosts and Routers

   It is a direct violation of the end to end principle to assume
   intermediate systems intelligent and end systems dumb.  Routers are
   hosts relay packets between multiple interfaces, thus, actively
   engages in generating routing tables. As has been the tradition of
   early days of the Internet, hosts with single interface are still
   expected to listen to IGP (e.g. routed -q). Note that DHCP can tell
   hosts which IGP to use. Note also that global routing table is
   assumed to be small.

3.8 Neighbor Discovery

M. Ohta               Expires on November 25, 2003              [Page 4]

INTERNET DRAFT      Simple Internet Protocol, Again             May 2003

   Neighbor discovery is not used on the Internet and is forbidden.  It
   has hopelessly bloated, partly because of a failed attempt to support
   ATM (IPv6 thought multicast over ATM were easy) and partly because of
   another failed attempt to support stateless autoconfiguration.

   As for address resolution, the original purpose of ND, except for the
   last hop, address resolution information for next hop routers become
   available from IGP exchange. In other cases, use ARP or let hosts
   speak IGP.

3.9 Jumbograms

   Jumbograms are not used on the Internet and is forbidden.  Super
   computers today are massively parallel ones that it has enough scalar
   power to handle streams of 64KB of packets.

3.10 Link & Site Local Address

   Link and site local address is not used on the Internet and is
   forbidden.

   Note that a network behind NAT is not a part of the Internet. One may
   still use NAT with IPv6, but it has nothing to do with IPv4 or IPv6
   specification.

4. Other Restriction to CIP

   To ease implementations, a router can forward packets to the next hop
   by looking at upper 64 bits of an destination address only.
   Multicast address format should be reconsidered accordingly.

   A host can accept packets to it by looking at lower 64 bits of an
   destination address only.

5. Remaining Works

   Multi6 WG is working on site multihoming of IPv6, at least
   theoretically.

   However, as there can be limited number of ASes operated at TLAs,
   support for NLA level ASes multihomed to TLA level ASes must be
   discussed somewhere.

   Mobility must be tightly integrated with multihoming, as both treats
   multiple IP addresses of a host, that current specifications on MIPv6
   must be ignored.

6. Security Considerations

M. Ohta               Expires on November 25, 2003              [Page 5]

INTERNET DRAFT      Simple Internet Protocol, Again             May 2003

   IPSEC sucks.

7. Author's Address

   Masataka Ohta
   Graduate School of Information Science and Engineering
   Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN

   Phone: +81-3-5734-3299
   Fax: +81-3-5734-3299
   EMail: [email-masked]

M. Ohta               Expires on November 25, 2003              [Page 6]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 May 2003 15:38:36 +0200

This document appears to be about 56 days late, or perhaps 309 days early.

Ohta-san asserts that IPv6 will not be deployed in its present form. That 
isn't consistent with the evidence I see, and it isn't a relevant issue for
multi6, which deals with IPv6 in its present form, as far as I can
understand the charter.

The detailed assertions in the draft are mainly wrong, but since they
are irrelevant to multi6, I hope we will not waste bits here on them.

  Brian

---

From: Tim Chown <[email-masked]>
Date: Tue, 27 May 2003 14:58:03 +0100

> This document appears to be about 56 days late, or perhaps 309 days early.

Well, he could have suggested setting the RFC3514 Evil Bit on all of his
"Complex IP" packets? :)

But agreed for sure.

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 28 May 2003 08:02:15 +0859 ()

Brian;

> This document appears to be about 56 days late, or perhaps 309 days early.

Considering that IPv6 document is about 56 years late, or perhps 309
years early, maybe.

For the next round to claim IPv6 is deployed?

> isn't consistent with the evidence I see,

Evidence?

Note that it has been a stated that "IPv6 will be deployed in its
present form. That is consistent with the evidence I see." for these
8 years.

So, let's have a reality check. What evidence do you have?

If you don't have it, as an evidence of deployment, how many end
users, can you say, are using IPv6?

> and it isn't a relevant issue for

No. We did discuss some changes.

> are irrelevant to multi6, I hope we will not waste bits here on them.

Removal of autoconfiguration, for example, does affect multi6.

As all the useless features of IPv6 have complex interrelationships,
if you think some of the assertions are wrong, it's your turn
to state so with evidences on the part you want to refute.

							Masataka Ohta

---

From: Hiroki Ishibashi <[email-masked]>
Date: Wed, 28 May 2003 18:20:21 +0900

>   not located at port number part.

If my understanding is correct, integrity check including IP header
cannot be done with ESP.  AH can do that.

Hiroki Ishibashi

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 28 May 2003 23:18:39 +0859 ()

Ishibashi san;

> cannot be done with ESP.  AH can do that.

An interesting point (on how IPSEC sucks).

First, which part of IP header, do you want to check the integrity?

Once a host receives a packet and delivers it to some application
using SPI (which is why SPI is equivalent to port information), no
information in IP header is no longer necessary and it is too
late to check integrity of information in IP header.

Note that, unlike CIP, SIPA does not have IP options which could
have complex and unpredicatable interaction with IPSEC.

Secondely, it is my understanding of IPSEC that, while a mandatory
transform, DES-CBC, does not provide integrity check (involving IP
headers), other transforms can. And, who use DES, these days?

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 28 May 2003 16:48:15 +0200

On woensdag, mei 28, 2003, at 16:19 Europe/Amsterdam, Masataka Ohta 
wrote:

>>>   AH is

> First, which part of IP header, do you want to check the integrity?

The source address is something I'd really like to check.

When I get around to it, I plan to write a draft about how ISPs can do 
proxy IPsec AH processing for their customers to eliminate denial of 
service traffic.

> late to check integrity of information in IP header.

That's why we do AH first and reject the packet if it doesn't check 
out. Applications are not involved in IPsec, that's the whole point. 
Otherwise you could just as well use TLS.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 May 2003 15:59:45 -0700

When you say proxy AH do you mean the ISP actually creating the AH or 
just discarding invalid/bad AHs?

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 May 2003 01:14:01 +0200

> just discarding invalid/bad AHs?

The idea is that the customer gives to its correspondents a key to be 
used in calculating the authentication header. This key is derived from 
one of a small set of possible "master keys" combined with the 
correspondents source address. The master keys are communicated to the 
ISP (for instance by inserting them in a BGP attribute) so the ISP can 
calculate the key used for a packet and then check the authentication 
header. Then packets that don't have an AH or for which the AH check 
fails are severely rate limited while packets that pass the check can 
flow freely. When a key is abused the master keys are rotated and the 
abuser simply doesn't get a new key.

This requires some serious hardware at the ISP side but it should get 
rid of DoS real good. The main problem is allowing control traffic in 
order to distribute the keys to the correspondents. Depending on 
whether we can/want to use unmodified IKE or not this should either be 
backward compatible or easy to fix, but probably not both.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 29 May 2003 14:20:51 +0859 ()

Iljitsch;

> The source address is something I'd really like to check.

You don't.

If payload passes authentication check, the payload is considered
to be reliable regardless of the source address.

> proxy IPsec AH processing for their customers to eliminate denial of 

It is an utter violation of the end to end principle and assured
not to scale, which, for example, means poor performance.

In this case, a proxy box of an ISP is an easy victim of the DoS
attack.

The protection against DoS is to let distribute the load to end
systems of ISP's customers.

> Otherwise you could just as well use TLS.

I'm afraid you are assuming authentication check by ESP is much
slower than that by AH.

It is true that, in general, encryption/decryption is a little bit
slower than authentication check.

So, you don't gain so much, even if authentication by ESP is as slow
as decryption.

Moreover, it is possible to have an ESP transform which first performs
authentication check and, only if the check is successful, decryption
(or do nothing, if encryption is not necessary) that there is no
difference.

Note that, by trying to protect things which do not have to be
protected, you can have an unmanagably complex multi6 solution.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 29 May 2003 14:38:06 +0859 ()

Iljitsch;

The only thing you can do against DoS is to detect its origin.

Complex attempt of protection with larger number of components
and more computation makes DoS more effective.

> The master keys are communicated to the 
> ISP (for instance by inserting them in a BGP attribute)

in plain text?

> Then packets that don't have an AH or for which the AH check 
> fails are severely rate limited

> This requires some serious hardware at the ISP side

You are saying you must provide high performance hardware to get
severely limited rate, even though there is no attackers, which
is a lot worse than DoS.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 May 2003 10:06:11 +0200

Masataka,

On donderdag, mei 29, 2003, at 07:21 Europe/Amsterdam, Masataka Ohta 

> to be reliable regardless of the source address.

Re the spam discussion on the IETF list: I'd rather know I'm dealing 
with a "good" source rather than check the content of everything I 
receive.

> not to scale, which, for example, means poor performance.

Writeups of e2e that I've seen explicitly state that something that 
should be done end-to-end MAY also be done in the network as an 
optimization. As long as it's an optimization and not shifting of 
responsibility it's ok.

I don't see why this shouldn't scale: 10 times more traffic means 10 
times more crypto chips. O(n) scaling isn't that bad.

> In this case, a proxy box of an ISP is an easy victim of the DoS

Good luck DoSing a box that can do crypto at line rate.  :-)

Obviously DoSers can raise the stakes by trying to DoS (some part of) 
the ISP rather than the customer, but I'm not worried about that. ISPs 
typically have bandwidth in the order of gigabits, while customers may 
only have a few megabits. Flooding a 10 Mbps pipe is trivial, and done 
so often stopping it is a problem. Flooding a few 1 Gbps pipes is hard 
and should show up on the radar screens of even the most uncooperative 
source networks so stopping this is much, much easier.

> I'm afraid you are assuming authentication check by ESP is much

No. What I'm saying is that porting all your applications to support 
SSL is much slower than porting your OS to support IPsec.

On donderdag, mei 29, 2003, at 07:39 Europe/Amsterdam, Masataka Ohta 

> The only thing you can do against DoS is to detect its origin.

That's why we make them get a key that only works for a single origin 
address and use that key in each packet.

> in plain text?

Why not? Obviously the BGP attribute wouldn't be transitive, so the 
master keys would stay within the ISP network.

> severely limited rate, even though there is no attackers, which

ISPs would need enough of these boxes to easily handle the maximum 
expected DoS traffic. The system would only have to be enabled for a 
certain customer when the customer is under attack. But even if the 
system is enabled all the time there might be situations where the 
protection is worth the extra cost. Obviously this would be an extra 
value added service on top of regular IP transit, rather than a 
standard part of IP.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 29 May 2003 20:54:21 +0859 ()

Iljitsch;

Thank you for demonstrating how a simple "optimization" harms
the Internet without really improving anything.

> with a "good" source rather than check the content of everything I 

How can you check source without cheking the content?

Note that ICV of AH is computed over both IP header and the conent.

> optimization. As long as it's an optimization and not shifting of 

The good source on the end to end principle is RFC1958, which is,
thanks to Brian, very carefully worded. It does not state: "as long
as it's an optimization and not shifting of responsibility it's ok".

In the RFC, it is stated that:

   To quote from [Saltzer], "The function in question can completely and
   correctly be implemented only with the knowledge and help of the
   application standing at the endpoints of the communication system.
   Therefore, providing that questioned function as a feature of the
   communication system itself is not possible. (Sometimes an incomplete
   version of the function provided by the communication system may be
   useful as a performance enhancement.")

So, it is assured to be "incomplete" and it is of course that hosts
are expected to have the functionality.

For example, TCP takes care of lost packets, though ethernet may
perform local retransmission of packets lost in collision.

> times more crypto chips. O(n) scaling isn't that bad.

The RFC continues as:

   This principle has important consequences if we require applications
   to survive partial network failures. An end-to-end protocol design
   should not rely on the maintenance of state (i.e. information about
   the state of the end-to-end communication) inside the network. Such
   state should be maintained only in the endpoints, in such a way that
   the state can only be destroyed when the endpoint itself breaks
   (known as fate-sharing). An immediate consequence of this is that
   datagrams are better than classical virtual circuits.

and

   The network's
   job is to transmit datagrams as efficiently and flexibly as possible.
   Everything else should be done at the fringes.

As you should know, common line rate today is 10G, because people
want routers operate at the rate at which hardware can barely
perform the simplest job of forwarding packets.

> Good luck DoSing a box that can do crypto at line rate.  :-)

See above. :-)

Note that a performance bottleneck is retrieval of SA.

Now, the RFC also state:

   To perform its services, the network maintains some state
   information: routes, QoS guarantees that it makes, session
   information where that is used in header compression, compression
   histories for data compression, and the like. This state must be
   self-healing; adaptive procedures or protocols must exist to derive
   and maintain that state, and change it when the topology or activity
   of the network changes.

and, what, do you think, will happen, if your AH use serial number
and your site is multihomed?

> source networks so stopping this is much, much easier.

These days, it costs about $50 a month to have 100Mbps access, though
ISP backbone is only as fast as 10G.

> master keys would stay within the ISP network.

Are you seriously saying that you distribute plain text keys to
multiple ISPs you are conneted and can still feel safe?

> certain customer when the customer is under attack.

Wrong.

Another problem of your approach is that it is not local optimization.

ISP or hosts at another end of the communication is involved, which
can not be controlled by your ISP.

On the other hand, a host naturally controls behaviour of its peer,
which is why the end to end principle is great.

> But even if the 

Again, it is not a local service.

Another problem of non-local optimization is reduced MTU, which
makes 1280B of packets from your host dropped somewhere in the
Internet.

And there should be a lot more.

							Masataka Ohta