Subject: RE: Minutes / Notes

From: "Tony Li" <[email-masked]>
Date: Mon, 21 Jul 2003 09:34:21 -0700

|    
|    > So, i guess that you need to carry the locator of the 
|    destination, since it
|    > is needed to forward the packet to the destination.
|    > I guess that you don´t need to carry the destination 
|    identifier in all
|    > packets.
|    > For the source endpoint information, i am not sure.
|    > I think that carrying the source identifier would make 
|    more sense, since it
|    > identifies the other endd of the communication. 
|    
|    For the source part (locator vs. id) we need to understand 
|    how multicast
|    routing would work. Today it applies RPF to the source 
|    address and uses the
|    hierarchical structure of the source address to aggregate 
|    the information used
|    by the RPF. If the source identifiers are not aggregatable 
|    this will be an
|    issue.

For multicast, the source address needs to be the locator, NOT
the identifier.  RPF is a topological computation.

|    The ability to return packets without much overhead, such 
|    as an ICMP error or
|    a  TCP SYN, might be important to avoid a class of DoS 
|    attacks om routers.

Important, yes, but not because of DoS effects.  Just simple
rate-of-return arguments suggest that routers will do a better
"best effort" job of returning errors if they don't have to jump
through hoops.  And unlike hosts, the router cannot maintain an
effective cache of all of the sources that might send it erroneous
packets.

|    Having the source locator in the packet
|    means that an ICMP error can be generated without performing
|    any ID->locator mapping

Concur.  IMHO, this is a pragmatic necessity.

Tony

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 21 Jul 2003 20:37:03 +0300

> effective cache of all of the sources that might send it erroneous

Recording a route in a packet, if designed right, allows error
messages to be returned to the source.  Recording a route has
the additional benefit that the information is always right.
You don't need to configure your ingress filters.  Since the
routers record the path to the field, you know exactly the path
the packet took.

There are engineering challenges, though, and it may be
impractical to implement it.

The important point is, however, that if the id/loc separation
is done, the source address is not needed by the end-hosts any
more.  It is needed in the very first packet flowing in a direction,
and perhaps in the second one, until the id->loc state is verified
and established, but not after that.

We discuss this in length in our 2001 Nordsec paper, as I
mentioned already.  In that paper we discuss the point from
the IPsec point of view, but most of the discussion directly
applies to the id/loc separation point-of-view.

--Pekka Nikander

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Jul 2003 09:21:34 +0300 (EEST)

> impractical to implement it.
[...]

Yes, and remember the how spammers got to forging the SMTP Received:  
headers.  You really can't trust the recorded route: it may have any
number of forged "bogus" entries.  However, at least a part of that trail
is always valid -- it's just impossible to tell how big a part.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jul 2003 13:07:27 +0859 ()

Pekka;

> and established, but not after that.

The Internet is connectionless.

TCP is not IP, the Internet Protocol.

							Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 24 Jul 2003 07:29:03 +0300

> TCP is not IP, the Internet Protocol.

< Id -> locator > mapping / binding / whatever is state.

--Pekka Nikander

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jul 2003 15:26:18 +0859 ()

Pekka;

> < Id -> locator > mapping / binding / whatever is state.

Huh? State?

IP layer does have certain state such as that for routing table,
which does not make it connection oriented.

Of course, there certainly is state of a connection, which MUST
be located at the transport layer or above, which is why
destination locator MUST be chosen by the transport layer
or above.

So is IP.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jul 2003 09:37:17 +0200

> < Id -> locator > mapping / binding / whatever is state.

It's state in the same way that the routing tables are state -
i.e. in general transport and applications have been taught to 
ignore it, and it gets recreated by magic when it gets destroyed. 
But this WG has to worry about the magic.

  Brian

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 24 Jul 2003 11:59:31 +0200

Hi again Masataka,

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Masataka Ohta
> Enviado el: jueves, 24 de julio de 2003 6:08
> Para: Pekka Nikander
> CC: Tony Li; Erik Nordmark; [email-masked]
> Asunto: Re: Minutes / Notes
>
>
> Pekka;
>

What about MIP?
I mean, there is a state stored in the IP layer about the CN and which
addresses (HoA CoA) are being used in the communication.

Perhaps we should explore the possibility that the IP provides a connection
oriented service. In such way, the connection is open with a given host and
then locators can change (just as MIP does)

Regards, marcelo

---

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

Marcelo;

> What about MIP?

MIP dynamically create a virtual point to point (thus, connection
oriented) link layer between end systems.

> addresses (HoA CoA) are being used in the communication.

The state belongs to the virtual link layer below lower IP layer.

> oriented service.

You should better use ATM.

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 24 Jul 2003 17:58:09 +0200

On torsdag, jul 24, 2003, at 08:27 Europe/Stockholm, Masataka Ohta 

> which does not make it connection oriented.

Mapping would create state. State != connection oriented.

- - kurtis -