Subject: Re: [Anima] draft-ietf-anima-autonomic-control-plane-06

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Jun 2017 02:02:40 +0200

[oops. resending with fixed address for pascal]

Adding Pascal explicity
because i may be confused about various RPL things here:

I may be wrong, but it looks to me as if MichaelRs comments and reference to
this new draft about RPL IPinIP header stuff makes it sound as if we MUST
somehow support these IPinIP headers in ACP:

https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-useofrplinfo-10&url2=draft-ietf-roll-useofrplinfo-14  

Also, during the last IETF, i think MichaelR said something to the extend that
the "profile" defined for RPL via the latest -06 version should rather go into
some form of RPL profile draft.... But if i remember correctly, Pascal told me
there is no such "RPPL profile" draft format.

When i discussed with Pascal, he reconfirmed to me that the approach/profile
choosen for RPL in the Cisco IOS implementation of ACP should be perfetly
RPL standards compliant - and it does not do any IPinIP header extensions.

This is something i would prefer as the mandatory minimum ACP requirements
because i am fearful of asking all type of equipment to support RPL routing
protocol specific IPinIP header processing. I am not even sure if i could
today expect to get this IPinIP header processing in all linux that i might
expect on native ANI devices, but given how we're unlikely allowed for some
intervening device to insert/delete those headers, the use of IPinIP headers
would eliminate the option to easily set up extensions ("autonomic connect")
to the ACP in a NOC - into pre-existing management devices with the
"What The F**K is RPL" TCP/IP stack.

Not using IPinIP headers does of course come at the limitation of  - if i
understand it correctly - a single instance with a single (active) root.
As long as we can have automatic root election so that we have root redundancy,
i think this is a sufficient minimum functionality for ACP.

It would be great to bring in as much as possible of that IPinIP support via
SHOULD, but i am not 100% clear how this can be done:

- It seems to be easy to make IPinIP support SHOULD for endpoints. Such an
  endpoint could only use the default instance/root of RPL. Right ?
- It is less clear to me if/how its possible to introduce partial support
  for IPinIP on transit nodes. I am hping that RPL can automatically
  figure out that additional instances/dodags can only work across paths
  where all transit nodes support IPinIP. Then the problem is solved.
  If this si something RPL can not singnal, then it seems as if a
  transit node without IPinIP support would kill non-default instance/transit
  paths.
- I am very interested to make non IPinIP capable transit nodes sufficient
  for MUST ACP requirements because i am quite sure that a relevant part of 
  HW accelerated forwarding engines will not support IPinIP routing, so any
  mandatory introduction of IPinIP would kill HW acceleration for ACP. Which IMHO 
  would make me ask to rethink the choice of ACP default routing protocol.

So...

Q1: Do we agree on this direction ?

Q2: How can we finalize the sufficient/necessary text mods to ACP to express
this ? (profile definition etc..)

Thanks a lot!
    Toerless

On Fri, Apr 07, 2017 at 10:04:21AM +1200, Brian E Carpenter wrote:
> Comment at the end..
> 
> On 07/04/2017 09:31, Michael Richardson wrote:
> > 
> > Brian E Carpenter <[email-masked]> wrote:
> >     >> Unless RPL for the ACP or any future ACP mechanism do require reception and processing
> >     >> of IPv6-in-IPv6 packets, ACP routers SHOULD filter/drop IPv6-to-IPv6 packet targeted
> >     >> to their ACP address.
> > 
> >     > I'm still not clear what the attack is. This rule seems to be saying "don't act as a
> >     > protocol 41 tunnel end point by default." But who would do that anyway? If you aren't
> >     > configured as a tunnel end point, protocol 41 is /dev/null. If you are configured
> >     > as a tunnel end point, you know what to do with the packet by definition. Don't act
> >     > as a GRE end point by default either. In fact, if you get any packet you don't understand,
> >     > drop it.
> > 
> > Because we have to insert RPI header with an IPIP header, that means that
> > every RPL router node needs to be will to accept IPIP packets addressed to
> > it.   It should find IPouter.dst = ME, and IPinner.dst = ME.
> > (with IPouter.src being the device that inserted the IPIP header,
> > and IPinner.src being the original source of the packet).
> > 
> > *IF* the ACP router has some "clients" (i.e. VMs inside it), it may want
> > to do IPIP encap/decap for the client machines.
> > 
> >     >> When reception/processing of IPv6-in-IPv6 packets is required for RPL, only
> >     >> IPv6-in-IPv6 packets with an ACP address from the same autonomic domain should be
> >     >> accepted.
> > 
> >     > Yes. But it does seem a bit obvious, frankly. Also, I can't imagine a use case.
> >     > I can imagine a use case where packets addressed from and to an ACP address arrive
> >     > encapsulated in a non-ACP packet, because we are connecting two ACP clouds
> >     > over a non-ACP tunnel, but in that case the tunnel end point will not be visible
> >     > in the ACP VRF anyway.
> > 
> > Agreed.
> > The point in the security considerations is to make it really clear that
> > traffic should not pass via the ACP to the Internet.
> > 
> > Imagine a compromised machine (a desktop in the NOC!!!) that can send IPIP
> > traffic via the ACP to a backbone router, which will then decapsulate it
> > (ignoring our words), and sending it out to the Internet at 100Gb/s speeds?
> > This is the issue that I want to make sure the "considerations" point out.
> 
> Absolutely. And it could be a BYOD in the NOC that manages to join the ACP,
> even. We really do need to tackle node and ASA authorization in Phase 2.
> 
>     Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Jun 2017 18:21:45 -0400

