Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 12 Jul 2012 22:39:13 +0200

Hi Ulrich,

I am not expert in security issues, but IMHO, I agree with Chris to
recommend to include in draft-02 both securing messages and packets
(in general for packets), so the document should specify NHDP messages
and MANET packets [AB]. The reasons are first, because NHDP is a MANET
Interface protocol between neighbor routers. secondly it uses RFC5444
format that the future MANET routers will use. Third, NHDP uses
RFC5444 which was specified for information exchange between MANET
routers.

[AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt

Regards
Abdussalam
=======

On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg <ulrich at herberg.name> wrote:
> Dear Chris,
>
> I agree that we need to provide similar mechanisms as in NHDP-sec for TC
> messages as well. I don't think that signing the packet is enough, since
> that does not provide end-to-end security. Instead, I suggest to submit a
> draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, and
> how to handle these messages in OLSRv2.
>
> However, I believe that it would be beneficial for certain applications to
> also be able to sign/verify packets. But I don't think that the NHDP-sec
> document is the right place for this, since other applications (e.g. DYMO)
> may not use HELLO messages at all, but would still like to sign/verify
> packets.
> Maybe it would be better to have an extra document "packet-sec" which
> specifies how to sign/verify packets?
>
> Best
> Ulrich
>
>
> On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK)
> <Chris.Dearlove at baesystems.com> wrote:
>>
>> (Sending again, to sort out the formatting problem with the last attempt.)
>>
>> As I read it, this draft is proposing using the RFC 6622 mechanism to sign
>> HELLO messages. RFC 6622 actually allows for signing packets as well as
>> signing messages (both, either, or neither to be used as required). There
>> isn't a major difference when considering HELLO messages, as few if any
>> packets will contain more than one HELLO message, and the packet and the
>> message will be signed by the same party.
>>
>> However NHDP doesn't exist in a vacuum, in particular it is used by
>> OLSRv2. Any security mechanism that is described in what will be an RFC for
>> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also has
>> TC messages to consider, and they don't satisfy the points noted above (on
>> number or on who signs them). And one option for OLSRv2 is to sign all
>> packets, not messages. This can be a sensible decision there, for several
>> reasons, in some real circumstances.
>>
>> Consequently, I don't believe that this draft should describe only signing
>> HELLO messages as the correct thing to do, that it should also allow signing
>> packets as an equal status option. If someone wants to raise the possibility
>> of signing (possibly by methods with different properties) both at the
>> message and packet level, that may have its use cases too.
>>
>> Incidentally, even within the limited framework of just NHDP, it is
>> possible that packets need protection. If an NHDP implementation chooses to
>> use packet sequence number as part of its link quality mechanism, as it may,
>> then an unprotected packet header is a vulnerability.
>>
>> (For the sake of completeness, RFC 6622 also allows address block
>> signatures. I don't have a reason to suggest using this within NHDP or
>> OLSRv2.)
>>
>> --
>> Christopher Dearlove
>> Senior Principal Engineer, Communications Group
>> Communications, Networks and Image Analysis Capability
>> BAE Systems Advanced Technology Centre
>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>> Tel: +44 1245 242194 |  Fax: +44 1245 242124
>> chris.dearlove at baesystems.com | http://www.baesystems.com
>>
>> BAE Systems (Operations) Limited
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,
>> Farnborough, Hants, GU14 6YU, UK
>> Registered in England & Wales No: 1996687
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Mobile Ad-hoc Networks Working
>> Group of the IETF.
>>
>>         Title           : Using Integrity Check Values and Timestamps For
>> Router Admittance in NHDP
>>         Author(s)       : Ulrich Herberg
>>                           Thomas Heide Clausen
>>         Filename        : draft-ietf-manet-nhdp-sec-02.txt
>>         Pages           : 12
>>         Date            : 2012-05-29
>>
>>    This document specifies a security extension to the MANET
>>    Neighborhood Discovery Protocol (NHDP).  The extension introduces the
>>    use of Integrity Check Values (ICVs) and Timestamps in HELLO messages
>>    in order to provide a router admittance mechanism, and therefore to
>>    counter a selection of security threats to NHDP.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-02.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-02.txt
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/
>>
>> _______________________________________________
>> manet mailing list
>> manet at ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>> ********************************************************************
>> 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.
>> ********************************************************************
>>
>

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 12 Jul 2012 13:54:59 -0700

