Subject: Re: [Roll] Using IPsec with RPL

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 24 Jul 2010 23:06:31 +0200

Le 17/06/2010 19:31, Michael Richardson a écrit :
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>
>
> There is a thread about IPsec with RPL. I read it all.
>
> Most of the thread misses the point about IPsec.
>
> Let me just prefix this by stating that I've worked on IPsec related
>  standards for 15 years, implemented it several times in several
> different operating systems, and managed the technical aspects of the
> Linux Freeswan and Xelerance Openswan projects.  I mention this
> because many of you in this group are experts in your fields (of
> which I am often ignorant), and the reverse is the case.
>
> For quite a number of years, non-security WGs of the IETF tried to
> say just say, "Use IPsec" in their protocols.  This was a total
> FAIL.
>
> Starting around 2000, mostly with the iSCSI specifications, using
> IPsec means actually specifying a number of things.  Not just Tunnel
> vs Transport, and not just AES vs 3DES. In fact, those things are
> irrelevant.
>
> The question is: where does the trust and authorization come from?
>
> This is the question I keep asking about the security in RPL.
>
> We can use AH format or not.

Let's use it.

> It doesn't matter much.

I think there are some differences, because AH may protect more fields
of RPL (ICMP), but I have to check in detail.

> There are essentially no interesting hardware accelerators that can
> do AH calculations, that can't also do just do HMAC-SHA1-96.  (The
> HMAC construct has proved to be very resiliant to all the hash
> attacks involving preimages.  You might think that MD5 is be broken,
> but HMAC-MD5 is still very strong)

WEll yes, I believe the strength required depends on the nature of
attacks.   A computational attack coming from a supercomputer (or
distributed.net?) would require more strength to resist.

In this sense, I believe MD5 or even MD4 could be enough (yes, HMAC-MD5)
for RPL.

Who are the attackers?  What's their computing power?

(and yes, I still have to read the RPL doc in detail, soon).

Alex

>
>
>
> ***** The question is: how do we create and distribute keys? *****
>
>
>
> IKE? IKEv2? How many keys are required?  A naive use of IPsec *OR
> ANY NETWORK INTEGRITY* system would require a set of available keys
> for each pair of nodes that wishes to communicate.  THIS WON'T WORK.
>
> As such we must look to the gkmp WG and consider whether statically
> distributing keys is useful.
>
> We must also very carefully consider bootstrapping, and asking the
> questions: which parts of an RPL (DIO,DOA,+various P2P pieces)
> message can a receiving node trust and/or act upon *EVEN* if the
> integrity check can not be verified?
>
> IPsec has been specified for multicast from the beginning, but in
> general you have to: a) manually key the SAs b) this implies turning
> off replay protection
>
> I believe that we could document a standard way of using AH with our
>  hop-by-hop multicast and unicast packets (treating the unicast
> packets as if they were multicast for security), and it might be
> useful. But, what's the point if we aren't using IKE?   There is
> little code reuse that I can see.  Specification reuse, great.
> Particularly in the "FOO-bar algorithm for use with ESP/AH".
>
> - -- ]       He who is tired of Weird Al is tired of life! |
> firewalls  [ ]   Michael Richardson, Sandelman Software Works,
> Ottawa, ON    |net architect[ ] [email-masked]
> http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch
> the video<http://www.youtube.com/watch?v=kzx1ycLXQSE> then sign the
> petition.
>
>
> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBTBpb7oCLcPvd0N1lAQLBnwf/T4J3iq6A2oFmchHCJfxMC1gy3SvNodQI
> zxoeiIJn035yy08dTWbCBSdpfDqQR9d7oxLw75eb02PFLjUCd44/SS8AGuy2vBMw
> LJo0tmEmmGJWdZiqzZKWRA5J+2EloTGWqFhRjfwtHD03QCtQMPN5RhygW5PLz4Of
> Pp3iOZqt9Sbce5aDX2PnOcy2hnQPK0zWczXqpjcBxf3bipEK9PkY5uiPggzMAWJ5
> wmdbcI4EK9eAkP1Hrs8/RzcjWzAva6V6xp1r0qlrqK2LuXValTRFIRy5xP6CTHbA
> xW3++uiigS9kk0rGvHT6IsTAon0H7buwxSyHpuUImLLLtij+saXeTQ== =m0Vn
> -----END PGP SIGNATURE-----
> _______________________________________________ Roll mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>