Subject: [anonsec] btns-ipsec-apireq.txt

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Sun, 09 Apr 2006 09:45:06 -0700

>>>>> "strand" == strand  <Love> writes:
    strand> There was a short discussion on how to proceed with the API
    strand> item from the charter. Sam Hartman with help from David
    strand> Black will present at next IETF. Michael Richardson promised
    strand> to look at the old API requirements document that he and
    strand> Bill Sommerfeld made for IPSP.

  The document has been formatted again, and it is at:

  http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-ipsec-apireq-00.txt

  If this is judged in scope for BTNS, then I'll ask the ID editor to
publish with that name.  If there is still doubt, I'll post under my name.

    strand> * Require support of bare keys, and add self-signed
    strand> certificates as a SHOULD.  * The IKE extentions will be
    strand> folded into the core document and Michael Richardson help
    strand> Nicolas with document as a co editor.

  What I think that we need is usage scenarios.
  I'm trying to write this up now.

    strand> Updated milestones ==================

Nov06	WG LC on IPsec interfaces draft
Nov06	Submit IPsec interfaces draft to the IESG

  I think that this is achievable, but I guess we have to have a
document to discuss well in advance of July.

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

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Mon, 10 Apr 2006 13:24:22 +0300

Michael,

Thanks for working on this!  It is great to see this go forward.

Personally, I would be happy to accept this as a WG document.  It  
seems like a good starting point for fulfilling our goal e), Develop  
an informational document describing the interfaces that IPsec  
implementations should provide to allow IPsec SAs to be used to  
secure higher layer protocols.

A few points:

- - It would be nice if the lists were formatted with bullets; they are  
now a little bit hard to read.

- - When considering motivations (Section 3), the following paper of  
ours may be worth reading:

   Jari Arkko, and Pekka Nikander, "Limitations of IPsec Policy  
Mechanisms," to appear in Security Protocols, Eleventh International  
Workshop, Cambridge, UK, April 2-4, 2003., http://www.tml.tkk.fi/~pnr/ 
publications/cam2003.pdf

- - In Section 5, I would like to see some more discussion of what are  
the problems of determining "WHO", or identity of the peer...  Yes,  
it will be discussed in Section 8, but once the document is fleshed  
out a little bit, there may be some distance between Sections 5 and 8.

- - I think I agree with your mission in 8.4, but also that it is out- 
of-scope of our current WG work.  Nothing the mission (perhaps even  
in Section 3) and providing hooks for it, is IMHO very good, though.

- - In 11.1, if you are using public keys as identities, the app should  
have some access to them.  IIRC, Miika Komu struggled a little bit  
with that problem when he considered HIP native API issues.

- --Pekka

On Apr 9, 2006, at 19:45, Michael Richardson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBRDk6DoCLcPvd0N1lAQJO0ggAl3Jia52iLtdxwoGjsw6phj288nxJw+As
> vTpmWcWjN4ipLdMvYd3UiDh/KeLwD2sSg0O4K73SJ1J0d2gH4qydTOmQHS96Mh4a
> VviCZqxQRnOo/4v3yqCpmQnsAx7FMK4/wbFPhwP7u7u/c+inx+NmLllTdnFrIal6
> xD47sx5RitqhI4KIW6d72tTPZBCjnpAiK2D1pav+c+wSI48pT0WiFSMAeuJOAkUd
> AjA+aINJN1mmT2kp6n4K+7M2jNiTU5Z5rU67Nc918/5IratkyE4nUEAWrbBW8rkH
> h5/qdvzdJ50DPvmakHIjW/s+xqEeQJ8t+r8D5bqjRJYi8Ygb0eJbTw==
> =cpKV
> -----END PGP SIGNATURE-----
> _______________________________________________
>

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Mon, 10 Apr 2006 09:19:49 -0700

>>>>> "Pekka" == Pekka Nikander <pekka.nikander at nomadiclab.com> writes:
    Pekka> A few points:

    Pekka> - - It would be nice if the lists were formatted with
    Pekka> bullets; they are now a little bit hard to read.

  Sure. I haven't edited the document in 3 years...
  I'm going to ask have this version published, and then reflect your
