Subject: Re: [manet] manet Digest, Vol 67, Issue 22

From: Kavitha Ammayappan <[email-masked]>
Date: Thu, 19 Nov 2009 16:07:51 +0530

I would like to put forth my view about the usage of signatures for claiming
security in MANET. Why should we look in to some other alternative instead
of signatures for claiming security in MANET as it consumes much energy?

Regards
Kavitha Ammayappan

On Thu, Nov 19, 2009 at 3:58 PM, <[email-masked]> wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/manet
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send manet mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/manet
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of manet digest..."
>
>
> Today's Topics:
>
>   1. Re: Security drafts (Henning Rogge)
>   2. Re: Security drafts (Thomas Heide Clausen)
>   3. Re: Security drafts (Dearlove, Christopher (UK))
>   4. Re: Security drafts (Henning Rogge)
>   5. Re: Security drafts (Thomas Heide Clausen)
>   6. Re: Security drafts (Thomas Heide Clausen)
>   7. Re: Security drafts (Henning Rogge)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 19 Nov 2009 11:04:57 +0100
> From: Henning Rogge <[email-masked]>
> Subject: Re: [manet] Security drafts
> To: [email-masked]
> Cc: 'Rex Buddenberg' <[email-masked]>, "'Dearlove, Christopher
>        \(UK\)'" <[email-masked]>,       Thomas Heide
> Clausen
>        <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu November 19 2009 10:49:19 Thomas Heide Clausen wrote:
> > All good comments. I won't pretend to answer to your questions, as I
> > don't know that I know the ultimate answers ;) I'd just bounce a
> > couple of thoughts out and off you for discussion
> >
> > I do know that there are uses for situations where a given network may
> > maintain two topologies: one "secured" and one "not secured". Thus,
> > one topology may reject a given entry in the LSDB while another
> > topology in the same router may accept and use it, depending on the
> > validation of signatures.
> Yes, we could do this, as long as unsigned messages cannot change the state
> delivered by signed messages.
>
> > A blanket "throw away a message which doesn't validate, also without
> > forwarding" would, I think, disable this functioning.
> Yes.
>
> > Consequently,
> > this holds also for "throw away a packet which contains a message
> > where the signature doesn't validate".
> A packet should be only thrown away completely if the packet signature is
> wrong (if it contains a packet signature).
>
> Henning Rogge
>
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Neuenahrer Stra?e 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-263,   Fax +49 228 9435 685
> mailto:[email-masked] http://www.fkie.fraunhofer.de
> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 197 bytes
> Desc: This is a digitally signed message part.
> Url : <
> http://www.ietf.org/mail-archive/web/manet/attachments/20091119/916c7e46/attachment.sig
> >
>
> ------------------------------
>
> Message: 2
> Date: Thu, 19 Nov 2009 11:07:42 +0100
> From: Thomas Heide Clausen <[email-masked]>
> Subject: Re: [manet] Security drafts
> To: Henning Rogge <[email-masked]>
> Cc: Rex Buddenberg <[email-masked]>, "Dearlove,    Christopher
>        \(UK\)" <[email-masked]>, [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
>
>
> On Nov 19, 2009, at 11:02 AM, Henning Rogge wrote:
>
> > On Thu November 19 2009 10:24:57 Ulrich Herberg wrote:
> >> This is an interesting point. I fear, however, that allowing to block
> >> an originator forever leads to another attack. A malicious router
> >> simply sends a few unsigned (or badly signed) messages claiming to
> >> originate from another router.
> > Unsigned or badly signed messages/packets should NEVER be used to
> > block a node
> > if the capability exists to forge your own MAC/Source-IP. You simply
> > don't
> > have any information where the message is coming from, the only
> > thing you can
> > do is to call a higher layer (Help, I'm getting lot's of forged
> > messages !).
> >
> > The only exception I see is if you receive a message with a bad
> > signature but
> > the package was signed correctly. In this case it's clear that the
> > forwarding
> > node is either a stupid attacker or malfunctioning, so you could
> > remove it.
> >
>
> Or, maybe, that the forwarding node was not equipped to validate the
> signature. E.g. a protocol extension using a message type unknown to
> the forwarder, and where the "key-space" is proper to the extension
> (i.e. disjoint from that of NHDP/OLSRv2). I know of extensions (to
> OLSRv1, though) where this is the case.
>
> I'd not even consider "good packet signature, bad message signature"
> as a reason to remove the sender of the packet.
>
> Thomas
>
> > Henning Rogge
> >
> > --
> > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r
> > Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> > Kommunikationssysteme (KOM)
> > Neuenahrer Stra?e 20, 53343 Wachtberg, Germany
> > Telefon +49 228 9435-263,   Fax +49 228 9435 685
> > mailto:[email-masked] http://www.fkie.fraunhofer.de
> > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
> > _______________________________________________
> > manet mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/manet
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 19 Nov 2009 10:13:01 -0000
> From: "Dearlove, Christopher (UK)" <[email-masked]>
> Subject: Re: [manet] Security drafts
> To: "Thomas Heide Clausen" <[email-masked]>
> Cc: Rex Buddenberg <[email-masked]>, [email-masked]
> Message-ID:
>        <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> > I can think
> > of no situation where dropping a whole packet if a contained message
> > doesn't validate would make sense
>
> There are always two cases of "doesn't validate" to consider
> - Has signature, signature is bad.
> - Doesn't have signature.
>
> You can afford to be harsher in the former case than the latter.
> Whether that extends to dropping a whole packet is another matter.
>
> > In terms of the way forward, it appears clear to me that discussing
> > things in the context of protocols (NHDP/OLSRv2/DYMO) may be easier -
>
> > and allow us to extract the general/agnostic matters.
>
> Agreed. In fact it may make sense to say in NHDP/OLSRv2 specific drafts
> that an aim is exactly that, given the RFC 5444 multiplexing framework.
>
>
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 19 Nov 2009 11:14:34 +0100
> From: Henning Rogge <[email-masked]>
> Subject: Re: [manet] Security drafts
> To: Thomas Heide Clausen <[email-masked]>
> Cc: Rex Buddenberg <[email-masked]>, "Dearlove,    Christopher
>        \(UK\)" <[email-masked]>, [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu November 19 2009 11:07:42 Thomas Heide Clausen wrote:
>
> > > Unsigned or badly signed messages/packets should NEVER be used to
> > > block a node
> > > if the capability exists to forge your own MAC/Source-IP. You simply
> > > don't
> > > have any information where the message is coming from, the only
> > > thing you can
> > > do is to call a higher layer (Help, I'm getting lot's of forged
> > > messages !).
> > >
> > > The only exception I see is if you receive a message with a bad
> > > signature but
> > > the package was signed correctly. In this case it's clear that the
> > > forwarding
> > > node is either a stupid attacker or malfunctioning, so you could
> > > remove it.
> >
> > Or, maybe, that the forwarding node was not equipped to validate the
> > signature. E.g. a protocol extension using a message type unknown to
> > the forwarder, and where the "key-space" is proper to the extension
> > (i.e. disjoint from that of NHDP/OLSRv2). I know of extensions (to
> > OLSRv1, though) where this is the case.
> >
> > I'd not even consider "good packet signature, bad message signature"
> > as a reason to remove the sender of the packet.
> I think this would depend on the policy of the network.
>
> Maybe you drop the node at once (because you have mandatory signature
> checking
> on all nodes), maybe you just drop the message and inform your IDS "got bad
> message signature from node X forwarded by node Y".
>
> Henning Rogge
>
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Neuenahrer Stra?e 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-263,   Fax +49 228 9435 685
> mailto:[email-masked] http://www.fkie.fraunhofer.de
> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 197 bytes
> Desc: This is a digitally signed message part.
> Url : <
> http://www.ietf.org/mail-archive/web/manet/attachments/20091119/d11ea6f3/attachment.sig
> >
>
> ------------------------------
>
> Message: 5
> Date: Thu, 19 Nov 2009 11:16:25 +0100
> From: Thomas Heide Clausen <[email-masked]>
> Subject: Re: [manet] Security drafts
> To: Henning Rogge <[email-masked]>
> Cc: Rex Buddenberg <[email-masked]>, "Dearlove,    Christopher
>        \(UK\)" <[email-masked]>, [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
>
>
> On Nov 19, 2009, at 11:14 AM, Henning Rogge wrote:
>
> > On Thu November 19 2009 11:07:42 Thomas Heide Clausen wrote:
> >
> >>> Unsigned or badly signed messages/packets should NEVER be used to
> >>> block a node
> >>> if the capability exists to forge your own MAC/Source-IP. You simply
> >>> don't
> >>> have any information where the message is coming from, the only
> >>> thing you can
> >>> do is to call a higher layer (Help, I'm getting lot's of forged
> >>> messages !).
> >>>
> >>> The only exception I see is if you receive a message with a bad
> >>> signature but
> >>> the package was signed correctly. In this case it's clear that the
> >>> forwarding
> >>> node is either a stupid attacker or malfunctioning, so you could
> >>> remove it.
> >>
> >> Or, maybe, that the forwarding node was not equipped to validate the
> >> signature. E.g. a protocol extension using a message type unknown to
> >> the forwarder, and where the "key-space" is proper to the extension
> >> (i.e. disjoint from that of NHDP/OLSRv2). I know of extensions (to
> >> OLSRv1, though) where this is the case.
> >>
> >> I'd not even consider "good packet signature, bad message signature"
> >> as a reason to remove the sender of the packet.
> > I think this would depend on the policy of the network.
> >
> > Maybe you drop the node at once (because you have mandatory
> > signature checking
> > on all nodes), maybe you just drop the message and inform your IDS
> > "got bad
> > message signature from node X forwarded by node Y".
> >
>
> Right, I agree. This is rather deployment/policy dependent. We just
> need to make sure that we not enforce a behavior that excludes useful
> behaviors.
>
> Thomas
>
> > Henning Rogge
> >
> > --
> > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r
> > Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> > Kommunikationssysteme (KOM)
> > Neuenahrer Stra?e 20, 53343 Wachtberg, Germany
> > Telefon +49 228 9435-263,   Fax +49 228 9435 685
> > mailto:[email-masked] http://www.fkie.fraunhofer.de
> > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 19 Nov 2009 11:18:01 +0100
> From: Thomas Heide Clausen <[email-masked]>
> Subject: Re: [manet] Security drafts
> To: "Dearlove, Christopher (UK)" <[email-masked]>
> Cc: Rex Buddenberg <[email-masked]>, [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On Nov 19, 2009, at 11:13 AM, Dearlove, Christopher (UK) wrote:
>
> >> I can think
> >> of no situation where dropping a whole packet if a contained message
> >> doesn't validate would make sense
> >
> > There are always two cases of "doesn't validate" to consider
> > - Has signature, signature is bad.
> > - Doesn't have signature.
> >
> > You can afford to be harsher in the former case than the latter.
> > Whether that extends to dropping a whole packet is another matter.
>
> Actually, I made a comment to this effect to Henning and on the list
> just now - not even in that case is it (always) reasonable to drop the
> packet, as the forwarder might just be an innocent bystander not able
> to validate the contained messages that it forwards.
>
> >> In terms of the way forward, it appears clear to me that discussing
> >> things in the context of protocols (NHDP/OLSRv2/DYMO) may be easier -
> >
> >> and allow us to extract the general/agnostic matters.
> >
> > Agreed. In fact it may make sense to say in NHDP/OLSRv2 specific
> > drafts
> > that an aim is exactly that, given the RFC 5444 multiplexing
> > framework.
>
> I could live with that, Ulrich?
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 19 Nov 2009 11:28:09 +0100
> From: Henning Rogge <[email-masked]>
> Subject: Re: [manet] Security drafts
> To: [email-masked]
> Cc: Rex Buddenberg <[email-masked]>, "Dearlove,    Christopher
>        \(UK\)" <[email-masked]>,        Thomas Heide
> Clausen
>        <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu November 19 2009 11:18:01 Thomas Heide Clausen wrote:
> > On Nov 19, 2009, at 11:13 AM, Dearlove, Christopher (UK) wrote:
> > > You can afford to be harsher in the former case than the latter.
> > > Whether that extends to dropping a whole packet is another matter.
> >
> > Actually, I made a comment to this effect to Henning and on the list
> > just now - not even in that case is it (always) reasonable to drop the
> > packet, as the forwarder might just be an innocent bystander not able
> > to validate the contained messages that it forwards.
>
> I think the signatures will get even more important in combination with the
> state-machine-drafts mentioned at IETF. Together they would allow to check
> for
> misbehaving nodes and trigger alerts to an IDS infrastructure (or a local
> response daemon).
>
> Henning Rogge
>
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f?r
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Neuenahrer Stra?e 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-263,   Fax +49 228 9435 685
> mailto:[email-masked] http://www.fkie.fraunhofer.de
> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 197 bytes
> Desc: This is a digitally signed message part.
> Url : <
> http://www.ietf.org/mail-archive/web/manet/attachments/20091119/41534a0b/attachment.sig
> >
>
> ------------------------------
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>
> End of manet Digest, Vol 67, Issue 22
> *************************************
>

-- 
"Every one is the architect of his own fortune."   Mathurin Regnier

---

From: Henning Rogge <[email-masked]>
Date: Thu, 19 Nov 2009 17:15:47 +0100

Am Donnerstag 19 November 2009 11:37:51 schrieb Kavitha Ammayappan:
> I would like to put forth my view about the usage of signatures for
>  claiming security in MANET. Why should we look in to some other
>  alternative instead of signatures for claiming security in MANET as it
>  consumes much energy?
First not all attacks on a MANET can be contained with signatures.
Second signatures open an attack vector itself on the CPU consumption of the 
protocoll.
Third embedded nodes might be not equipped to run signatures on their messages 
including signatures to prove their links.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Nov 2009 17:14:25 -0000

> I would like to put forth my view about the usage of signatures 
> for claiming security in MANET. Why should we look in to some 
> other alternative instead of signatures for claiming security
> in MANET as it consumes much energy?

If you've got a solution that's lower energy, I'm sure we'd
like to hear it. But as this is the IETF not the IRTF I think
we're limited to the art of the currently possible, not an
open-ended look for something else.

Here's the basic problem. I want to form an ad hoc network. How
do I allow A and B (who are "good guys") to join with me to start
that network, but not allow X (who is a "bad guy") to join.

That's not to say that any solution to that problem is acceptable.
It might be too expensive (as you note). But it also might not
solve the problem, it might have too much pre-configuration needed,
it might introduce new problems, to name but three. But something
that solves that is a minimal starting point.

---

From: [email-masked]
Date: Thu, 19 Nov 2009 16:20:23 -0600

Christopher Dearlove wrote on Thur, 19 Nov 2009 that

>- Doesn't have signature.

Even if packet/messages have valid signature, should also consider 
protecting against someone recording a valid transmission/message and then 
replaying it from a different part of the network as if the packet/message 
originated from there.

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 19 Nov 2009 23:28:21 +0100

Hi,

> replaying it from a different part of the network as if the packet/message

Yes, this is an optional part of the NHDP-sec draft (and will be in
the OLSRv2-sec draft as well). The draft allows to include a timestamp
TLV in messages and to reject messages that are "too old". The reason
why this is optional is that it has some additional assumptions (such
as synchronized clocks). In the current revision of the draft, only
the unix timestamp is used for the timestamp TLV. As Henning pointed
out, the others uses of the timestamp TLV as described in the
packetbb-sec draft (e.g. using NTP time format, or a sequence number)
could be allowed as well for protection against replay attacks.

Ulrich

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 20 Nov 2009 09:30:10 -0000

> Even if packet/messages have valid signature, should
> also consider protecting against someone recording
> a valid transmission/message and then replaying it
> from a different part of the network as if the
> packet/message originated from there.

The delayed in time replay attack has some protection
offered in the general draft by means of a timestamp.
If you can ship a message across a network quickly
(cooperating attackers, or one fast attacker) so that
the timestamp doesn't protect you, then you need
something more. What you can do, I'm not sure.

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 20 Nov 2009 10:39:29 +0100

> something more. What you can do, I'm not sure.

Yes, this is an accurate description. I am not sure we can do anything
against this attack. In research, there are heuristics against these
attacks, based on additional information such as positions of routers,
radio range of the wireless interfaces, etc. But without such
information, I am not aware how such attacks can be counteracted.

Ulrich