Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt

From: Erik Nordmark <[email-masked]>
Date: Sun, 9 Dec 2001 00:44:48 +0100 (CET)

> It seems that in mobileip wg, reflector attack scenarios were
> identified for routing headers in Savola's draft. One solution,
> which seems to me feasible to implement (no state needed),
> was to mandate segments left to 1 and check that the address
> in the routing header is owned by the receiving MN host.
> Seems these scenarios are not necessarily mobileip-specific.
> I am wondering, are routing headers in this wg considered
> a special-purpose mechanism that cannot be used?

While such a check is reasonable for a host, a firewall can't actually
check this since it doesn't know the relationship between Care of Addresses
and Home Addresses.
I don't know how significant this issue is but given the concerns
expressed in Savola's draft about allowing general routing headers through
firewalls it seems worth-while to think about this and not immediately dismiss
it - having a separate packet format for routing headers (specifying
addresses of one ore more hops) from the ability to specify an extra
IP address for the destination *might* be the better thing to do.

> For home address options there are sections in Arkko's second
> draft in mobileip where it is recommended them always to be protected
> and (indirectly) to support both weak and strong authentication.

Yep.

  Erik

--------------------------------------------------------------------
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: "Jari T. Malinen" <[email-masked]>
Date: Sun, 09 Dec 2001 16:05:49 -0800

> IP address for the destination *might* be the better thing to do.

I have some doubt on this being better. How I would understand this issue
to apply is when a firewall e.g. would like to enforce: don't let source
routed packets through but only packets with both addresses in the same
end-host.

Though the firewall can't know CoA-HAddr associations, it might not
want to enforce these packets only to concern MNs. The same reflector
attacks could also be done using non-MN hosts. When enforcing the above
example firewall policy, maybe it could be less change-requiring to
recommend the host-check rule also for non-MN's (CNs). Then, a firewall
would allow only rthdrs with segments left 1 through. If reflector scenarios
need to be avoided in the domain, end nodes need to enforce this. This because
also tunneling to an end host can be made to reflect the inner packet to
another host. Hence, a format change in a protocol may not be what is
needed to address this issue, a rule in one form or another in the
end hosts might be needed anyway. Inventing a new format could make the
rule look implicit, though it needs to be enforced anyway in an
implementation.

Comparing to having a new message format, all hosts using it would
anyway need to implement the new format. The host rule for rthdr would
have the same scope of implementation change but with existing protocol
messages, and the change would only be an added check in implementation
of existing protocols, without protocol specification. Does this address
the issue?

>   Erik

BR,

-Jari

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Dec 2001 07:41:43 +0200 (EET)

> of existing protocols, without protocol specification. Does this address

The problem here is that a random CN host does *not* *have to* enable 
routing header processing at all -- and is therefore not affected.  With 
current mechanisms, a random CN does not have a need for implementing 
"interface-local" routing headers, but it could be done nonetheless.

On the other hand, MN *must* enable routing header processing.  As
currently specified, this opens the host to the attacks specified in my
draft.  The has to be some control on what routing headers to accept, more
fine-grained than on/off.

Another possible heuristic for accepting routing header could be:

if segments left == 1
 if the address to be swapped is a home address
   accept routing header
 fi
else if routing header processing is enabled
   accept
else
   reject
fi

This would be more MIPv6-centric and possibly easier to implement.  I 
don't know if there is need for "generic" use of interface-local routing 
headers outside of MIPv6 context at the moment.

-- 
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: Erik Nordmark <[email-masked]>
Date: Mon, 10 Dec 2001 06:25:40 +0100 (CET)

> routed packets through but only packets with both addresses in the same

Sorry, I can't seem to parse the above paragraph.
 
> would allow only rthdrs with segments left 1 through. 

My point is that segments left = 1 routing headers can be still used
to hop between two separate nodes. The firewall can't tell the difference
unless it knows all the CoA-HoA relationships for the MNs inside it.

> If reflector scenarios
> need to be avoided in the domain, end nodes need to enforce this.

But the segments left = 1 routing header could list internal routers
and not end nodes. So just checking on all end hosts inside the firewall
isn't sufficient to prevent any use general use of routing headers.

> This
> because also tunneling to an end host can be made to reflect the inner
> packet to another host. Hence, a format change in a protocol may not be what
> is needed to address this issue, a rule in one form or another in the

My point is that the current format is an overloading which makes it
impossible for a firewall to tell the difference between two different
uses of the routing header.

As Pekka's draft points out this could lack of distinction could
be addressed by defining a new type of routing header which is
limited to "forwarding" on the same node.

> of existing protocols, without protocol specification. Does this address

No.

  Erik

---

From: "Jari T. Malinen" <[email-masked]>
Date: Mon, 10 Dec 2001 10:00:45 -0800

> "interface-local" routing headers, but it could be done nonetheless.

