Subject: [mobile-ip] Final Agenda for IETF52

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Tue, 4 Dec 2001 15:18:35 -0600

INT     mobileip IP Routing for Wireless/Mobile Hosts WG
		 (Dec 12th Wed, 0900-1130)
---------------------------------------------------------

1   Agenda Bashing		10 Mins		WG Chairs	
    WG Doc Status update						

2   MIPv6 Security Discussion			  75 Mins

    a. Securing MIPv6 Binding Updates		  

    b. Home Address Option/Routing Header vs Tunnelling

    c. Piggybacking of binding updates

Discussion lead by Gabriel Montenegro, Jari Arkko and Erik Nordmark

I-Ds relevant to this discussion:

http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-sec-reqts-
02.txt
http://www.ietf.org/internet-drafts/draft-arkko-mipv6-bu-security-01.txt
http://www.ietf.org/internet-drafts/draft-montenegro-mobileip-mipv6-sece
val-00.txt
http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01.
txt
http://www.ietf.org/internet-drafts/draft-arkko-mipv6ro-secframework-00.
txt

Note: Only if you have read these I-Ds can you make comments at the
microphone 

3   RFC3012bis:	Issues identified and Changes made	10 Mins Charles

http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc3012bis-00.tx
t

4. Handoffs: Low Latency(v4) and Fast HO (v6)		30 Mins

   a. Discussion of issues based on implementation experience
      James Kempf
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-hando
ffs-v4-03.txt
http://geocities.com/kempf42/llanalysis.pdf

   b. Fast handoff - Updates/Changes/Issues raised on list
      Gopal Dommety
http://people.nokia.net/~patil/Internet_Drafts/draft-ietf-mobileip-fast-
mipv6-04.txt   

5. Localized Mobility Management Requirements           10 Mins
   Carl Williams
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lmm-requirements
-00.txt

6. MIPv6 at ETSI Bakeoff Report     10 Mins		Sebastien Barbin

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 04 Dec 2001 15:02:46 -0800

>                  (Dec 12th Wed, 0900-1130)

I think we should modify 'b' to say " Home Address Option
vs Tunnelling" because Pekka has suggested a solution for
the routing header problem in his
draft-savola-ipv6-rh-ha-security-01.txt

Every host should follow these rules

Routing header MUST be processed if
	1. segleft is 1
	2. destination address and intermediate address both
	   belong to the same interface of the host that
	   received the packet.
Routing header MUST not be processed if
	1. the address to be swapped does not belong to
	   the same interface as the destination address
	   on the IPv6 header.

if a IPv6 host follows the above rules, is there still a
security problem? if not, I suggest we drop the issue of
router header Vs tunneling and use routing header with the
above two rules.

regards
Vijay

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Dec 2001 10:03:04 +0100

I think we should modify 'b' to say " Home Address Option
   vs Tunnelling" because ...

=> I disagree: home address option and routing header are two
basic types of tunnel address compression (cf the Deering/Zill's
draft-deering-ipv6-encap-addr-deletion-00.txt), i.e. there is
no essential difference.
But if your purpose is to show that mobile-ip is the wrong WG
I agree, and IMHO the same remark applies to 'c' (piggy-backing).

Regards

