Subject: threats ID

From: Masataka Ohta <[email-masked]>
Date: Sat, 17 Jan 2004 06:41:15 +0900

Below is a threats analysis draft ID.

						Masataka Ohta
--

INTERNET DRAFT                                                   M. Ohta
draft-ohta-multi6-threats-00.txt           Tokyo Institute of Technology
                                                            January 2004

Threats Relating to Transport Layer Protocols Handling Multiple Addresses

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

   This document lists security threats related to IPv6 multihoming
   solutions, transport layer protocols of which are expected to handle
   multiple addresses of a host and an identity of the host is
   recognized not necessarily by a single address.

   The intent is to look at how IPv6 multihoming solutions might make
   the Internet less secure than the current Internet, without studying
   any proposed solution but instead looking at threats that are
   inherent in the problem itself.

1. Security Considerations

   With the current Internet, most transport layer protocols identifies
   a host with a single address.

   However, for scalable multihoming, transport layer protocols are
   expected to handle multiple addresses of a host and an identity of
   the host is recognized not necessarily by a single address.

   Then, there are four new possibility of security threats.

      Connection Hijacking with False Peer Address
         hosts in multihomed sites may be supplied a false peer address
         from an attacker, which redirect existing connection to a wrong
         location.

      New DDoS Opportunity with False Source Information

M. Ohta                 Expires on July 15, 2004                [Page 1]

INTERNET DRAFT              Security Threats                January 2004

         hosts may be used for distributed DoS to damage the rest of the
         Internet

      New DoS Opportunity on Identification
         depending on a way to identify a host, the host may be subject
         to DoS

      Privacy on Identification
         depending on a way to identify a host, hosts may not be able to
         hide its privacy

   The following subsections analyze the threats with or without MITM
   (Man in the Middle).

1.1. Connection Hijacking with False Peer Address

   If a host has connected communicating with a peer, and if a transport
   layer protocol allows dynamic address set change during a connection,
   an attacker may be able to supply false information on source address
   of the peer to the host to hijack the connection.

   On the current Internet, where connections are identified by a pair
   of addresses, which is fixed during connection, this kind of attack
   is not possible at the transport layer. However, similar attack is
   possible at upper layers. For example, an attacker may rewrite URLs
   in HTML text over HTTP over TCP to hijack a web browsing session. Or,
   an attacker may rewrite DNS reply of IP addresses during URL
   resolution or at the initiating phase of an application layer
   connection. As a protection against such attacks, transport and/or
   upper layer protocols use cookie or cookie like information, such as
   randomized port number, TCP sequence number, DNS message id and so
   on.

   Without assuming MITM, existing transport and/or upper layer
   protocols using cookie or cookie like information can be naturally
   extended as a reasonable protection against connection hijacking by
   false source information.

   Of course, cookie is powerless against MITM and once a forged source
   address, URL or DNS answer is supplied by MITM, the effect will be
   persistent even after the MITM goes away.

   If transport layer protocols handling multiple addresses of a host
   does not have cookie or cookie like mechanism at least as strong as
   that of TCP and still allow dynamic address set change during
   connection, there will be a new security threat of connection
   hijacking.

1.2. New DDoS Opportunity with False Source Information

   On the current Internet, an attacker can send a packet with forged
   source address expecting that a reply packet is sent to host of the
   source address, as DDoS attack to the host.  There often is some
   amplification possible. For example, DNS reply is often a lot longer

M. Ohta                 Expires on July 15, 2004                [Page 2]

INTERNET DRAFT              Security Threats                January 2004

   than query.  The attacked host has no way to know the location of the
   attacker from the attacking packets, sender of which often does not
   even have logging.

   Transport layer protocols handling multiple addresses of a host is
   subject to similar attack.

   If transport layer protocols handling multiple addresses of a host
   has DoS amplification property worse than the current Internet hosts,
   there will be the existing security threat of DDoS will be more
   serious.

1.3. New DoS Opportunity on Identification

   If a host has an identification involves computationally expensive
   security mechanism, it can be used for DoS attack to the host.

   On the current Internet, cookie is exchanged before performing the
   computationally expensive process, though mere holding of cookie
   information can be expensive operation as exemplified by TCP SYN
   flooding.

   Cookie protection, of course, is powerless against MITM.

   If transport layer protocols having new connection identification
   mechanism does not support initial cookie exchange, there will be a
   new security threat of DoS.