views into the -01.

    Pekka> - - When considering motivations (Section 3), the following
    Pekka> paper of ours may be worth reading:

    Pekka>    Jari Arkko, and Pekka Nikander, "Limitations of IPsec
    Pekka> Policy Mechanisms," to appear in Security Protocols, Eleventh
    Pekka> International Workshop, Cambridge, UK, April 2-4, 2003.,
    Pekka> http://www.tml.tkk.fi/~pnr/ publications/cam2003.pdf

  added.

    Pekka> - - In Section 5, I would like to see some more discussion of
    Pekka> what are the problems of determining "WHO", or identity of
    Pekka> the peer...  Yes, it will be discussed in Section 8, but once
    Pekka> the document is fleshed out a little bit, there may be some
    Pekka> distance between Sections 5 and 8.

  okay.

    Pekka> - - I think I agree with your mission in 8.4, but also that
    Pekka> it is out- of-scope of our current WG work.  Nothing the
    Pekka> mission (perhaps even in Section 3) and providing hooks for
    Pekka> it, is IMHO very good, though.

    Pekka> - - In 11.1, if you are using public keys as identities, the
    Pekka> app should have some access to them.  IIRC, Miika Komu
    Pekka> struggled a little bit with that problem when he considered
    Pekka> HIP native API issues.

  Yes, I agree. 

- --

---

From: miika at iki.fi (Miika Komu)
Date: Tue, 11 Apr 2006 19:05:35 +0300 (EEST)

On Mon, 10 Apr 2006, Michael Richardson wrote:

Hi folks,

>     Pekka> HIP native API issues.

Some background documents:

Shorter version:

http://www.niksula.cs.hut.fi/~mkomu/docs/f17-komu.pdf

Medium-length IETF draft formatted version:

http://www.ietf.org/internet-drafts/draft-mkomu-hip-native-api-00.txt

Longer version with requirements (and bunch of other things):

http://gaijin.iki.fi/hipl/hip-native-api-final.pdf

I'd like to align our HIP related work with the work of other WGs and vice
versa. The native APIs for HIP were accepted as official WG item at the
last IETF, so we are looking for feedback for the native APIs and I'd also
like to give feedback for other drafts.

If I understood correctly, it seems like shim6 guys are interested in the
interactions between applications, locators, referrals, resolver and shim
module.  We have touched those topics in the native HIP API work, but
there is still a bunch of things to be done.

Based on the "IPsec API requirements" draft, seems like the BTNS folks are
interested in allowing the applications to discover and influence the
security properties of the applications. This topic has been also touched
in the native HIP API, but there is still a lot to be done also here.

If there is interest in joint effort regarding APIs, maybe we should set
up a separate mailing list for discussing the core API issues? I think
cross-posting to several mailing lists is not very nice. As an
alternative, we could ask if the apps area mailing could be used also.

-- 
Miika Komu              miika at iki.fi          http://www.iki.fi/miika/

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Tue, 11 Apr 2006 12:32:06 -0400

I think coordinating these efforts is good provided that the
coordination does not block any effort.

Also, note that the BTNS charter is much narrower than HIP.

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Tue, 11 Apr 2006 10:58:24 -0700

>>>>> "Miika" == Miika Komu <miika at iki.fi> writes:
    Miika> If there is interest in joint effort regarding APIs, maybe we
    Miika> should set up a separate mailing list for discussing the core
    Miika> API issues? I think cross-posting to several mailing lists is
    Miika> not very nice. As an alternative, we could ask if the apps
    Miika> area mailing could be used also.

  Yes, I want a joint effort.
  I leave it to the chairs/ADs to decide what mailing list to use, and
more particularly, what WG to live in.  Please make sure that there 
is a gmane.org group for the mailing list.

- --

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 12 Apr 2006 10:19:13 -0700

IDs need to be published as individual submissions first in order to be
accepted as WG docs. Then the *WG* decides whether it becomes a WG doc.

Once it's submitted, let me know and I'll post it on the website too.

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 12 Apr 2006 12:41:15 -0500

> Once it's submitted, let me know and I'll post it on the website too.

I don't think so.

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Wed, 12 Apr 2006 14:19:28 -0400

>>>>> "Joe" == Joe Touch <touch at ISI.EDU> writes:

    Joe> IDs need to be published as individual submissions first in
    Joe> order to be accepted as WG docs. Then the *WG* decides
    Joe> whether it becomes a WG doc.

Joe, it is not actually a requirement that drafts need to be
individual submissions first.  The WG can choose to adopt a work item
based only on a description of that work item.

