Subject: [mobile-ip] WG Last Call on Threat Model and Security Requirements for MIP v6

From: Phil Roberts <[email-masked]>
Date: Fri, 5 Oct 2001 10:07:55 -0400

Hi folks,

    this is a working group last call on the threat model and security
requirements
for Mobile IP v6 draft.  The intention is to publish this document as an
informational
RFC.  Please post comments on this document to the mobile ip mailing list.

http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01
.txt

Last call expires Oct 19, 2001.

Phil and Raj

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Oct 2001 23:35:25 +0300 (EEST)

> Last call expires Oct 19, 2001.

I posted some comments on:

Date: Sun, 30 Sep 2001 15:49:31 +0300 (EEST)
Subject: [mobile-ip] MIPv6 SecReqs: HA Option processing, HA Dyn Discovery

There was a lot of philosophical cruft :-) in the mail, though, but a
main point from SecReqs perpective was:

--8<--
I have may have missed something, but it appears to me that two scenarios
discussed in more detail:

 1) usage of Home Address Option.  Its use need not be authenticated.
Anyone can put it in.  This makes _one-way_ (nice enough for UDP and ICMP)
IP spoofing less than trivial.
--8<--

This has not been commented by anyone.

I think SecReqs document should also address the following issues:

(new)
 - mobile nodes (at least) MUST have forwarding via routing headers
enabled.  This can be used to e.g. reflect traffic by laundering (DoS,
security disclosure, ...) by anyone in the Internet.  This works for TCP
connections too.

(home address)
 - use of home address may allow one to perform DoS attacks w/ source
address spoofing, among others.  Home Option must be processed in every
IPv6 node even if there is no BU or anything that will use it.  This could
get nasty.

These are covered, to some extent, in:

http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-00.txt

I'd definitely want to have these issues taken into consideration when
considering different MIPv6 security options, as these could basically
affect every IPv6 node, whether mobile or not, in the end..

-- 
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: Alexandru Petrescu <[email-masked]>
Date: 14 Oct 2001 22:36:29 +0200

Pekka Savola <[email-masked]> writes:
>  1) usage of Home Address Option.  Its use need not be
> authenticated.  Anyone can put it in.  This makes _one-way_ (nice
> enough for UDP and ICMP) IP spoofing less than trivial.

It looks to me you're describing an attacker that puts a Home Address
option in a random packet towards a victim, without using any Mobile
IPv6 features (notably, without any BU's), right?

> security disclosure, ...) by anyone in the Internet.  This works for TCP

If I understand correctly your scenario: attacker sends packets
containing a routing header first to "victim MN" and then "victim MN"
would route them to a victim2 elsewhere; victim2 will not realize who
is the true attacker, it would believe the attacker is the "victim
MN".  Right?  If so, then this is not related to Mobile IPv6, I think.

> http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-00.txt

Yes, thank you for the draft.  I replied in private, my comments not
related to Mobile IPv6 or the requirements draft.

Alex

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Oct 2001 13:37:52 +0300 (EEST)