True, CN does not need to support interface-local routing headers.
However, when CN supports routing headers, there is currently no
distinction whether they are interface local or not. But as you say,
when no routing header support is there, there is no problem.

> fine-grained than on/off.

To clarify, with host-check rule I was refering to the condition you describe
below, not just turning routing header processing on/off in MNs.

> headers outside of MIPv6 context at the moment.

Agreed.

BR,

-Jari

---

From: "Jari T. Malinen" <[email-masked]>
Date: Mon, 10 Dec 2001 10:34:38 -0800

Erik,

Let us compare a bit the cases to get more understanding.. I see your
point, though would also like to clarify the alternative I was explaining.
I was in search of an alternative with minimum change requirement. These
are design choices affecting many places so they are worth discussing a bit..

We are here talking of a domain that
- does not allow source routing in general, but
- allows 1-address source routing if the addresses are in the same node.

> unless it knows all the CoA-HoA relationships for the MNs inside it.

My point was that even though firewall would not know, if we have
enforcement of the "host-check" rule [cf. Pekka's mail for its decoding],
in all nodes _receiving_ the routing header, this would be a distributed way
of enforcing the conditions we discuss.

> isn't sufficient to prevent any use general use of routing headers.

This merits a clarification, partially due to 2460's terminology that has
caused some confusion earlier. A firewall who forwards a routing
header does not receive it, but merely checks for its existence in the
packet. A forwarding source router would be any node that receives the
packet, processes the routing header, and forwards it ahead according
to the routing header.

In the distributed approach I was describing, we would need the
"host rule" to be something to enable or disable in forwarding source
routers, too. In case source routing would be disabled for the domain,
they too would disable this.

> uses of the routing header.

I agree, and if the condition we discuss would be enforced locally
in a firewall, it would need to know this from the message.

> limited to "forwarding" on the same node.

True. This is another way, which is a "cheaper" way than a totally
new extension header to have the control localized to the firewall.

> > of existing protocols, without protocol specification. Does this address

So to get more clarity, is the localization (to the firewall) of
controlling the use of routing header something that you find necessary?
If so, would the use of "type 1" routing header in MIPv6 draft address
the issue?

BR,

-Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 10 Dec 2001 22:08:35 +0100

In your previous mail you wrote:

=> I disagree: the firewall doesn't know only if nobody sends the
information to it. If mobile nodes inside the domain the firewall
manages send (using the network access control for instance) this
kind of information to the firewall it should be able to do
smart ingress filtering for packets with home address option
(i.e. solve the ingress filtering fouled by home address options
by a better ingress filtering) and (symmetrically) be able to
filter out rogue source routing.

Regards

[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Dec 2001 23:17:42 +0200 (EET)

> filter out rogue source routing.

Firewall cannot know this without keeping state, as discussed in my draft 
(and with you :-).

IMO, I greatly dislike stateful firewalls.  They're one of the breakers of
e2e.

I don't think we should require stateful firewalls for this.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Dec 2001 00:42:29 +0100 (CET)

> Erik,

Sorry for not responding sooner - the email didn't have me on the to
or cc lists.

> of enforcing the conditions we discuss.

Yes, if you make all hosts and routers inside the firewall have that check
you'd be fine.

Two issues:
1. the firewall might not want to trust all the internal hosts and routers
   to be correctly configured with such a rule.
2. I think this would prevent using routing headers for their general use
   for traffic that is local to the domain inside the firewall.

So it seems like if these should be the default rule for all hosts and routers
we've effectively redefined the type 0 routing header to be only useful
for MIPv6. And if it isn't the default then issue #1 is definitely present.

Sounds like if there are strong arguments for this level of security 
it would be politer to define a new header than cripple the general usability
of the routing header.

> they too would disable this.

We're in agreement on this one.

> new extension header to have the control localized to the firewall.

For what notion of "cost" do you come to that conclusion?
To me the cost/benefit tradeoff between a new routing header type
and e.g. Deering/Zill tunneling headers isn't obvious.

> controlling the use of routing header something that you find necessary?

I honestly don't know.
Pekka brought up the issue - perhaps he can comment?

The background for this was that allowing generic use of routing headers
is dangerous and is something that firewalls might block.
But I don't fully understand the severity of allowing general use of routing
headers - it does allow a DoS attacker to hide a bit since it could be
present at any previous hop in the routing header.

> If so, would the use of "type 1" routing header in MIPv6 draft address

Yes, but is this conceptually simpler than Deering/Zill tunneling?
Easier to implement?

They seem to be about equivalent in these respects as far as I understand
today.

  Erik

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 10 Dec 2001 15:53:22 -0800

Hello folks,

> Yes, if you make all hosts and routers inside the firewall have that check

The same care is going to be required for routing headers as would be
for more general encapsulation in this regard.

For routing headers, all that is required is to check that the home address
is the next intermediate routing point after the care-of address.  If these
addresses were inserted into a longer sequence of intermediate routing
points, the same check would be sufficient _for the purposes of Mobile IPv6_!
The other parts of the routing path in the routing header would have to be
checked according to the rules of whatever policy was used to build up
the other parts of the routing path.

The exact same careful checking would be required if encapsulation
were used instead.

In this way, no crippling of the utility of the routing header would result.
On the other hand, I hope that my point can be understood that all such
uses will require care to avoid unwanted vulnerabilities.  Just like with
encapsulation!

>    for traffic that is local to the domain inside the firewall.

I think it's crucial that hosts using routing headers for care-of address
redirection are themselves responsible for doing the check, and not
to rely on the firewall.  It's not the job of the firewall.  And if encapsulation
were in use, it would definitely not be the job of the firewall.  I don't see
why this is considered to be a relevant issue.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Dec 2001 01:02:23 +0100 (CET)

> checked according to the rules of whatever policy was used to build up the
> other parts of the routing path.

I missing something: My assumed use case is that folks
want to use routing headers so that 
nodes can express a routing header with R1, R2, R3, Dest
while limiting certain traffic to only express "MIPv6 routing headers"
i.e. where there is a single hop on the final destination.
In such a case which filter rules would apply on the various nodes.

> The exact same careful checking would be required if encapsulation

In the abstract I agree.

But those checks will not disable some other general facility like routing 
headers.
Having a decapsulating node have a mechanism for various protocols
that use tunneling to specify what is acceptable to decapsulate
(so that MIPv6, configured IPv6-in-IPv6 tunnels, etc can all specify
what is acceptable) would make a lot of sense.

> On the other hand, I hope that my point can be understood that all such

I missing the point.

  Erik

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 10 Dec 2001 16:16:37 -0800

Hello Erik,

> In such a case which filter rules would apply on the various nodes.

My understanding is that the Mobile IPv6 use of routing headers
SHOULD NOT be managed in such a way as to preclude other
uses.  There was some discussion on the mailing list about this
a couple of months ago, and consequently some revisions were
made to draft ...-15 to enable more general use of the routing
header.  Before, there wasn't much discussion about it, but every
time that the topic came up I think that the sense was to avoid
usurping the use of the routing header.  Compatible co-existence
was more the intention.

> But those checks will not disable some other general facility like routing

And, neither should Mobile IPv6, according to my understanding.

> what is acceptable) would make a lot of sense.

Indeed, we could have a separate encapsulation for every application.
Or, as I hope, we can carefully specify the use of the existing tools in a
way to maintain their generality while still getting the particular function
we need.

> > On the other hand, I hope that my point can be understood that all such

Is it clearer now?

Regards,
Charlie P.

---

From: "Jari T. Malinen" <[email-masked]>
Date: Mon, 10 Dec 2001 17:21:14 -0800

Erik, (sorry omitting you from to-field)

>    to be correctly configured with such a rule.

True. However, to use general source routing, you may need such
configuration anyway.

>    for traffic that is local to the domain inside the firewall.

If the forwarding source routers do have the host-check rule disabling
as an option, they'd need to do further checking for legal destinations
to enforce locality you mention. Otherwise packets won't always stay
local to the domain.

But as said, the distributed approach is one option.

> it would be politer to define a new header than cripple the general usability

Given the distributed scheme I sketched, it would give all possibilities
to do source routing, routing forwarders would just need to locally allow for
source routing and have appropriate restrictions not to source-route anywhere.
I'd not call this crippling but insertion of distributed protection that would
allow a more controlled source routing.

Analogous would be to allow web access to a server inside, you must locally
ensure the server does not crash and let root shells run in it. This would
also possibly be doable in a firewall, but currently the control is
usually done watching all your reachable web server have current patches
not to crash.

Source routing would be a similar "service" in the distributed model.

> and e.g. Deering/Zill tunneling headers isn't obvious.

First, the security analysis in mobileip has identified the discussed
issues in routing header. They'd be needing attention anyway. MIPv6 would
give the opportunity both to have the issues for routing header fixed and
to define the forwarding needed by MIPv6 securely, both with the same fix.

Also, current implementations already know semantics of routing header,
among other thing, already being able to skip an even unknown rthdr type,
should this alternative be adapted, and as no new extension headers are needed,
less change to base IPv6 implementations.

> Yes, but is this conceptually simpler than Deering/Zill tunneling?

Slightly due to the already-known-semantics mentioned above. Also, if this
tunneling is not quickly mandated into the standard to all nodes, there
will be a big headache adapting it to legacy.

> They seem to be about equivalent in these respects as far as I understand

This on my opinion requires a closer look. In format, yes, in all the
implementation rules discussed here for the current RH/HAO, whether
the same rules can be applied to the tunneling and keep the idea of
genericity, I am not so sure. Other uses may have constraints conflicting
with MIPv6.

And finally, a silly question: if they do not have any difference,
why can't RH/HAO as well be considered the generic approach usable also
elsewhere?

BR,

-Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Dec 2001 04:10:46 +0100 (CET)

> why can't RH/HAO as well be considered the generic approach usable also

Deserves a silly answer.
Yes, we should get IPsec to stop using IPv6-in-IPv6 tunneling
and instead use RH/HAO, and we'll move RFC 2473 to historic :-)

One of the disadvantages of working on a draft for 5-6 years is that
the world might have changed around you.
Assuming that the new world will take one step back, one to the side,
and one step forward to use the new approach about to become a proposed 
standard when there already is a well-understood and deployed mechanism
seems a bit odd to me.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Tue, 11 Dec 2001 05:46:10 +0100

=> the state can be kept by the network access control system (which
cannot be stateless). And stateful firewalls are strictly more powerful
than stateless firewalls (this is not free of course).

=> I dislike all firewalls, but this problem is a threat against
ingress filtering so an ingress filtering solution is better.

=> I am afraid that if we ignore the problem the result will be
the filtering of all packets with more than two addresses as it is
the case for IPv4: we have to do a compromise...

Regards

PS: ingress filtering is not require, this is only a BCP.
There is no reason to be stricter.
--------------------------------------------------------------------
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: "T.J. Kniveton" <[email-masked]>
Date: Mon, 10 Dec 2001 22:08:09 -0800

> standard when there already is a well-understood and deployed mechanism

Well I have had an awful time trying to reply to this due to weirdness
with my wireless connection and sendmail, but let me paraphrase myself
and try sending again; maybe the 10th time is a charm...

I am not sure how silly your answer is supposed to be, but I am stuck on
thinking about how we should interact with a changed world in this case.
There is some conversation about replacing HAO with a nascent proposal
which is based upon using tunelling, which you said is about to become a
proposed standard. This means that the solution might "make sense" in
this changed world -- but one could come up with another alternative
based on other standards, it is just a matter of the lingua franca used
to describe mechanisms to achieve the same goal. The questions, as I
understand them, are really (a) is HAO broken enough that we need to
remove and/or replace it? and if so, (b) is the tuneling proposal a
suitable replacement?

There seems to be some disagreement about (a), but even assuming (a) for
the sake of argument.. people have so far refuted the relative
advantages of (b), other than the one in your answer: because it is
based on a proposed standard. It seems the security and anonymity
advantages are in question. At least insofar as the proposal might
relate to work in the Mobile IP group.

There are many examples of protocols that exist in today's changed
world, and still do just fine. The discussions about Mobile IPv6 have
certainly included considerations about what has changed in the last 5
years. But they are based on technical merits as well -- in my own
opinion, there doesn't seem to be anything that's come along that has a
clear superiority *and* serves the same purpose of the HAO, so it is
just as legitimate now as it was 5 years ago (hence you know where I
stand on (a)).

Well maybe you can tell me now how serious your answer was. And if I am
still trying to figure it out, perhaps the joke is on me...

-TJ

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Dec 2001 16:50:32 +0100 (CET)

> proposed standard.

Ah - sorry for not being more clear.
The "new approach about to become a proposed standard" is, from the
perspectives of the IETF at large, something called Mobile IPv6.

The well-understood and deployed mechanism (for MIPV4, IPsec, etc) is
IP-in-IP tunneling.

Does that change things?

  Erik

> This means that the solution might "make sense" in

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Dec 2001 17:57:31 +0200 (EET)

I'll try to discuss most points in this thread here..

> present at any previous hop in the routing header.

This is an issue that came up after I wrote a draft on 6to4 security.

It frustrated me a great deal that IPv6-in-IPv4 tunneling with the same 
protocol number 41 could be used for various things:

1. configured tunneling

2. automatic tunneling
 2.1 automatic tunneling with compatible addresses
 2.2 6to4
 2.3 ISATAP
 (more to come?)

If any two of 2.x are used in the same node, it's impossible to
distinguish and create complete security rules for more than one of them
simultaneously.. because protocol 41 has been overloaded.

The rules can't really be made in the firewall (without encapsulation
support etc.), but they can't really be made on the end-nodes either.  
Thus, this is even worse issue than here.  With RH, we still have a choice
for both.

