Subject: [MULTIMOBSEC-API] first steps in APIs

From: Miika Komu <[email-masked]>
Date: Sat, 22 Apr 2006 22:39:53 +0300 (EEST)

Welcome to multimobsec-api list! I hope the list name is somehow adequate 
and that I got all interested people subscribed. If you don't want to be 
on the list, you can unscribe from:

https://www1.ietf.org/mailman/listinfo/multimobsec-api

We had a meeting with Shinta and Marcelo since they happen to be in the 
same country and city as I at the moment. We discussed about some 
technical details and especially how to start collaborating.

Initially, we though that we could have one "core" draft which includes 
only the things that are common for all working groups. In the end, we 
though that it might be better to have a core draft that describes all 
"peripheral" things like general locator management, failure and 
reachability detection. Things really specific to individual working 
groups could be described in separate extension drafts.

If I recall correctly, Jari suggested starting the core draft in shim6 
working group. It could be at least the initial home for the draft.

We can use draft-komu-native-hip-api as a base for the draft, or start 
from the scratch. Both approaches are fine to me.

Comments?

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

_______________________________________________
MULTIMOBSEC-API mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/multimobsec-api

---

From: Michael Richardson <[email-masked]>
Date: Sat, 22 Apr 2006 20:03:55 -0400

>>>>> "Miika" == Miika Komu <[email-masked]> writes:
    Miika> Initially, we though that we could have one "core" draft
    Miika> which includes only the things that are common for all
    Miika> working groups. In the end, we though that it might be better
    Miika> to have a core draft that describes all "peripheral" things
    Miika> like general locator management, failure and reachability
    Miika> detection. Things really specific to individual working
    Miika> groups could be described in separate extension drafts.

  My impression is that we actually have two commonalities, not three.
  I.e. the venn diagram looks like:

	      *****************
              *		      *
       .------*-----.	      *
       |      *     |	      *
       |IPsec * HIP |  shim6  *
       |      *     |	      *
       |      *     |	      *
       .------*-----.	      *
	      *		      *
	      *****************

  What does shim6 have in common with IPsec over IPv4?
  This question is not an argument, but rather, a genuine question.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

    "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 24 Apr 2006 13:39:08 +0300

Hi,

I guess that the identified commonalities are about some mechanisms 
that are likely to be present in multiple scenarios.
For instance, it seems likely that in hip and in shim6 there will be a 
need to deal with multiple addresses/locators. So, there seem to be 
somo common functios w.r.t. the managment of such addresses, like 
learning the locator set (both the local and the peer) as well as the 
currently used locator pair. Moreover, it seems interesting to let the 
lower layer that is handling the locator inform the upper layer that a 
new locator pair is being used.

Another issue that seems to be common in several scenarios is about 
reachability. First of all, it seems possible to re.use the failure 
detection and path exploration mechanism defined in the shim6 protocol 
in other protocols other than shim6 like, mipv6 or hip. Now, in this 
case, it seems possible to define a certain set of fucntions to allow 
the upper layer protocols to interact with this failure detection 
mechanism, like tunning timers, defining the number of alternative 
paths to be explored and so on.

So bottom line is, the commonality comes from these two characteristics 
that seems to be available in the differetn scenarios:

- there are multiple addresses that need to be managed
- a mechanism for failure detection and path exploration is used by the 
different protocols and it needs to be tuned/managed

The functions related to such functions can be made common to all the 
protocols.

Makes any sense?

regards, marcelo

