Subject: RE: [Mobike] issue 12: interaction with other protocols doing RR

From: <[email-masked]>
Date: Mon, 1 Nov 2004 18:00:19 +0200

Tero Kivinen writes:
>
> Jari Arkko writes:
> > I would like to suggest that we do our own specific
> > type of test, but allow same tests to be "reused" across
> > protocols where this makes sense. That is, in MOBIKE
> > we do our own test that verifies liveness of the address
> > and that the peer is indeed still the same IKEv2
> > node and has knowledge of some secret keying material.
> > In addition, we add a note saying that the use of
> > the results of this test may be possible in other
> > protocol layers*.
> 
> How about, if we simply define the requirements for our tests, 
> and say that if those requirements are met by some other tests 
> already done, then tests inside MOBIKE can be skipped. And then 
> we would of course define what our tests provide, so others can 
> skip their tests if your tests fullfill their needs too. 

I think the main requirement would be verifying that the same 
entity that sent the address update message claiming to be at 
address X can also receive packets sent to X.

IMHO it sounds quite unlikely that any other protocol could 
provide this information...? 

What we could get is something like "This host has recently 
communicated with someone at address X with protocol FOO",
but we probably don't know if that someone is the sender of 
the MOBIKE address update or its intended victim...

(Well, there are cases where we actually could know it: e.g., 
the peer in IKE and "FOO" authenticated with the same 
credentials, or something like that. But I think these 
cases are quite rare...)

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 08 Nov 2004 22:07:21 +0200

We have gotten less input on this issue than on
others, but the way that I read this is the
following:

(1) We have a basic agreement that we define
     what MOBIKE RR provides, and if other
     protocols are happy with that then they
     can use it without doing their own.

(2) THere was a discussion if this works the
     other way around, i.e., from another protocol
     to MOBIKE. Tero argued for this and Pasi
     presented a counter argument. I think the
     counter argument made sense, and since Tero
     was silent I'm going to assume you were OK
     with it too.

(3) Atul suggested that APIs be worked on. We
     at the IETF are typically not chartered to
     work on APIs; I'm sure you see obvious ways
     of doing this in your implementation, however.
     But in MOBIKE, we are chartered to actually work
     on one API, the PFKEY API. It may be that
     this would be a part of the that work, or maybe
     not -- time will tell. But its clear that it
     is not a requirement for the protocol work to
     proceed. So we'll remember this when and if we
     get to the PFKEY part. (Folks: we need to produce
     are base spec before we get any further!)

In conclusion I think we can close this one too.

--Jari