Subject: [manet] Node subversion [Was: AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02]

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Apr 2013 21:26:19 +0100

Hi, 

I think that some of these comments relate to subversion of nodes. This topic
often comes up in discussion of routing protocol security (although strangely
not in the discussion of application level security - maybe they have more
security clue than we do!)

There are two types of subversion:
1. Installing new software on existing hardware
2. Replacing in-the-field hardware

The second of these is usually protectable by security associations since
physically replacing one node will not replicate the security credentials and so
the node will not be able to participate in the security relationships necessary
for the protocol.

The first is usually regarded as faintly amusing! The idea that your main
problem with a subverted node is harm to the routing infrastructure is wrong. If
a node that routes packets has been subverted then *anything* may happen in your
network. Protection against software subversion varies from nodes that
physically self-destruct if tampered with, to nodes that require security checks
before software can be modified.

But, in both cases, there is nothing that the routing protocol can do. If a
routing peer has the security credentials but decides to act badly, so be it!
(There were a number of attempts to characterise the on-wire behavior of
bad-actors, but - perhaps, of course - such attempts are self-defeating).

Another view of a physical attack is one that degrades the performance of a node
or link, perhaps through radio interference. I would argue that the only thing
that a routing protocol can do in this case is to observe the degraded
performance and to adjust metrics accordingly. However, I would also say that
this is not actually the responsibility of the routing protocol, but of the
management system in the network.