El 23/04/2006, a las 3:03, Michael Richardson escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBRErEaICLcPvd0N1lAQKe8ggAtDwNIAVxePSedHddtw9osLF4IdPfusdM
> f4ROgImN/hi4qcfsvoV7ViTVw2dBaoRWRHYvus4KSQOqcjk3n8qolrHa6zn1aCNH
> aK7LU9Wyd/IQRBhrH4rjWP0UHPd689QE6zr6DGS7oe9W8pjCylvAle+wqRfOYlhU
> dU9/lud/VpJw/B7mrMXdnQ1o7XfArYUKUC9NN+4PmV34JEg+3Cv0ah+jmlsVlEKU
> n0GhXLtadFIkwvsPfghv0CBk68TdwguObg1TPJ2HVyaO6iLztQs96cCYNWCHo9j0
> v/DraWNWSfgtVw6JtzYD2+UBbIRAwSml9YbquyjRW9gagk/QL6oKtQ==
> =MnPt
> -----END PGP SIGNATURE-----
>

---

From: Miika Komu <[email-masked]>
Date: Mon, 24 Apr 2006 23:33:13 +0300 (EEST)

>  I.e. the venn diagram looks like:

(Probably very little.)

---

From: Miika Komu <[email-masked]>
Date: Tue, 25 Apr 2006 00:16:42 +0300 (EEST)

On Mon, 24 Apr 2006, marcelo bagnulo braun wrote:

> So bottom line is, the commonality comes from these two characteristics that 
> seems to be available in the differetn scenarios:
>

Yes it does, at least HIP wise.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Apr 2006 17:19:58 -0400

>>>>> "marcelo" == marcelo bagnulo braun <[email-masked]> writes:
    marcelo> So bottom line is, the commonality comes from these two
    marcelo> characteristics that seems to be available in the differetn
    marcelo> scenarios:

    marcelo> - there are multiple addresses that need to be managed - a
    marcelo> mechanism for failure detection and path exploration is used by
    marcelo> the different protocols and it needs to be tuned/managed

    marcelo> The functions related to such functions can be made common to
    marcelo> all the protocols.

    marcelo> Makes any sense?

  So do you feel that there is any overlap between shim6 and IPsec?
  I think we have two APIs here. 

  And that's fine -- decoupling is good.
  The HIP folks have to coordinate twice, but we don't have to come to a
consensus among three groups.

---

From: Shinta Sugimoto <[email-masked]>
Date: Tue, 25 Apr 2006 09:08:04 +0300

Hello Michael,

On Sat, 22 Apr 2006 20:03:55 -0400

>   I.e. the venn diagram looks like:

As you pointed out, currently SHIM6 only handles IPv6 addresses
in its locator management.  But in the future, it could also
support IPv4 locator as well.  It is addressed in Section 1.3 of
Erik Nordmark's draft <draft-nordmark-shim6-esd-00.txt>.

So, there is not need to exclude IPv4 locator management from
the common part, I think.

Regards,
Shinta

---

From: Shinta Sugimoto <[email-masked]>
Date: Tue, 25 Apr 2006 09:09:45 +0300

Hi,

On Mon, 24 Apr 2006 13:39:08 +0300

> The functions related to such functions can be made common to all the 

yes, makes sense to me too.

Regards,
Shinta

---

From: Shinta Sugimoto <[email-masked]>
Date: Tue, 25 Apr 2006 09:26:43 +0300

Hi Miika,

Sorry for replying lately.  Please find my comments below.

On Sat, 22 Apr 2006 22:39:53 +0300 (EEST)

> from the scratch. Both approaches are fine to me.

Given common understanding that "common part" would be the locator
mangement, failure detection and reachability exploration, we may
need to start from scratch.  If I understand it correctly, HIP native API
is mainly about providing endpoint descriptor for application to make
it more HIP-friendly way.  So I am afraid that the main focus is
different from the common API stuff.

Regards,
Shinta

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 25 Apr 2006 09:42:38 +0300

>   I think we have two APIs here.

I don't know...

what about MOBIKE? wouldn't mobike need similar locator management and 
failure detection functions?

what about MIP? (with the HA) in this case we would need to manage 
multiple locators and deal with failure detection over the IPSec tunnel 
with the HA...

but again, i don't really know just exploring

regards, marcelo

---

