Subject: [Mobike] comments on draft-dupont-mobike-transport-00.txt

From: Jari Arkko <[email-masked]>
Date: Mon, 11 Oct 2004 15:16:22 +0300

In general, I find the function proposed by this draft very
useful. Although its clear that more work is needed. In
particular, we can be more concrete when the Mobike base
protocol exists.

Some comments below:

> 3.  Two examples

I did not understand the SCTP example. Can you expand on it?

>    IKEv2 and Mobike mechanisms do verify that the primary peer address
>    (for IKEv2) and further alternate peer address (for Mobike
>    mechanisms) are correctly authenticated and authorized, so they MAY
>    safely be used for transport mode IPsec security associations as
>    endpoint addresses.

I'd like to understand this better. Is it correct to say that
the folllowing issues are involved:

  o  Verification that the claimed IP address actually exists.
     FOr instance, the peer has not just manufactured a bogus
     address. The IKE negotiations and/or address tests take
     care of this.

  o  Verification that its really this peer that is behind
     this IP address. It would be bad if I could grab
     someone else's IP address because, say, if that someone
     else needed to communicate with the node in future
     but couldn't do so because I already had a connection
     open with that address pair.

  o  Verification that a number of different addresses A,
     B, C, etc. all are the same entity. This is actually
     the main issue, right?

> 2.  Transport mode and addresses

Maybe I'm missing something obvious but I think we also
need a discussion on how this impacts upper layer protocols.
I can see how SCTP and Mobile IPv6 can survive address
changes, but is the proposal to limit this function to
those two examples, or be more generic?

Some nits:

> But transport mode IPsec security associations are end-to-end and
>    have no outer addresses: they cannot be managed by Mobike, for
>    instance, they cannot be updated. 

Perhaps s/they cannot be managed by Mobike/current designs
for Mobike do not support their management/

>  This document uses the standard keywords
>    [keywords] to indicate requirement levels.

Move this to its own section or subsection.

>  to put transport mode ouside of its immediate scope.  But as

s/ouside/outside/

>    Using a Mobike peer address management (as in [ADDRMGT]) a mobile

Pending the appearance of a WG draft for the base MOBIKE solution,
I think it would be appropriate to list a couple of other alternative
address management protocol proposals too, just to make it clear
that what you say in this draft is not bound to [ADDRMGT] but could
also be used with the other drafts.

> A
>    multi-homed peer can register using a Mobike mechanism its addresses
>    as peer addresses and is authorized to use them to build transport
>    mode IPsec security associations using only one IKE session, aka IKE
>    security association. 

Maybe say instead: "Using Mobike, a multi-homed peer can register its
addresses as peer addresses. It is then also authorized to use them to
build multiple transport mode IPsec security associations within the same
IKEv2 security association."

--Jari

P.S. Is anyone else having trouble with the mobike mailing list?
I've sent several e-mails today and at least for now they are not
getting through, nor is there anything in the archive for October.

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Mon, 11 Oct 2004 19:07:52 +0200

In your previous mail you wrote:
   
   In general, I find the function proposed by this draft very
   useful. Although its clear that more work is needed.

=> I know but I believe only the form (i.e., better wording,
clarifications, etc) needs to be improved.

   In particular, we can be more concrete when the Mobike base
   protocol exists.
   
=> IMHO we need only few properties of it, not a concrete proposal.

   
   
=> I'll rework it (followup in private).

   
=> note that the verification is done by the Mobike protocol and
the details are not *relevant*.

   
   
=> these are details so these are irrelevant: the Mobike protocol
is supposed to be safe.

=> until an upper layer protocol will fully survive to address changes
we can assume there is no interest to transport mode to survive
to address changes.

   changes,

=> note this is not really true for SCTP: SCTP has only limited
readdressing support.

   but is the proposal to limit this function to
   those two examples, or be more generic?
   
=> the proposal is to do nothing today to solve the issue, i.e.,
to put transport mode stuff out of the immediate scope of Mobike.

   
=> I give the reference only as an example, or in other words
the reference is here to avoid a long explaination about what I mean
by "peer address management".

Thanks

[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 11 Oct 2004 14:06:46 -0700

Francis,

> to put transport mode stuff out of the immediate scope of Mobike.
The draft talks about how MOBIKE can be used with MIPv6 (BU) and SCTP
which are both transport mode SAs. I don't know where in the document it says
that transport mode stuff should be put outside of MOBIKE. Also, the charter
includes SCTP also. So, are you saying that this should be changed ?
I am a bit confused.

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Mon, 11 Oct 2004 23:41:58 +0200

The draft talks about how MOBIKE can be used with MIPv6 (BU) and SCTP
   which are both transport mode SAs.

=> perhaps you are confused because you've forgotten that neither MIPv6
(BU) or SCTP need address changes for these transport mode SAs?
For instance MIPv6 (BU) uses the home address... And SCTP uses
different streams for different paths.

   I don't know where in the document it says
   that transport mode stuff should be put outside of MOBIKE.

=> the document puts the transport mode stuff outside of MOBIKE.
Can you propose some text to explain why? (I believe it was known
but obviously a rationale is needed).

   Also, the charter includes SCTP also.

=> yes and this is a good thing. But the SCTP model doesn't require
address changes, it only requires multiple integrated address management
(integrated = as a set vs. one by one).

   So, are you saying that this should be changed ?

=> no but direct address changes for transport mode are so complex
that their study should be postponed at least...

Thanks

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 11 Oct 2004 21:34:44 -0700

> different streams for different paths.
I have not forgotten. That is what i understood from "section 3".

> but obviously a rationale is needed).
I am fine with the decision. But i don't know what part of your document
says that. You keep saying that you want keep it outside and i thought
your document says so. I could never find it.

> that their study should be postponed at least...
What do you mean by "direct" address change ?

thanks
mohan

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Oct 2004 17:12:49 +0200

=> by a 100% IPsec mechanism. BTW I've seen other messages about this issue
expressing the same kind of ideas with other terms.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Oct 2004 09:54:53 +0200

=> is there another proposal using sets? As I'll submit soon a new version
of my transport mode draft, I'd like to fix this point!

Regards