1.4. Privacy on Identification

   If transport layer protocols having new connection identification
   requires hosts having persisting identification information, it will
   be used to track the identify of the host, which is a new security
   threat.

2. 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 July 15, 2004                [Page 3]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Jan 2004 14:22:42 +0100

Thanks. Since this is fairly short, I hope we can integrate
it in draft-nordmark-multi6-threats-00.txt if people agree
with your analysis.

   Brian

> Below is a threats analysis draft ID.

<snip>

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 19 Jan 2004 18:55:40 +0100

Hi,

IMHO both drafts complement themselves pretty well because Erik & Tony's
draft essentially analyze the threats from a IP layer perspective and
Masataka's draft analize the threats from a transport layer perspective.

After some mail exchanges with Pekka N., my understanding is that that there
is an important distinction to be made between these two cases when
considering the hijacking attack. The point is that in transport layer
solutions, the hijcack attack is limited to the existent established
connection while in the IP layer (shim layer also) solutions the attack
applies to the complete endnode. Because the attack applies to the endnode,
the attacker can do things like establishing aconnection creating some state
so that futuer communications initated by the victim are also redirected.
That is in IP layer solutions the complete identity of the victim is
hijacked for all the applications and for all the communications,
pre-establihed or future communications (as long as the malicous state
exists in the victim)

This implies that the risk is very different in one case than in the other
one and different security solutions are required.

So I guess that i agree with Masataka that a return routability check with a
cookie is enough to redirect a connection but IMHO this is not enough to
redirect a complete identity at the IP layer level.
I mean time shifting attacks may be acceptable as long they can only affect
a connection.

Regards, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Brian E Carpenter
> Enviado el: lunes, 19 de enero de 2004 14:23
> Para: Masataka Ohta
> CC: Multi6 List
> Asunto: Re: threats ID
>
>

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 20 Jan 2004 09:42:18 +0900

Marcelo;

> Masataka's draft analize the threats from a transport layer perspective.

The problem for Erik and Tony, then, is that IP layer of
multi6 is no different from the current one.

> considering the hijacking attack.

Good.

Can you answer the following simple question?

What, do you think, is being hijacked?

Connections?

Note that, unless you extensibly modify IP layer, there is no
connections there.

> The point is that in transport layer
> applies to the complete endnode.

Wrong. Attack is always applied to the end.

> Because the attack applies to the endnode,

Establishing a connection is a functionality of the transport
layer.

> That is in IP layer solutions the complete identity of the victim

There is no IP layer solutions.

Just like NAT operates not only at the IP layer but also at the
transport and applicaiton layers, shim layers are not only at
the IP layer.

> I mean time shifting attacks may be acceptable as long they can only affect

"Time shifting attack" is meaningful if only there is persistent
relationship, that is connection, that it is not at the
connectionless layer.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 20 Jan 2004 09:44:24 +0900

Brian;

> it in draft-nordmark-multi6-threats-00.txt if people agree

My draft, IMHO, is not only short but also denies most, if not
all, of the points of "draft-nordmark-multi6-threats-00.txt",
that simple replacement is just enough.

						Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 20 Jan 2004 07:23:57 +0200

Marcelo,

> applies to the complete endnode.

Thank you.  A very good explanation.

This also relates somewhat to performance.  If you have per-connection 
state,
then you have to create the state separately for each connection.  If 
you
have per-host state, then you create the state on first connection, and
then share it with the other ones that are created during the lifetime
of the state.

Whether a per-host state (in addition to the per-connection state) is a 
good
idea is an architectural issue.  In my opinion, many of the shim 
approaches
do create a kind of a new layer, say layer 3.5, which contains a 
per-host
state, potentially shared by multiple transport layer connections.

> the attacker can do things like establishing a connection creating 
> some state
> so that future communications initated by the victim are also 
> redirected.
> That is, in IP layer solutions, the complete identity of the victim is

Right.

> one and different security solutions are required.

Well, I might not call the risks "very" different, but they are 
different.

> redirect a complete identity at the IP layer level.

If I understand Ohta-san correctly, he perceives that an architectural
change that creates a per-host state at the end-hosts in the IP layer,
or one that creates a new layer between IP and transport, are abhorrent
and should not be considered.  Hence, my perhaps faulty understanding
of his thoughts is that the concept of location-independent IP layer
identity does not exist.  But maybe I understand his thoughts wrong.