Thus, I would say that physical attacks on notes are out of scope.

Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ulrich Herberg
> Sent: 09 April 2013 20:23
> To: Abdussalam Baryun
> Cc: draft-ietf-manet-nhdp-sec-threats; manet
> Subject: Re: [manet] AB#3 Comments for WGLC draft-ietf-manet-nhdp-sec-
> threats-02
> 
> AB,
> 
> On Tue, Apr 9, 2013 at 8:20 AM, Abdussalam Baryun
> <[email-masked]> wrote:
> >[...]
> >
> > As a respond to my first to AB#1, AB#2 messages, and to [1] message.
> > The NHDP threat related to physical attacks were ignored by the I-D.
> > The I-D describes non-physical attacks in section 4 but does not for
> > physical attacks, which has threats. The neighbors may get both
> > together non-physical and physical, as if two or more neighbors are in
> > radio range coverage. I don't think this was introduced in the I-D,
> > which I hope editors follow.
> >
> > Military Scenario Example:
> >
> > Identity or link spoof can occur in other scenarios mentioned in I-D
> > (i.e. spoofed the address while attacker is out of that neighbor radio
> > coverage, as in section 4.4.1 Fig.1 ). Malicious router (M) may not
> > identity-spoof attack only after the neighbor is physically attacked,
> > then M takes over that neighbor identity and responsibilities, even if
> > they were in same radio coverage. This is a threat because these
> > neighbors are in range of each other, and the node disapers from the
> > network. The I-D does not consider the situation where the neighbor
> > disapears from the network but replaced by an attacker M. This example
> > scenario assumes that neighbors are in range but not aware of the
> > physical attack, and the malicious node is aware.
> >
> > AB> Please editors of the I-D, consider in section 4.4.1 to add the
> > threat described, if not clear for you, please reply,
> 
> What do you mean by physical attacks? Tampering with the hardware of
> the router running NHDP? I think that this is not the scope of the
> draft (and also irrelevant); the draft purely looks at security
> threats of misconfigured or malicious NHDP routers that misbehave when
> using NHDP. It could be that such a router has been hacked via an
> implementation flaw or physically exchanged some parts of the
> hardware; that does not matter. For the case you describe, how does it
> matter if the router disappears and comes back later? (whether or not
> it is physically exchanged, or just stopped sending HELLOs for a
> while).
> 
> Regards
> Ulrich
> 
> 
> 
> 
> > [...]
> >
> > References:
> > [1] The message below, by Dearlove, C., (2013), IETF MANET WG
> > Discussion list, Re: [manet] AB#1 Comments for WGLC
> > draft-ietf-manet-nhdp-sec-threats-02, 09.04.2013.
> >
> >
> > On 4/9/13, Dearlove, Christopher (UK) <[email-masked]>
> wrote:
> >> I'm neither recommending that a reference is included or excluded, I'm just
> >> providing here where one good source of definitions. Whether to reference
it
> >> is a judgement call as to what is considered widely known, and what isn't.
> >>
> >> But that definition is not limited to physical attack.
> >>
> >> --
> >> 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
> >> [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
> >>
> >>
> >> -----Original Message-----
> >> From: Abdussalam Baryun [mailto:[email-masked]]
> >> Sent: 09 April 2013 12:44
> >> To: Dearlove, Christopher (UK)
> >> Cc: manet
> >> Subject: Re: [manet] AB#1 Comments for WGLC
> >> draft-ietf-manet-nhdp-sec-threats-02
> >>
> >> ----------------------! WARNING ! ----------------------
> >> This message originates from outside our organisation,
> >> either from an external partner or from the internet.
> >> Keep this in mind if you answer this message.
> >> Follow the 'Report Suspicious Emails' link on IT matters
> >> for instructions on reporting suspicious email messages.
> >> --------------------------------------------------------
> >>
> >> Hi Chris,
> >>
> >> The I-D seems not to define physical attacks (my understanding), which
> >> I was not sure of but [1] (mentioned in first AB#1 message) did
> >> include, but I think your input is prefered to include in the I-D or
> >> used,
> >>
> >> AB
> >>
> >> On 4/9/13, Dearlove, Christopher (UK) <[email-masked]>
> >> wrote:
> >>> AB> you don't define *Threat*, and *Attack*
> >>>
> >>> Personally, I would start with ISO 27000 which has:
> >>>
> >>> =====
> >>> 2.45
> >>> threat
> >>> potential cause of an unwanted incident, which may result in harm to a
> >>> system or organization
> >>>
> >>> 2.4
> >>> attack
> >>> attempt to destroy, expose, alter, disable, steal or gain unauthorized
> >>> access to or make unauthorized use of
> >>> an asset (2.3)
> >>>
> >>> 2.3
> >>> asset
> >>> anything that has value to the organization
> >>> NOTE There are many types of assets, including:
> >>> a) information (2.18);
> >>> b) software, such as a computer program;
> >>> c) physical, such as computer;
> >>> d) services;
> >>> e) people, and their qualifications, skills, and experience; and
> >>> f) intangibles, such as reputation and image.
> >>>
> >>> 2.18
> >>> information asset
> >>> knowledge or data that has value to the organization
> >>> =====
> >>>
> >>> (The rules are that you may substitute in the definition, so attack may
> >>> be
> >>> parsed as "attempt to destroy, expose, alter, disable, steal or gain
> >>> unauthorized access to or make unauthorized use of anything that has
> >>> value
> >>> to the organization".)
> >>>
> >>> [There is also an overlapping set of definitions in ISO 27032, but 27000
> >>> is
> >>> more relevant here.]
> >>>
> >>> I don't know if there are any RFCs that reference ISO 27000.
> >>>
> >>> --
> >>> 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
> >>> [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
> >>>
> >>>
> >>>
> **************************************************************
> ******
> >>> 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.
> >>>
> **************************************************************
> ******
> >>>
> >>>
> >>
> >>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 9 Apr 2013 22:37:49 +0200

Hi Adrian,

I asked the editors to define *attack* but they don't want to, so if
it was out of the scope, So I need editors to make it clearly defined
in the document, IMHO, excluding that attack or including SHOULD be
informed in this informational I-D

AB

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Apr 2013 22:19:37 +0100

This discussion is getting a bit circuitous!

However, if you want IETF definitions of security terms, please read RFC 4949.
And please direct any questions on the contents to the Security Area and not to
this list!

Authors of draft-ietf-manet-nhdp-sec-threats COULD ;-) add an informative
reference to 4949.

Adrian

> Sent: 09 April 2013 21:38
> To: [email-masked]
> Cc: Ulrich Herberg; draft-ietf-manet-nhdp-sec-threats; manet
> Subject: Re: Node subversion [Was: AB#3 Comments for WGLC draft-ietf-manet-
> nhdp-sec-threats-02]
> 
> Hi Adrian,
>

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 9 Apr 2013 14:38:13 -0700

On Tue, Apr 9, 2013 at 2:19 PM, Adrian Farrel <[email-masked]> wrote:
[...]
> Authors of draft-ietf-manet-nhdp-sec-threats COULD ;-) add an informative

That is POSSIBLE. We MIGHT add the reference ;-)

Seriously, it would not hurt adding this informative reference, so
it's fine for me to add it.

Ulrich

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 10 Apr 2013 03:00:22 +0000

