Hi all,
Please don't stick with IKEv2
because IETF also standardized other key exchange protocol,
i.e KINK (kerberos based ipsec key exchange protocol).
Or could you please list those exchange protocols in the RFC
if describing name of specific exchange protocol in the RFC?
To show a list of choises for implementors.
Here are our experiences:
- As I told in this ML,
one of the problem of IKE/IKEv2 is PK (public key cryptography)
when applying IPsec to resource limited devices.
- PK impacts against those devices' sensitive factors:
footprint/gatesize/throuput/power consumption.
- Then, if using IKE* w/ PSK (Pre-Shared Key) instead of PK,
the number of PSK is O(N^2) due to its e2e bases.
It means scalability issue.
- So, 3rd trusted party model (= Key Distribution Center model)
is one of reasonable choices if you use PSK instead of PK.
Because the number of PSK is O(N).
# Kerberos is one of KDC models.
# As FYI, if my understanding is correct,
# key management of SP100 is also a kind of KDC model.
# And, centralized management like KDC is fit for
# the management style of "small-but-many-devices" system.
- KINK (RFC4430) was designed for that.
- I guess that many people worry that
it is nightmare to speak multiple key exchange protocols.
But, system is not so much complicated
because resource limited devices usually relay on some servers.
ex. Cheap devices speak cheap key exchange protocol (=KINK) only.
Just several servers should be multilingual (IKE*/KINK).
<A hat of WIDE Project>
- We have opened reference code of multiple IPsec key exchange
protocols (IKE/IKEv2/KINK) daemon called Racoon2.
It can handles those protocols in the same node.
So, it can be helpful hint for your multilingual servers.
</A hat of WIDE Project>
Those is why I think IPsec is still useful security tools.
Again, I understand that above approach is not universal.
# and there is no universal approach of security, after all :-)
However, it can solve a part of issues discussed here
which can not be solved with IKE*.
(ex. some applications of sensor/actuator or resource limited devices).
Thanks,
From: Ed Jankiewicz <[EMAIL PROTECTED]>
Subject: Re: the role of the node "requirements" document
Date: Wed, 27 Feb 2008 16:27:26 -0500
> I lean towards (3) because IPsec without IKE or something is
> unmanageable. I could support MUST or SHOULD, or a conditional
> statement, and would prefer linking to IKEv2 as part of the package.
> Thomas hinted at the "chicken and egg" problem with IKEv2 - we'd like to
> mandate it to encourage implementation, but hesitate to mandate
> something that hardly exists in the near future...
>
> But I would go along with Brian's sentiment about IETF not dictating
> use; that has been said a few times in various ways during this
> discussion. Reality is even if 4294 is not updated, it makes no
> difference to the actual implementation and use of IPsec; if revision
> says nothing about IPsec, it makes no difference. If the revision says
> SHOULD or MUST, probably makes no difference. Implementors will make
> their own choices as will buyers of products.
>
>
> Brian E Carpenter wrote:
> > On 2008-02-28 09:34, James Carlson wrote:
> >
> >> Dow Street writes:
> >>
> >>> 1. the Internet *does not* need a mandatory security mechanism at
> >>> the IP layer
> >>> 2. the Internet *does* need a mandatory security mechanism at the IP
> >>> layer, but IPsec is not the right one because it is too heavyweight
> >>> 3. the Internet *does* need a mandatory security mechanism at the IP
> >>> layer, but IPsec *alone* is insufficient (without IKE, key mgmt, etc)
> >>> 4. I don't care about the architecture of the Internet, because I
> >>> intend to develop devices that are never connected to the global
> >>> Internet (and therefore play no role in defining the Internet
> >>> architecture or adhering to Internet best practices).
> >>>
> >> I suppose I'm closest to (1) in your list, but I'd still phrase it
> >> differently.
> >>
> >> 5. IP itself works properly without IPsec -- and demonstrably so.
> >> It's not a _requirement_; it's not something that without which IP
> >> simply fails to operate. It's desirable, and likely highly
> >> desirable, but it's not a fundamental issue.
> >>
> >
> > I'm close to this position too, but even closer to
> >
> > 6. As long as the IETF specifies a way of securing the IP layer,
> > it's an implementation, procurement and operational issue
> > whether it gets used. Words in an RFC have no control over that.
> >
> > And don't forget what Thomas said about keying.
> >
> > Brian
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email protected]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> >
>
> --
> Ed Jankiewicz - SRI International
> Fort Monmouth Branch Office - IPv6 Research
> Supporting DISA Standards Engineering Branch
> 732-389-1003 or [EMAIL PROTECTED]
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
