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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Fri, 19 Oct 2001 02:13:36 +1000

> Hesham Soliman (EPA) writes:
>  > 	=> Well, I think the only MUST we need to solve 
>  > 	this issue is to have something in RFC2460 saying 
>  > 	that it MUST be possible to configure nodes to 
>  > 	avoid forwarding packets to other hosts based on a 
>  > 	routing header. Wouldn't this knob be enough and 
>  > 	satisfy MIPv6 requirements and RFC2460 ?
> 
>    No, I think there needs to be some verbiage
>    (if not already present!) that says that a
>    host MUST be able to forward to itself. Otherwise
>    MIP and other uses of CoA's might not be
>    implemented (eg, multihoming). That would be
>    unfortunate. I think this is mainly an issue
>    of MUST implement. Policy knobs are always an
>    option beyond that :-)
> 
	=> I guess I wanted to say the same thing but 
	you have the time difference advatange so you're
	saying it better :)
	MUST forward to itself, 
	MUST have a knob for forwarding to other nodes 
	OK ?

	hesham

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 18 Oct 2001 10:46:58 -0700

Hello Hesham,

>      MUST have a knob for forwarding to other nodes

I tried to point out in a note last night that it is enough
for relay nodes to follow directives about forwarding to
the next node in the list.  In the case needed for Mobile IPv6,
this is simple.  A node can authorize itself to forward
packets to itself.  In the general case, more persuasion
may be needed, but the principle would remain the same.

OK?

Regards,
Charlie P.

---

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

> may be needed, but the principle would remain the same.

I just had an idea which might be used to "authenticate" this for _hosts_:

if segments left == 1
 if both addresses are assigned on the node (possibly on the same interface)
  if both addresses are of the same zone (e.g. no global->site/link)
    if there exists a /128 host route to the to-be-swapped address
      assume forwarding to it is allowed

Of course, this would be only one, implementation-dependant way of showing 
this "trust".

Host route inside a node _could_ be something that could be easily used --
MIPv6 could set one up for Home Address no problems.

Thoughts?

-- 
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: "Charles E. Perkins" <[email-masked]>
Date: Thu, 18 Oct 2001 11:53:28 -0700

> Of course, this would be only one, implementation-dependant way of showing

What you are describing is a rule for forwarding a routing header
along paths inside a single host.  I'm trying to get at it from a
somewhat different angle, as follows.

Suppose there is a protocol by which the following state is inserted
at a forwarding node (host or router):
- If my address is in a routing header, and I am requested to forward
  the packet to a _particular_ next address when it arrives with my
  address in the routing header, I will agree to do so.

This has to be done individually for all such "next addresses" that
might show up in a routing header.  Agreement to forward to one
particular next address doesn't imply full agreement for all possible
next addresses, or even for any other next address at all.

I like this rule.  The point is that you can't just forward blindly,
but only after agreement by way of some protocol which essentially
does the setup.

For mobile nodes, there's nothing to do except for keeping track of
its own addresses, which is appropriate for this case.  The act of
disseminating the Binding Update can be viewed, in this context, as
"advertising" a mobile node's (internal) agreement to forward packets
to its home address.  This does not at all mean that the mobile node
agrees to act as a forwarding node for all possible routing headers.

> MIPv6 could set one up for Home Address no problems.

I agree it could be done inside a mobile node by way of an explicit
host route, but I don't think that has to be put into the Mobile IPv6
specification.  There are other ways to do it that have the same
external effect.

Regards,
Charlie P.

---

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

> somewhat different angle, as follows.

True.
 
> agrees to act as a forwarding node for all possible routing headers.

I see a practical problem with this.  

Assume a non-MIPv6 scenario, where the sending node should establish this
permission on the first destination towards some next destination.

There would indeed need to be a real protocol for this.

Sounds awafully heavy for something as simple as this (much like Binding 
Update, indeed, actually!)

It works in the restricted scenario you described just fine.

> specification.  There are other ways to do it that have the same

Indeed, it's too implementation-specific.

Problem with this is that it has to be done (usually) inside the OS
kernel.  Is it prudent to keep a list of home addresses there?

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 18 Oct 2001 12:29:07 -0700

Hello Pekka,

>>   address in the routing header, I will agree to do so.

             ..........

> Update, indeed, actually!)

It could certainly require protocol in the general case.  But:
- Setting up routing headers should properly be considered a routing protocol.
- Setting up routing headers is "like" setting up encapsulation, and in the
  applications which I am familiar with for setting up encapsulation, such a
  protocol exists.
- You have adequately pointed out the dangers which ensue unless explicit
  agreement exists.

I think that Francis, you, and I all agree that some controls need to be in
place, and that the controls are essentially automatically fulfilled when
the routing header is used for addresses on the same node.  I can imagine
some further discussion on the last point, but not for care-of addresses.

I thought that my formulation captured some of the essence of the problem,
and pointed towards the properties that such a setup protocol would need,
and that I could get my mind wrapped around it a little more simply.  In a
way, all we need to agree here is that (a) routing headers need to be
controlled and agreed beforehand, and (b) Mobile IPv6 use of care-of
addresses satisfies the necessary control and agreement.  Further expansion
on this theme may properly reside in the IPv6 working group.

> kernel.  Is it prudent to keep a list of home addresses there?

It's not absolutely necessary to do that, but on the other hand
the IP addresses are in the kernel, and likely some of them are
already marked as home addresses.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 19 Oct 2001 10:13:52 +0200

if segments left == 1
   
=> I believed this was enough but you gave a strong argument
in your answer to Gabriel in favor of a stronger check: address should be
in order a care-of and a home addresses (the binding update list should
give all the needed informations).
BTW as soon as we know exactly what we need, we should go to the IPv6 WG
mailing list, perhaps with a specific document, and of course we should
ask for a slot for the next meeting.

Regards

[email-masked]

PS: the reference is the Security Considerations of your draft.
PPS: I believe the Interface-local rule is not very applicable
for a mobile multi-homed/multi-interface host: we have to jump
into specific/specialized rules.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Oct 2001 14:06:05 +0300 (EEST)

> ask for a slot for the next meeting.

How does this sound, in pricinple:

--8<--
On Hosts, Routing Header processing MUST be supported, but the processing
MUST NOT be enabled by default.  The enabling of the processing SHOULD be
configurable.

Regardless of the processing setting above, routing headers destined to
the host are further processed if the following applies:

 type == 0 and segments left == 1 and,

 if the to-be-swapped address in Routing Header is either:

   1) a Home Address assigned to the node,
 
     the Routing Header MUST be processed in full. 
 
   2) an address which has been authorized in some way to be a valid 
      target of routing header processing [this is a superset of 1)],

      the Routing Header MAY be processed in full.
--8<--

Problem with this approach is, that the packet filter (without state about 
mobility) cannot know whether the destination address is valid or not if 
someone wants to perform such tests.

IMO, it might be much simpler to just define "Type-2" routing header which
would require property 1) and nothing else.

Note that 1) disregards a pretty theoretical situation where one would
have e.g. separate site-local and global home addresses, and you'd like
more fine-grained control on what is allowed.

This omits (on purpose) the more general case of "node-local routing 
header", because:

 1) it's a complex issue which can't be solved without problems
 2) I don't see any valid need for it :-), does anyone?