Sure, it's easy to make it work this way...

I'd like to avoid this kind of overloading ("because it's easy to do it
like that") if we can.  I'd rather not repeat the same issues with
automatic tunneling with routing headers in a few years.

However, I don't see this "distinguishability" as a MUST as long as:

 1) MIPv6 MUST NOT require all processing of routing headers be enabled in 
MN's

 2) MIPv6 MUST require a special case for routing header processing that
is sufficiently secure.

 3)IPv6 SHOULD/MUST state (given 1,2) that nodes SHOULD NOT/MUST NOT 
enable routing header processing on hosts by default

( one could argue that currently, RFC2460 requires they must be processed 
[due to MIPv6] -- not all share my interpretation on this ) 

That is, if we can say quickly enough "routing headers cannot harm your
hosts!" they might not be taken as a security threat, and
distinguishability would not be required.

...

But really, IMO the tougher issue is how HAO will/should be handled.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Dec 2001 18:04:49 +0200 (EET)

> than stateless firewalls (this is not free of course).

If the state is outsourced but changes rapidly, this is IMO a still 
stateful firewall.. and we cannot rely on the existance of AAA, I think.
 
> ingress filtering so an ingress filtering solution is better.

This is a problem that affects all filtering, not just ingress (for source 
address).

> There is no reason to be stricter.

