Subject: Re: [Roll] [roll] #124: draft-ietf-roll-security-threats-01.txt --- Include further explanation

From: "roll issue tracker" <[email-masked]>
Date: Mon, 21 Oct 2013 01:40:22 -0000

#124: draft-ietf-roll-security-threats-01.txt --- Include further explanation

Comment (by [email-masked]):

 {{{
 s3.3: Highly directional traffic: Are you trying to say that the LBRs are
 higher valued targets and warrant something different than the regular
 nodes?-- BY ST
 }}}
 LRBs and low-ranked nodes are higher value targets, but predicting which
 nodes (in an inventory
 of thousands) is probably pretty difficult, so having good security
 everywhere is easier.  Further, if low-rank nodes are easily identified,
 then they are more easily destroyed, leaving a lower rank (and if we
 differentiated, less secure) node to fill in.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  [email-masked]          |  [email-masked]
     Type:  defect                   |      Status:  new
 Priority:  major                    |   Milestone:
Component:  security-threats         |     Version:
 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:3>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 21 Oct 2013 02:03:55 -0000

section 8.2.4 has been changed to list the countermeasure that RPL has to
 replays.

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:4>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 21 Oct 2013 02:30:11 -0000

section 5.3.1/8.3.1: rewrote this section with specific reference to RPL
 mechanisms.

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:5>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 21 Oct 2013 02:43:18 -0000

section 5.3.4/8.3.4: removed geographic information is ideal, as it is
 seldom trustworthy, and may not, as mentioned in the comment, not even be
 desireable (ethernet faster than wireless).

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:6>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 21 Oct 2013 02:50:57 -0000

5.3.5/8.3.5: I agree: a stable wormhole that does not lead to cuthulu is a
 feature... it is the instability that could be a problem, and RPL has
 hystersis (MRHOF) to deal with this.

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:7>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 21 Oct 2013 02:53:58 -0000

Geopriv/RFC3693 reference removed.

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:8>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 21 Oct 2013 03:14:44 -0000

Section 6.2/9.2: removed suggestion about transitive trust.  Logging is a
 major can of worms, probably requiring another WG document with a MIB!

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:9>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 21 Oct 2013 03:19:59 -0000

section 6.4/9.4: is stuff that seems to be left over from some author of
 this document thinking that this was requirements for 6550, rather than
 analysis of mechanisms available in 6550.

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/124#comment:10>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 21 Oct 2013 03:21:43 -0000

Comment (by [email-masked]):

 >
 > === Section 6.5.1[[BR]]
 > *This draft boils down to this paragraph if I'm not mistaken:
 >
 >    A ROLL protocol MUST be made flexible by a design that offers the
 >    configuration facility so that the user (network administrator) can
 >    choose the security settings that match the application's needs.
 >    Furthermore, in the case of LLNs, that flexibility SHOULD extend to
 >    allowing the routing protocol security requirements to be met by
 >    measures applied at different protocol layers, provided the
 >    identified requirements are collectively met.
 >
 > I'm absolutely fine with the first sentence.  I'm even okay with the
 second
 > sentence it gets done at the application layer all the time, but at the
 > application layer they can all point to something that's all specified
 up and
 > has MTI etc (think TLS).  If we end up doing that here then something
 similar
 > needs to end up happening.  If use cases are so broad that they can't
 possibly
 > pick an underlying security mechanism then you need to try again but
 with a
 > smaller net. -- by ST

 Needs further discussion over beer.

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/124#comment:11>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 21 Oct 2013 03:22:05 -0000

Changes (by [email-masked]):

 * owner:  [email-masked] => [email-masked]
 * status:  new => assigned

-- 
---------------------------------------+-------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect                     |      Status:  assigned
 Priority:  major                      |   Milestone:
Component:  security-threats           |     Version:
 Severity:  Active WG Document         |  Resolution:
 Keywords:                             |
---------------------------------------+-------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/124#comment:12>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 21 Oct 2013 03:27:55 -0000

* status:  assigned => closed
 * resolution:   => fixed

Comment:

 Ticket #133 opened with last bit.

-- 
---------------------------------------+-------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect                     |      Status:  closed
 Priority:  major                      |   Milestone:
Component:  security-threats           |     Version:
 Severity:  Active WG Document         |  Resolution:  fixed
 Keywords:                             |
---------------------------------------+-------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/124#comment:13>
roll <http://tools.ietf.org/wg/roll/>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 21 Oct 2013 19:34:07 +0200

Dear ROLLers,

We have just submitted draft-roux-roll-mpl-eval-00 about evaluation 
results of MPL, using an in-house simulator.

draft-roux-roll-mpl-eval-00
"Preliminary results about MPL performance evaluation"
Pierre Roux <[email-masked]>
Alexandru Petrescu <[email-masked]>
Mounir Kellil <[email-masked]>

http://tools.ietf.org/html/draft-roux-roll-mpl-eval-00

Please comment.

Yours,

Alex, with co-authors.