I, on the the other hand, certainly believe that adding 
location-independent
IP layer identity would be good for the Internet.

While (if) there is such a large disagreement between Ohta-san and me,
it may be impossible to agree on security.

--Pekka Nikander

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 20 Jan 2004 08:49:46 +0100

Ohta-san,

> multi6 is no different from the current one.

I am not really following what you are arguing for. Do you mean to say 
that

a) Eriks draft is incorrect?
b) Eriks draft is not complete?
c) Eriks draft adds security that is not relevant? (I.e does not 
increase security)
d) Eriks draft adds security beyond what we have today (but perhaps at 
too high cost)?
e) Something else?

Best regards,

- - kurtis -

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 20 Jan 2004 10:18:36 +0100

Hi Masataka,

please consider the differences between performing a hijack attack on MIP
(layer 3 solution) or performing a hijack attack on SCTP (transport layer
solution)

in the first case the complete end node is hijacked (that is its IP address
that is its identifier) and in the second case only a given connection is
hijacked

threats are different and security required is different

( i am really tring to agree with your draft here :-)

regards, marcelo

> nombre de Masataka Ohta
> Enviado el: martes, 20 de enero de 2004 1:42
> Para: [email-masked]
> CC: Brian E Carpenter; Multi6 List
> Asunto: Re: threats ID
>
>
> Marcelo;
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Jan 2004 09:59:05 +0100

> 1. Security Considerations

:-)

>    false source information.

That's not quite true. Obviously when there is a man in the middle all 
bets are off. However, when protection consists of cookies then a "man" 
doesn't have to be "in the middle": being on the sidelines is good 
enough. For instance, the attacker may be on a shared subnet (such as a 
wireless lan) with one of the victims, allowing him to intercept the 
cookie and subsequently inject false packets into the communication 
between the victims. Under some circumstances, this may be enough to 
steal a session.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Jan 2004 12:11:25 +0100

If a network-layer mh solution uses multiple identifiers, then what gets 
hijacked is an individual identifier, not the node. Thus what is hijacked
is the subset of sessions in the node using the same identifier. 
Transport-layer solutions can claim that they reduce that set of sessions 
to one at a time. 

Nevertheless I find it surprising for Matasaka to assert that most of
the threats in draft-nordmark-multi6-threats-00.txt only apply to
network layer solutions. Do people have an opinion about that?

In any case this does not prevent combining the two drafts, which will
be much easier for readers, e.g.:

Part 1: threats that only affect network layer solutions
Part 2: threats that affect both network and transport layer solutions
Part 3: threats that only affect transport layer solutions

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 20 Jan 2004 12:25:21 +0100

> is the subset of sessions in the node using the same identifier.

good point

> network layer solutions. Do people have an opinion about that?

well, i may have induced also this perception...
I haven't really made an analysis about if the threats mentioned in Erik's
draft only apply to IP layer solution, but it is just that i have always
asumed that this draft had these type of solutions in mind, so that its
analysis applied to this type of solution. Sorry if i generated some
confusion here.
OTOH, Masataka's draft states clearly in the tittle that it is considering
the thransport layer solutions.

> Part 3: threats that only affect transport layer solutions

Yes, or other option is to make an analysis for IP layer solutions and
another for transport layer, but in any case IMHO we should clearly
undestand the differences between the two cases.

regards, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 20 Jan 2004 21:35:01 +0900

Pekka Nikander;

> This also relates somewhat to performance.  If you have per-connection 

You always have per-connection state, though half established
connection may have state only at one end, for example, as a
protection against TCP SYM flood.

> If you

Some application, such as DNS, may have per-host state.

However, IP layer does not have any state of a connection, because
it is connectionless. State of MIP binding is not of a connection
but of a binding between two addresses of a single end.

Several connections may share states, though it introduces new
security threats without any meaningful benefit.

> In my opinion, many of the shim approaches
> do create a kind of a new layer, say layer 3.5, which contains a per-host

All the shim layers are working at least at layer 4 that there
is no point to say layer 3.5

They depend on layer 4 details such as how TCP calculates its check
sum. MTU change creates another dependency with layer 4 and above.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 20 Jan 2004 21:38:10 +0900

Kurt;

> I am not really following what you are arguing for. Do you mean to say 