Filtering is a reality that is here to stay.  In the hostile world, we
cannot deny or ignore that.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 11 Dec 2001 19:28:32 +0100

1. configured tunneling
   
   2. automatic tunneling
   
=> oh, you forgot 6over4 !

=> we can start for the today situation: HAO are not recognized/supported?

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 11 Dec 2001 19:35:26 +0100

stateful firewall..

=> but state loss has less impact...

   and we cannot rely on the existance of AAA, I think.
    
=> if you have to take the responsability of what nodes inside your domain
are doing, AAA existance is a reasonable assumption.

   
=> we speak about the source address hiding by reflection in DDoS using HAO,
i.e. how to use HAO to foul the ingress filtering used as a protection
against DDoS, don't we ?

   
=> my argument was about the word mandatory in your original message.

Regards

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Dec 2001 20:59:46 +0200 (EET)

> i.e. how to use HAO to foul the ingress filtering used as a protection

Routing Header also brings up issues that would need state in the 
firewall, in a similar fashion.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Dec 2001 19:05:37 +0100 (CET)

>  1) MIPv6 MUST NOT require all processing of routing headers be enabled in 

Just MNs? Or hosts in general?

It isn't obvious to me from reading RFC 2460 whether a host can drop packets
with routing headers instead of resubmitting them for transmissing to the
next hop.

