Subject: [mobile-ip] Comments on draft-savola-ipv6-rh-ha-security-00.txt

From: Erik Nordmark <[email-masked]>
Date: Mon, 12 Nov 2001 18:22:57 +0100 (CET)

Pekka,

Thanks for bringing up these issues and writing them down in a draft.
I hope the draft helps focus WG discussions.

First a terminolgy question: in section 2 and elsewhere you use
the term "reflected DoS attacks" in a way that seems different than the
Paxon paper. http://www.aciri.org/vern/papers/reflectors.CCR.01/index.html
In particular, I think the following a forward routing header where there
is no information loss is quite different than X sending a TCP SYN packet
with source address A to B in order to get SYN ACK packets sent from B to A.
Do you have a definition of "reflected DoS attacks" that can help clear this
up? Perhaps I'm confused.

In section 2.2 it says "first the trails would lead to reflector2"
but wouldn't the logs indicate the source (spoofed) as the likely
offender. Then deeper analysis will show that there was a routing header
involved.

In 2.3 it talks about using "publicly known routers". Another possibility
is to use anycast addresses that identify sets of routers (like all
routers for an ISP) thereby identifying larger topological clouds than a single
router. I think such usage is more likely than listing individual routers.

As others have pointed out I think there are some issues
with restricting the forwarding to "interface-local" in section 2.4.1.
I agree that there are special cases like security gateways that have
"inside" and "outside" where in general you need to make sure
that routing headers can't be used to skip from one "domain" to another.
But for regular hosts it is fine to allow any interface.
In order to prevent link-locals and site-locals to "leak" 
you need the zone restriction, but one could argue that normal hosts
wouldn't have a security issue here.

Section 2.4.3 talks about a more radical approach to by using routing
header type. I think a cleaner and radical approach would be to define
a new extension header type for what is essentially tunneling with the
source address supressed.
Thus you'd have an IPv6 packet with 
	source = CN
	destination = CoA
and an extention header with
	final destination = Home Address

When the packet is received the receiver *treats this the same* as an
IPinIP encapsulated packet with an outer header
	source = CN
	destination = CoA
and an inner IP header with
	source = CN
	destination = Home Address

That way whatever policy knobs a host has for knowing when a packet
can be decapsulated can be applied.

It might be helpful if Section 3 also went into issues that appear
if ITRACE is used.

Without a home address option a reflector attack can be
done by sending
	src = victim
	dest = reflector
This will cause reverse ITRACE messages to be sent to victim from the
ITRACE capable routers between the attacker and the reflector, thus the
victim can use this to traceback towards the attacker even though its
address is not in the packets.

Using the home address option the attacker can instead send
	src = attacker (gets by ingress filtering)
	dst = reflector
	HAO = victim
In this case the reverse itrace messages go to the attacker i.e. the victim
does not see them.
Once the packet is reflected the "attacker" IP address is lost:
	src = reflector
	dst = victim

Thus HAO can be used to lauch attacks that reverse ITRACE can't track down.

Section 3.4.2 says
   As the address to be compared against is the source address, not
   destination, without keeping state filtering could be performed if
   and only if:
and I'm having a hard time parsing the sentence.

   Erik

---

From: Pekka Savola <[email-masked]>
Date: Thu, 15 Nov 2001 18:56:41 +0200 (EET)

Sorry for taking a while.  The comments took some chewing and at the same 
time, I was revising the draft.  Depending on your (hopefully) further 
comments, I should be able to put up a new version very soon.

On Mon, 12 Nov 2001, Erik Nordmark wrote:

Erik, thanks for very detailed comments.  It'll help in making the 
issues clearer.

> up? Perhaps I'm confused.

Yes, my terminology was different (actually I hadn't even read Vern's 
paper) -- I used it in a more generic sense.  For me, reflected attack was 
anything that used third parties to get at the final destination.  Would 
there be a better term for this; I couldn't think of any?

I'll add a terminology section with this, ingress and egress filtering at 
least.

> offender. Then deeper analysis will show that there was a routing header

Yes.  I skipped a few steps here, because tracing obviously spoofed 
addresses is of no use, and "backtracking" hop-by-hop (unless routing 
header is present) is the only way to get on the real trails.  I'll 
clarify this.

Now I just thought of another way a flooder could lay false trails: he 
could insert routing header entries with segments left=0 at the source, 
and the destination _might_ believe the packet went through all of those 
intermediate routers.  Thus using the existance of routing header is not 
enough proof.  I'll add this to the draft as well.
 
> router. I think such usage is more likely than listing individual routers.

Good point, I'll note that.  
 
> with restricting the forwarding to "interface-local" in section 2.4.1.

These are often "implementation dependant" issues, that is, whether MIPv6 
is treated as a "virtual interface as a whole" or a feature of an address, 
interface, node or whatnot.

