Subject: [MULTIMOBSEC-API] Re: btns-ipsec-apireq.txt

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

>>>>> "Miika" == Miika Komu <[email-masked]> writes:

    Miika> We have now three layers of identifiers now:

    Miika> * application layer: endpoint descriptor
    Miika> * transport layer:   initial shim6 locator (ULP), or some kind of CGA (HIT)
    Miika> * network layer:     current (shim6) locator

So, in the IPsec space we have:

  a) principal       - DN,SPKI Id,PGP identity,public key
  b) IKE layer       - certificate/public key and/or hash of same.
  c) transport layer - ULP (could be HIT)
  d) IPsec layer     - SPI# (SA bundle and pair)
  e) network layer   - current (shim6) locator

It is an explicit non-goal to provide access to (d).
We already think we have access to (c) via current API.
It is (b) and (a) that we are trying to get access to.

Does this mean that there is in fact more commonality?
  
    Miika> So, I would say that we should return transport layer id in 
    Miika> getsockname/getpeername, and use a separate API for the locators.

Good. Principle of least surprise.

    Miika> Shinta is referring to case 1b with sendmsg and recmsg. However, Pekka 
    Miika> said that it might be better to use some other function, perhaps something 
    Miika> like NETLINK socket to receive this information. This way, data transfer 
    Miika> would be decoupled better from locator/security related events.

  you need to have cmsg attached to sendmsg/recvmsg if you expect to support
connectionless protocols. Each message may well have a different answer.

]       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

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

---

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

> It is an explicit non-goal to provide access to (d).

Indeed.  Connection latching should obviate the need for applications to
care about SPIs.

> It is (b) and (a) that we are trying to get access to.

Yes!

The BTNS connection latching I-D discusses this somewhat.

(a) could be any of the ID types discussed in RFC4301, which relate
fairly closely to IKEv2 ID types, which relate somewhat to credentials.

(b) would be, IMO, only public keys or fingerprints thereof.  I see
entire certs as useful for granular authorization, but not necessary for
the kinds of applications discussed in the BTNS WG.

Note that (a) and (b) pretty much imply connection latching (to see why
see the post-Vancouver, pre-Dallas threads on the BTNS WG list).

> Does this mean that there is in fact more commonality?

I think so.

Nico
--