Re: [Roll] Roman Danyliw's Discuss on draft-ietf-roll-useofrplinfo-25: (with DISCUSS and COMMENT)

[Ines Robles <[e-mail]>]

Hello Roman,

Many Thanks for your review. We have submitted a new version with
corrections. Please find answers in-line.

On Tue, Apr 30, 2019 at 11:24 PM Roman Danyliw via Datatracker <
[e-mail]> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-roll-useofrplinfo-25: Discuss
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Per Section 11:
>    [RFC2473] suggests that tunnel entry and exit points can be secured,
>    via the "Use IPsec".  The suggested solution has all the problems
>    that [RFC5406] goes into.  In an LLN such a solution would degenerate
>    into every node having a tunnel with every other node.  It would
>    provide a small amount of origin address authentication at a very
>    high cost; doing BCP38 at every node (linking layer-3 addresses to
>    layer-2 addresses, and to already present layer-2 cryptographic
>    mechanisms) would be cheaper should RPL be run in an environment
>    where hostile nodes are likely to be a part of the LLN.
>
> ** I'm having trouble understanding what recommendation this text was
> making.
> The first sentence seems to suggest IPSec, the second sentence seems to
> discount that advice; and the third seems to suggest BCP38 as an
> alternative.
> Could you please clarify.
>
> ** Please be explicit on which challenges in RFC5406 are being cited (e.g.,
> which sections)
>

<author> we have clarified the text. “Use IPsec” is never a useful
statement, which is the point of RFC5406. Using IPsec to secure these IPIP
tunnels would not work.