> that routing headers can't be used to skip from one "domain" to another.

True.

> But for regular hosts it is fine to allow any interface.

This one is debateable.

> wouldn't have a security issue here.

I think link/site-local etc. restriction is essential.  

I will add another host-based approach (more general "administrator 
policy" of which a special case would be "if final destination is always 
known to be home address, it's always okay").
 
> source address supressed.

I don't really see any benefit in this, except saving like 20 bytes by 
skipping source address and a few other fields that would have been 
present in the IPv6 header.

Or were you suggesting, kind-of, "Home Address Option" -type Extension 
Header?  Replace destination X with Y, but additionally subject it to some 
specific tests?

A (small) gain of non-tunneling mechanisms include, at least, a more
realistic view of the network as everyone does not seem to be one hop
away.

Is there something I missed?

> It might be helpful if Section 3 also went into issues that appear

Nice.  I hadn't thought of itrace interaction :-).

There are two issues:

 - home address option and reverse itrace messages
 - routing header and normal itrace messages

(Routing Header could be used to lure at least some part of the messages
to some unsuspecting "relay" routers which don't know what to do with
them.  I'll probably add a mention of it into the threats section.)
 
> address is not in the packets.

Note: reverse itrace is at:
http://www.research.att.com/lists/ietf-itrace/2000/09/msg00044.html

if there was a draft, it has long since expired.  I'm not sure whether it 
makes sense to dig very deep into this, as it appears current itrace 
specification does not include this reverse possibility.  There are some 
problems with it anyway (the source being assumed to be spoofed and 
all...).

I'd like to hear your opinion whether this reverse itrace is an issue to 
be concerned about.

> Thus HAO can be used to lauch attacks that reverse ITRACE can't track down.

Yes, if itracing of the source is possible.

> and I'm having a hard time parsing the sentence.

Thanks.  I've replaced:

--8<--

     - local mobile nodes never roam outside of the internal network
       performing filtering.
--8<--

With:
--8<--
   Without keeping state filtering could be performed only if:

     - local mobile nodes never roam outside of the internal network
       performing filtering.
--8<--

This may be a bit clearer now, at least from the parsing point :-).  I 
could also elaborate how I got to that conclusion, but it's more or less a 
reverse (destination/source address) from the upper section, so I skipped 
it for brevity.

-- 
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: Thu, 15 Nov 2001 18:57:30 +0100 (CET)

> there be a better term for this; I couldn't think of any?

I haven't re-read the Vern's paper to see how general his
use of the term is.
Perhaps adding a note (or a mental note) that this might not be consistent
with other use, and making sure the term is well-defined in the document.

> enough proof.  I'll add this to the draft as well.

Good point.

> > But for regular hosts it is fine to allow any interface.

I haven't seen an argument where a host in general cares about 
network interfaces at this level. Is this just a Weak-ES vs. Strong-ES
model issue that appeared back in RFC 1122 and RFC 1127?

> I think link/site-local etc. restriction is essential.  

Agreed.

> Is there something I missed?

See draft-nordmark-mobileip-hindsight-00.txt and see if it is clearer.
Even if the format (HOA option and routing header vs. the tunneling header
I suggest in that draft) doesn't change I think, based on the arguments
you made in your draft, that the processing rules in the highsight draft
would apply.

> I'd like to hear your opinion whether this reverse itrace is an issue to 

Even if ITRACE isn't used (forward/reverse) other proposed schemes like
	Snoeren et al, Hash-Based IP Traceback,
	http://www.acm.org/sigcomm/sigcomm2001/p1.html
might have problems since they only deal with certain packet
transformations (like fragmentation) - dealing with the "reflection"
of a packet with a home address option means that such a system would need
to know about such transformation as well.

This I think preventing such unauthentication and unauthorized transformations
would be a good thing.

>    Without keeping state filtering could be performed only if:

Insert comma after "state".

   Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 16 Nov 2001 12:30:04 +0200 (EET)

> model issue that appeared back in RFC 1122 and RFC 1127?

Basically, but there is IMO a significant difference.  Weak-ES vs.  
Strong-ES can be seen also as a security risk (and it has been brought up
e.g. in Bugzilla before), but that's a known issue.
'
However, it can be (normally) abused only if you have local access to the 
network, that is, you can do something like:

# route add -host 127.0.0.1 gw a.b.c.d

This is not possible unless you're directly connected with a.b.c.d.  

However, with routing header, you are able to perform in effect the same
functionality from everywhere in the internet.  Therein, in this 
globality, lies the problem.

> you made in your draft, that the processing rules in the highsight draft

I see certain benefits in those, but one of the most important of them 
seems to be saving about 16-20 bytes off each datagram.  IMO, this should 
not be a major problem.

I've read your draft cursorily, I'll probably comment on it tomorrow I 
hope.

> This I think preventing such unauthentication and unauthorized transformations

Ok, this is a good thing to mention because itrace is not the only 
possible application which would could be disabled.

B.t.w., do you think it's good idea to discuss both routing header and 
home addres in the same draft?   I've had my doubts.  On the other hand, 
the issues are very similar, often only with destination/source reversed.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 16 Nov 2001 13:49:48 +0200 (EET)

On Fri, 16 Nov 2001, Pekka Savola wrote:

I have revised my draft, and it is available at:

http://www.netcore.fi/pekkas/ietf/draft-savola-ipv6-rh-ha-security-01.txt

Further comments are always welcome, of course.  I'll send it to I-D in a
few days unless anything comes up.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 16 Nov 2001 14:14:21 +0100 (CET)

> e.g. in Bugzilla before), but that's a known issue.