The document specifies signing/verifying NHDP messages. RFC5444 packets are
not specific to NHDP, and therefore should IMO not be discussed in a
document entitled "Using Integrity Check Values and Timestamps For Router
Admittance in NHDP". That's why I suggested to handle this in an additional
document for RFC5444 packets.

Regards
Ulrich

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 13 Jul 2012 00:08:51 +0200

I agree with Ulrich. 

Note that this is all about "messages" in as much as NHDP is concerned.

1) NHDP specifies something akin to "an implementation may recognize additional reasons for considering a HELLO message invalid for processing"; this I-D specifies such an additional reason, by way of a TLV in HELLO messages.

2) NHDP "owns" HELLO messages, and therefore gets first dip on an incoming HELLO message post-demultiplication. Including the ICV Message TLV in HELLO messages therefore makes sense.

Ad 1), I note that this I-D is intended to exactly plug in at that place in 6130.

Thomas

-- 
Thomas Heide Clausen
http://www.thomasclausen.org/

"Any simple problem can be made insoluble if enough meetings are held to
 discuss it."
   -- Mitchell's Law of Committees

On 12 Jul 2012, at 22:54, Ulrich Herberg <[email-masked]> wrote:

> The document specifies signing/verifying NHDP messages. RFC5444 packets are not specific to NHDP, and therefore should IMO not be discussed in a document entitled "Using Integrity Check Values and Timestamps For Router Admittance in NHDP". That's why I suggested to handle this in an additional document for RFC5444 packets.
> 
> Regards
> Ulrich
> 
> On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun <[email-masked]> wrote:
> Hi Ulrich,
> 
> [email-masked]

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 13 Jul 2012 04:10:17 +0200

Hi Ulrich,

I will need to read Chris message reasons again. However, when the
RFC6130 document was written/updating maybe no one asked for adding
packet specification that is why RFC6130 does not specify packet, also
does not object it. So in future a request/update may appear. RFC6130
seams to be designed for All MANET Routings, so for example including
reactives as AODV, DSR, DYMO, and LOAD. I think it is important for
Reactive protocols to have packet specified.

RFC6130>page 9> Is applicable to networks, especially wireless
networks, in which
unknown neighbors can be reached by local broadcast or multicast packets.

meaning> Reaches neighbors by local broadcast OR multicast [RFC5444] packets.