From: Miika Komu <[email-masked]>
Date: Tue, 25 Apr 2006 10:00:51 +0300 (EEST)

> I don't know...

I think there is some overlap even between shim6 and btns, but the overlap 
is somewhat marginal. Consider these examples:

* You could request current IPsec security parameters from shim6 module
   and it would tell you that there is none
* To set-up BTNS IPsec policies and associations, you also need locators

However, there is no reason why these APIs couldn't be decoupled.

> but again, i don't really know just exploring

There is some overlap, but I think it is possible to abstract it. HIP is 
the common denominator, so HIP people need to make sure that the "gray 
area" is covered in the drafts.

In any case, it would be very useful for everyone to review all drafts 
with a close attention what their working group wants from the APIs.

---

From: Miika Komu <[email-masked]>
Date: Tue, 25 Apr 2006 09:48:56 +0300 (EEST)

> consensus among three groups.

So, it seeems like we would have two APIs: one for security (IPsec) and 
the other one for locators. We'd need consensus between BTNS-HIP and 
SHIM6-HIP. It might even make things easier.

If we split things already at this point, it may not make sense to create 
"core" drafts. Otherwise, we may end up with too many documents (?):

   * locator core
   * SHIM6 locator extensions
   * HIP locator extensions
   * IPsec security core
   * BTNS security extensions
   * HIP security extensions

On the other hand, this separation might be better for other lower layer 
protocols as well. Comments, opinions?

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 25 Apr 2006 12:33:10 +0300

>
> So, it seeems like we would have two APIs: one for security (IPsec) 
> and the other one for locators. We'd need consensus between BTNS-HIP 
> and SHIM6-HIP. It might even make things easier.
>

ok, i am not familiar with what BTNS is doing, but if you say so...

> If we split things already at this point, it may not make sense to 
> create "core" drafts. Otherwise, we may end up with too many documents 
> (?):
>
>   * locator core

i would add:

* Reachability detection core
* Reachability detection shim6
* Reachability detection HIP

regards, marcelo
> On the other hand, this separation might be better for other lower 
> layer protocols as well. Comments, opinions?
>
> --

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 25 Apr 2006 12:41:15 +0300

To me, one of the more important parts of this exercise is to see  
whether, from an application's point of view, one could more or less  
implement HIP-functionality with BTNS+CGA+SHIM6.  In other words, my  
gut feeling is that that it would be good if

   HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff.

--Pekka

---

From: Miika Komu <[email-masked]>
Date: Tue, 25 Apr 2006 15:53:27 +0300 (EEST)

On Tue, 25 Apr 2006, Pekka Nikander wrote:

> To me, one of the more important parts of this exercise is to see whether, 
> from an application's point of view, one could more or less implement 
> HIP-functionality with BTNS+CGA+SHIM6.  In other words, my gut feeling is 
> that that it would be good if
>

This would work for me.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Apr 2006 09:22:00 -0400

>>>>> "Shinta" == Shinta Sugimoto <[email-masked]> writes:
    >> What does shim6 have in common with IPsec over IPv4?  This
    >> question is not an argument, but rather, a genuine question.

    Shinta> As you pointed out, currently SHIM6 only handles IPv6
    Shinta> addresses in its locator management.  But in the future, it
    Shinta> could also support IPv4 locator as well.  It is addressed in

...

    Shinta> So, there is not need to exclude IPv4 locator management
    Shinta> from the common part, I think.

I still see an empty set with IPsec over IPv4, as we don't deal with
locators at all.

- --

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Apr 2006 09:24:58 -0400

>>>>> "marcelo" == marcelo bagnulo braun <[email-masked]> writes:
    marcelo> what about MOBIKE? wouldn't mobike need similar locator
    marcelo> management and failure detection functions?

  MOBIKE is about moving the outer part of an IPsec tunnel around.

  The addresses inside (the identifiers if you prefer), remain the same,