Yes, but that shows up when IP addresses are somehow trusted for
access control, like in your 127.0.0.1 example.

Thus when there are applications which use IP addresses for this
and different physical interfaces are trusted at different levels
you run into trouble.

> globality, lies the problem.

Agreed.
But if all non-loopback interfaces are trusted at the same level
and only the loopback interface benefits from more trust, then it
is sufficient to prevent "leakage" between the loopback interface and
the other interfaces. This can be done by making sure packets with 127.0.0.1
as source or destination are dropped when arriving on any non-loopback
interface and treating the source routed packets as "arriving" even after the
IP addresses have been swapped, and decapsulated packets should also be
treated as "arriving" on the physical interface in the general case I think.

In that case the use of an address assigned to interface eth0 on the eth1
interface doesn't matter since those interfaces are trusted (or distrusted)
to the same extent. Only the boxes that trust different 
physical interfaces to different extent need a stronger ES model for reception.
 So I think we are agreeing on the problems here.
We might still be disagreeing on what the default setting should be.

> the issues are very similar, often only with destination/source reversed.

Yes, I think they are basically the same but in different direction.
The rules for what packets are acceptable in the two directions might be
rather different but it still makes sense to discuss them in the same
context/draft.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Sun, 18 Nov 2001 13:55:44 +0200 (EET)

> > e.g. in Bugzilla before), but that's a known issue.

Note from above, I meant Bugtraq, naturally. :-)

> access control, like in your 127.0.0.1 example.

IP addresses will always be trusted, to some extent, until there is a
global PKI or some way of trusting, to some extent, an arbitrary node.. or
even working semi-local PKI.  That's life. :-)

127.0.0.1 was just one example, naturally.

> and different physical interfaces are trusted at different levels

I agree this is the most important in security gateways.

However, different interfaces are not an absolute requirement, but by far
the most popular scenario.

As noted, same-interface rule is not perfect...

An example of the other is a certain kind of a node.  Assume a webserver,
tcp wrappers, portmapper, etc. do a rudimentary form of identification via
IP address (for the latter, there are few alternatives).  It's not
necessarily the only form of authentication.

Say, this web server has two addresses for virtual hosting two sites.
One is more private than the other, although no top secret information is 
conveyed there.  There might be blocks in the firewall for some virtual 
host addresses (from certain netblocks, for example), but not all...

> treated as "arriving" on the physical interface in the general case I think.

Packets re-received through routing header should be subjected to these
checks (I'm not sure if it is 100% required), one of which, is loopback
prevention (as required by addrarch)
 
>  So I think we are agreeing on the problems here.

Yes.

> We might still be disagreeing on what the default setting should be.

Probably.  My argument is that multi-interface nodes almost always (to my 
knowledge) trust the interfaces to a diffrent extent.

Most access routers, servers with e.g. management, backup or whatever 
interfaces, etc.

Exceptions I can think of quickly are core routers (being routers, these 
rules don't apply to them anyway), and some webservers etc. that have 
multiple interfaces for load balancing, redundancy etc.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 19 Nov 2001 10:50:35 +0100 (CET)

> multiple interfaces for load balancing, redundancy etc.

Ah - you only list servers in your list.
What about the many clients that have e.g. a 802.11 and a GPRS interface,
plus potentially a logical interface hosting a single home address.
For such multi-interfaced devices the default of allowing routing headers
to "cross" between interfaces make sense to me.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Mon, 19 Nov 2001 11:55:54 +0200 (EET)

> to "cross" between interfaces make sense to me.

802.11 and GRPS have potentially different security, for example, company 
WLAN and mobile operator GPRS.

The main issue here is, IMO, what to do with logical interfaces.  At least
some of these could be treated as an exception (that is, interpreted as
being assigned on every interface), especially if the implementation is
made such that Home Addresses are on a logical interface, not a property
of a physical interface address.