I will request/suggest (after issuing draft-dsrv2) to consider to
update RFC6130 (I don't mind doing draft) to specify packets as a tool
for neighbor discovery. In DSRv2 source-routing neighbor discovery
specified in packets is needed, which MANET Packets [AB] are used by
NHDP. I suggest that it will be interesting for AODVv2 (the needed
reactive in WG) as well to use *optional* packets in its neighbor
discovery with metric-type in MANET Packet instead of only the hello
message.

Abdussalam
===============

On 7/12/12, Ulrich Herberg <[email-masked]> wrote:
>> >> OLSRv2. Any security mechanism that is described in what will be an
>> >> RFC
>> for
>> >> use packet sequence number as part of its link quality mechanism, as
>> >> it
>> may,

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 13 Jul 2012 04:52:57 +0200

On 13 Jul 2012, at 04:10, Abdussalam Baryun <[email-masked]> wrote:

> does not object it.

Incorrect. RFC6130 specifies use of RFC5444. All messages are carried in packets in RFC5444.

> So in future a request/update may appear. RFC6130

????

> discovery with metric-type in MANET Packet instead of only the hello

I am sorry to be blunt, but it appears clear to me from the above, that you've not understood RFC5444 nor RFC5498.

Do you understand that, in RFC5444, a message _always_ is contained in a _packet_? That a _packet_ serves as a mechanism for efficiency for containing multiple _messages_ in a single transmission? That a _message_ serves for relating information conveyed to a specific protocol and so as a demultiplexing mechanism?

I would suggest studying and understanding the different protocols, before rushing to call for their update.

Best,

Thomas

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 13 Jul 2012 12:54:23 +0200

Hi Thomas,

> Incorrect. RFC6130 specifies use of RFC5444. All messages are carried in

I agree that RFC6130 specify use of RFC5444, and all NHDP-messages are
carried in RFC5444-packets. But I am correct that there is no mention
of the requirement language that: NHDP *MUST NOT* be creating
RFC5444-Packets or using them in signalling.

>> Reactive protocols to have packet specified.

no information to reply !

> I am sorry to be blunt, but it appears clear to me from the above, that
> you've not understood RFC5444 nor RFC5498.
>

Why I don't understand? I see that the language used in RFC5444,
RFC5498, and RFC6130, does not mention, *MUST NOT*, or other
restrictions is having NHDP specifying packets for its behavior. If
you think I am incorrect please point to a reference paragraph in
these documents.

> Do you understand that, in RFC5444, a message _always_ is contained in a
> _packet_? That a _packet_ serves as a mechanism for efficiency for
> containing multiple _messages_ in a single transmission? That a _message_
> serves for relating information conveyed to a specific protocol and so as a
> demultiplexing mechanism?

Yes I do understand, that a RFC5444 packet MAY contain
RFC5444-messages (RFC5444 page 24), and that a RFC5444-message May be
encapsulated in RFC5444-packets ( RFC5444 section 5.2). we always need
to follow the requirement language in Standards documents.

> rushing to call for their update.

I am sorry if desturbed, but I am really interested in NHDP and would
like to make the better use of it. However, I will do your advise and
not rush into the call, but will discuss the idea of the updates on
the list,

I thank you for your comment and advises,

Best Regards

Abdussalam Baryun
==================================================
>>>> On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg <ulrich at
>>>> herberg.name>
>>>> wrote:
>>>>> Dear Chris,
>>>>>
>>>>> that does not provide end-to-end security. Instead, I suggest to
>>>>> submit
>>>>> a
>>>>> However, I believe that it would be beneficial for certain
>>>>> applications
>>>> to
>>>>>> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2
>>>>>> also
>>>> has
>>>>>> TC messages to consider, and they don't satisfy the points noted
>>>>>> above
>>>> (on

---

From: Henning Rogge <[email-masked]>
Date: Fri, 13 Jul 2012 13:44:09 +0200

> to follow the requirement language in Standards documents.

This is the key misconception.

RFC5444 packets MAY contain RFC5444 messages.
RFC5444 messages MUST be contained in RFC5444 packets.

Otherwise, they would not be RFC5444 messages.

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-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 13 Jul 2012 12:18:57 +0000

I don't agree. Note that if all you are running is NHDP, then signing packets is more secure than signing messages, as you get to cover the packet sequence number as well.
What I think is wrong is to suggest that the only correct way to protect NHDP is to sign HELLO messages. Whether by inclusion or external reference, signing packets should be also an option.

I'll take that further to OLSrv2 as well. Now there signing messages vs signing packets has advantages to the former. But signing packets also has advantages of simplicity and covering packet header. It is incidentally not correct to say that signing TC messages provides end to end security. It's actually last-bit-one-from-end to end, and still relies on a form of transitive trust. Packet based signatures rely on a greater degree of transitive trust. There is a difference in threat models and vulnerabilities, and that may matter, but it's not (unfortunately) as simple as one being end to end and thus avoiding transitivity issues.

[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: Thomas Heide Clausen [mailto:[email-masked]]
Sent: 12 July 2012 23:09
To: Ulrich Herberg
Cc: Dearlove, Christopher (UK); manet
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf> on how to deal with suspicious emails.
I agree with Ulrich.

Thomas

On 12 Jul 2012, at 22:54, Ulrich Herberg <[email-masked]<mailto:[email-masked]>> wrote:
The document specifies signing/verifying NHDP messages. RFC5444 packets are not specific to NHDP, and therefore should IMO not be discussed in a document entitled "Using Integrity Check Values and Timestamps For Router Admittance in NHDP". That's why I suggested to handle this in an additional document for RFC5444 packets.

Regards
Ulrich
On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ulrich,

Regards
Abdussalam
=======

On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg <ulrich at herberg.name<http://herberg.name>> wrote:
> <Chris.Dearlove at baesystems.com<http://baesystems.com>> wrote:
>>
>> chris.dearlove at baesystems.com<http://baesystems.com> | http://www.baesystems.com
>>
>> manet at ietf.org<http://ietf.org>

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 13 Jul 2012 14:36:15 +0200

Chris,

I figured that you wouldn't agree.

I agree, of course, with your observation that none of the signature models yields end-to-end security, but I don't think that that's the issue here. 

Personally, I do not see packet ICVs as being appropriate for neither NHDP nor OLSRv2 - at least, not for the uses that I see/have, but I am not saying that they do not exist. I could make an argument that a packet ICV would have to be validated before knowing that a HELLO message was delivered to an NHDP instance, and that the validation might be based on different principles (or, even layers) for packet/messages. 

I see what you say about protecting packet sequence numbers by way of a packet-level ICV, but I would argue that:

	o	As packet sequence numbers are generated "outside" NHDP, and are incremented for all 
		packets (not just those with HELLOs), specifying the validation of a packet-level ICV in NHDP would
		be inappropriate (as in: potentially conflicting with another mechanism)

	o	Whatever mechanism would provide "packet sequence number statistics" to NHDP (such as the
		demultiplexer) would want to be the entity doing that packet-level ICV validation, in part as
		I would _suspect_ that inability to validate a packet-level ICV should cause the whole packet
		with all contained messages to be dropped.

That said, with reference to the I-D, I think I speak for the authors when saying that we're welcoming a suggestion that would address the issue that you raise?

Best,

Thomas

On Jul 13, 2012, at 14:18 , Dearlove, Christopher (UK) wrote:

> [email-masked] | http://www.baesystems.com
> 
> Please see this process on how to deal with suspicious emails.
> 
> I agree with Ulrich. 
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 13 Jul 2012 12:52:18 +0000

This partly depends on what your planned document structure is, Ulrich just mentioned the possibility of a generic 5444 document. I'm actually not sure that wouldn't be more relevant, as it is hard to actually separate these things.

But I think this is jumping in with solutions before considering a threat model. Let's suppose that we have hardware that (a) stores key materials in secure tamperproof storage,  (b) doesn't make mistakes, and (c) we use a signature method that's cryptographically infeasible to break. Then in this case (not uniquely) packet signatures actually provide as much security as message signatures. Of course I can also think of threat models that do favour message signatures. But this is exactly like the choice of signature methods, which is not mandated because different threats require different solutions. The same is true of packet and message signatures. Each (and indeed the third option of both) should be allowed, we should not have a document that prefers one above the other except following a security analysis - which is not on offer.

From: Thomas Heide Clausen [mailto:[email-masked]]
Sent: 13 July 2012 13:36
To: Dearlove, Christopher (UK)
Cc: Ulrich Herberg; manet
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

*** WARNING ***

Best,

Thomas

*** WARNING ***

Thomas

Regards
Ulrich

Regards
Abdussalam
=======

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 13 Jul 2012 09:55:00 -0700

Chris,

On Fri, Jul 13, 2012 at 5:52 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

>  This partly depends on what your planned document structure is, Ulrich
> just mentioned the possibility of a generic 5444 document. I'm actually not
> sure that wouldn't be more relevant, as it is hard to actually separate
> these things.
>

My concern is, if you want to specify packet signing in the NHDP-sec
document, that NHDP itself would never see the packet. The RFC5444
multiplexing would see a HELLO message in the packet and send it to NHDP
(which can use the mechanisms specified in NHDP-sec to reject or accept the
message). I think that a packet signer/verifier is tied to the RFC5444
parser itself, which would accept or reject the whole packet. So in my
view, it would actually be much easier to separate it into an additional
draft, rather than combining it with NHDP.
Moreover, protocols that do not use NHDP but use RFC5444 would probably
like to use packet ICV verification as well, but they don't need all the
NHDP part.

> ****
>
> ** **
>
> But I think this is jumping in with solutions before considering a threat
> model. Let's suppose that we have hardware that (a) stores key materials in
> secure tamperproof storage,  (b) doesn't make mistakes, and (c) we use a
> signature method that's cryptographically infeasible to break. Then in this
> case (not uniquely) packet signatures actually provide as much security as
> message signatures.
>

If you assume a transitive trust model. If a router receives a TC message
(unsigned) in a correctly signed packet, the receiving router can be sure
that the TC has not been modified after transmission by the previous hop.
It has no information what happened before that. But I agree that for
certain deployments that may be enough.

> Of course I can also think of threat models that do favour message
> signatures. But this is exactly like the choice of signature methods, which
> is not mandated because different threats require different solutions.
>

Right. I am absolutely in favor of specifying packet ICV handling. The only
question for me is where to do that.

> The same is true of packet and message signatures. Each (and indeed the
> third option of both) should be allowed, we should not have a document that
> prefers one above the other
>

Correct.

> except following a security analysis - which is not on offer.
>

Yes. There was some emails about the nhdp-sec-threats document by Jiazi
several months ago, but there was not much activity on the mailing list..
Do you think that that document should contain such an analysis?

Best regards
Ulrich

> ****
> ** **
> -- ****
> Christopher Dearlove****
> Tel: +44 1245 242194 |  Fax: +44 1245 242124****
>
> Registered in England & Wales No: 1996687****
>
> ** **
>
> *From:* Thomas Heide Clausen [mailto:[email-masked]]
> *Sent:* 13 July 2012 13:36
> *To:* Dearlove, Christopher (UK)
> *Cc:* Ulrich Herberg; manet
>
> *Subject:* Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt****
>
>  ** **
>
> ** **
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.**
> Please see this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>on how to deal with suspicious emails.
> *****
>
> Chris,****
>
> ** **
>
> I figured that you wouldn't agree.****
>
> ** **
>
> I agree, of course, with your observation that none of the signature
> models yields end-to-end security, but I don't think that that's the issue
> here. ****
>
> ** **
>
> Personally, I do not see packet ICVs as being appropriate for neither NHDP
> nor OLSRv2 - at least, not for the uses that I see/have, but I am not
> saying that they do not exist. I could make an argument that a packet ICV
> would have to be validated before knowing that a HELLO message was
> delivered to an NHDP instance, and that the validation might be based on
> different principles (or, even layers) for packet/messages. ****
>
> ** **
>
> I see what you say about protecting packet sequence numbers by way of a
> packet-level ICV, but I would argue that:****
>
> ** **
>
>             o          As packet sequence numbers are generated "outside"
> NHDP, and are incremented for all ****
>
>                         packets (not just those with HELLOs), specifying
> the validation of a packet-level ICV in NHDP would****
>
>                         be inappropriate (as in: potentially conflicting
> with another mechanism)****
>
> ** **
>
>             o          Whatever mechanism would provide "packet sequence
> number statistics" to NHDP (such as the****
>
>                         demultiplexer) would want to be the entity doing
> that packet-level ICV validation, in part as****
>
>                         I would _suspect_ that inability to validate a
> packet-level ICV should cause the whole packet****
>
>                         with all contained messages to be dropped.****
>
> ** **
>
> That said, with reference to the I-D, I think I speak for the authors when
> saying that we're welcoming a suggestion that would address the issue that
> you raise?****
>
> ** **
>
> Best,****
>
> ** **
>
> Thomas****
>
> ** **
>
> On Jul 13, 2012, at 14:18 , Dearlove, Christopher (UK) wrote:****
>
>
>
> ****
>
> I don't agree. Note that if all you are running is NHDP, then signing
> packets is more secure than signing messages, as you get to cover the
> packet sequence number as well.****
>
> What I think is wrong is to suggest that the only correct way to protect
> NHDP is to sign HELLO messages. Whether by inclusion or external reference,
> signing packets should be also an option.****
>
>  ****
>
> I'll take that further to OLSrv2 as well. Now there signing messages vs
> signing packets has advantages to the former. But signing packets also has
> advantages of simplicity and covering packet header. It is incidentally not
> correct to say that signing TC messages provides end to end security. It's
> actually last-bit-one-from-end to end, and still relies on a form of
> transitive trust. Packet based signatures rely on a greater degree of
> transitive trust. There is a difference in threat models and
> vulnerabilities, and that may matter, but it's not (unfortunately) as
> simple as one being end to end and thus avoiding transitivity issues.****
>
>  ****
>
> --****
>
> Christopher Dearlove****
>
> Tel: +44 1245 242194 |  Fax: +44 1245 242124****
>
> Registered in England & Wales No: 1996687****
>
>  ****
>
> *From:* Thomas Heide Clausen [mailto:[email-masked]]
> *Sent:* 12 July 2012 23:09
> *To:* Ulrich Herberg
> *Cc:* Dearlove, Christopher (UK); manet
> *Subject:* Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt****
>
>  ****
>
>  ****
>
> **** WARNING ********
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.**
> Please see this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>
>  on how to deal with suspicious emails.*****
>
> I agree with Ulrich. ****
>
>  ****
>
> Note that this is all about "messages" in as much as NHDP is concerned.***
> *
>
>  ****
>
> 1) NHDP specifies something akin to "an implementation may recognize
> additional reasons for considering a HELLO message invalid for processing";
> this I-D specifies such an additional reason, by way of a TLV in HELLO
> messages.****
>
>  ****
>
> 2) NHDP "owns" HELLO messages, and therefore gets first dip on an incoming
> HELLO message post-demultiplication. Including the ICV Message TLV in HELLO
> messages therefore makes sense.****
>
>  ****
>
> Ad 1), I note that this I-D is intended to exactly plug in at that place
> in 6130.****
>
>  ****
>
> Thomas****
>
>  ****
>
> -- ****
>
> Thomas Heide Clausen****
>
> http://www.thomasclausen.org/****
>
>
>
>
> ****
>
> "Any simple problem can be made insoluble if enough meetings are held to**
> **
>
>  discuss it."****
>
>    -- Mitchell's Law of Committees****
>
>  ****
>
>
> On 12 Jul 2012, at 22:54, Ulrich Herberg <[email-masked]> wrote:****
>
>  The document specifies signing/verifying NHDP messages. RFC5444 packets
> are not specific to NHDP, and therefore should IMO not be discussed in a
> Ulrich****
> [email-masked]> wrote:****
>
> Hi Ulrich,
>
> =======****
> > On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK)****
>
> >> Tel: +44 1245 242194 |  Fax: +44 1245 242124****
>
> >> chris.dearlove at baesystems.com | http://www.baesystems.com****
>
> >>
> >> manet mailing list****
> >> manet at ietf.org****
> >****
>  ****
> https://www.ietf.org/mailman/listinfo/manet****
>
> https://www.ietf.org/mailman/listinfo/manet****
>
> ** **
>