It is not uncommon for WGs to decide they will only adopt work items
after looking at an individual draft.  That is a valid policy for a WG
to adopt, but it is not a requirement of RFC 2418 or 2026.

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 12 Apr 2006 11:15:34 -0700

>> Once it's submitted, let me know and I'll post it on the website too.

To what part?

That the WG decides what becomes a WG doc?

Or that the WG can't possibly decide this unless it's publicly
available; that's the point of publishing it as individual.

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 12 Apr 2006 11:28:18 -0700

> based only on a description of that work item.

The WG adopted this as a work item (it's in the charter). That item was
not based on this version of the doc; it's fair to let the WG decide how
to proceed.

> to adopt, but it is not a requirement of RFC 2418 or 2026.

That's been the case with the WG thus far. Is there a reason to vary
from that procedure here?

Joe

---

From: shinta at sfc.wide.ad.jp (Shinta Sugimoto)
Date: Thu, 13 Apr 2006 14:52:26 +0300

Hi Miika,

On Tue, 11 Apr 2006 19:05:35 +0300 (EEST)

> On Mon, 10 Apr 2006, Michael Richardson wrote:

[snip]

> there is still a bunch of things to be done.

Yes, now I am sorting out what kind of API is needed for SHIM6.
In SHIM6, the issues are mainly how app can easily/efficiently deal with
locators, and interaction between SHIM6 module and ULP (especially TCP)
should also be defined.  But certainly there is a relation to other API
works (including the work done in HIP).

> alternative, we could ask if the apps area mailing could be used also.

Sounds good. I am happy to join the collaboration.

Regards,
Shinta

---

From: miika at iki.fi (Miika Komu)
Date: Mon, 17 Apr 2006 22:41:27 +0300 (EEST)

On Mon, 17 Apr 2006, Erik Nordmark wrote:

> Miika Komu wrote:
> Interesting.
> I'm trying to understand why and where you have an ED (endpoint
> designator) instead of a HIT.
> Is this only needed to support opportunistic mode?

This is one use case. Some other possible use cases are:

* Future compatiblity with larger HITs in the future
* Future compatibility with process/session layer migration schemes
* Makes developer's life with application defined HIs slightly easier

> (I'd personally do opportunistic mode as a HIT discovery exchange before
> telling TCP/UDP to setup state based on a HIT.)

If you do this in the resolver, you might be creating some unwanted
connections.

> What is the uniqueness requirements for the ED? Is it just a locally
> allocated number that a host could start assinging at 1 for the remote
> hosts it talks to?

Currently yes. It could be unique only in the process context, depending
on the implementation.

It would be possible extend the ED context slightly if there were (HIP)
extensions for negotiating this. This way, an ED could be shared with a
peer and we would have SCTP likish stream identifiers.

I have been actually thinking of adding this idea to the API draft (but
this may be the wrong discussion forum that).

> Is a TCP connection identifier by a pair of ports and a pair of EDs, or
> a pair of ports + HITs?

Currently, an ED is only a local alias for HIT, so TCP is identified using
ports and HITs. However, this could be extended as a described above.

> How does the application associate state for remote peers if the EDs are
> all it has, and the EDs are locally allocated? For instance, the
> application could communicate with ED=7 to host A and host B could also
> have picked ED=7. Is it a requirement that the applications associate
> all their state for remote hosts with the HI?
>
> (And if TCP operates on EDs, the previous question applies to TCP as well.)

If we would have some extensions for negotiating for randomly picked EDs,
I guess this would work.

> Thus if EDs only need to be introduced for opportunistic mode, I think
> it is a lot simpler to handle opportunistic mode in a different place in
> the layering, instead of inventing an ED namespace with all associated
> issues.

See my resolver comment above. Alternatively, you could handle the
opportunistic mode with the socket handler implementation, but even in
that case the application gets (incorrectly?) an IP which may be
problematic with (HIP) mobility and multihoming.

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Fri, 21 Apr 2006 15:56:09 -0400

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20060421/65a8f2b6/attachment.bin

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Sat, 22 Apr 2006 19:08:13 -0400

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20060422/632caaa0/attachment.bin

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Sat, 22 Apr 2006 19:28:37 -0400

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20060422/b20a69af/attachment.bin

---

From: miika at iki.fi (Miika Komu)
Date: Mon, 24 Apr 2006 01:16:27 +0300 (EEST)

On Sat, 22 Apr 2006, Michael Richardson wrote:

>    Miika> Currently yes. It could be unique only in the process context,
>    Miika> depending on the implementation.
>
> <implementation detail alert>
>  I am seriously considering making the EDs, which I think of as first class
> objects, be file descriptors.  Further, they may well be Unix domain sockets
> (perhaps with a new family type) that are already connected to the
> appropriate keying daemon.
> </implementation detail alert>

Yes, this is true.

> (I think the HIP people might need to explain how HIP opportunistic mode
> differs from rfc4332. It isn't the same)

It means that there is a leap of faith because the first packet of the HIP 
key exchange is sent to an unkown HIP layer identifier (=HIT). In 
practice, this might be a little bit problematic to implement because the 
application might be doing a connect call on an IP address. It is 
problematic in the sense of mobility; when hosts move, the address may 
become invalid.

There are various ways to go around this problem which mostly involve in 
wrapping or modifying the application sockets somehow, either at the 
application layer or sockets layer in kernel. Compared to them, ED makes 
things simpler because the HIT can be later on filled when the HIT is 
actually learned later on during the key exchange.

---

From: shinta at sfc.wide.ad.jp (Shinta Sugimoto)
Date: Tue, 25 Apr 2006 11:30:07 +0300

Hi Michael,

please find my comments inline.

On Sat, 22 Apr 2006 19:08:13 -0400
Michael Richardson <mcr at sandelman.ottawa.on.ca> wrote:

> 
> >>>>> "Shinta" == Shinta Sugimoto <shinta at sfc.wide.ad.jp> writes:
> 
> (when I first read your name, I was sure it must be "Shim6ta Sugimoto"...)
> 
>     >> If I understood correctly, it seems like shim6 guys are interested in
>     >> the interactions between applications, locators, referrals, resolver
>     >> and shim module.  We have touched those topics in the native HIP API
>     >> work, but there is still a bunch of things to be done.
> 
>     Shinta> Yes, now I am sorting out what kind of API is needed for SHIM6.
>     Shinta> In SHIM6, the issues are mainly how app can easily/efficiently
>     Shinta> deal with locators, and interaction between SHIM6 module and ULP
>     Shinta> (especially TCP) should also be defined.  But certainly there is
>     Shinta> a relation to other API works (including the work done in HIP).
> 
>   I am perhaps someone naive in my understanding of shim6. 
>   I followed multi6, and was well briefed over dinner at the last IETF as to
> how shim6 works. I must be admit that I'm at a loss to understand the shim6
> API question, when it is not being used to bootstrap to HIP.
>   
>   As I understand it, upon initial connect, the application is going 
> (via getpeername/getsockname), going to see the address that was used to
> connect to it, and the local address to which the connection was made.
> 
>   Should the shim6 layer detect a loss of connectivity and switch to another
> address, the transition will be not be seen to the application.  Is it an 
> open question what getsockname/getpeername() will say after the transition?

No.  IMO, getsockname()/getpeername() should not be affected by the
locator change.  If SHIM6 context is applied to given flow, then locator
changed to something else, that should be kept invisible to the ULP.

>   i.e. is the kernel supposed to maintain the original fiction,

Yes.

> or is it
> better that it indicate what is reality at that moment, so that if the
> purpose of the query was to start a second connection (i.e. FTP...) that
> it can start with a better hint.

Apart from the above (that the locator change should not affect
getsockname()/getpeername()), telling the 'reality' of the locator
selection to the ULP might be helpful.  Not sure how much is it helpful
though.  Such extension would allow application to get information
about the locator which is bound to given socket.  Similary, we may
extend sendmsg()/recvmsg() to deliver locator information to the
application storing them in acillary data, for instance.  But again,
I don't see clear need (good usecase) for that.  Do you see any ?

>   I can see how getsockname()/getpeername() are not good enough, and you'd
> like a more sophisticated answer. This is similar, certainly to what IPsec
> wants: we want to know far more than what that interface can provide.
>   (And in the case IPv4 transport mode through a NAPT, the answer from
> getpeername() is perhaps completely ambiguous)

I see.  BTW, is there any other cases than NAT where IPsec requires
more sophisticated Socket API calls if peer is multihomed ?

>   Is that the extent of the requirements?

Yes, I think so.

>   Or are there more?

Not sure at the moment.

Regards,
Shinta

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Tue, 25 Apr 2006 09:29:58 -0400

>> I can see how getsockname()/getpeername() are not good enough,
    >> and you'd like a more sophisticated answer. This is similar,
    >> certainly to what IPsec wants: we want to know far more than what
    >> that interface can provide.  (And in the case IPv4 transport mode
    >> through a NAPT, the answer from getpeername() is perhaps
    >> completely ambiguous)

    Shinta> I see.  BTW, is there any other cases than NAT where IPsec
    Shinta> requires more sophisticated Socket API calls if peer is
    Shinta> multihomed ?

  Many people would like to be able to establish multiple IPsec SAs
between two nodes that are multihomed. I.e. one for each interface
address. Many would like to load balance between the tunnels.

  (The only situation that I'm aware that have been deployed is actually
  where one load balances between *machines*, with failover between the
  two machines, and it's all about tunnels, so the end-application never
  sees this)

  Given shim6, let ULP=ESP, and just use shim6. So, IPsec in the kernel
may need to know about shim6, but application does not see shim6, only
IPsec.

- -- 

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

---

From: miika at iki.fi (Miika Komu)
Date: Tue, 25 Apr 2006 16:31:14 +0300 (EEST)

> changed to something else, that should be kept invisible to the ULP.

Agree with Shinta.

>> or is it better that it indicate what is reality at that moment, so 
>> that if the purpose of the query was to start a second connection (i.e. 
>> FTP...) that it can start with a better hint.
>
> though.

We have now three layers of identifiers now:

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

This the "clean" view of the APIs. For legacy apps, application layer id 
could be CGA type of address or just a (shim6) locator.

In the light of this viewpoint, I think getsockname()/getpeername should 
return the application information that is adjacent to the application 
layer, that is transport layer information.

> Such extension would allow application to get information about the 
> locator which is bound to given socket.

In HIP we have HITs that cannot be resolved from DNS because they are flat 
(they are hashes of public keys). If you call getpeername, receive a HIT 
and pass it to a third host (the term is "referral"), it might be of any 
use the third host. The reason is that the third host might not be able to 
find the corresponding locator. Despite of this shortcoming, this will be 
most probably solved using DHT based look up services in future.

Alternatively, we could pass the IP address instead of HIT. This is 
actually makes things worse because in HIP hosts are mobile.

So, I would say that we should return transport layer id in 
getsockname/getpeername, and use a separate API for the locators.

> Similary, we may extend sendmsg()/recvmsg() to deliver locator 
> information to the application storing them in acillary data, for 
> instance.  But again, I don't see clear need (good usecase) for that. 
> Do you see any ?

I there are three cases:

1. get identifier related info
    1. a) explicit request from the application
    1. b) sockets returning even information to the application
