btns-ipsec-apireq.txt

>>>>> "Miika" == Miika Komu
<miikaiki.fi> 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[
] mcrxelerance.com      http://www.san
delman.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


_______________________________________________

On Tue, Apr 25, 2006 at 03:29:55PM -0400, Michael Richardson
wrote:
> 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).

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

> We already think we have access to (c) via current API.
> 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
-- 
_______________________________________________