---

From: Teco Boot <[email-masked]>
Date: Tue, 31 Jul 2012 08:00:29 +0200

I provided feedback to authors before: I strongly prefer having a document on MANET packet security before we go into further details, such as manet-nhdp-sec. Another concern is that NHDP messages are extended by other protocols.

Teco

Op 13 jul. 2012, om 18:55 heeft Ulrich Herberg het volgende geschreven:

> Chris,
> 
> On Fri, Jul 13, 2012 at 5:52 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:
> My concern is, if you want to specify packet signing in the NHDP-sec document, that NHDP itself would never see the packet. The RFC5444 multiplexing would see a HELLO message in the packet and send it to NHDP (which can use the mechanisms specified in NHDP-sec to reject or accept the message). I think that a packet signer/verifier is tied to the RFC5444 parser itself, which would accept or reject the whole packet. So in my view, it would actually be much easier to separate it into an additional draft, rather than combining it with NHDP. 
> Moreover, protocols that do not use NHDP but use RFC5444 would probably like to use packet ICV verification as well, but they don't need all the NHDP part.
> 
>  
> 
>  
> 
> But I think this is jumping in with solutions before considering a threat model. Let's suppose that we have hardware that (a) stores key materials in secure tamperproof storage,  (b) doesn't make mistakes, and (c) we use a signature method that's cryptographically infeasible to break. Then in this case (not uniquely) packet signatures actually provide as much security as message signatures.
> 
> 
> If you assume a transitive trust model. If a router receives a TC message (unsigned) in a correctly signed packet, the receiving router can be sure that the TC has not been modified after transmission by the previous hop. It has no information what happened before that. But I agree that for certain deployments that may be enough.
>  
> Of course I can also think of threat models that do favour message signatures. But this is exactly like the choice of signature methods, which is not mandated because different threats require different solutions.
> 
> 
> Right. I am absolutely in favor of specifying packet ICV handling. The only question for me is where to do that.
>  
> The same is true of packet and message signatures. Each (and indeed the third option of both) should be allowed, we should not have a document that prefers one above the other
> 
> 
> Correct.
>  
> Yes. There was some emails about the nhdp-sec-threats document by Jiazi several months ago, but there was not much activity on the mailing list.. Do you think that that document should contain such an analysis?
> 
> Best regards
> Ulrich
>  
> 
>  
> 
> --
> 
> Christopher Dearlove
>