> [due to MIPv6] -- not all share my interpretation on this ) 

There is other use of routing headers such as being able to remotely
do a traceroute from the other end by source routing the packets
through that host.

> But really, IMO the tougher issue is how HAO will/should be handled.

Do you see issues with only accepting packets with HAOpt when the receipient
has a matching binding cache entry?
That seems to be the simplest approach to me.

Of course there are some details e.g. on how the MN discovers that the CN has
garbage collected the BCE but I think an ICMP error can handle that (but
I haven't thought enough about that).

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Dec 2001 21:13:07 +0200 (EET)

> Just MNs? Or hosts in general?

MN's are the only IPv6 hosts that need it right now, AFAIR.

All hosts would also be good, but I'm not sure if there's any _need_ to
burden IPv6 implementations that don't support MIPv6 at this point.
 
> with routing headers instead of resubmitting them for transmissing to the

AFAICS, the behaviour when routing header processing is disabled is left 
undefined.  Perhaps an IPv4 analogy would apply.

> do a traceroute from the other end by source routing the packets

I'm not sure if that is all that useful, but you're right.  There might be 
an exception (as is noted in RFC1122 IIRC) about "local routing headers".  
The check would be made stricter by e.g. requiring to-be-swapped address 
must equal the source address.

If one is able to spoof the source address, this could be used for 
anonymous reflection by spoofing source address to be that of the final 
victim.  Therefore I don't think this kind of use should be encouraged.

> I haven't thought enough about that).

I don't see security issues with that.

I was worried about the same thing too -- as Michael Thomas also pointed
out.  This could lead to rather unpredictable behaviour.  Getting this
robust enough (packets discarded until ICMP is received to notify about
this might not be enough) may be challenging.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Dec 2001 12:37:47 -0800 (PST)

> I haven't thought enough about that).

   Well, you probably should. This is essentially
   the same problem as the IPsec SPI-blackhole
   problem. It doesn't currently have a solution,
   and there are quite a few implications. DoS
   being one of the big ones.

	     Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Dec 2001 12:47:19 -0800 (PST)

> ingress filtering so an ingress filtering solution is better.

   I don't think I agree. Ingress filtering was adopted
   primarily because it could be done relatively easily
   through RPF checks. It's still pretty much an architectural
   hack though, and what we are seeing here is another
   manifestation of RFP-break-with-assymmetric-routes, IMO.

   I think it's far more productive to go back to first
   principles here in light of the new requirements. At
   the very least, we should consider whether edge policing
   is possible or desirable given the necessity of introducing
   new state and signaling. Maybe we ought to consider the
   end to end principle again.

	  Mike

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Dec 2001 23:14:07 +0100 (CET)

> burden IPv6 implementations that don't support MIPv6 at this point.

But if there is a security issue with mobile hosts forwarding packets
with RH (that contain them as a destination) why doesn't that
concern extend to hosts that don't implement MIPv6?

> must equal the source address.

But that wouldn't allow 3rd party traceroute (such as the NOC doing a
traceroute from A to B by source routing packets to B through A).
I have no idea if this is used operationally...