> somehow support these IPinIP headers in ACP:

It's an argument that we have to have in the ACP document.
Yes, we can get away without the RPI header.  I'm not happy about it, but I
can live with it.  I'd like to be tolerant of including them, however.
RFC2460bis text lets us clearly state this, and the useofrplinfo revised
document will, I think make it clearly ignorable.

    > there is no such "RPPL profile" draft format.

Not at all. The RPL profile template is at:
    https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template/
    (yes, it's expired, never to be published)

    https://datatracker.ietf.org/doc/rfc7733/ (section 4)
    https://datatracker.ietf.org/doc/rfc8036/ (section 7)

are examples of the RPL profile.

    > today expect to get this IPinIP header processing in all linux that i

At present RPI is not supported in current Linux kernels, but there are
people working on it.  RPI headers are produced by OpenWSN and Contiki
implementations now.

    > i think this is a sufficient minimum functionality for ACP.

There is always one root per instance, RPI lets you have multiple instances.
RPI provides for loop detection (and the resulting: fast repair) which I think
that we actually rather need if we expect this to be used for critical function.

If we aren't going to depend RPI,  we'll need to carefully tweak the RPL
parameters so that we get frequent enough announcements.  We may be able to
leverage the IPsec DPD messages to detect link down's and do reparent events
though.  That should be easily written up in the ACP document.

    > endpoint could only use the default instance/root of RPL. Right ?

Yes.

    > transit node without IPinIP support would kill non-default instance/transit

We have to do this globally, I think, we will need to define a signal for
this, and we have to put this into the DIO.  I think this will be generally
useful for RPL.  Probably it deserves a seperate draft, but let's start it
in the ACP document first.

    > would make me ask to rethink the choice of ACP default routing

I agree.
Note that the worst situation of IPinIP is that the header has to be added
and removed at each hop, and the outer IP is a link-local address.  Inside
the IPsec tunnel, it probably looks like:

   IPll ESP RPI IP ULP

With the IPll ESP RPI part being added/removed at each hop.  Based upon 20
years of building drivers for hardware acceleration, I don't think that this
will matter much to HW accel.

    > this ? (profile definition etc..)

We need to convene an ACP design team call.

I don't think that we can get to that until the voucher and brski and grasp
documents are into WGLC.

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

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 8 Jun 2017 01:10:21 +0200

Thanks, Michael. Inline.

> are examples of the RPL profile.

Great. I thought in Chicago you said you would volunteer converting the current section
about Roll profile in ACP spec into that format. Is that offer still valid ?

> that we actually rather need if we expect this to be used for critical function.

I hope i am restating Pascals argument correctly that the RPI based repair is
only needed when you do want to be lazy on DAO state maintenance. Given
how our profile asks for aggressive starte maintenance, tht should be sufficient
(as it is on any other routing protocols).

> though.  That should be easily written up in the ACP document.

Good point. I guess thats details that would go beyond RPL profile.
Text suggestions welcome, otherwise i'll try to make up something.

> in the ACP document first.

Like with the GRASP discuss in the last email, i would like to see that we
keep the option of pushing out difficult, longer-term stuff stuff into
separate drafts to finally close on some ANI Minimum-to-implement option.

Btw: I am very interested to have some more high-available ACP option, but
that would be even more work, eg: Something like MRT support with RPL.
Maybe we can discuss in Prague..

> will matter much to HW accel.

Well... If i look at the routing requirements that i see:
  - ability to have different NOCs are separate roots
  - ability to have MRTs

I think i could easier resolve those requirements with (S/M,D) based
forwarding entries than with IPinIP header fields to specify an instance.
But i guess that such approaches would be novel for RPL and (see above)
therefore require more work.

> I don't think that we can get to that until the voucher and brski and grasp

Sure.

Cheers
    Toerless

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Jun 2017 22:40:20 -0400

> about Roll profile in ACP spec into that format. Is that offer still

Yes, I'll still do that, but there are some other BRSKI edits that seem to
take priority :-)

    > Text suggestions welcome, otherwise i'll try to make up something.

That's actually exactly what the RPL Profile addresses.

    > Maybe we can discuss in Prague..

What is "MRT" in this context?

    > therefore require more work.

Different NOCs could create different DODAGs, yes, but it requires InstanceIDs.
There may be some other options.