Subject: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-useofrplinfo-29: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Sun, 26 May 2019 21:27:00 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-roll-useofrplinfo-29: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my Discuss (and Comment) points!

I just have a few more minor notes on the -29:

the "(1)" footnote is no longer present.

I'm also not sure about the global change from "<foo>_i are the
intermediate routers" to "<foo>_i is the intermediate router", since the
general case can still have more than one intermediate in each
direction.  But perhaps we should leave this to the RFC Editor.

Section 11

nit: "especially if the target of the attack is targeting another LLN"
had redudant "target" added -- just "especially if attack is targeting
another LLN" would be fine.

I think the claim that "[i]n the end, the IPsec tunnels would be
providing only BCP38-like origin authentication!" could use some
additional justifcation.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 May 2019 14:03:06 -0400

> providing only BCP38-like origin authentication!" could use some

Sure, but I don't have a short version of it, and I believe that this
long version below is too busy to put into the draft.  It would
probably also require "eight-by-ten colour glossy pictures with circles and
arrows"..

When you build a tunnel from <A> to <B>, and it connects traffic from
A/net to B/net, and <A> does appropriate RFC4301 processing to pick
the right SPD, that means that traffic coming through the tunnel from <A>
must always be from nodes that A can verify (with BCP38 going into the
tunnel) are from A/net.   That is, IPsec provides a transitive guarantee
to the tunnel exit point that the tunnel entry point did BCP38 on traffic
going in.  But, thanks to IKEv2 Traffic selectors, the exit point knows the
tunnel SPD parameters, and can if it wishes validate the (source) addresses
fit into the tunnel if it wants. 4301 made this optional, I seem to recall.

Nodes behind A can, of course, spoof any address they like from A/net.
So B is assured that traffic coming out were always from A/net, but
has no idea if it's the correct A/net.

Now, within the LLN, A/net and B/net are the same network (prefix).
(Lets call it AB/net)

If you use IPsec, then you create O(n^2) tunnels between all possible
LLN routers that could exchange traffic.

Since every single one of the routers is willing to add an IPsec-IP wrapper
to traffic that does not have an appropriate header (to deal with unaware
leaves), then at B, all it can be sure about is that traffic coming out of
the tunnel is from some node in AB/net.

** If the root does BCP38 filtering on incoming traffic (which is really cheap),
** you get exactly the same assurance.

Also, if you use IPsec, you have to build things:
      IP2 RH3 RPI ESP {IP1 ULP}

In the non-storing mode version, you could deal with O(n) tunnels since all
traffic goes through the root.  If there are no unaware leaves and no traffic
to the Internet, then IP1.src always == IP2.src (upward, s/src/dst/ for
downward), and you could do really good address validation.
Of course, in that case, where there are no unaware leaves, and no need to
ever add IPIP headers either.

In the Storing mode version there is no RH3, but traffic does not go to the
root, so this is where O(n^2) tunnels could be required.  You can route the
IKEv2 packets, because they always come from routers, not unaware leaves,
so RPI headers can be inserted when they IKEv2 packet is originated.
Again, since the 6LR is willing to route (via encapsulation) any packet
From AB/net into the tunnel, the recipient has no idea where traffic came
from.

And, in storing mode we have the same problem with the IKEv2 and ESP traffic
as we do with the RPI: we don't know where the last 6LR is, so we don't know
where to make the tunnel to.  In that case, we'd have to resort to doing
IPsec over Link-Local addresses, a tunnel for each parent/child hop.  So
at the last 6LR, we get an AB/net origin packet from our parent, and what
can we say about it's origin?  That it's from somewhere in the LLN.

I think that in
https://datatracker.ietf.org/doc/draft-thubert-roll-unaware-leaves/, which
the WG has not adopted yet, that we might be able to put a requirement
on unaware leaves that they be able to decapsulate traffic like:
   IP2(dest=me) RH3 RPI IP(dest=me) ULP
and thus all the hop-by-hop IPIP encapsulation can go away, but we haven't
done that yet.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 May 2019 10:00:45 +0000

Hello Michael and Benjamin

<snip>
 
> I think that in
> https://datatracker.ietf.org/doc/draft-thubert-roll-unaware-leaves/, which the
> WG has not adopted yet,

Just did : )

>                                              that we might be able to put a requirement on
> unaware leaves that they be able to decapsulate traffic like:

Yes, we can.