…then PLEASE do… ;-) 

Regards,
Stan

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 9 Apr 2013 21:17:56 -0700

Can you define the word "PLEASE"? It's not known 6919 terminology. Or is
there an errata that I have not seen?

And I'd like to correct myself... I said "it would not hurt adding..."; of
course I meant "it WOULD PROBABLY not hurt adding..."

Ulrich

On Tuesday, April 9, 2013, Stan Ratliff (sratliff) wrote:

> >>>> I think that some of these comments relate to subversion of nodes.
> This
> >>>> topic
> >>>> physically replacing one node will not replicate the security
> credentials
> >>>> and so
> >>>> a node that routes packets has been subverted then *anything* may
> happen in
> >>>> your
> >>>> physically self-destruct if tampered with, to nodes that require
> security
> >>>> checks
> >>>> routing peer has the security credentials but decides to act badly,
> so be
> >>>> it!
> >>>> Another view of a physical attack is one that degrades the
> performance of a
> >>>> node
> >>>> or link, perhaps through radio interference. I would argue that the
> only
> >>>> thing
> >>>> performance and to adjust metrics accordingly. However, I would also
> say
> >>>> that
> >>>>> From: [email-masked]

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 10 Apr 2013 10:57:57 +0100

Message Author: Abdussalam Baryun
Dated: 10.04.2013
Classified: Informational

Hi Adrian,
AD of Routing Area

I did not have any intention to make myself get-knowledge, I know the
definition and don't need to ask other WGs, the reviewer job is to ask the
authors not others. The reviewer's job is not to comment on things for his
knowledge it is the knowledge of other readers in future. The reviewer is
an owner of the document under review because he is a participant in MANET
WG, hope that IETF editors remember that.

Please note that the *attack* was not defined, and the reviewer knows what
it means but there was confusion in the review process (each reviewer has
his own procedure that I hope IETF respects). The RFC6130 is the standard
under study by the I-D of NHDP threats, therefore the reviewer needs to
have consistency between both documents.

Reviewer got into the below process:
============================
1) Read both documents RFC6130 and the I-D.

2) The RFC6130 mentions wireless sensors as possible deployment, the
reviewer needed to read LLN threats for consistency, because many sensors
lossy.

3) The document of LLN threat analysis was read by the reviewer.

4) the LLN document defines *attack* and mentions physical attacks as
threats (please note that the reviewer did not bring up new idea of attacks
it was all in IETF documents), so reviewer wants consistency.

5) the reviewer wants to know why the I-D thinks that the threats are
common, but it does not refer to the LLN threats even though the RFC6130
mentions sensors.

6) Reveiwer did not ignore the input of MANET WG discussion related to
lossy nodes. One participant mentions that MANET can be lossy if it gets
physical attacks. The MANET WG does not define this as out of scope. The
reviewer has right to ask the authors as the document is MANET document and
the MANET WG does not define excluding such attack.

7) The comments were published, and requesting editors to define *attack*
and *threats*, and if possible to refer to the LLN threat document (
reviewer does never ignore other WG documents because in same Working Area).

8) Editors refused to define important words, refused to refer to any. Only
after you send your comments the editors followed. The reveiwer wanted the
better for the Internet Community and responded. I hope IETF don't
misunderstand reviewer's process.

9) Reviewer feels discouraged, and not understand reasons of such reaction
to volunteering efforts and no editing process working in parallel with
other efforts.

I may send another comment for the WGs, regarding this issue, for progress.

Please note that the reviewer is doing a good job if you compare how many
people reviewed the I-D. The reviewer is never reason to recycle, it is
ignoring issues of other I-Ds that make things recycles in any WG in any
Area.

Best Regards
Abdussalam Baryun

This message is a reply to clarify the reviewer's intention. This
On Tue, Apr 9, 2013 at 10:19 PM, Adrian Farrel <[email-masked]> wrote:

> > > routing peer has the security credentials but decides to act badly, so
> be
> > > it!
> > > Another view of a physical attack is one that degrades the performance
> of a
> > > node
> > >> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > >> Ulrich Herberg
> > >> >> I'm neither recommending that a reference is included or excluded,
> I'm
> > >> >> just
> > >> >>> potential cause of an unwanted incident, which may result in harm
> to
> > >> >>> a
> > >> >>> system or organization
> > >> >>>
> > >> >>> 2.4
> > >> >>> attack
> > >> >>> (The rules are that you may substitute in the definition, so
> attack
> > >> >>> may
> > >> >>> be

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 10 Apr 2013 11:59:23 +0100

Hi,

> I did not have any intention to make myself get-knowledge, I know
> the definition and don't need to ask other WGs, the reviewer job is
> to ask the authors not others. The reviewer's job is not to comment
> on things for his knowledge it is the knowledge of other readers in
> future. The reviewer is an owner of the document under review
> because he is a participant in MANET WG, hope that IETF editors
> remember that.

And in view of all this it is your job to supply suggested text, not to ask
questions.
This is not a quiz or an academic review.
We are trying to write a document together.
 
> Please note that the *attack* was not defined

And we have agreed that a reference to 4949 will be added. So perhaps we can
close this topic and get on with our lives?

> and the reviewer knows what it means but there was confusion
> in the review process (each reviewer has his own procedure that
> I hope IETF respects). 

i very much doubt that the IETF (singular or corporate) cares one hoot for what
process anyone uses when reviewing a document.

> The RFC6130 is the standard under study by the I-D of NHDP threats,
> therefore the reviewer needs to have consistency between both
> documents.
> 

[snip]
 
> 4) the LLN document defines *attack*

No it doesn't! It references and quotes from RFC 4949.

> mentions physical attacks as threats (please note that the
> reviewer did not bring up new idea of attacks it was all in
> IETF documents), so reviewer wants consistency.

The LLN document looks at a broader scope of attacks on LLNs.
This document looks at the threats for specific routing protocols. That is a
difference that cannot be reconciled except by expanding the scope of this
document.

I assume you would like that scope expanded.
I do not see any support for this position within the working group.
You might consider writing your own draft on the wider security issues for
MANETs if you believe that this needs to be addressed. I cannot guarantee that
the WG will be interested or supportive, but you can publish your work as a
white paper or through the ISE.

> 5) the reviewer wants to know why the I-D thinks that the threats
> are common, but it does not refer to the LLN threats even though
> the RFC6130 mentions sensors.

I understand that there are issues of English usage. English is not your native
language. It is also not the native language of the document editor.

"Common" is perhaps not the perfect word. You didn't make an alternative
suggestion, but I suspect and alternative would have be "the main". However, I
don't have an issue with the use of the word, and I am a pedant.

> 6) Reveiwer did not ignore the input of MANET WG discussion
> related to lossy nodes. One participant mentions that MANET 
> can be lossy if it gets physical attacks. The MANET WG does not
> define this as out of scope. 

But surely you have misunderstood! The fact a physical attack causes a link to
become (more) lossy does not make the attack within scope for the specific
protocols considered by this document because those protocols already handle
lossy links. So, as my email said, there is nothing that needs to be done or
said for this type of attack.

> The reviewer has right to ask the
> authors as the document is MANET document and the MANET
> WG does not define excluding such attack.

Asking questions is not the same as asking them to do things. If you want
material included in the document, you have to write it yourself.
 
> 7) The comments were published, and requesting editors to define
> *attack* and *threats*

Haven't we already covered that several times, now. A reference to 4949 is being
included. Nothing more needs to be said on this point.

> and if possible to refer to the LLN threat document

That has been discussed. No-one else has said on the list that they consider
this a good idea, and several have said they think it a poor idea. I believe
that closes the issue.

> 8) Editors refused to define important words, refused to refer to 
> any. Only after you send your comments the editors followed. 

I didn't see a refusal. I did see discussion about maybe referencing an ISO
document. 
I didn't see any recommendation for a reference or text from you.
The editors may have followed my comment because I made a concrete proposal for
a specific change.

> 9) Reviewer feels discouraged, and not understand reasons of such
> reaction to volunteering efforts and no editing process working in 
> parallel with other efforts.

I am sure everyone feels very sad that you feel discouraged. the answer is not
to increase your volume, but to increase your quality.

> I may send another comment for the WGs, regarding this issue, 

I, for one, would appreciate it if you throttled back on your comments and
focused on making positive contributions. Reviews that just point out
deficiencies are not very constructive to the IETF process - you need to supply
solutions, not problems. And discussions of process, how things happened, or who
said what, are getting seriously disruptive. I really think they need to stop
being posted to the MANET list. I cannot believe that the majority of the
working group is interested, and they are very clearly not in scope.
 
Thanks,
Adrian