> IPv6 features (notably, without any BU's), right?

Yes.

> MN".  Right?  If so, then this is not related to Mobile IPv6, I think.

Not quite.  

Victim2 would see packets coming from the direction of 'victim MN', and 
if the source address is spoofed, this trail leads to 'vicim MN', not the 
actual attacker.  This is an issue, but nothing new.

What I tried to say is that if a router/packet filter guarding victim MN
and victim2 would pass the intended traffic to victim MN but _not_
victim2, this will get around the block as destination address is
overwritten.

These problems, in itself, are not Mobile IPv6 specific.  I don't claim 
them to be.  There are some consequences, though, combined with Home 
Address usage.

But the _real problem_, one could say caused by MIPv6, is that all nodes
(at least all mobile nodes) _must_ have this Routing Header processing
enabled.  One could say MIPv6, as defined, may open every mobile node for
abuse.

If there was no MIPv6, there would be no strong need to be able to process 
routing headers in hosts, only a few, possibly hand-picked, routers.  The 
risks would be manageable.

As you see, MIPv6 appears to make the Routing Header abuse problem the 
reality.

---

From: Alexandru Petrescu <[email-masked]>
Date: 15 Oct 2001 18:28:58 +0200

> > IPv6 features (notably, without any BU's), right?

So I take this as your agreement that the attack above (on the Home
Address option) is not related to Mobile IPv6, so not to be taken into
account into the requirements draft.  Moreover, a quick scan of the
-15 draft shows that care has been taken to protect nodes against
usage of the Home Address option (disconnected from BU's).  For
example state is not created in nodes receiving Home Address options.

> What I tried to say is that if a router/packet filter guarding
> victim MN and victim2 would pass the intended traffic to victim MN
> but _not_ victim2, this will get around the block as destination
> address is overwritten.

Can you give a simple, but simple, scenario of a threat?  One
paragraph?

> But the _real problem_, one could say caused by MIPv6, is that all
> nodes (at least all mobile nodes) _must_ have this Routing Header
> processing enabled.  One could say MIPv6, as defined, may open every
> mobile node for abuse.

I understand.  But I think that Routing Headers are processed by
mobile nodes not because Mobile IPv6 requires them, but because
rfc2460 requires them.

> If there was no MIPv6, there would be no strong need to be able to
> process routing headers in hosts, only a few, possibly hand-picked,
> routers.

Can you assert that Mobile IPv6 is the only protocol that relies on a
host to process a Routing Header?  Are you sure that no other IETF
protocol does so?  I would be interested to find out this too.  

Alex

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Oct 2001 20:35:04 +0300 (EEST)

On 15 Oct 2001, Alexandru Petrescu wrote:
> account into the requirements draft.

Wrong.

Mobile IPv6 adds Home Address option.  If there was no MIPv6, there would
be no HA and there would be no attack.  Thus MIPv6 is "responsible" for
this behaviour (ie: security of home address option).

>  Moreover, a quick scan of the

No state protects only against one kind of DoS, namely, overloading the 
state machine or exhausting memory.

I have yet to see _anything_ that would protect e.g. against:

src host=spoofed-someone/real-someone
dst host=victim
dst option, home address=victim-i-want-to-blame/someone-victim-trusts
udp header, dst port=111

and some nice exploit/DoS in the payload.

The fact remains that the destinations will always see source as 
"someone-victim-trusts", even if it has never received any binding updates 
or anything MIPv6-specific, save the home address option.

If I have missed this scenario, please clarify?
 
> Can you give a simple, but simple, scenario of a threat?  One

Not easy, unless something can be assumed, host[1,...,N] defined, and
perhaps a diagram drawn.

"Mobile hosts must process routing header.  Having to enable routing
header processing for everyone is dangerous as it can be used to reflect
traffic and to get around packet filters' access lists."

More would require pretty specific elaboration on how processing works.
 
> mobile nodes not because Mobile IPv6 requires them, but because

RFC2460 appears to be intentionally vague about this.  There are different
opinions on this.  I think 2460 may have been made this way so that MIPv6
etc. would work.

It's clear that RH processing would be disabled on hosts by default (if
for nothing else, the IPv4 Host Requirements RFC), if not for MIPv6.
 
> protocol does so?  I would be interested to find out this too.  

This was discussed (rather duologous conversation between me and Francis 
Dupont) on ipng last month under subject "Routing Header Considered 
Harmful".

Microsoft mentioned using something called "round-trip traceroute" as an
option IIRC, which may use routing header w/ hosts.  I don't recall any
other possible requirement.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Oct 2001 15:28:00 +0200 (CEST)

> This has not been commented by anyone.

When the HA option was designed there wasn't a good understanding
of reflectors for DoS attacks, thus the analysis of the HA option
security doesn't take this into account.

Do you expect the result of this is that HA options can not be used unless
athenticated and authorized?
This seems to imply that some significant work is needed to change MIPv6
so that an HA option is not sent until the CN has the HA->CoA mapping
in its binding cache. This would be a significant change because today
a CN can garbage collect binding cache entries at will which doesn't
seem to work if the MN needs to know for sure that a binding cache entry
exists before sending the HA option.

> security disclosure, ...) by anyone in the Internet.  This works for TCP

I think it is useful to clarify this in both the security requirements doc
and in the MIPv6 spec.
Note that the MN does not need be able to forward in general for MIPv6
to work - the next hop when processing the routing header is the MN itself.

So it makes sense to state this in the security req draft and also
make the MIPv6 spec say that a MN processing a routing header should,
unless it is serving as a router for other purposes, only process routing
headers where the MN itself (one of its Home Addresses) is the next=last hop
in the routing header.

   Erik

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Oct 2001 16:52:44 +0300 (EEST)

Yes.

Yes, it's painful :-(.

But I don't especially like the idea of being able to spoof the source 
address at will either.  And having this kind of feature integrated so 
deeply in IPv6 that it can never be dug out.

> headers where the MN itself (one of its Home Addresses) is the next=last hop

Yes, which is why I suggested another routing header type (say Type 2) 
altogether, to clearly separate the processing of the two.  And to make it 
distinguishable by intermediate nodes (e.g. packet filters), which could 
IMO be of big help in the long run.

A more straightforward approach would be to revise Type 0 processing rules
as you pointed out.  This has its own caveats too (think of
"private"/"public" addresses assigned on the same node), outlined in
"Security Considerations" of my draft:

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 16 Oct 2001 16:02:24 +0200

Hello,

> headers where the MN itself (one of its Home Addresses) is the next=last hop

Actually MIPv6 uses the routing header as a destination option...

The routing headers used by a CN to send packets to a MN are
only meant to be processed by the end-host (namely the MN) and not
by the intermediate nodes...(so why using a routing header? There might be
some good or historical reasons that i don't see?)

Wouldn't it make sense to define a new destination option that will
contains the HomeAddress of the MN (very similar to the MIPv6 current
HomeAddress option by in the other direction). A CN would then send the packets
to the MN's current CoA and add this new option that contains the MN's home
address.

This would solve most of the problems described in the draft:
(1) a firewall could decide to reject all packets that contain a routing header
and MIP
would still be supported, (2) this new option could be authenticated and
possibly be encrypted for confidentiality reason....

What do you think? Did i miss something?

Thanks,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Alexandru Petrescu <[email-masked]>
Date: 16 Oct 2001 16:36:12 +0200

> athenticated and authorized?

I would rather say that the HA options can not be used unless part of
an authenticated BU or similar, and not independent.

Alex

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 16 Oct 2001 16:42:09 +0200

Alexandru Petrescu wrote:

> Claude Castelluccia <[email-masked]> writes:
> > The routing headers used by a CN to send packets to a MN are only
> > meant to be processed by the end-host (namely the MN) and not by the
> > intermediate nodes...(so why using a routing header? There might be
> I think a good reason for using routing headers for this purpose is
> that they are supposedly readily implemented by "normal" IPv6 nodes,
> so no additional implementation effort for Mobile IPv6.

A "normal" IPv6 already needs to implement the HomeAddress option in
order to
support MIPv6...so i don't buy your argument ;-)

Claude.

--

---

From: Alexandru Petrescu <[email-masked]>
Date: 16 Oct 2001 16:40:01 +0200

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Oct 2001 17:07:54 +0200 (CEST)

> deeply in IPv6 that it can never be dug out.

As the analysis at the time shows (somewhere in the MIPv6 spec)
the fact that the CoA (the topologically correct) and the HA address
are present in the packet means that it isn't identical to
being able to spoof source addresses.

E.g. if X is sending packets to B with IP src = CoA = X and HAopt=A
to as part of a DoS attack against B, then when the DoS attack is
investigated by observing the packets both X and A can be seen.
With "normal" source address spoofing only A would have been in the packet.

But the problem is that if B is running any upper layer protocol that
acts as a reflector (by responding to received packets) then this can
be used to attack A. And TCP is a good reflector responding to SYN packets
by sending SYN|ACK packets.

   Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 16 Oct 2001 17:28:35 +0200

> an authenticated BU or similar, and not independent.

Sorry for following on my message, my above comment is rather naïve
(where's the cancel key? :-)

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Oct 2001 18:42:31 +0200 (CEST)

> some good or historical reasons that i don't see?)

Yes, MIPv6 uses routing headers in a special way. Only one address in
the routing header and the IPv6 dst and the routing header address
must be assigned to the same node.
 
> HomeAddress option by in the other direction). A CN would then send the
> packets to the MN's current CoA and add this new option that contains the
> MN's home address.

If folks want to redefine the actual packet formats as opposed to
adding rules on how routing headers are processed by MNs, then it
might make sense to go the direction of viewing this use of the routing
header as a "compressed" form of IPinIP tunneling instead of a different
destination option.
Such a compressed IPinIP option would just have one IPv6 address (since
the source address of the "tunnel" to the MN is the source address in
the IPv6 header) thus it would be the same size as the routing header
with one IPv6 address.

  Erik

> (1) a firewall could decide to reject all packets that contain a routing
> header and MIP

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Oct 2001 21:04:03 +0300 (EEST)

(no need to have me as Cc:, btw :)

> With "normal" source address spoofing only A would have been in the packet.

True, but there is also the issue of "Double Spoofing".  X and A could 
both be spoofed (A trivially, X if there is no ingress filtering, or it's 
done so that it's not precise enough).

For example, X would be spoofed so that the originator cannot be traced, 
and A spoofed to be a node that is suspected/known to be trusted by the 
destination.
 
> by sending SYN|ACK packets.

Also very true.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Oct 2001 21:12:28 +0300 (EEST)

On 16 Oct 2001, Alexandru Petrescu wrote:
> Also, it's interesting to note that rfc1825 (superseded by rfc2401)
> states:
>    "Routing headers for which integrity has not been cryptographically
>     protected SHOULD be ignored by the receiver.  If this rule is not
>     strictly adhered to, then the system will be vulnerable to various
>     kinds of attacks, including source routing attacks [Bel89] [CB94]
>     [CERT95]."
> This shows there was a certain level of awareness of the routing
> header problem at the time of writing of that rfc.

However, it appears that RFC2460 authors wanted to leave this open in the
standards track document; the wording there (about Routing Header being
mirrored in the destination if it was authenticated) suggest they were
also aware of (at least some) AH issues.  Probably not enough.

It's also clear that RFC2401 and RFC2460 people may have had a different
view of the global, in practise, applicability of IPSEC AH.

---

From: Alexandru Petrescu <[email-masked]>
Date: 16 Oct 2001 16:48:47 +0200

Erik Nordmark <[email-masked]> writes:
> make the MIPv6 spec say that a MN processing a routing header
> should, unless it is serving as a router for other purposes, only
> process routing headers where the MN itself (one of its Home
> Addresses) is the next=last hop in the routing header.

Just a quick note on the other usages of routing header; I found by
scanning the drafts:

-hmipv6
-Mobile IPv6 Regional Forwarding
-Mobile ipv6 neighborhood routing for fast handoff
-draft-itojun-ipv6-anycast-analysis-02.txt
-Mobile IPv6 handoff by Explicit Multicast
-draft-ohnishi-mobileip-mbg-00.txt
-draft-draves-ipngwg-ingress-filtering-00.txt

Alex

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Oct 2001 21:27:52 +0300 (EEST)

> the IPv6 header) thus it would be the same size as the routing header

This makes sense as an alternative approach.

But always remember that "automatic tunneling open to everyone in the 
Internet" presents yet another slew of possible security problems as noted 
from ngtrans methods like 6to4, compatible addresses etc.

So this definitely should not be implemented like e.g. every node would 
have to receive and process IP6-IP6 tunneled packets.

If this compressed form had sufficient number of sanity checks etc. I
guess it could be made to work.  But basically it would still require a
new header/option type.

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 16 Oct 2001 21:00:39 +0200

Pekka Savola wrote:

> ...

...

> guess it could be made to work.  But basically it would still require a

I was thinking along these lines today in an exchange with Claude and was taking some notes...

Issues with MIPv6 and Routing Headers

Turns out MIPv6 does not use routing headers correctly. It really wants to use another destination option
(quite similar to the home address destination option already defined).

RH's are unbounded in the number of intermediate nodes, so they're harder to control and it's harder to
track down the originator of, say, a reflector attack (this is exactly the problem pointed out by vern paxson
in his paper on DDOS in the internet as the main problem with gnutella).
So, yes,  a simpler bounded option used exclusively for mobile ip would make it more palatable.

Even the rh-ha draft notion of 'interface-local' doesn't make sense, unless i'm misunderstanding.
Wouldn't you want something more like 'host-local' instead? One example:
mosquito net had a metricom star-mode hack whereby they would xmit using one
modem and receive on another, so wouldn't this 'interface-local' rule fail in this case?
Many similar cases, you don't care much about both addresses belonging to the same
interface, you care that they belong to the same host.

Processing the Forwarding Option

    For home addr option: the CN should verify that it has a binding for homeAddress (in the HA option)
    and care-of address (the src of the packet). Both of these are remote addresses; both should
    correspond to the same remote host.

     For this new forwarding option: the MN must verify that the address contained
    therein is one of its local addresses. Both of these are local addresses; both should correspond to
    this, the destination host.

Perhaps this new option is useful for renumbering, quick failover or multihoming purposes as well?

Forwarding Option for BETH

This option could be used to save in the tunneling, supposedly a not negligible gain, given we're
doing BETH to begin with. So instead of doing rfc2473 (generic packet tunneling in ipv6), one
would use this new forwarding header which should be smaller.

Now, however, instead of being end-to-end as in the routing header replacement usage above,
it would be initiated at the aAR:

     CN sends:
        cn->coa
            (which may itself include a forwarding option with the home address
            and perhaps a 'local' bit on)

     aAR substitutes the destination address and sends this:
        cn->AR
        forwarding option: coa (this may have a bit saying if its supposed to be local forwarding or not)

The AR gets it from aAR, processes the forwarding option and sends the packet on its
way:

        cn->coa

It's just a shorter form of 2473. Presumably, if one's interested in draft-sreeman-enhance-beth*
and its chained tunneling one could do the above as follows:

     CN sends:
            cn->coa
                (which may itself include a forwarding option with the home address and perhaps a 'local' bit on)

     aAR substitutes the destination address and sends this:
            cn->oAR
            forwarding option: coa this may have a bit saying if its supposed to be local forwarding or not

     oAR substitutes the destination address and sends this:
            cn->nAR
            forwarding option: coa this may have a bit saying if its supposed to be local forwarding or not

The nAR gets it from oAR, processes the forwarding option and sends the packet on its  way:
        cn->coa

One may not need to use a bit to indicate 'local' versus 'non-local' forwarding.
As long as the receiving node has some sort of  'binding' (local or non-local) for the address in the
forwarding option then it may work.

-gabriel

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Oct 2001 22:15:47 +0300 (EEST)

I'll respond to just one point here.

On Tue, 16 Oct 2001, gabriel montenegro wrote:
> Even the rh-ha draft notion of 'interface-local' doesn't make sense,
> unless i'm misunderstanding. Wouldn't you want something more like
> 'host-local' instead? One example: mosquito net had a metricom
> star-mode hack whereby they would xmit using one modem and receive on
> another, so wouldn't this 'interface-local' rule fail in this case?
> Many similar cases, you don't care much about both addresses belonging
> to the same interface, you care that they belong to the same host.

No.  Host-local is too open; please see Security Consideration of my 
draft.

Either the MIPv6 implementation would have to "bind" the allowed addresses
together somehow, or this would have to be really restricted (if e.g.  
one would want to support this form of "routing header" outside of MIPv6)

With IPv4 analogy:

Host A has two interfaces eth0 and eth1.  eth0 is two public IP addresses
and eth1 a private 10.x.x.x address.  A few services are meant for private
network only, with e.g. a specific bind().

Now with routing header, anyone could reach to eth1's private 10.x.x.x 
address from anywhere in the internet.

This seems very bad.

Therefore, the check must be strict, in one way or the other.  The same
zone (ie. not global-site/global-linklocal/site-link, ...), and same
interface.  This isn't perfect but it's the best you can do, I fear, in
the global case.

If the check is *MIPv6* -only, the final address could be defined to "MUST 
match the configured Home Address".

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Oct 2001 22:02:05 +0200 (CEST)

> from ngtrans methods like 6to4, compatible addresses etc.

I didn't claim a different encoding would change anything security wise -
it doesn't.

I just responded to Claude's suggestion about using a destination option
as a different encoding suggesting an alternate different encoding to
the current one.

> have to receive and process IP6-IP6 tunneled packets.

Agreed.

> guess it could be made to work.  But basically it would still require a

Agreed.

  Erik

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 16 Oct 2001 13:32:35 -0700

Hello Gabriel,

> (quite similar to the home address destination option already defined).

I looked, and I didn't see why you made this claim.  What is
incorrect?

> So, yes,  a simpler bounded option used exclusively for mobile ip would make it more palatable.

A new option, while it may have a more restricted applicability,
would not necessarily be simpler for at least the reason that it
would take longer to specify correctly.  The fact that a new option
can be made to have restricted applicability does not mean that
the more general option is being used incorrectly.  Furthermore,
since the options would be so similar, it might take a lot of
effort to figure out exactly how they interact, what the ordering
would be if they both appeared, and so on.

I don't even see that there is a problem here that needs to be
solved.  If there is one, then it seems to me to be a lot better to
solve it using the easiest available methods, instead of creating
whole new design approaches.

Regards,
Charlie P.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 16 Oct 2001 16:01:25 -0500

Hi Charlie,
  You seem to favor the solution 6.1 in Arkko's draft?
I kind of like 6.2 as well, it is also simple. Maybe problem with present implementations, but correcting a design
flaw early is better, IMHO.
  Appreciate if you can clarify.
Regards,

--
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S CTO2
1201 E. Campbell Rd.
Richardson, TX 75081-1936 USA
Email : [email-masked]
Phone : (972) 996-5075 Fax : (972) 996-5174

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 16 Oct 2001 14:08:58 -0700

Hello Behcet,

I didn't yet get around to transcribing my comments on Jari's
draft, but if I may offer an incomplete opinion I think it is a
fine piece of work.  I would favor the approach outlined
in section 6.4, with the proviso that:
- If IPsec is agreeably configured to authenticate
   Binding Update, it can be used instead of the BU
   authentication data option.  In other words, sometimes
   a Binding Update could be authenticated by a method
   that depends on some future IPsec mechanism, instead
   of requiring the authentication data suboption to be present
   anyway even if IPsec were already somehow enabled to
   to do the job.

But as I said this is an incompletely formed opinion, and
I have to finish studying the document to figure it out more.
Plus, I definitely don't intend to say that we have to figure
out how to do all the IPsec stuff right now.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 Oct 2001 11:18:46 -0700 (PDT)

> risks would be manageable.

   Couldn't there be different requirements for hosts
   vs. routers? Ie, a node MUST process a packet with
   a routing header, but MAY drop packets for which the
   next destination address is not a valid destination
   address for the host?

   Ie, the host will forward to its stack, but not
   out another interface? This seems pretty consistant
   with the definition of hosts and routers.

	   Mike

---

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Oct 2001 22:06:30 +0300 (EEST)

>    with the definition of hosts and routers.

Yes, this is one approach (alternative would be to define "Type-2"  
routing header, so RH's used would be distinguishable in the network.  
This has some significant benefits wrt. packet filtering) I'm suggesting
in draft-savola-ipv6-rh-ha-security-00.txt, to be exact:

--8<--
   If a node would have to process the Routing Header (that is,
   destination address equals the node and segments left > 0), it SHOULD
   check whether segments left equals 1, and if both the current
   destination address and to-be-swapped destination address in the
   Routing Header are both assigned to the same interface of the node
   and are both of the same zone [ADDRSCOPE], the Routing Header is here
   referred to as "Interface-local Routing Header".

   On Routers, further processing of Routing Headers SHOULD be
   configurable and SHOULD be enabled by default.

   On Hosts, further processing of Routing Headers MAY be configurable
   and MUST be disabled by default.

   Regardless of the general Routing Header processing setting, all
   nodes SHOULD still process "Interface-local" Routing Headers.
   Disabling this exception MAY also be configurable.
--8<--

I was pretty conserative with SHOULD/MUST, could have been stricter.

Please also see the security implication of this "interface-local" 
property:

--8<--
   One should note that note that "Interface-local" property of Routing
   Headers is important to be, indeed interface-specific, not node-
   specific.  Consider a node with two interfaces, one public, and one
   completely private.  Even if a private service would be bound to the
   private interface only, one should not be able to use this private
   service from anywhere in the Internet.

   Even the interface-locality is not bulletproof, as some addresses
   assigned to the interface may be more private and public than others;
   at least this way the potential harm can be minimized.

   The same zone requirement is also important (how this is observed is
   implementation dependent; the check doesn't need to be explicit in
   Routing Header processing) so one cannot reach e.g. link- or site-
   local addresses through Internet.

   More fine-grained control of the two addresses could be obtained via
   access lists if they support Routing Header processing.
--8<--

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 17 Oct 2001 16:54:03 -0400

Hi Charlie,
  Thanks for your reply.
Maybe 6.4 is also OK but to be on the safe side I still favor 6.2. The advantage is, then we can count on any future
breakthrough on IP security to apply on MIPv6 as well, e.g. an update of RFC 2401 will one day come out and solve all
the so-called attacks.

  Looking forward to your reply to Arkko's draft.

Regards,

--
Behcet

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 17 Oct 2001 21:23:47 -0700

Hello Pekka,

> in draft-savola-ipv6-rh-ha-security-00.txt, to be exact:

After reading your draft, which has many good points, I started
to believe that there is a good solution to the problems with
unrestrained use of routing headers.   In every case I could think
of, the problem could be characterized as one node following
an external directive to forward data to another "next" node without
authorization by that next node.  Maybe that's almost a tautology,
but it does point in a good direction towards a solution.  Namely,
a node shouldn't follow the routing header unless it has somehow
gotten this authorization.

In the case of interest, the mobile node certainly has authorization
to send packets from one of its addresses to another one of its
addresses, so there isn't much to be done here.  However, I
believe it would be valuable to formulate this as a more general
result -- namely, that the process of establishing routes along
the intermediate nodes in the routing header has to bring with
it the necessary authorization for each node to use the next
hop.  I like this rule because it seems to get exactly at the source
of the problem, and on the other hand in some ways it is a lot
less restrictive than the rules you suggested in your draft.

Regards,
Charlie P.

PS. I will type in the rest of my comments on your draft soon.

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 18 Oct 2001 11:47:43 +0200

Hi Pekka,

>    access lists if they support Routing Header processing.

I tend to agree with your analysis here. I do however have a problem
combining this with the discussion Ryuji and I had earlier regarding an
MN with multiple interfaces. We discussed implementation issues, like
which interface to assign the home address to. We both agreed that a
virtual interface would be best. We believed in this because a home
address should be able to make use of care-of addresses on different
interfaces and to not have it bound to a specific card that might be
removed. This view collides with your routing-header rules.

Maybe it's no big deal, the home address could be assigned to _all_
physical interfaces. Anyway, I just wanted to bring this up.

/Mattias

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Oct 2001 21:00:57 +0300 (EEST)

> physical interfaces. Anyway, I just wanted to bring this up.

Yes, I had thought of this.  I took it as too implementation-specific 
issue ("logical interface" or "a feature of a physical interface") to 
mention it.  Perhaps I should add a note there.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Oct 2001 20:53:45 +0200

Thus MIPv6 is "responsible" for this behaviour (ie: security of
   home address option).
   
=> is H.3 enough for you (I've privately sent a comment about this
and I'll resend it if the thread doesn't give a solution I like) ?
BTW I agree this is a MIPv6 issue.

=> my opinion is there should be a knob about host behavior and
the default should be "don't forward a packet with a routing header
outside of the node". This closes the security issue and works with
mobile hosts. The problem is more that the issue is an IPv6 WG one
(again I'll look at further in the thread, I've seen Eric Nordmark's
name so I believe I've just to find time :-).

Regards

[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Oct 2001 22:54:40 +0300 (EEST)

I'll change the subject a bit .. it's getting too swamped. :-)

> BTW I agree this is a MIPv6 issue.

The threat is basically okay for Home Address.

I'm not satisfied with the details though.

--8<--
   Scenario H.3:

   According to the Mobile IPv6 spec: "A node receiving a packet that
   includes a Home Address option MAY
    implement the processing of this option by physically exchanging the
    Home Address option field with the source IPv6 address in the IPv6
    header."
--8<--

So it does read in mipv6 -14.

I see a problem with MIPv6 draft.  Nowhere is it defined how Home Address
Option must be processed (at least I couldn't find it).  Only mentioned as
a MAY in security considerations.

Has anyone implemented this differently?
The end-result is probably always the same, and that should be reflected 
in the wording in secreqs.

--8<--
 the following requirements apply to ALL
   IPv6 nodes (whether host or router, whether mobile or stationary):

    -  Every IPv6 node MUST be able to process a Home Address option
       received in any IPv6 packet
--8<--

what does 'be able to process' mean in this context?  Recognize and be 
able to parse it?  Parse it and MUST have the processing enabled?

Both drafts should be updated on this one, I think.

--8<--
   Requirement H.3:

   CNs SHOULD NOT/MAY NOT process any packet (BU or not) containing a
   Home Address option unless they have verified that that the node
   sending the packets is authorized to use the home address in the
   destination option.
--8<--

Combined with the problems above, it seems, whether conscious or not, that 
the threat is being down-played.

I don't think I could accept any other wording than: 
'CNs MUST NOT process any packet [...]'