---

From: "Rick Taylor" <[email-masked]>
Date: Tue, 31 Jul 2012 10:49:25 +0100

For those of us who missed the relevant parts of the mailing discussion,
what was the consensus on general ICV verification for RFC5444 packets?

I am with Teco, a separate manet-rfc5444-sec document would be very
useful.

Rick Taylor

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Teco Boot
Sent: 31 July 2012 07:00
To: Ulrich Herberg
Cc: Dearlove, Christopher (UK); manet; Thomas Heide Clausen
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

I provided feedback to authors before: I strongly prefer having a
document on MANET packet security before we go into further details,
such as manet-nhdp-sec. Another concern is that NHDP messages are
extended by other protocols.

Teco

Chris,

On Fri, Jul 13, 2012 at 5:52 AM, Dearlove, Christopher (UK)
<[email-masked]> wrote:

This partly depends on what your planned document structure is, Ulrich
just mentioned the possibility of a generic 5444 document. I'm actually
not sure that wouldn't be more relevant, as it is hard to actually
separate these things.

My concern is, if you want to specify packet signing in the NHDP-sec
document, that NHDP itself would never see the packet. The RFC5444
multiplexing would see a HELLO message in the packet and send it to NHDP
(which can use the mechanisms specified in NHDP-sec to reject or accept
the message). I think that a packet signer/verifier is tied to the
RFC5444 parser itself, which would accept or reject the whole packet. So
in my view, it would actually be much easier to separate it into an
additional draft, rather than combining it with NHDP. 
Moreover, protocols that do not use NHDP but use RFC5444 would probably
like to use packet ICV verification as well, but they don't need all the
NHDP part.

	But I think this is jumping in with solutions before considering