[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Dec 2001 16:23:32 +0200 (EET)

> I agree, and IMHO the same remark applies to 'c' (piggy-backing).

I agree with Francis.

If we are to adopt tunneling, it seems to make sense to use it for both
HAO and RH.  If there were no problems with HAO, introducing tunneling
just for RH might not be as "imperative".  These issues are intertwined,
as the mechanisms compared to tunneling are very similar.

-- 
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: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Dec 2001 11:18:02 -0800

hi,

Francis Dupont wrote:
> I agree

great that you agree. this is good. lets throw these issues out 
of the Mobile IP WG. and lets to stick to solving the problem 
of key distribution between the MN and CN. this is what we 
should be concentrating on at this IETF IMO.

regards
Vijay

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 05 Dec 2001 11:56:08 -0800

Hello Pekka,

I admit I am behind and have not studied the new tunneling
draft yet.  But I am surprised that you might suggest that
we should use a new tunneling method that isn't even a working
group document yet, when we already have methods that are:
- Draft Standard
- Implemented
- Interoperable

I reckon that the new tunneling method does not resolve any
existing security questions.  Placing a normative dependency
into Mobile IPv6 to a brand new tunneling draft would only make
sense if we could somehow imagine that improvement would result,
and if the new tunneling draft had some magic ability to get to
Proposed Standard in the near future.

I will try to study the relevant drafts right away (I've been
away on extended travel) to see what improvements might result,
but as far as it has been explained to me I don't see them yet.

Regards,
Charlie P.

Pekka Savola wrote:

---

From: Michael Thomas <[email-masked]>
Date: Wed, 5 Dec 2001 12:40:18 -0800 (PST)

> as the mechanisms compared to tunneling are very similar.

   Let me understand what is being proposed here. Are
   we saying that the tunneling between MN/CN is sufficiently
   general, and its security implications sufficient murky
   that would should remove it from MIPv6 and charter a
   new WG to work on the general problem rather
   than a MIPv6 specific problem? 

	  Mike

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Dec 2001 23:12:28 +0200 (EET)

To Charlie also,

>    than a MIPv6 specific problem? 

First, a clarification.

I wasn't saying "we should move to tunneling".  I was just trying to point 
out issues for consideration, _in case_ tunneling was decided to be a 
solution.  I have not yet formed opinion on the subject.

I'm not sure how you read that from what I wrote, but I think I see what
you're pointing out; tunneling between some addresses is a problem that,
under some circumstances, might be usable outside of MIPv6 context (one
issue could be multihoming).  In fact, this looks like ipng material
(where, indeed, address deletion draft was originated).  How we get
something usable out of that.. well, I think it's still up to MIP people
to see what's required if one would like to make it suit the MIP needs.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Dec 2001 23:18:21 +0200 (EET)

> group document yet, when we already have methods that are:

I wasn't advocating its use; I was just discussing several issues _if_ we
would, at some point (this is very probably a now or never issue), decide
it's usable.

Note: HAO, which is one of the used methods, is still internet-draft.  The 
latter two apply though.

> existing security questions.

That may or may not be; difficult to say at this point.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Dec 2001 13:50:03 -0800

> Note: HAO, which is one of the used methods, is still internet-draft.  The

it is just a destination option which is a draft standard. 
and it is meant only for the destination.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Dec 2001 10:00:01 +0100

=> this is not the case of the home address option (we have not
even an independent definition of it) and the routing header has
some security issues that should be solved in a to be written
document (IPv6 host requirements). So we cannot say there is no
problem and it is better to deal with them in a larger and proper
forum (i.e. the IPv6 WG).

=> not be itself but the idea is to put the burden in another WG,
this should have two advantages:
 - more time to solve the real problem, i.e. how to secure BUs & co.
 - no danger to get a bad & late feedback as it happens about IPsec.

   Placing a normative dependency

=> the purpose is not to slow down Mobile IPv6 at all!

   If the new tunneling draft had some magic ability to get to
   Proposed Standard in the near future.
   
=> or the discussion about it reveals unsoluble security problems
and Mobile IPv6 has a real problem, or the discussion shows how
to not infringe upon security and Mobile IPv6 gets the benefit
(with current or new mechanisms).

=> the purpose is not improvements, it is a discussion of this kind
of mechanisms in a general context. And this is *necessary* or how
do you explain that the vast majority of deployed IPv6 implementations
have both no home address option support and a half-backed security
policy for source routing on hosts?

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Dec 2001 10:27:06 +0100

=> we don't need a new WG because we already have the IPv6 WG.
But the purpose is really to generalize the problem and to give it
to another WG... IMHO this is better than to wait the IETF last call
for getting the IPv6 WG opinion, isn't it?

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 06 Dec 2001 10:14:23 -0800

Pekka,

you didnt respond to one of my questions below...

> router header Vs tunneling and use routing header with the

if the IPv6 host follows the above two rules while processing
the routing header, do you still see any security problems
with the Mobile IPv6 use of routing header?

if 'no' is the answer, I suggest we drop this issue NOW! TODAY!
we dont have to waste time next wednesday.

regards
Vijay

---

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Dec 2001 20:27:45 +0200 (EET)

> we dont have to waste time next wednesday.

You didn't mention the same zone requirement that was also in the draft; I 
think the omission was not on purpose.

There's pretty marginal threat left assuming same zone restriction, and if
the processing is implemented like this, I think the risk is probably
manageable.

But that doesn't mean it must be *the* way to do it.  There is still the 
issue of HAO vs. tunneling, though.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 06 Dec 2001 10:57:12 -0800

hi Pekka,

> the processing is implemented like this, I think the risk is probably

I am very glad that you agree on this.

> 
> But that doesn't mean it must be *the* way to do it.  

I can give you a very frank answer for this. routing header has been
shown to work. it is a draft standard. a lot of implementors have
spent a lot of time implementing this. they have also spent a lot
of time going to interops and show that it works (atleast 4 interops
that I know of). and I am NOT going to let anybody change it. 
(especially now that you agree that it is safe to use).

> There is still the

I will get to that soon.

regards
Vijay

---

From: Michael Thomas <[email-masked]>
Date: Thu, 6 Dec 2001 11:26:53 -0800 (PST)

> for getting the IPv6 WG opinion, isn't it?

   Fine, I was just trying to figure out whether moving
   it out of MIP was what was being discussed. I haven't
   made up my mind whether that makes sense. I have to
   admit that this is somewhat tempting, as going through
   this entire exercise again for ipv4 route optimization 
   doesn't thrill me.

		  Mike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Dec 2001 11:16:18 +0100

=> as there is no home address option and near every routers filter
out source routed packets in IPv4 I don't understand your objection...

Regards

---

From: Michael Thomas <[email-masked]>
Date: Fri, 7 Dec 2001 09:10:23 -0800 (PST)

> out source routed packets in IPv4 I don't understand your objection...

  I haven't read over Steve's draft, but I got the
  impression that it was just a tunnel with the
  ability to optimize redundant IP headers. I wouldn't
  think that is v6 specific, and that it was possibly
  a replacement for the RH/HAO mechanism in MIPv6 today.

	     Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 07 Dec 2001 09:40:26 -0800

Hello Francis,

> forum (i.e. the IPv6 WG).

I think that Vijay has suggested a very simple statement about how
to eliminate problems with the routing header.  The new encapsulation
mechanism would not solve this problem, and would require an almost
identical policy to solve it (i.e., the two destinations would have
to be on the same host).

Furthermore, there might be other uses of the routing header, or of
the new tunneling header, that would require other policies.  The
required policy in the case of Mobile IPv6 is particular to Mobile IPv6,
and so it should be documented within the Mobile IPv6 specification.
Work of a more general nature (say, in another working group) would
have to take into account a great many possible uses which are not
germane to Mobile IPv6.

> => the purpose is not to slow down Mobile IPv6 at all!

I reckon this means that we can go forward with routing header
and home address option, and make future adjustments if it is
indicated by the future work.

I don't expect that any other working group would be as motivated
to complete the necessary work as the mobile-ip group would be.

> (with current or new mechanisms).

That's a big IF, and I am almost certain this will not be the case.

I think that after some amount of thought it can be seen that the
routing header and Home Address option, compared to various forms of
encapsulation, have pretty much the same essential features, and neither
choice offers any particular security benefits over the other.

> policy for source routing on hosts?

The solution for half-baked policies is to fix them after identifying
the problems.  To translate the discussion into a new problem space,
or even in a new working group, is chancy at best and carries with it
the real prospect of arbitrarily long delays.

Source routing is one technique that can be very complicated in general.
As an example, if one uses source routing to specify a routing path
that is generated based on specific security policies, or based on
specific QoS guarantees, then the presumption is that there is a lot
of signaling which has preceded the use of the source route.  This
signaling would be carried out with specific purpose in mind.  For
Mobile IPv6, the specific purpose is very clear.  Both addresses are
specifically presumed to be associated with the same node - viz.,
the mobile node itself.

One technique which is more complicated than source routing, from
the point of view of understanding necessary policy restrictions,
is encapsulation itself.  Making the appropriate policy restrictions
on a generalized encapsulation protocol will be even more difficult than
making the appropriate restrictions on the use of source routing.
This is especially true since the appropriate restriction for Mobile
IPv6 use of source routing is very simple to identify, understand,
and implement.

For these reasons, I believe it is unlikely that we will gain any
advantages in either timeliness or operational simplicity or performance
by waiting for completion of the new tunneling headers.  This is not to
say that the work should not be pursued.  In fact, after learning more
about the new draft, I think it is interesting to compare the new tunneling
work with what was standardized in RFC 2004. But to hold it out as having
promise for resolving some existing security problem is, I think, wishful
thinking.  This is especially true since we have now had the discussion
on what the security problems are, and we can go directly about getting
solutions for them.

Regards,
Charlie P.

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 7 Dec 2001 12:44:07 -0800

Folks,

I remember seeing a presentation in the area of location privacy.
Something other than Claude and Francis's draft
draft-castelluccia-mobileip-privacy-00.txt.

Could the author or whoever remembers it, send me
an e-mail? I'd like to get a copy of the draft.

Thanks!

alper

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Dec 2001 22:18:02 +0100

I think that Vijay has suggested a very simple statement about how
   to eliminate problems with the routing header.

=> I know but the problem remains until its solution is in a standard
document (and applied). My concern is this document is in the scope
of the IPv6 WG, not of the mobile-ip WG, so we are only losing our
time because of the wrong mailing list/working group.

=> I disagree: a Mobile IPv6 node is first an IPv6 node. The security
problem (and its solution) is bound to the routing header and not to
mobility, i.e. mobile IPv6 has shown there is a hole in IPv6 specs
(the need of a policy about routing headers).

=> this is the idea: give the burden to someone else.

=> the necessary work is in the IPv6 WG charter and there is no
closed door between the two groups.

=> I was not clear enough: I agree the features are the same, my idea
is the result for one should apply to the other.

   
=> it seems we disagree about a fundamental point: in order to get mobile
IPv6 nodes we first need to get IPv6 nodes. The routing header problem
is an IPv6 one so it has to be solved by the IPv6 WG ASAP. I don't want
to have some FUD about routing header just because the problem wasn't
been dealt with in time as it happened for IPv4.

=> is it an example of wishful thinking (:-)?
BTW I'd like to know how we can get the mandatory support of the Home Address
Option in specs and its support in the real world without the help of the
IPv6 WG...

Regards

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 07 Dec 2001 13:59:28 -0800

Francis Dupont wrote:
> 
>  In your previous mail you wrote:
> 

My point in the text following this statement was as follows.
The _reason_ for establishing the intermediate points to be used
in a routing header varies according to the "application".
Thus, the way in which the recipient has to check for validity
varies according to the "application".  While Mobile IPv6 is not
an application in the usual sense of the word, it is a protocol
which makes use of a routing header for a specific purpose.  This is
not a general purpose signaling for general purpose use of the
routing header.  It is specific to Mobile IPv6, and therefore
the rules by which the routing header processing has to be checked
have to be specific within the Mobile IPv6 document.

> => I disagree: a Mobile IPv6 node is first an IPv6 node.

Yes, but this statement is not relevant to the purpose at hand.

>                                                         The security

Use of the terminology "security problem" is not very good here.
The problem is that we have to be sure that a node which is supposed
to accept a routing header for the purposes of mobility doesn't
accept routing headers that have deleterious effects unrelated to
Mobile IPv6.  So, yes it's a "security problem", but more specifically
it shows the need to refuse to carry out unauthorized routing operations.

> been dealt with in time as it happened for IPv4.

I think that I have explained the reason for my disagrement on this
point in a way that might be clearer this time.  To try another
restatement:
  Use of routing header probably has to be enabled for specific purposes.
  I think it is extremely unlikely that the IPng working group can
  establish a comprehensive list of all future purposes for which
  the routing header may be applicable.  I think that each new purpose
  might require different rules for preventing unwarranted intrusions
  for unauthorized routing.

  Thus, it's appropriate for the Mobile IPv6 group to establish the rules.

Furthermore, these statements would have to be even more strongly if
applied to the otherwise functionally identical scenarios appropriate
for generalized encapsulation techniques.

> => is it an example of wishful thinking (:-)?

Am I allowed to distinguish between wishful thinking, and my bit of
optimism which comes from reading oh-so-many e-mails and drafts on the
subject over the last few months?

> Option in specs and its support in the real world without the help of the

If we resolve the remaining questions surrounding the Home Address
Option, and if the document passes IETF Last Call, then I think that
by process we will get support in the real world.

But that is a big subject, and appropriate to another e-mail in
the near future.

Regards,
Charlie P.