I mean there is no threats introduced at the IP layer of multi6
because the IP layer of multi6 is no different from the current
one.

It's not me who said:

	Erik & Tony's draft essentially analyze the threats from
	a IP layer perspective

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 20 Jan 2004 21:48:39 +0900

Iljitsch;

It should be leagal. :-)

> between the victims. Under some circumstances, this may be enough to 

MITM means someone who can snoop, erase and modify packets of victims.

It is not necessary that victims and MITM are separated by routers.

It is not even necessary that victims and MITM are separated by
L2 switches or L1 hubs.

Even if two victims are directly connected by a pair of fiber,
MITM can exist by cutting the pair and inserting itself in
between.

Silimar attack is much easier if physical media is wireless lan.

I think I gave you an example of how easy to create MITM with
wireless lan.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 20 Jan 2004 21:56:08 +0900

Marcelo;

> (layer 3 solution) or performing a hijack attack on SCTP (transport layer

Sure. While MIP has its own security threat, it has nothing to do
with M6.

As I repeatedly point it out, there is no reasonable timeout value
shared between MIP and M6 that there is no point mixing MIP binding
and M6 connection.

MIP timeout is determined by expected size of cell divided by
expected movement speed of hosts, while M6 timeout is determined
by transport and application protcols.

> that is its identifier) and in the second case only a given connection is

In the first case, what is hijacked is binding between home and care
of addresses, which is not a connection. You can still call it a
connection, but its meaning is totally different from connection
of TCP or SCTP.

> ( i am really tring to agree with your draft here :-)

Thanks.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 20 Jan 2004 22:08:13 +0900

Brian;

> network layer solutions. Do people have an opinion about that?

It's marcelo who wrote:

I myself do not think so called network layer solutions ever exist.

Read my architectural draft on why there can't be.

							Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 20 Jan 2004 14:02:37 +0100

> of addresses, which is not a connection.

Exactly, it is state that concerns the node as a unit, so the complete
identity of the node is affected

> You can still call it a

Exaclty, this is why i am saying that threats are different.

One case is when the layer 3 identifier is hijacked and a different thing is
when a tcp connection is hijacked

So, what Brian is proposing AFAIU is to analyze the threats concerning these
two different cases and compare them in a the threats draft

regards, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 20 Jan 2004 22:20:16 +0900

marcelo;

> when a tcp connection is hijacked

Why do you think layer 3 identifier can ever be hijacked
specifically with M6?

I do understand that layer 3 identifier stored in an application
of DNS can be hijacked.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Jan 2004 21:54:52 +0100

On 20-jan-04, at 13:35, Masataka Ohta wrote:

> However, IP layer does not have any state of a connection,

That's not true. The routing table is state, as is per-destination path 
MTU information. I'm not even going to mention IPsec.

> because it is connectionless.

For a connection you need per-connection matching state in at least two 
places, the source and the destination. For IP you still need state, 
but it's per IP address or even per prefix, and it doesn't have to 
match on both ends. But it's still state.

> is no point to say layer 3.5

I believe NOID and certainly ODT allow layer 4 to work without changes, 
and the changes they make to layer 3 are such that they can easily be 
thought of as a layer between 3 and 4, as those changes only apply to 
the endpoints and not to what happens in routers (ok, except for 
address rewriting). So "layer 3.5" makes sense to me.

BTW, my point about man in the middle was that an attacker can still do 
damage without having full man in the middle capabilities, for instance 
by intercepting packets and injecting falsified ones, without 
necessarily being able to stop the flow of traffic between the 
endpoints. This is important, because true man in the middle capability 
isn't something that is easily achieved, while "man on the sideline", 
where the attacker can observe data and inject his own, but not stop 
the real data from flowing, is fairly trivial to achieve in many 
situations.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Jan 2004 22:06:35 +0100

> undestand the differences between the two cases.

I think it's an important observation that working per identifier pair 
or working per session have some very different security aspects.

Which of course begs the question: which is the better approach? I'm 
not much in favor of having to do a time consuming negotiation for each 
TCP or UDP "session", as many sessions have a lifetime of only a few 
packets. (On the other hand this could finally make HTTP implementers 
clean up their act and not start upwards of 10 TCP sessions per 
second...) On the other hand, "fool me once, redirect my traffic 
forever" isn't all that appealing either.