a threat model. Let's suppose that we have hardware that (a) stores key
materials in secure tamperproof storage,  (b) doesn't make mistakes, and
(c) we use a signature method that's cryptographically infeasible to
break. Then in this case (not uniquely) packet signatures actually
provide as much security as message signatures. 

If you assume a transitive trust model. If a router receives a TC
message (unsigned) in a correctly signed packet, the receiving router
can be sure that the TC has not been modified after transmission by the
previous hop. It has no information what happened before that. But I
agree that for certain deployments that may be enough.

	Of course I can also think of threat models that do favour
message signatures. But this is exactly like the choice of signature
methods, which is not mandated because different threats require
different solutions. 

Right. I am absolutely in favor of specifying packet ICV handling. The
only question for me is where to do that.

	The same is true of packet and message signatures. Each (and
indeed the third option of both) should be allowed, we should not have a
document that prefers one above the other

Correct.

Yes. There was some emails about the nhdp-sec-threats document by Jiazi
several months ago, but there was not much activity on the mailing
list.. Do you think that that document should contain such an analysis?

Best regards
Ulrich

	-- 

	Christopher Dearlove

	Senior Principal Engineer, Communications Group
	Communications, Networks and Image Analysis Capability
	BAE Systems Advanced Technology Centre
	West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
	Tel: +44 1245 242194 <tel:%2B44%201245%20242194>  |  Fax: +44