2. set identifier related info

Here, identifier could be an HIT, CGA, ULID or locator. I think 1a and 1b 
could be specified using getsockopt and setsockopt to avoid adding new 
system calls.

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

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 25 Apr 2006 10:29:28 -0500

> I don't see clear need (good usecase) for that.  Do you see any ?

Ah, er, I see Michael's point.  What if the app wants to initiate a
connection to a peer for which it already has a connection.  Are there
such applications today?  (Yes!  NFSv4.)  How can such applications
continue to work then in this environment?  Ah, but there's no guarantee
that they'd work even if getsockname()/getpeername() returned the peer's
current locator because the peer and the application might be racing
around the next change.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 25 Apr 2006 10:47:28 -0500

> layer, that is transport layer information.

Well, why not label getsockname()/getpeername() legacy interfaces?  Then
you need to worry about two things:

 - backwards compatibility for users of getsockname()/getpeername() in
   various circumstances; if it can't always be preserved, oh well,
   don't be mobile :)

   If the application connect()ed using any locator other than an IP
   address then you can return all available information about the two
   end-points to the application.  Otherwise, if the application
   connect()ed to an IP address or used accept() and did not do anything
   else to indicate support for anything other than IP addresses, then
   getsockname()/getpeername() should only return IP addresses (and ULP
   port numbers).

 - new APIs for everything the application might care for (see below),
   perhaps as an extension of existing APIs (see above)

> actually makes things worse because in HIP hosts are mobile.

Alternatively you make both items available to the application, which
then can pass them to the third party, which then does not need to do
any resolution (provided that the peer hasn't moved).

Nico
--

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Tue, 25 Apr 2006 15:29:55 -0400

>>>>> "Miika" == Miika Komu <miika at iki.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.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
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
--