> victim.  Therefore I don't think this kind of use should be encouraged.

But it is a bit different than reflection ... in subtle ways.
My brain can't tell if these differences are significant...

> this might not be enough) may be challenging.

A possible addition would be allowing the CN to sending "binding nack"
when deleting the BCE. 
Then the ICMP error would occur e.g. when such a message is lost
or the CN crashes and reboots (i.e. doesn't have the ability to send
a nack).

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Dec 2001 00:24:59 +0200 (EET)

> concern extend to hosts that don't implement MIPv6?

It does concern them, but I guess I didn't say it clearly:

We can tell everyone to disable routing headers in hosts *IF* this
particular case is special-handled *where it's used*.  Currently, only 
MN's use it.  Therefore implementing this in MN's and switching the 
default would be the minimal procedure.

Hope this clarifies?

> I have no idea if this is used operationally...

Yes it wouldn't, but this kind of traceroute should be done with routers 
anyway (and this discussion wouldn't apply), or if really careful, the 
forwarding could be toggled on.

> My brain can't tell if these differences are significant...

Yeah, too many reflection attacks :-).  Difficult to say whether it's 
critically different.. but that's one more potential nastie anyway.. 

> or the CN crashes and reboots (i.e. doesn't have the ability to send

Perhaps those that analyzed the IPSEC behaviour (if it's similar enough) 
can elaborate on the subject.  But I think this is better done in a 
separate thread, in mobile-ip@ only.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 12 Dec 2001 00:10:25 +0100

=> for routing headers one has the choice between to protect against
abuses in the firewall (symmetrical to home address options) or in
mobiles nodes so this belongs to the second order.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 12 Dec 2001 00:48:07 +0100

=> my idea is more ingress filtering by firewalls at the egress points
of a site than ingress filtering based on RPF check inside upstream ISPs
as it seems to be your idea.
Or from another point of view I believe more in a responsability of
behaviors of inside nodes (i.e. using firewalls to protect the Internet
from our users) than in a smart sanity check (RPF ingress filtering).
Bout of course this is IMHO (:-)...

Regards

---

From: Robert Elz <[email-masked]>
Date: Wed, 12 Dec 2001 16:31:09 +0700

Date:        Tue, 11 Dec 2001 19:05:37 +0100 (CET)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <[email-masked]>

  | It isn't obvious to me from reading RFC 2460 whether a host can drop packets
  | with routing headers instead of resubmitting them for transmissing to the
  | next hop.

You don't have to read 2460 to know the answer to that particular question.

Of course it can (drop them) - hosts, routers, anything else, are permitted
to drop any packets that they want to, for any purposes that they want to,
nothing can force someone else to process any packets they don't want to
process.

That can mean disrupted communications if applied to extremes of course,
to which the solution is simply not to rely upon any system which drops
packets that you need forwarded ... in the above example, you really wouldn't
sanely attempt to source route through a host which you didn't know was
prepared to forward your packets.

There is though a different, related, question - one where what 2460 says
is applicable ... that is whether a host implementation should simply drop
packets containing source routes, rather than forwarding them.

Here we get the questions of the conformance of the implementation to the
spec.

And there I think the answer is a clear no - implementations are required
to be at least capable of processing routing headers (even in hosts).

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Dec 2001 16:47:02 +0100

> => oh, you forgot 6over4 !
In any case, I think the reusability of type 41 is a feature, not a bug. It means we
only have to persuade ISPs and corporate security people to open up one IPv4 protocol
type to enable all forms of 6in4 tunnels.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Dec 2001 20:44:46 +0200 (EET)

>   | with routing headers instead of resubmitting them for transmissing to the
[snip]
> to be at least capable of processing routing headers (even in hosts).

The last sentence IMO doesn't answer the real question.

I think it's quite clear that all nodes must support routing headers, that 
is, recognize the header type, be able to parse it, not send ICMP 
parameter problem packets back to the source, etc.

The real question how one processes a datagram with a routing header when 
the forwarding of routing headers has been disabled.  This issue is not 
mentioned in the specification (one could argue it should not be).

The options basically are:

 1) ignore the routing header, that is, act like segments left would have 
been = 0
 2) drop the packet silently
 3) drop the packet and send back an ICMP message
    - with some already defined type/code
    - with some new type/code

---