1245 242124 <tel:%2B44%201245%20242124> 

	[email-masked]
<mailto:[email-masked]>  | http://www.baesystems.com
<http://www.baesystems.com/> 
	
	BAE Systems (Operations) Limited
	Registered Office: Warwick House, PO Box 87, Farnborough
Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
	Registered in England & Wales No: 1996687

	Subject: Re: [manet] I-D Action:
draft-ietf-manet-nhdp-sec-02.txt

	*** WARNING ***

	This message originates from outside our organisation, either
from an external partner or the internet.
	Keep this in mind if you answer this message.
	Please see this process
<http://intranet.ent.baesystems.com/howwework/security/spotlights/Docume
nts/Dealing%20With%20Suspicious%20Emails.pdf>  on how to deal with
suspicious emails.

	Chris,

	I agree, of course, with your observation that none of the
signature models yields end-to-end security, but I don't think that
that's the issue here. 

	Personally, I do not see packet ICVs as being appropriate for
neither NHDP nor OLSRv2 - at least, not for the uses that I see/have,
but I am not saying that they do not exist. I could make an argument
that a packet ICV would have to be validated before knowing that a HELLO
message was delivered to an NHDP instance, and that the validation might
be based on different principles (or, even layers) for packet/messages. 

	I see what you say about protecting packet sequence numbers by
way of a packet-level ICV, but I would argue that:

	            o          As packet sequence numbers are generated
"outside" NHDP, and are incremented for all 

	                        packets (not just those with HELLOs),
specifying the validation of a packet-level ICV in NHDP would

	                        be inappropriate (as in: potentially
conflicting with another mechanism)

	            o          Whatever mechanism would provide "packet
sequence number statistics" to NHDP (such as the

	                        demultiplexer) would want to be the
entity doing that packet-level ICV validation, in part as

	                        I would _suspect_ that inability to
validate a packet-level ICV should cause the whole packet

	                        with all contained messages to be
dropped.

	That said, with reference to the I-D, I think I speak for the