so applications do not see any change. 

  A MOBIKE daemon *itself* might benefit from the mechanisms provided by
shim6 (if it were available for IPv4), but the end-user application
would never see the changes. That's the purpose of MOBIKE.

  As for MIP, again, the point of the effort is to maintain the same set
of identifiers for the application.

- --

---

From: Miika Komu <[email-masked]>
Date: Tue, 25 Apr 2006 16:42:26 +0300 (EEST)

> I still see an empty set with IPsec over IPv4, as we don't deal with

Perhaps I did not understand this properly. At least in BEET IPsec mode, 
you will have HITs in security policies and IP addresses (=locators) in 
security associations. Before packet leaves the host, the HITs are 
replaced with locators as specified in IPsec SPs and SAs. In addition, you 
can have a single security policy mapping to several security associations 
in IPv4 multihoming (or multi-SAing),

HIP handles also the case where you have IPsec over IPv6 addresses.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Apr 2006 15:32:03 -0400

>>>>> "Pekka" == Pekka Nikander <[email-masked]> writes:
    Pekka> To me, one of the more important parts of this exercise is to see
    Pekka> whether, from an application's point of view, one could more or less
    Pekka> implement HIP-functionality with BTNS+CGA+SHIM6.  In other words, my
    Pekka> gut feeling is that that it would be good if

    Pekka> HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff.

  So, you do not so much want us to find common pieces, but rather to
delinate clearly where one starts and one ends.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Apr 2006 17:05:43 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
    Nicolas> Yes, but I think there's a point where they may meet: at the API
    Nicolas> for obtaining the end-point IDs of a latched connection, and,
    Nicolas> therefore, the 
    Nicolas> representation of these IDs (IKEv2-style representation, + BTNS
    Nicolas> publickey ID type, + HITs).

When you receive a latched connection that was accepted due to BTNS,
and the ID that was asserted in IKE was ID_IPV6 (recalling that BTNS
made you not care that much about how valid it was for them to assert that),
would you expect to see the end-point ID be:
      a) the IPV6 that was asserted via IKE.
      b) the HIT that the transport/shim6 layer asserted
      
Aren't these two different things?
Particularly when the IE in IKE was in fact FQDN or something.

I can see applications that take a connection the first time, set
up some kind of account, have the account validated by out-of-band method
(e.g. the user paid for the service), and recall the public key used to sign
on. Subsequent sign-ons are authenticated nicely by public alone.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Apr 2006 16:15:52 -0500

> Particularly when the IE in IKE was in fact FQDN or something.

You would expect to get the coerced peer ID, the BTNS publickey ID whose
value is the peer's public key.

You want to see the IP addresses?  Sure, you can do that today.  You
want to see your NATed address, Ok, that's something new.

> on. Subsequent sign-ons are authenticated nicely by public alone.

Yes, exactly, that's ad-hoc authentication based on enrolment of BTNS
public keys.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 26 Apr 2006 09:57:53 +0300

> of identifiers for the application.

exactly, this is also the case for shim6 and for hip, but the point of 
an API extension for this cases is that shim6/hip/mobike/mip aware 
applications can be aware of locators and reachability of those because 
they want to have more control about them. In particular, this is 
important in the case of reachability, because the application is more 
capable of determining when a failure has occurred (at least what the 
app considers a failure to be)

So, i guess the point is that while all these allow a transparent 
behaviour for the apps, the goal of the API is to allow access to more 
detailed information for those apps that can handle it

regards, marcelo