I think there is some middle ground here, where sessions can be grouped 
in such that an optimal tradeoff between increased risk and decreased 
performance is found. However, this probably means the MH layer needs 
to know more than a few intimate details of what the transport 
protocols are up to.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 20 Jan 2004 14:38:37 -0800

> Transport-layer solutions can claim that they reduce that set of sessions 

It is probably true in general that if normal traffic needs to do
X amounts of work per transport connection, than a redirection attacker
needs to do some work proportional to X per transport
connection.
Thus the ability to aggregate the signaling needed for rehoming for
multiple transport connections would affect legitimate traffic just as
much as it would affect an attacker.

> network layer solutions. Do people have an opinion about that?

It might depend on the details of the transport layer solutions.
Taking the premeditated redirection attack as an example.
If an attacker can guess that port A on node B will talk to port C on
node D in the near future, then premediated redirection attacks can be
launched on a transport solution which identifies the "redirectable
unit" by the 5-tuple.
But if the transport solution uses some hard to guess random component
(an SCTP verification tag is an example; another example would be some
emphemeral IDs) to identify the redirectable unit, then it would be much
harder to perform a premediated redirection attack.

My take on this is that the threats exist in all cases. Different
approaches, and in particular different bindings with transport level
mechanisms, can provide rather different ways of handling the threats.

Should it come to comparing transport vs. layer 3.5 approaches I think
the hardest thing for a transport level approach is for UDP traffic; 
preventing the various threats for UDP isn't much different than
preventing them for IP.

   Erik

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 Jan 2004 08:18:12 +0900

Iljitsch;

> That's not true. The routing table is state,

It is not state of a connection.

> as is per-destination path 
> MTU information.

It is a wrong understanding of PMTUD issues.

PMTUD is an issue of connections.

A few years ago, transport people finally recognized it and
had a BoF or WG to do PMTUD at the transport layer. I haven't
traced the activity, because I think PMTUD is a bad idea even
if it is implemented at the transport layer.

> I'm not even going to mention IPsec.

SPI is, effectively, is a transport layer identifier just as
port numbers, which is one of a reason why design of IPsec is
poor.

> places, the source and the destination. For IP you still need state, but 
> it's per IP address or even per prefix, and it doesn't have to match on 
> both ends. But it's still state.

See the first line of this mail.

> I believe NOID and certainly ODT allow layer 4 to work without changes,

You can believe so, just as you can believe NAT allow layer 4 to work
without changes.
 
> endpoints.

Sure. For example, on the Internet today without M6, you can modify
DNS result by sending false answer before the real one is returned.

> This is important, because true man in the middle capability 
> where the attacker can observe data and inject his own, but not stop the 
> real data from flowing, is fairly trivial to achieve in many situations.

Maybe. But, it has nothing to do with M6.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 21 Jan 2004 00:37:38 +0100

> It is not state of a connection.

Ok.

>> as is per-destination path MTU information.

> if it is implemented at the transport layer.

In IPv4 PMTUD is mostly a TCP thing: UDP and other non-TCP packets are 
generally transmitted with the DF bit set to zero. However, this isn't 
possible in IPv6: if a router returns a "packet too big" ICMP message, 
the source is required to start fragmenting subsequent packets. So in 
IPv6, PMTUD is very much an IP layer issue, even if the transport layer 
is also aware of it.

:-)

The real problems start at layers above 4 with NAT...

Fortunately none the MH mechanisms that have been proposed here use NAT 
(as far as I can remember, at least).

>> This is important, because true man in the middle capability isn't 
>> something that is easily achieved, while "man on the sideline", where 
>> the attacker can observe data and inject his own, but not stop the 

> Maybe. But, it has nothing to do with M6.

I tend to agree but I don't think we can entirely dismiss the potential 
attacsk that go beyond what's possible today when attackers have this 
capability.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 Jan 2004 13:24:19 +0900

Iljitsch;
 
> In IPv4 PMTUD is mostly a TCP thing:

Whether PMTUD is a TCP thing or not is independent of IP layer.

> UDP and other non-TCP packets are 
> generally transmitted with the DF bit set to zero.

It is because minimum MTU of IPv4 is too small.

> However, this isn't 

Just send 1280 bytes.