authors when saying that we're welcoming a suggestion that would address
the issue that you raise?

	Best,

	Thomas

	I don't agree. Note that if all you are running is NHDP, then
signing packets is more secure than signing messages, as you get to
cover the packet sequence number as well.

	What I think is wrong is to suggest that the only correct way to
protect NHDP is to sign HELLO messages. Whether by inclusion or external
reference, signing packets should be also an option.

	I'll take that further to OLSrv2 as well. Now there signing
messages vs signing packets has advantages to the former. But signing
packets also has advantages of simplicity and covering packet header. It
is incidentally not correct to say that signing TC messages provides end
to end security. It's actually last-bit-one-from-end to end, and still
relies on a form of transitive trust. Packet based signatures rely on a
greater degree of transitive trust. There is a difference in threat
models and vulnerabilities, and that may matter, but it's not
(unfortunately) as simple as one being end to end and thus avoiding
transitivity issues.

	--

	Christopher Dearlove

	Senior Principal Engineer, Communications Group
	Communications, Networks and Image Analysis Capability
	BAE Systems Advanced Technology Centre
	West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
	Tel: +44 1245 242194 <tel:%2B44%201245%20242194>  |  Fax: +44
1245 242124 <tel:%2B44%201245%20242124> 

	[email-masked]
<mailto:[email-masked]>  | http://www.baesystems.com
<http://www.baesystems.com/> 
	
	BAE Systems (Operations) Limited
	Registered Office: Warwick House, PO Box 87, Farnborough
Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
	Registered in England & Wales No: 1996687

	From: Thomas Heide Clausen [mailto:[email-masked]] 
	Sent: 12 July 2012 23:09
	To: Ulrich Herberg
	Cc: Dearlove, Christopher (UK); manet
	Subject: Re: [manet] I-D Action:
draft-ietf-manet-nhdp-sec-02.txt

	*** WARNING ***

	This message originates from outside our organisation, either
from an external partner or the internet.
	Keep this in mind if you answer this message.
	Please see this process
<http://intranet.ent.baesystems.com/howwework/security/spotlights/Docume
nts/Dealing%20With%20Suspicious%20Emails.pdf>  on how to deal with
suspicious emails.

	I agree with Ulrich. 

	Note that this is all about "messages" in as much as NHDP is
concerned.

	1) NHDP specifies something akin to "an implementation may
recognize additional reasons for considering a HELLO message invalid for
processing"; this I-D specifies such an additional reason, by way of a
TLV in HELLO messages.

	2) NHDP "owns" HELLO messages, and therefore gets first dip on
an incoming HELLO message post-demultiplication. Including the ICV
Message TLV in HELLO messages therefore makes sense.

	Ad 1), I note that this I-D is intended to exactly plug in at
that place in 6130.

	Thomas

	-- 

	Thomas Heide Clausen

	

	"Any simple problem can be made insoluble if enough meetings are
held to

	 discuss it."

	
	On 12 Jul 2012, at 22:54, Ulrich Herberg <[email-masked]>
wrote:

		The document specifies signing/verifying NHDP messages.
RFC5444 packets are not specific to NHDP, and therefore should IMO not
be discussed in a document entitled "Using Integrity Check Values and
Timestamps For Router Admittance in NHDP". That's why I suggested to
handle this in an additional document for RFC5444 packets.
		
		Regards
		Ulrich

		On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun
<[email-masked]> wrote:

		Hi Ulrich,
		
		I am not expert in security issues, but IMHO, I agree
with Chris to
		recommend to include in draft-02 both securing messages
and packets
		(in general for packets), so the document should specify
NHDP messages
		and MANET packets [AB]. The reasons are first, because
NHDP is a MANET
		Interface protocol between neighbor routers. secondly it
uses RFC5444
		format that the future MANET routers will use. Third,
NHDP uses
		RFC5444 which was specified for information exchange
between MANET
		routers.
		
		[AB]
http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt
		
		Regards
		Abdussalam
		=======

		On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg <ulrich

		> <Chris.Dearlove at baesystems.com
<http://baesystems.com/> > wrote:
		>> Tel: +44 1245 242194 <tel:%2B44%201245%20242194>  |
Fax: +44 1245 242124 <tel:%2B44%201245%20242124> 

		>> chris.dearlove at baesystems.com
<http://baesystems.com/>  | http://www.baesystems.com
<http://www.baesystems.com/> 

		>> manet at ietf.org <http://ietf.org/>