Subject: Re: nonexisting destination on p2p link

From: [email-masked]
Date: Tue, 1 May 2001 03:07:29 -0300

¡Hola!

> >implementing your suggestion prevents the option of doing something
> >similar for IPv6.
> >let the packets bounce between the two routers for a while, in the end
> >you'll get a time exceeded message anyway.
> 	do you think it okay even if outsiders (bad guys) can chew your
> 	bandwidth?  i think not.

And while we have so many tunnels over the IPv4 internet, that means chewing
bandwidth in all the way between the end points of the tunnel, not just in
a private link as would be with a physical connection...

> itojun

					HoraPe
---
Horacio J. Peña
[email-masked]
[email-masked]
[email-masked]
[email-masked]
--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Tue, 01 May 2001 16:26:16 +0700

Date:        Tue, 01 May 2001 11:19:11 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	do you think it okay even if outsiders (bad guys) can chew your
  | 	bandwidth?  i think not.

No, nor do I.

But you are proposing to fix this by special case code.  I'd prefer to
fix it by correctly configuring my routing table.

That is, if the only thing out the P2P link in a specific address range
is 1 address, I should have a /128 in the routing table, not a /64.

If for some reason I have chosen to install a /64 for the link, then I
must want all those packets to get sent down the P2P link.

On the other hand, if the /128 is all that exists, then regular forwarding
decisions (with no special cases) will arrange that packets that shouldn't
get forwarded down the link don't get sent that way.