Given that all the protocols are required to operate with MTU of
1280 anyway, that most link will have MTU of 1500 forever, that
no multicast protocols can perform PMTUD and that each transport
and application layer protocol must be modified to accomodate
PMTUD, there is no point to be bothered to have PMTUD.

It is very good design of IPv6 to outlaw fragmentation.

Even better is to make minimum MTU 1280.

The best could have been to make minimum MTU 1500 to
outlaw dialup protocol of PPP over Ethernet, though.
 
> (as far as I can remember, at least).

I'm not sure what do you mean "proposed" but Dave Crocker explicitely
admit his proposal essentially NAT.

> attacsk that go beyond what's possible today when attackers have this 

I have shown, with DNS, that what's possible today is connection
hijacking, which means it is already worst.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Jan 2004 19:34:30 +0100

> Read my architectural draft on why there can't be.

The WG will be tackling architectural analysis as its next major effort.
I think there will be people who have a different opinion from you.

   Brian

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 Jan 2004 18:10:13 +0900

Brian;

> I think there will be people who have a different opinion from you.

If you have a different opinion from me, post it with technical
reasons, or better, write a draft.

If you don't, don't expect others do. Never say others might do
something. Others can take care of themselves.

That is the constructive way of discussion.

								Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 23 Jan 2004 07:08:55 +0100

> You can believe so, just as you can believe NAT allow layer 4 to work

I think there is a notable difference. In my reading you are using NAT 
very loose for all forms of address rewrite. NAT to me does static 
rewrites, with no form of signaling. Especially breaking referrals by 
hiding the "true" address to the outside world. Most (if not all) 
id/loc proposals here (claims) that referrals do work. There is a hugh 
difference, referrals is a crucial component of any multi6 solution. 
This was also pointed out in the comments by Patrick.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 23 Jan 2004 15:51:28 +0900

Kurt;

> rewrites, with no form of signaling.

Wrong. Rewriting is not the essential problem.

Right. The problem is lack of signaling OF *CONNECTIONS*.

As you might know, there is no connections and signaling at
the IP layer.

Thus, the only thing NAT and other layer 3 things can do is
guessing the connection state by a lack of communication
for certain period of time, though, sometimes, you can detect
TCP SYN and FIN.

However, that you observe no traffic over a connection does
not necessarily mean that the connection is broken.

That there is no response for a UDP packet may mean that an
reply ack is lost, that no reply is required by the protocol
above UDP or that the packet is an ack.

There is no signaling unless layer 4 and above are involved,
though guessing may work for TCP.

> Especially breaking referrals by 

NAT rewriting is transparent to applicaitons, if the applications
relies on TCP and DNS and DNS is modified to reflect the rewriting.

So are other proposals, including mine, as is explained in
my proposal.

However, TCP is not IP, which is the point of my presentation
at Vienna.

						Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Jan 2004 11:58:35 +0100

Masataka, you conclude by saying

> However, TCP is not IP, which is the point of my presentation

We can hardly disagree. But TCP is not SCTP, UDP, DCCP or ICMP either.
The systems level argument for a layer 3.5 solution is that it can cover
all cases, including ones we have not invented yet.

You are correct that a layer 3.5 solution requires cached state, probably
with timeouts due to the lack of disconnect signalling. There is a classical
solution to that, which is for the ULP to send a keepalive signal to prevent
the cache from timing out. That would indeed be a ULP enhancement, but a very
minor one and not essential.

   Brian

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 23 Jan 2004 20:19:56 +0900

Brian;

> We can hardly disagree. But TCP is not SCTP, UDP, DCCP or ICMP either.

That's why TCP is not IP.

> The systems level argument for a layer 3.5 solution

There is no such thing as layer 3.5.

Network layer solutions are at layer 3, transport layer solutions are
at layer 4. PERIOD.

> is that it can cover

UDP, which we already invented, can not be covered by network
layer solutions.

> with timeouts

Anything with wrongly guessed timeout is no solution.

> There is a classical
> the cache from timing out.

That is a modification to the ULP, including application ones and
is substantial.

That you must modify something above layer 4 gives a very convincing
evidence, even for those who don't understand layering enough to dream
of layer 3.5, that layer 3.5 is a fallacy.

> That would indeed be a ULP enhancement, but a very

That is a well known argument for NAT.

However, it is not an enhancement but a restriction.

It is the essential reason why NAT is not acceptable.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Jan 2004 13:48:58 +0100