New Text: Whenever IPv6-in-IPv6 headers are being proposed, there is a
concern

  about creating security issues.  In the security section of

  [RFC2473 <https://tools.ietf.org/html/rfc2473>], it was suggested that
tunnel entry and exit points can be

  secured, via "Use IPsec".  This recommendation is not practical for

  RPL networks.  [RFC5406 <https://tools.ietf.org/html/rfc5406>] goes into
some detail on what additional

  details would be needed in order to "Use IPsec".  Use of ESP would

  prevent RFC8183 <https://tools.ietf.org/html/rfc8183> compression
(compression must occur before

  encryption), and RFC8183 <https://tools.ietf.org/html/rfc8183>
compression is lossy in a way that prevents

  use of AH.  These are minor issues.  The major issue is how to

  establish trust enough such that IKEv2 could be used.  This would

  require a system of certificates to be present in every single node,

  including any Internet nodes that might need to communicate with the

  LLN.  Thus, "Use IPsec" requires a global PKI in the general case.

  More significantly, the use of IPsec tunnels to protect the IPv6-in-

  IPv6 headers would in the general case scale with the square of the

  number of nodes.  This is a lot of resource for a constrained nodes

  on a constrained network.  In the end, the IPsec tunnels would be

  providing only BCP38 <https://tools.ietf.org/html/bcp38>-like origin
authentication!  Just doing BCP38 <https://tools.ietf.org/html/bcp38>

  origin filtering at the entry and exit of the LLN provides a similar

  level amount of security without all the scaling and trust problems

  of using IPsec as RFC2473 <https://tools.ietf.org/html/rfc2473>
suggested.  IPsec is not recommended.

</author>

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> (1) Abstract.  Per “Additionally, this document updates RFC 6550 to
> indicate
> about this change …”, this sentence didn’t parse for me in explaining the
> relationship with RFC6550.
>


<author>Corrected to: Additionally, this document updates RFC 6550 defining
a flag

  in the DIO Configuration Option to indicate about this change.

</author>

>
> (2) Section 1.  Typo.  s/implementors/implementers/
>

 <author> fixed </author>

>
> (3) Section 2.  Editorial Nit.  s/header refers to:/header refers to/
>

<author> fixed </author>

>
> (4) Section 3.  A few editorial comments on how these updates are
> presented:
>
> ** Inconsistent spacing in Section 3 title:
> s/Updates to RFC6553, RFC6550 and RFC 8138/
> Updates to RFC6553, RFC6550 and RFC8138/
>

<author> fixed </author>

>
> ** Section 3.1 and Section 3.3 open with the motivation for the change.
> Section 3.2 does not.
>
> <author> Added in the text:

<t> This modification is required to be able to decompress the RPL RPI
option with the new value (0x23).</t></author>



> ** Section 3.3 title describes the proposed change.  Section 3.1 and 3.2
> simple
> state “Updates to RFCxxx”
>

<author> Corrected: <section title="Updates to RFC6553: Indicating the new
RPI value.">

<section title="Updates to RFC8138: Indicating the way to decompress with
the new RPI value."></author>



>
> ** Section 3.1 – 3 titles include a space in the RFC names (i.e.,
> RFC-space-number).  The Section 3 title does not.
>

<author>Corrected: all together without space-RFC6553-

</author


> (5) Section 3.1.  Editorial Nit.
>
> ** s/[RFC6553] states as shown below/[RFC6553] states as shown in Figure 1/
>
<author>fixed </author>

>
> ** Recommend citing the relevant page and section number from RFC6553 too.
>
<author>fixed </author>

>
> (6) Section 3.2.  Please use more explicit language to describe how this
> section updates RFC8138.
>

<author>fixed </author>

>
> (7) Section 3.2.  Figure 3 is depicted in this section but not referenced
> in
> the text.
>
<author>fixed </author>

>
> (8) Section 4.  Typo.  s/A RPL Stack is shown in Figure 5/A RPL Stack is
> shown
> in Figure 6/
>
<author>fixed </author>

>
> (9) Section 5.  Editorial Nit. s/these nodes are/These nodes are/
>
<author>fixed </author>

>
> (10) Section 5.  A few editorial recommendations for this paragraph:
>
> The uses cases describe the communication between RPL-aware-nodes,
>    with the root (6LBR), and with Internet.  This document also describe
>    the communication between nodes acting as leaves that do not
>    understand RPL, but are part of the LLN.  these  nodes are named as
>    not-RPL-aware-leaf, mentioned previously.  (e.g.  Section 6.1.4 Flow
>    from not-RPL-aware-leaf to root) This  document describes also how is
>    the communication inside of the LLN when it has the final destination
>   addressed outside of the LLN e.g. with destination to Internet.
>    (e.g.  Section 6.2.3 Flow from not-RPL-aware-leaf to Internet)
> ** s/these nodes are/These nodes are/
>
<author>fixed </author>

>
> ** The sentence “This document describes also how …” doesn’t parse.
>
<author>fixed </author>

>
> ** The use of “(e.g. …)” as a standalone sentence doesn’t parse.
>
<author>fixed </author>

>
> (11) Section 5.  Per “There is some possible security risk when the RPI
> information is released on the internet …”, I recommend reframing this text
> around the fact that the leak of RPI info would not present an issue. As
> is,
> the impact reads ambiguously to me.
>

<author> Corrected to:”No clear attack has been described when the RPI
information is released to the Internet. At worst, it is clear that the RPI
option would waste some network bandwidth when it escapes.  This is traded
off against the savings in the LLN by not having to encapsulate the packet
in order to remove the artifact ”

</author>



>
> (12) Section 6.  The meaning of “root” in Figure 7 is not explained in the
> text
> above it.
>
<author>fixed </author>

>
> (13) Section 6.1.4.  Typo. s/encapsuladed/encapsulated/
>
<author>fixed </author>

>
> (14) Section 9.  Editorial Nit.
> s/ During bootstrapping the node get the DIO with the information of RPL
> Option
> Type/ During bootstrapping the node gets the DIO with the information of
> RPL
> Option Type/
>
<author>fixed </author>

>
> (15) Section 11.  Make BCP38 a reference (i.e., [BCP38])
>

<author>fixed </author>

Many Thanks again,

Ines, Michael and Pascal