I appreciate the implementor imperative to save me from my own mistakes
(even if purely motivated from avoiding having to constantly tell people
what they're doing wrong) - but please don't do that.  Let me make mistakes
and learn.

kre

---

From: [email-masked]
Date: Tue, 01 May 2001 18:35:41 +0900

>must want all those packets to get sent down the P2P link.

	again, this really depends on how an implementor model p2p interface
	on their implementation.  it seems to me that there's no common
	consensus, at all, on how p2p interfaces gets implemented, and
	how these routes to p2p gets advertised to neighbors by routing
	protocols.  cisco and gateway are the popular interpretation, i guess.
	i guess it hard to standardize the interpretation/model of p2p
	interface.

	if i know the peer's address, i can install blackhole route for /64,
	and specific route for /128 (for my interface address and the peer's).

	however, it is not always possible to know peer's address beforehand:
	- we don't always know peer's address (think about linklocal address
	  - fe80::/10), and
	- we don't run NS/NA on L2 without hardware address, so
	- we don't know the peer's address.
	i would like to solve the problem for this case.

>get forwarded down the link don't get sent that way.

	actually, "use the default route" can be dangerous here.  on 6bone, we
	see a lot of bogus unicast NS/NA toward global address (probably due to
	NUD) sent to offlink destination over wrongly-configured default
	route.  we are seeing them as the following kernel printf() messages.
	since they have TTL=255, they go all the way to the final destionation
	(like www.kame.net).  i hope to help people configure the boxes right,
	but if there are millions people (i guess there will be) i can't
	keep up.

May  1 13:26:29 apple /netbsd: nd6_ns_input: invalid hlim 249
May  1 13:26:48 apple last message repeated 8 times
May  1 13:45:06 apple /netbsd: nd6_ns_input: invalid hlim 249
May  1 13:45:34 apple last message repeated 11 times

itojun

---

From: Robert Elz <[email-masked]>
Date: Tue, 01 May 2001 16:56:55 +0700

Date:        Tue, 01 May 2001 18:35:41 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	however, it is not always possible to know peer's address beforehand:
  | 	- we don't always know peer's address (think about linklocal address
  | 	  - fe80::/10), and
  | 	- we don't run NS/NA on L2 without hardware address, so
  | 	- we don't know the peer's address.

Then what use is installing the route?   If you don't know the link
local address of the remote end, simply don't install a route to it.

On a p2p link the only people who are going to be able to send to a
link local addr are the 2 end points, by definition you don't know his
address to send to, thus you can't be sending any packets to him.
If he sends packets to you (hoping that you will loop them back to him)
then whether you fail to do that because of your proposed rule that
makes a special case for p2p links, or whether you do it because there's
no route to his link local, seems to make little practical difference.

If you do, via a routing protocol, or any other way, manage to discover
what the remote end's LL address is for the P2P link, then you can install
the route, and then you would be able to send to it.

  | 	actually, "use the default route" can be dangerous here.

Yes, without doubt, default routes cause problems (they also make life
easy, so they're not going away...)

  |  i hope to help people configure the boxes right,
  | 	but if there are millions people (i guess there will be) i can't
  | 	keep up.

Certainly the default setup, what "just happens" should be the safe way.

I'm even trying hard to imagine what kind of config screwup could cause
the effects that you are describing (though I guess we should have considered
that as a likely possibility back when the coin toss was made to decide
whether NS etc would be an ICMP protocol or a link level protocol (like ARP)).

The point is that if you force the safe way, rather than just defaulting
to it, you immediately kill the possibility that some future clever
invention can ever be made to work.   If people just need to change their
configs to allow something new it is easy - but if code changes need to be
made, it gets so hard that the whole thing is a write-off.

kre

---

From: [email-masked]
Date: Tue, 01 May 2001 19:06:05 +0900

>the route, and then you would be able to send to it.

	suppose you have a tunnel between two machines, establish a tunnel
	between them, and would like to run ripng.  they have link-local
	address, La and Lb, respectively, on their interface.

	router A
	  | La
	  |
	  | Lb
	router B

	normally router A does not know Lb, router B does not know La.
	they will learn about each other using routing protocols (ripng).

	to throw out ripng packets to the other end, we would need to have
	fe80::%interface/64 as well as ff02::%interface/64 to be installed
	onto the routing table.  they are normally installed by default by
	the operating system.  now, we have the problem i have described
	repeatedly (packet to non-existing destination will make a loop).

	am I confused in some way?  the above is reallife example for us,
	how do you setup routers in your setup?  do you tell the other end your
	linklocal address?  if you did that, you will have trouble replacing
	router in your end.

	or, are you proposing this scenario?
	- routing table has ff02::%interface/64
	- routing daemon discovers each other
	- routing daemon installs Lb%interface/128 once they discover each
	  other
	none of the existing routing daemons (i know of) work this way.

itojun

---

From: Robert Elz <[email-masked]>
Date: Tue, 01 May 2001 17:25:17 +0700

Date:        Tue, 01 May 2001 19:06:05 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	to throw out ripng packets to the other end, we would need to have
  | 	fe80::%interface/64 as well as ff02::%interface/64 to be installed
  | 	onto the routing table.

"Need to have fe80::%interface/64" ??  Why?

  | 	how do you setup routers in your setup?

Most likely the same way that you do, but without the bad apps that are
sending to bogus link locals I guess (that or I just haven't bothered
looking as hard for the looping packets).

  | 	or, are you proposing this scenario?

More like that, yes.

  | 	- routing daemon installs Lb%interface/128 once they discover each
  | 	  other
  | 	none of the existing routing daemons (i know of) work this way.

Of course not - until you raised the issue recently, no-one really understood
that there was a problem to be solved.

But it need not be the routing daemon that installs the route (though it
easily could be, given that installing routes, and deleting them again, is
its main function) - you could also have the kernel install the route when
it receives a packet from a link local addr (essentially install the neighbour
cache entry based upon info in received packets) - in this case most likely
the multicast ripng packets from the remote router.

I think I prefer having the routing daemon do it, that provides more
opportunities for it to be subject to rules in a config file, etc, and
easier replacement by something more sophisticated.

I think that (at least) I should rest from this discussion for a while,
and await opinions from others.

kre

---

From: Pekka Savola <[email-masked]>
Date: Tue, 1 May 2001 14:38:36 +0300 (EEST)

> 	none of the existing routing daemons (i know of) work this way.

Have I missed something, or why does this have to be done in the routing
protocol?  Can't some more generic, lower level method like NS/ND work
here?

More generic /128 route addition can of course be problematic if it's not
done right in the routing protocol.  Imagine enabling a flawed version
this on a 1000-computer LAN segment and filling your routing table.

-- 
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 02 May 2001 07:26:09 +0900

>>>>> On Tue, 01 May 2001 17:25:17 +0700, 
>>>>> Robert Elz <[email-masked]> said:

> "Need to have fe80::%interface/64" ??  Why?

(Although here seems to be a mixture of an implementation issue and a
protocol issue,) you're right, we do not need fe80::%p2plink/64 to
send multicast RIPng packets on the p2p link (I intentionally changed
the scope ID part from "interface" to "p2plink").  

[As for the implementation, we do not even need ff02::%p2plink/64 to
send the packets, since our routing daemons usually specify the
outgoing *interface* using the advanced API...but this is a completely
different issue.]

In my understanding, our (KAME's) motivation is as follows:

1. we'd like to allow users to configure a /64 prefix even on a p2p
   link (the prefix might be link-local, site-local, or global.  That
   doesn't really matter in this discussion.)

2. we'd also like to allow users to use the /64 prefix on the p2p link
   just like an ethernet (i.e. broadcast) link.  That is, when P/64 is
   assigned to the link, users can assume there might be a node P:A on
   the other end of the link for an arbitrary interface ID 'A', which
   might be learned from DNS, off-line communication, some other
   discovery mechanism, or even some misconfiguration or attacks.

3. the only difference between broadcast links and p2p links is that we
   do not need the (link-layer) address resolution procedure on a p2p
   link.  Thus, when a user specifies a P:A as destination, the kernel
   can simply send a packet to an interface of the link, and the
   interface is uniquely determined in typical configurations (i.e. the
   only interface that attaches to the link).

4. however, this "optimization" of sending rule would raise the
   possibility that the other node receives a pakcet destined to an
   address that the node does not have (but that covers the prefix
   which should be regarded as on-link on the p2p link).  In this case,
   the packet would be looped on the link, consuming its hop-limit.

5. in fact, we've seen many such loops in our IPv6 backbone (as itojun
   described,) and wondered if we could add another kind of
   optimization for the forwarding rule.

As someone on the list pointed out, we could do NS-NA exchange on the
step 3 instead of just sending the packet.  However, we did not like
this approach because it could drop some packets during the
"resolution" period, or at least could delay the arrival of the
packet, while such drops and delay should not really be necessary.

My opinion is that this type of forwarding optimization (i.e. dropping
the packet and sending an icmp6 error instead of letting the packet be
looped) is worth considering, although it might not always be the best
choice (e.g. when someone wants to send a packet assuming that it
should be looped back for testing purposes).

So, how about specifing this as a "SHOULD be enabled by default, but
MUST be able to be configurable" stuff?  (And the default behavior
might be controversial.)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: [email-masked]
Date: Wed, 02 May 2001 09:58:42 +0900

>protocol?  Can't some more generic, lower level method like NS/ND work

	when there's no linklayer address (ppp/tunnel), the spec do not ask us
	to run NS/ND.  i guess it is not a good idea to require it,
	at this late stage of the standardization.

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 2 May 2001 14:18:04 +0200 (CEST)

Jinmei,

>    discovery mechanism, or even some misconfiguration or attacks.

Doesn't this mean that you'd like the other end of the link have more than
one interface ID? For the same reasons that folks use multiple interface IDs
on a multi access interface it would make sense to allow that on pt-pt
interfaces.

If you allow this there is a possibility that the other end uses a very
large number of interface IDs. Do you expect the two ends to somehow
discover (manually?) all the interface IDs?

Ignoring the DoS issue for a moment, there seems to be some utility
in sending anything in the /64 (except perhaps the sender's IP addresses -
different implementations seem to do that differently) across the pt-pt
link since it allows the peer to have any number of interface IDs in the /64.

*If* we want the above flexibility I don't think a simple
sending rule can fix the DoS issue - I think we need something akin
to sending an NS/NA pair across the link (even though that
sounds a bit silly on a pt-pt link).

  Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 03 May 2001 07:26:52 +0900

>>>>> On Wed, 2 May 2001 14:18:04 +0200 (CEST), 
>>>>> Erik Nordmark <[email-masked]> said:

> one interface ID?

Yes.

> discover (manually?) all the interface IDs?

No, at least in our current implementation.  As described above, it
just sends the packet to the p2p link, assuming the other end node has
the destination address.

> sending rule can fix the DoS issue

why not?  Do you mean an attack that sends a massive number of packet
that fills in the p2p link in a single direction (i.e. not looped)?
If so, that's right, but, this type of attack cannot be prevented by
NS/NA exchanges, either.

> I think we need something akin

					JINMEI, Tatuya