Masataka, please moderate your language. I understand layering
well enough to know that the layers in the OSI model are very
abitrary choices, and a better model would have been a recursive
one, with no predefined number of layers. Since that's not the
model the industry chose to adopt, we can approximate it by
inserting shim layers when we need to. 

NAT is indeed a defective shim layer, but what this WG has been
mainly talking about is architecturally designed shims.

   Brian

---

From: Tim Shepard <[email-masked]>
Date: Fri, 23 Jan 2004 11:05:01 -0500

> Network layer solutions are at layer 3, transport layer solutions are

As far as I am aware, the IETF has never reached a consensus on how
the layers are to be numbered or what layers should exist.  Clearly
the number of layers varies depending on exactly what you are doing.
Note that IPSEC adds a layer, increasing the number of layers below
TCP by one.  (I would say that IPSEC looks like it is quite a bit more
than half a layer, and it certainly appears to be thicker than many
other things which are allowed to occupy a full unit of layering in
our minds.)

I know that many people are aware of the layer numbering convention
that was developed for the OSI suite of compter networking protocols,
but I know of no reason to take that particular numbering of layers
seriously. I have trouble keeping straight which layer is which
number, so I would appreciate it if layers would be refered to by some
meaningful name and not just a bare number.

What layer number you are at depends on where you start counting and
how many things you have stuck between you and there.

			-Tim Shepard
			 [email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Fri, 23 Jan 2004 08:40:25 -0800

Brian,

BEC>  a better model would have been a recursive
BEC> one, with no predefined number of layers. Since that's not the
BEC> model the industry chose to adopt, we can approximate it by
BEC> inserting shim layers when we need to. 

I believe there are two things that can make your point more palatable.
The first might sound like quibbling, but I believe it really does help us
think and talk about these types of enhancements.

1.  Sub-layers.  These are entirely comfortable in the OSI model, and
frankly we have always had them in the Internet model.
Notably the network layer is actually 3 sub-layers.  Namely,
Convergence, Network, Inter-network.  IP-over-* is the convergence
layer. We have not really had a "network" layer in IP, I think.  But the
possibility of adding this new module to the architecture is pretty natural.

2.  Enhancement vs. hack. I've increasingly come to believe that the
addition we are talking about is a legitimate architecture enhancement,
rather than a special-case hack.  The distinction should be between IP
that is in every node along the path, versus IP that is only (or almost
only) in the endpoints.  What is nice is that the multiaddressing work
is not the first example of this distinction.  Any practical
implementation of IP has always made that distinction.  In case folks
disagree, then we can fall back to IPSec.

So, the Internet Model can get:

     Transport
     Network
        Host
        Transit
        Media Convergence (IP-over-*)

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

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 24 Jan 2004 08:08:57 +0900

Brian;

> Masataka, please moderate your language.

Moderate your language and never say layer 3.5 again.

> I understand layering
> abitrary choices,

I never say anything on OSI model.

In the Internet, layer 3 is connectionless whereas layer 4
maybe connection oriented.

> and a better model would have been a recursive
> one, with no predefined number of layers.

If you understand layering correctly, you should know that
internal of a layer is not visible from the adjacent
layers.

Recursive means some layer may have internal structure, which,
because of layering, is not visible from outside.

> mainly talking about is architecturally designed shims.

What some of the WG member has been talking about was
architecturally designed NAT. It failed, of course.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 24 Jan 2004 08:21:38 +0900

Tim Shepard;

> the layers are to be numbered or what layers should exist.

Thank you for agreeing with me that layer 3.5 is an improper
terminology.

However,

> TCP by one.

it is clearly stated in RFC2401 "Security Architecture for the
Internet Protocol", which defines IPSEC architecture, that:

   The goal of the architecture is to provide various security
   services for traffic at the IP layer, in both the IPv4 and IPv6
   environments.

It should also be noted that that Brian said layer 3.5 means he
thought IP layer layer 3 and transport layer layer 4, on which
I have no objection.

						Masataka Ohta

---

From: Dave Crocker <[email-masked]>
Date: Sat, 24 Jan 2004 06:40:15 +0900

> to know more than a few intimate details of what the transport

Thinking about the role of a "shared" pool of address, as with SLAP, I 
realized that one kind of multiaddress set is limited to a single association, 
and that the sharing only works when multiple associations have some 
referential properties that are the same, but not others.  Originally, I 
thought that the shared pool would only be at the granularity of host-to-host.

John Wroclawski suggested distinguishing sets of locators by additional 
parameters (eg, quality of service).  I believe this is exactly in line with 
your suggestion. The idea of creating subsets in order to reduce risk from an 
individual compromise was not in the discussion, but I believe it is solved by 
the same mechanism. 

Define a pooling mechanism.  Permit an extensible set of parameters to define 
subsets of the pool (or at least to label individual address sets.)  The 
details for choosing and using particuler parameters can come later.  

d/

---

From: Tim Shepard <[email-masked]>
Date: Sun, 25 Jan 2004 00:58:29 -0500

>    services for traffic at the IP layer, in both the IPv4 and IPv6

Interesting that the draft says that.  Note though that despite the
draft saying that IPSEC provides it "at" the IP layer, it in fact does
all of its communication sitting on top of unmodified IP.  For
example, the routers don't need to be upgraded to allow IPSEC to run
over them.  So in some meaningful sense, IPSEC is above the IP layer,
even if there is a document telling us that we're not supposed to
think about it that way.

			-Tim Shepard
			 [email-masked]

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sat, 24 Jan 2004 09:15:18 +0100

>> I think there is a notable difference. In my reading you are using 
>> NAT very loose for all forms of address rewrite. NAT to me does 
>> static rewrites, with no form of signaling.
>

Right, but along the same lines of reasoning -  NAT won't break 
anything at the _IP_ layer. It might break things at the ULPs though.

> for certain period of time, though, sometimes, you can detect

I would say that this is the difference between (most) of the proposals 
in multi6 and NAT. The proposals have provided mechanisms to let ULPs 
handle referrals, even when there is rewriting. Something that NAT does 
not provide.

> not necessarily mean that the connection is broken.

True. Which is also the topic of a long thread here some time ago.

> though guessing may work for TCP.

The mechanisms to allow address rewrite will have to

a) Leave to the ULPs to handle connection state and connection 
verification. An aid in doing this might be to create a middle layer 
(the 3.5) which functions as a recording mechanism on state.