From: Francis Dupont <[email-masked]>
Date: Wed, 12 Dec 2001 20:58:18 +0100

=> IMHO Robert Elz' answer implicitely  suggested 2 (which is what
I'd like to recommend too).

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Dec 2001 21:28:04 +0100 (CET)

Agreed.

>     - with some new type/code

Some food for thought:

Taking Steve Deering's suggestion into account there seems to be 3 knobs
that a node should have:
1. forwarding (or not) packets no explicitly addressed to itself
   (i.e. is the node a router or not)
2. forwarding (or not) packets with RH where the next hop is outside the
   node
3. forwarding (or not) packets with a RM where the next hop is the same node

For MIPv6 we need knob 3 to be on by default on the MN.

For #1: when a host receives a packet not explicitly addressed to itself
it must silently drop it.

For #2 I don't see anything in RFC 2460 or the icmpv6 draft about sending
ICMP error vs. silently dropping.

  Erik

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 13 Dec 2001 15:13:20 -0700

In may opinion ( already stated about 2 months ago) there are really no
problems with Routing Headers.

I am really thinking about this in terms of forwarding.  If while
processing
the routing header, I have to forward the packet off the node, then all
the
"router" rules apply (i.e I have to have forwarding enabled).  If the
packet
is forwarded to the same node (looped back), then I am not really
forwading this,
and the node consumes the packet.

We don't needlessly drop packets, MIPv6 is happy, and there are no holes
that
I can see (I may be blind though:)

-vlad

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Dec 2001 15:44:58 +0700

Date:        Wed, 12 Dec 2001 20:44:46 +0200 (EET)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | The options basically are:
  | 
  |  1) ignore the routing header, that is, act like segments left would have 
  | been = 0

That one is clearly wrong.

  |  2) drop the packet silently
  |  3) drop the packet and send back an ICMP message
  |     - with some already defined type/code
  |     - with some new type/code

Either of those could work - "administratively prohibited" would be an
ICMP that could be sent without having to invent a new one.

Whether you want to send an ICMP depends a lot on what you expect the cause
of the unintended source route to be ... if it is someone trying to launch
some kind of attack, and looking for someone to help them hide (or similar),
then silent drop is likely to be the conclusion - on the other hand, if you
expect these may come because of badly configured mobile nodes (or old packets
being sent to a node using an address that a mobile one used to occupy ..
a bit unlikely with IPv6 addresses of course) or similar, then sending an ICMP
would be right.

kre

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Dec 2001 15:27:33 +0200 (EET)

On Thu, 13 Dec 2001, Vladislav Yasevich wrote:
> processing the routing header, I have to forward the packet off the
> node, then all the "router" rules apply (i.e I have to have forwarding
> enabled).

I believe this is not how most implementatios have done this.  Else for
example "round-trip traceroute" would never have worked.

> If the packet is forwarded to the same node (looped back),
> then I am not really forwading this, and the node consumes the packet.
> 
> We don't needlessly drop packets, MIPv6 is happy, and there are no
> holes that I can see (I may be blind though:)

My biggest worry is that RH processing, what you call forwarding to the
same node, cannot be disabled in hosts.

Other worries include bringing every node in the Internet "on-link" to a 
certain point.  That is, when you're on-link you can do stuff like:

route add -host 127.0.0.1 <some on-link target>
route add -host <private interface address of an on-link target> <onlink target>

