btns-ipsec-apireq.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Pekka" == Pekka Nikander
<pekka.nikandernomadiclab.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/~pn
r/ 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. 

- -- 
]       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"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRDqFpICLcPvd0N1lAQJ09QgAhMhuz+9YubjN+ZZr2O6z1p/ARSGj
rPhu
BbL0wTgYbrAtaPiof7gT9cZqVpUe+JuKZUVY9YZ+3x6+086uG35dfWFNXv8i
wxvf
q1tMiTcbJL6vrbkQXQ9p+RivMGzYdXZY8Fjyx2M/pAmJ8XquA/ppSM9mBKMF
AqdT
jT2TZEOlx1E2GyvUMl+n5UDW9fft0zAAXpoUE+jc5DNm6Q+9bcH5uMkoUfMC
5m4P
vFtl+51nHFJvnNN8cVdFwy0F/Z5Se9BnzaabaLJnpSRPPZrBoa4gbVBVHlAx
dBZ3
Q1hGTNt8mawY0Errm6SQkVRMpC2I8sHOVpqGBDzQAcReqLz1gTYIDg==
=aK1J
-----END PGP SIGNATURE-----
_______________________________________________

On Mon, 10 Apr 2006, Michael Richardson wrote:

Hi folks,

>     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.

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-m
komu-hip-native-api-00.txt

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

ht
tp://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              miikaiki.fi          http://www.iki.fi/miika/
_______________________________________________

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.

_______________________________________________

Hi Miika,

On Tue, 11 Apr 2006 19:05:35 +0300 (EEST)
Miika Komu <miikaiki.fi> wrote:

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

[snip]

> 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.

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).

> 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.

Sounds good. I am happy to join the collaboration.


Regards,
Shinta

_______________________________________________