b) Provide a means to the ULPs to handle referrals transparently. 
Again, this can be done with a shim layer, or in other ways.

>> Especially breaking referrals by hiding the "true" address to the 
>> outside world. Most (if not all) id/loc proposals here (claims) that 
>> referrals do work. There is a hugh difference, referrals is a crucial 
>> component of any multi6 solution. This was also pointed out in the 
>> comments by Patrick.
>

To dive into semantics, part of the problem/difference between multi6 
proposals and NAT is the fact that NAT _is_ transparent to the ULPs and 
that no state is recorded at the end-nodes. And now we are close to 
drifting into the point that Vijay raised on if this is good or not.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 25 Jan 2004 18:10:52 +0900

Tim Shepard;

> all of its communication sitting on top of unmodified IP.

It is not a draft but the architectural RFC of IPSEC.

> For
> over them.

For example, the routers don't need to be upgraded to allow
fragmentation of IPv6 and reassembly of IPv4 and IPv6.

So?

> So in some meaningful sense, IPSEC is above the IP layer,

Hugh? Your point was not technical but lack of IETF consensus.

But, if you want to know technical points, see above.

Though IPSEC is poorly designed, its architecture is OK.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 25 Jan 2004 18:26:47 +0900

Kurt;

> anything at the _IP_ layer. It might break things at the ULPs though.

And the brokne ULPs need repairing, which means ULPs are modified.

> handle referrals, even when there is rewriting. Something that NAT does 

Are you saying ULP modification necessary or not?

> True. Which is also the topic of a long thread here some time ago.

It is an obvious evidence that NAT is a bad idea, which does
not worth a long thread.
 
> (the 3.5) which functions as a recording mechanism on state.

As there can be no such thing under UDP. such a middle layer, if any,
becomes layer 4 protocol specific and is a part of the layer 4
protocol. So, call it modified layer 4.

> Again, this can be done with a shim layer, or in other ways.

Are you saying you modify ULPs or not?
 
> that no state is recorded at the end-nodes.

You misunderstand NAT.

NAT (including so called IP layer multi6 proposals) is no
transparent.

NAT does not have correct knowledge on information recorded at
the ULPs of the end that NAT can not properly interoperate with
them.

							Masataka Ohta