[ping -t 255 <onlink-target> (so that the packet is received with 255 hop 
limit -- NOTE! this is only with tunneling, not applicable to RH]

etc.

My take is that I certainly wouldn't like anyone at all being able to do 
these because routing headers must be processed, and if they're "local" 
"forwarded" on the same node.

Therefore I think stricter rules on the applicability of RH are definitely 
needed.  In most cases, it's not necessary to be able to do.

But please, if you have specific arguments, have a look at my draft.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Dec 2001 15:32:34 +0200 (EET)

> type to enable all forms of 6in4 tunnels.

Yes, it can be seen as a feature.  Going back, though, it would probably
have made sense to reserve 32 bits in the format, including an 8-bit
"sub-type" identifier for those mechanisms.

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 14 Dec 2001 14:41:09 -0700

Pekka

I've read your draft and here is the list of comments regarding the
Routing
Header.  In my comments  I am making an assumption that hosts do not
forward
packets off the node.

---- Section 2.1 ----

With the above assumption, the webserver will not forward the packet to
host2 (unless of course you configure webserver as a router).

The webserver will the receive the packet described in the draft and
do processing according to 2460.  When processing the routing header,
it will follow the 2460 rules by swapping the addresses and attempting
to forward using let's say ip6_forward() method.  Since this is a host,
it should not be forwarding off the node (assumption above).  Since the
route
to 'host2' points off the node, the packet is dropped (and I think the
ICMP error is returned, not sure on this point).

---------------------

---- Section 2.2 -----

The description for Section 2.1 applies here as well.  Unless the
'reflector'
is a router (that's not doing ingress filtering), the packet will be
dropped at the reflector and the attack will fail.

I do not know how iTrace works so can't comment on Section 2.3

As you can see, if we restrict the hosts to not forward packets off the
node
( I think this is already done... indirectly), then the routing headers
do not really cause big problems.

As for your message with people creating routes to loopback, there is
nothing
you can do if people insist of shooting themselves in the foot. :)

-vlad

---

From: Pekka Savola <[email-masked]>
Date: Fri, 14 Dec 2001 00:51:50 +0200 (EET)

On Fri, 14 Dec 2001, Vladislav Yasevich wrote:

> Routing Header.  In my comments I am making an assumption that hosts
> do not forward packets off the node.

My draft makes the opposite assumption, as that is how I perceive most
implementations do (Linux, KAME, probably Windows as they use round-trip
traceroute, etc.), as seems to be expected by RFC2460.

Your points are valid when you make the above assumption.

Nonetheless, discussion in 2.5.1. and security considerations apply.  
IMO, "same-node" does not seem to be a strict enough requirement, if one
assumes this kind of routing header processing would have to be enabled on
*every* host.

> ---- Section 2.1 ----
> 
> [...]
> to forward using let's say ip6_forward() method.  Since this is a
> host, it should not be forwarding off the node (assumption above).  
> Since the route to 'host2' points off the node, the packet is dropped
> (and I think the ICMP error is returned, not sure on this point).

As far as I can see, no ICMP error is returned; I don't see where it would 
be specified, and quick tests don't show that either.

> As you can see, if we restrict the hosts to not forward packets off
> the node ( I think this is already done... indirectly), then the
> routing headers do not really cause big problems.

Where is this done indirectly?

As a matter of fact, until very recently, one implementation specifically 
allowed routing headers even when the general forwarding was  disabled .. 
because that is what impression RFC2460 gives.

> nothing you can do if people insist of shooting themselves in the
> foot. :)

Remember, it's _attackers_ who are not doing this -- not administrator 
shooting themselves in the foot.

Addrarch requires that these packets to loopback, site/linklocal are
dropped at input.  However, I'm curious whether all implementations 
process the packets received through this mechanism via the same input 
functions as regular packets would have been -- that is, has someone 
created "shortcuts" here..

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 14 Dec 2001 16:22:00 -0700

Pekka

RFC 2460 states the following:

>  router      - a node that forwards IPv6 packets not explicitly
>                addressed to itself.  [See Note below].

and the conseptual sending algorithm is this:
>         else {
>           swap the IPv6 Destination Address and Address[i]
>
>            if the IPv6 Hop Limit is less than or equal to 1 {
>               send an ICMP Time Exceeded -- Hop Limit Exceeded in
>               Transit message to the Source Address and discard the
>               packet
>            }
>            else {
>               decrement the Hop Limit by 1
>
>               resubmit the packet to the IPv6 module for transmission
>               to the new destination
>            }

One could argue that after the source routed packet is processed and
resubmitted for
transmision, it's is no longer addressed to the node processing it (the
source is the original source and the destination is the next hop). 
Thus, the node in effect is
forwarding this packet.  "Forwarding" is a function of router thus, in
my mind the
node has to be configured as router and has to obey all the router
rules.

> assumes this kind of routing header processing would have to be enabled on

I beleave that's what 2460 assumes.

> created "shortcuts" here..

This would be a bug in the implementation and the implementation needs
to be
fixed.  It doesn't make sence to impose restriction on a well behaving
implementation.

-vlad

---

From: Pekka Savola <[email-masked]>
Date: Fri, 14 Dec 2001 23:56:10 +0200 (EET)

On Fri, 14 Dec 2001, Vladislav Yasevich wrote:
> resubmitted for transmision, it's is no longer addressed to the node
> processing it (the source is the original source and the destination
> is the next hop).  Thus, the node in effect is forwarding this packet.  
> "Forwarding" is a function of router thus, in my mind the node has to
> be configured as router and has to obey all the router rules.

This is a very good argument which I haven't seen presented yet.  
The text might be clearer on this.  Thanks.

I think I'll reflect this in my draft, list the issues currently there 
with a note and describe a new scenario or two where this is not strict 
enough.

> I beleave that's what 2460 assumes.

This is worse than with IPv4 (there, hosts should basically disable
routing header even though local by default). (note that RFC1122 3.3.5 
uses a different interpretation of 'local').

> to be fixed.  It doesn't make sence to impose restriction on a well
> behaving implementation.

Well, the problem is -- how can we know if some implementation does this 
or not?  The description of behaviour (example: source routes outside of 
node, above) are sometimes a bit fuzzy.