The current text in section 6 places the load on the encapsulator, 
"
   o  When IP-in-IP is used and the outter headers terminate at the 6LR
      that generated the DAO, then the 6LR decapsulates the packet to
      the 6LN.  In that case the 6LN gets a packet that is free of RPL
      artifacts.  IP-in-IP to the 6LR MUST be used if the 6LN cannot
      handle the RPL artifacts or the way they are compressed [RFC8138].
      It SHOULD be used it there is a particular bandwidth or power
      constraint at the 6LN. 
"

As Michael says, athis can work if it is the root that decides of the encapsulation because of the 'E' flag in the non-storing DAO, but hardly for any arbitrary encapsulator in storing mode. Useofrplinfo alleviates the problem since an arbitrary source may avoid encapsulation, but mostly so because the x23 type should be ignored by a normal stack. I'm happy to had in section 6 text that says that we expect any 6LN to be able to decapsulate IP in IP with a HbH option x23 and a routing header. 

More problematic is the use of RFC 8138 compression by the source. Seems that the parent would need to un-compress the outer header. A nicer way would be to signal that the encapsulation can be removed by any router that is connected to the 6LN before passing the inner packet to the 6LN. For that I guess we'd need a new anycast address that would mean "whichever router serves the inner IP", like a locator. 

All the best

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 May 2019 10:34:13 +0000

Removing the IESG, let me propose new text (in yellow) for the RUL draft section 6 (dependencies on 6LN).

   An arbitrary 6LN is expected to support IPv6-in-IPv6 encapsulation when it is

   the destination of the outer header. If the 6LN is a host, it is expected to

   drop the inner packet if it is not the destination of the inner header.

   An arbitrary 6LN is expected to process an unknown Option Type in a

  Hop-by-Hop Header as prescribed by section 4.2 of < RFC8200>.

   This means in particular that an RPI with an Option Type of 0x23

   < ietf-roll-useofrplinfo> is ignored when not  understood.

   An arbitrary 6LN is expected to process an unknown Routing Header Type as

   prescribed by section 4.4 of <RFC8200>.

   This means in particular that Routing Header with a Routing Type of 3

   <RFC6553> is ignored when the Segments Left is zero, and

   dropped otherwise.

   When IP-in-IP is used and the outer headers terminate at the 6LR that

   generated the DAO, then the 6LR decapsulates the packet to the 6LN.

   In that case the 6LN gets a packet that is free of RPL artifacts.

   IP-in-IP to the 6LR MUST be used if the 6LN cannot handle or ignore the RPL

   artifacts or the way they are compressed <RFC8138>.

   It SHOULD be used it there is a particular bandwidth or power constraint at

   the 6LN that justifies saving the encapsulation at the last hop.

Does that help?

Pascal

> -----Original Message-----

> From: Pascal Thubert (pthubert) <[email-masked]>

> Sent: mardi 28 mai 2019 12:01

> To: Michael Richardson <[email-masked]>; Benjamin Kaduk

> <[email-masked]>; Routing Over Low power and Lossy networks

> <[email-masked]>

> Cc: The IESG <[email-masked]>; [email-masked]; roll-

> [email-masked]

> Subject: RE: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-

> useofrplinfo-29: (with COMMENT)

> > https://datatracker.ietf.org/doc/draft-thubert-roll-unaware-leaves/,

> > which the WG has not adopted yet,

> >                                              that we might be able to

> > put a requirement on unaware leaves that they be able to decapsulate traffic

> like:

> >    IP2(dest=me) RH3 RPI IP(dest=me) ULP and thus all the hop-by-hop

> > IPIP encapsulation can go away, but we haven't done that yet.

> The current text in section 6 places the load on the encapsulator, "

> As Michael says, athis can work if it is the root that decides of the

> encapsulation because of the 'E' flag in the non-storing DAO, but hardly for any

> arbitrary encapsulator in storing mode. Useofrplinfo alleviates the problem

> since an arbitrary source may avoid encapsulation, but mostly so because the

> x23 type should be ignored by a normal stack. I'm happy to had in section 6

> text that says that we expect any 6LN to be able to decapsulate IP in IP with a

> HbH option x23 and a routing header.

> More problematic is the use of RFC 8138 compression by the source. Seems

> that the parent would need to un-compress the outer header. A nicer way

> would be to signal that the encapsulation can be removed by any router that is

> connected to the 6LN before passing the inner packet to the 6LN. For that I

> guess we'd need a new anycast address that would mean "whichever router

> serves the inner IP", like a locator.