> iQEVAwUBRE4jJoCLcPvd0N1lAQJiNgf+KwUNs2RdKnIat0zoc0cBQXLtwbHa27ds
> v78cuzEtG28uq9IQ0lGngSlcNqouGM4taIVOvThQ2jEs9GG/2pSYgXON1VNbj2nG
> N7A+wuDC0EI5i7Qim/d4TplwGcmbHcPL+zCslKBf+KtU/UsKQ3WuIFkiNgJnmGIZ
> W1paC9g00X0p1QFOLfwlvgFVctHPBE2THLv4pDFb5/r3j2z7iCL7wGvwqSw3rTKK
> lzQjKhsi7g72pPPXyAty6CzQ4iYcsBcCyaorgH7FJurxh6SBPxpE4yX8pMK6hn+N
> DstQvQJzXx5QAr9OKkQHeLNfa57cbZ0Nc0p53ZMwHBkKeBxMP+RuuQ==
> =mm+X

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Apr 2006 10:37:30 -0500

>    HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff.

What is CGA?

Anyways, what you call "BNTS api" is really an IPsec API:

 - APIs for getting latched connection peer IDs (enough for
   channel bindings and application-driven LoF and enrolment)

    - APIs for requesting services beyond what the SPD requires (e.g.,
      confidentiality where the SPD requires only integrity protection,
      or any protection at all where the SPD allows bypassing)

    - APIs for requesting bypass (requiring privilege, of course)

 - APIs for editing the IPsec policy databases (PAD, SPD) (which could
   be used for application-driven LoF and enrolment, but this is a much
   bigger hammer than the above)

Given a canonical tokenization of IKE/IPsec/BTNS IDs and HITs I think
this comes very close to a basic HIP API.

Still needed:

 - additional APIs to deal with mobility/NAT (again, this would be
   fairly generic)

 - APIs to locate peers (this being rather specific to HIP).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Apr 2006 10:22:35 -0500

> * To set-up BTNS IPsec policies and associations, you also need locators

<clarification>

Er, let's be careful and avoid confusion on the BTNS list about this:

 - BTNS is, at its core, about NOT authenticating peers
 - BTNS allows for anonymity and pseudonymity

 - (BTNS pseudonymity &&
	(application-driven enrolment ||
	 application-driven leap-of-faith)) == ad-hoc IPsec authentication

 - Some BTNS applications (channel bindings) don't care for
   pseudonymity, and, therefore, don't care for ad-hoc IPsec
   authentication.

So, BTNS can be said to have locators, but it isn't strictly the case
that it does have locators -- "BTNS locators" are an application
construct, not a fundamental BTNS construct.

</clarification>

> However, there is no reason why these APIs couldn't be decoupled.

Yes, but I think there's a point where they may meet: at the API for
obtaining the end-point IDs of a latched connection, and, therefore, the
representation of these IDs (IKEv2-style representation, + BTNS
publickey ID type, + HITs).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Apr 2006 10:37:30 -0500

What is CGA?

Still needed:

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Apr 2006 10:22:35 -0500

<clarification>

 - (BTNS pseudonymity &&

</clarification>

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 25 Apr 2006 15:30:32 -0500

> delinate clearly where one starts and one ends.

Dunno about Pekka, but, I see what he termed "BTNS api" above as a
generic IPsec API, which I describe, in broad terms, in the BTNS
connection latching I-D[0].

Given this I think we're talking about a well-delineated generic IPsec
API[1] that is commonly useful in the BTNS, HIP and SHIM6 spaces.

[0] http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-00.txt

[1] There's another proposed IPsec API for editing IPsec policy
    databases, but I think this API would not be common to the BTNS, HIP
    and SHIM6 spaces.

Nico
--

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 27 Apr 2006 13:28:51 +0300

> API[1] that is commonly useful in the BTNS, HIP and SHIM6 spaces.

but shim6 is layered below IPSec, so actually you only need to access  
to the shim6  layer in case that you want richer information about  
locators, failures and this kind of stuff...

I mean, shim6 should be transparent to IPSec, which is not the case of  
HIP and BTNS AFAICT....

In other words, in general IPSec should be exactly the same with or  
without the shim.

Regards, marcelo

> [0]  
> http://www.ietf.org/internet-drafts/draft-ietf-btns-connection- 
> latching-00.txt
>