[anonsec] btns at ietf66

[Love Hörnquist Åstrand]

Hello working-group,

I allocated 2h slot for us at ietf66, we are currently meeting on
Tuesday at 15.20.

The my proposed agenda was just published to the ietf meeting
materials website,
if you have any updates, please email me.

Love


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://mailman.postel.org/pipermail/anonsec/attachments/20060621/be78f6e7/PGP.bin

[Michael Richardson]

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/anonsec/attachments/20060628/71b7535b/attachment.bin

[Love Hörnquist Åstrand]

I would like some more details about the "Use of IPsec".
Is there something I should read ahead of time?

Sam promised to make a presentation on his view of (IPsec) security
and how BTNS would fit into it, I'm sure Sam can fill out any issues.

Nico and I have formulated a clearer statement of a problem that BTNS
will introduce to gateways that think that they have a workable
global PKI.
It needs perhaps 15 minutes to explain, and I will try to write an
email to
the list outline the issue, and maybe some diagrams ahead of time.

Ok, I'll allocate a time for that.

"Discuss API issues". - I think that's me as well.
-> defining the scope is the most important part.

And part of that is figure out how to interact with other working groups
that also have ideas on how to control IPsec to use in their protocols.

Love


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://mailman.postel.org/pipermail/anonsec/attachments/20060629/07be2632/PGP.bin

[Michael Richardson]

"Discuss API issues". - I think that's me as well.

-> defining the scope is the most important part.

strand> And part of that is figure out how to interact with other
strand> working groups that also have ideas on how to control IPsec
strand> to use in their protocols.

At this point, I think that the shim6 people still did not comprehend
that the shim6/btns API intersect is empty.
I guess I can do a venn diagram.

I think that the shim6/hip intersect is non-empty, and that the
hip/btns intersect is also non-empty, but I don't know if:
hip - shim6 is != 0
and hip - btns is != 0

I.e. if btns and shim6 APIs can provide everything that HIP needs.

My instinct is that this is a IRTF todo.

- --
] 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"); [

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

[Nicolas Williams]

Nico and I have formulated a clearer statement of a problem that BTNS
will introduce to gateways that think that they have a workable global PKI.

More specifically, in the process of fleshing out detailed examples
including detailed PADs and SPDs we figured out how to describe the
IPsec wildcard PAD entry problem, and that multiple wildcard PAD entries
have more security considerations than a single wildcard PAD entry at
the end of a PAD.

The problem can be addressed in several ways, though it isn't fully
explored in the draft we submitted.

It needs perhaps 15 minutes to explain, and I will try to write an email to
the list outline the issue, and maybe some diagrams ahead of time.

Yes, we'll have some materials to present on this.

Nico
--