Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined?

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Sep 2015 23:44:44 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    > Can you write down your thoughts on this topic, so that I can
    > understand it?

    > To me, ACP and bootstrap have nothing to do with each other; and I seem
    > to hear from you that they are joined through IKE?

Assumption 1 (to be confirmed/denied elsewhere):
   - that the ACP is formed by a series of transport-mode IPsec
     tunnels setup to carry IP(proto-41) traffic. (i.e. tunnel-mode
     without the tunnel mode SPD restrictions).

Assumption 2:
   - that we run a routing protocol over these virtual IPIP interfaces,
     such as RPL, and the result is the ACP.  RPL takes care of numbering
     the ACP through it's PIO payloads, with the resulting /128s being
     aliases on a "loopback" interface (i.e. not attached to any specific
     IPIP interface).  All of this happens in a VRF; but in some cases,
     it may not be totally isolated from some of the data planes.

In order to build these tunnels, we have to run IKEv2 over link-layer
addresses.  To do this we have to have the addresses of the peers that run
ANIMA.  On a link without layer-2 security (1x/WPA) then we have to have a
way to discover the peers; this could be GRASP in some insecure formulation,
or some other service discovery.  We could even do this with multicast on UDP
port 500 (the IKE port).

Assumption 3:
  - a node really has no idea what constitutes a "domain certificate",
    it comes with with one IDevIDs, and may have one or more LDevIDs,
    but the enrollment process may either replace the IDevID, or argument
    it with LDevIDs instead.  As such, a node is always able to join a
    new network that provides the right credentials, and in some cases,
    it could be even "pre-enrolled" (it already has the right certificates).

So upon discovering peers, or being discovered, a node should bring up it's
ACP. That means doing an IKEv2 PARENT SA, and in this process it should offer
both RSA signature authentication (including a CERT, and a CERTREQ), as well
as offer PARENT SA authentication mechanism of EAP.

Note: RFC7296 says that the initiator signals it's interest in doing EAP
by leaving out the AUTH payload from I2.  I don't see anything in the
protocol that would forbid a responder from asking for EAP activities if
it is unable to validate the signature in the AUTH payload.  We might need a
Notify to indicate that this is an ANIMA process.

I could go on about how we actually need to always be ready for a new
enrollment, because the device may have moved, been sold, etc.
The device also may *not* have moved or been sold, but simply could have had
a new cable plugged in, and perhaps *that* side will be participating in a
different domain.

This is why I think that enrollment needs to happen as a result of a failure
to authenticate the ACP connection, not prior to it.

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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 10 Sep 2015 07:18:33 +0000

Thanks for this long response. Inline... 

> -----Original Message-----
> From: Anima-bootstrap [mailto:[email-masked]] On 
> Behalf Of Michael Richardson
> Sent: 10 September 2015 05:45
> To: [email-masked]
> Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of 
> combined?
> 
> 

Actually the ACP must be tunnel mode, because it carries packets that come from <elsewhere> and go to <elsewhere>, ie are routed through a specific ACP tunnel. 

>      it may not be totally isolated from some of the data planes.

OK. 

> addresses.  To do this we have to have the addresses of the peers that 
> run ANIMA.  On a link without layer-2 security (1x/WPA) then we have 
> to have a way to discover the peers; this could be GRASP in some 
> insecure formulation, or some other service discovery.  We could even 
> do this with multicast on UDP port 500 (the IKE port).

My view is also that this should be GRASP. Using IKE for that sounds really strange to me, but need to think more about it. 
 
>   - a node really has no idea what constitutes a "domain certificate",

I don't understand that statement. There is a series of interactions that we're specifying here, ANIMA transactions, and the result of those will be the device getting the  "domain certificate". What do you mean by the above? 

>     it with LDevIDs instead.  

The enrolment process provides the device with an LDevID. I see that in parallel to the IDevID, I don't see why it would "replace" that. But that's a detail I guess. 

>     As such, a node is always able to join a

Right. Small addition: Once a device has a domain certificate, it will stop the enrolment process. 

> So upon discovering peers, or being discovered, a node should bring up 
> it's ACP. That means doing an IKEv2 PARENT SA, and in this process it 
> should offer both RSA signature authentication (including a CERT, and 
> a CERTREQ), as well as offer PARENT SA authentication mechanism of EAP.

This is where we're going apart: I see that as two distinct steps. Not saying it couldn't be possibly done with one mechanism, but frankly, I don't see the benefit, and a lot more complication. 

> Note: RFC7296 says that the initiator signals it's interest in doing 
> EAP by leaving out the AUTH payload from I2.  I don't see anything in 
> the protocol that would forbid a responder from asking for EAP 
> activities if it is unable to validate the signature in the AUTH 
> payload.  We might need a Notify to indicate that this is an ANIMA process.

This is all assuming we WANT to combine. I would like to understand why we want to go down that route. 

> The device also may *not* have moved or been sold, but simply could 
> have had a new cable plugged in, and perhaps *that* side will be 
> participating in a different domain.

In my view: Once a device has a domain cert, it stops enrolment. If you want to move the device to another domain, you have to "push a button" to reset it. 

I hope we agree that a topological move in the same domain shouldn't matter since the ACP address is an identifier, not locator, and since topology is discovered anyway. 
 
> This is why I think that enrollment needs to happen as a result of a 
> failure to authenticate the ACP connection, not prior to it.

I see it differently, here is the way I see it happen: 

1 - A new node discovers link local what's around it. Since it has only its IDevID at the time, it cannot really validate anyone else quite yet. GRASP seems the right protocol for that. 
2 - The result is an adjacency table. It'll say something like 
<Neighbor link local address> <ID> <ID type> <validity> <...>
Where <ID> is either an IDevID, an LDevID, empty, or maybe something else later. 
Validity will likely be "not valid" because most cases we won't be able to validate at this stage. 

Now the device knows what's around it. But can't validate most of it. 

Now, sequentially for each device with a domain certificate a la ANIMA, the device starts a bootstrap process, one after the other. 

Let's assume that one neighbour can bootstrap the device. The result is that the device now has a domain cert. But NO ACP yet!!! 

The status now is the same adjacency table as above, BUT, now it should be able to validate the identity of at least the device that bootstrapped it. 

Draw a big line here. (and this line is really what we're arguing about, right? ;-) 
--------------------------------------------------------------------

New discussion: A domain device sees another, validated domain device. Next step: Establish the ACP. 

Now we do IKE and the rest of the story, using the domain certs for authentication. 

One reason to keep those beasts separate is because the domain cert might also get to the device by other means, or be pre-installed. So the ACP process should really be different. 

Michael

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Sep 2015 13:11:30 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    >> Assumption 1 (to be confirmed/denied elsewhere): - that the ACP is
    >> formed by a series of transport-mode IPsec tunnels setup to carry
    >> IP(proto-41) traffic. (i.e. tunnel-mode without the tunnel mode SPD
    >> restrictions).

    > Actually the ACP must be tunnel mode, because it carries packets that
    > come from <elsewhere> and go to <elsewhere>, ie are routed through a
    > specific ACP tunnel.

No, the ACP must have a tunnel, but because it doesn't know what the
source/destination of the packets is going to be, it can't use IPsec tunnel
mode.  Rather it has to use IPsec transport mode for IPIP packets.
The distinction is subtle, since the packets look the same on the wire.

Both look like:
                         IP1 / ESP / IP2 / ulp
In IPsec tunnel mode:    XXXXXXXXXXXXXXX
In IPsec transport mode: YYYYYYYYYY

In tunnel mode the IPsec system is responsible for validating that the
src/dst of IP2 match the policy (the X part).  Since we will run a routing
protocol on top, and the addresses will be assigned inside, we can't even
know what the addresses are going to be, and we can't just guess the entire
/48 (or /64) of the ULA, because that's not precise enough for IPsec.
In transport mode, the IPsec system just validates that the thing inside
the ESP is a proto=41, and leaves it at that.

    > My view is also that this should be GRASP. Using IKE for that sounds
    > really strange to me, but need to think more about it.

If we let GRASP talk to the bare wire, we open up GRASP to new kinds of
attacks that it wouldn't otherwise see if it's always inside the ACP.
(I would personally implement it as a seperate process if we did that)
On the other hand, IKEv2 has to deal with all those attacks ANYWAY.

Yes, multicasting an IKEv2 I1 packet is definitely odd.... but go read
RFC7296, section 2.6.  Essentially, a responder would agree that they
exist, but could consider the multicast destination address as an attack
and demand a COOKIE.  The initiator should really pick a new Ni.  If we
wanted to do this, I could write an ID explaining how; I don't know how
controversial it might be.

    >> Assumption 3: - a node really has no idea what constitutes a "domain
    >> certificate",

    > I don't understand that statement. There is a series of interactions
    > that we're specifying here, ANIMA transactions, and the result of those
    > will be the device getting the "domain certificate". What do you mean
    > by the above?

How does one know what a domain certificate is?
The IDevID shipped in the system might already be signed by the correct
Registrar.  The system could have been a new certificate (an LDevID), which
after the system is moved, is now wrong.  Maybe the system didn't move, but
just had a new interface attached, and the existing LDevID is wrong for
*that* interface.

    >> it comes with with one IDevIDs, and may have one or more LDevIDs, but
    >> the enrollment process may either replace the IDevID, or argument it
    >> with LDevIDs instead.

    > The enrolment process provides the device with an LDevID. I see that in
    > parallel to the IDevID, I don't see why it would "replace" that. But
    > that's a detail I guess.

The reason to replace the IDevID is to avoid being vulnerable to an attack by
the vendor (or an attack where the vendor's CA is compromised, or an attack
where a National Security Letter forces the vendor's hand).

    >> As such, a node is always able to join a new network that provides the
    >> right credentials, and in some cases, it could be even "pre-enrolled"
    >> (it already has the right certificates).

    > stop the enrolment process.

No, it can't do that.
It has to always be willing to do a new enrollment, potentially on a new
interface.
If it does that then the system can never be relocated, repurposed or sold
without touching the device before shutting it down from the place it is.

    >> enrollment, because the device may have moved, been sold, etc.  The
    >> device also may *not* have moved or been sold, but simply could have
    >> had a new cable plugged in, and perhaps *that* side will be

    > In my view: Once a device has a domain cert, it stops enrolment. If you
    > want to move the device to another domain, you have to "push a button"
    > to reset it.

That just doesn't fly for me.
What happens if I walk up to a device that is operating and push that button?
Wouldn't that be a denial of service?

    > I hope we agree that a topological move in the same domain shouldn't
    > matter since the ACP address is an identifier, not locator, and since
    > topology is discovered anyway.

I agree, as long as it's within the same ACP (and the ACP isn't partitioned
in a pathological way), then the move not a problem.

    > One reason to keep those beasts separate is because the domain cert
    > might also get to the device by other means, or be pre-installed. So
    > the ACP process should really be different.

If the domain cert is already there via other means (perhaps installed as the
IDevID), then the IKEv2 process just uses it, and the enrollment process
isn't necessary.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Sep 2015 08:14:48 +1200

On 11/09/2015 05:11, Michael Richardson wrote:
...

I don't see how the first stage of discovery (GRASP or non-GRASP) after
power-up can be anything but bare wire. Once you've found somebody to talk
to, you can presumably use some pre-loaded credentials to join the ACP.

Is this fundamentally different from DICE (which I recently reviewed with my
Gen-ART hat)?
https://tools.ietf.org/html/draft-ietf-dice-profile-16#section-4.1
A feature of the DICE profile is that it doesn't pick one of the
three options, which IMNSHO is very bad for interoperability.

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 11 Sep 2015 08:11:29 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: 10 September 2015 19:12
> To: Michael Behringer (mbehring) <[email-masked]>
> Cc: [email-masked]

Yes, I think you're right, it's been a while that I looked at the details. BTW, I suggest to use GRE rather than IPIP. Costs 4 bytes, but gives more flexibility. Thoughts? 
 
> In tunnel mode the IPsec system is responsible for validating that the src/dst
> of IP2 match the policy (the X part).  Since we will run a routing protocol on
> top, and the addresses will be assigned inside, we can't even know what the
> addresses are going to be, and we can't just guess the entire

I'm not arguing about transport mode, I think you're right, but just for my understanding: Why would a policy "any to any" not be sufficient here? Seems to me that would do the job? 

> In transport mode, the IPsec system just validates that the thing inside the
> ESP is a proto=41, and leaves it at that.
> 

That is true. On the other hand, I think we'll end up in situations where an ASA will talk to another ASA over the data plane, in which case that might happen anyway. 

The other thought is: Well, there will have to be some negotiation before setting up a tunnel, using protocol x. So we need to secure protocol x, whatever it is, against DoS, spoofing etc, as much as we can. Why does it matter whether x is GRASP or another protocol? Because some checks may not be needed if it's ACP only and the implementation would be more complex? But then, having another protocol just moves that complexity? 

> (I would personally implement it as a seperate process if we did that) On the
> other hand, IKEv2 has to deal with all those attacks ANYWAY.
> 
> Yes, multicasting an IKEv2 I1 packet is definitely odd.... but go read RFC7296,
> section 2.6.  Essentially, a responder would agree that they exist, but could
> consider the multicast destination address as an attack and demand a
> COOKIE.  The initiator should really pick a new Ni.  If we wanted to do this, I
> could write an ID explaining how; I don't know how controversial it might be.

Hmmm.... I start to see where you're going. Basically, use IKEv2 to do adjacency discovery, because it has already the required security mechanisms, and because you shouldn't re-invent something that works. Thinking out loud here... 

If you're sitting on a subnet where an IPsec gateway is connected, you'd probably confuse the hell out of that, so we'd need a different port to run on. 

Now there will be following cases: 
- the other node is not autonomic: Will not respond. That's ok
- the other node is autonomic:
   + in the same domain: authenticates, all good. 
   + but not enrolled: How would it respond? 
   + in a different domain: How would it respond? 

Looks like, probably we'd need to modify/extend IKE somehow. 
But yes, it would integrate nicely with building the tunnel, of course. 
Interesting idea. 

OTOH, how would it integrate with the enrolment process? The EAP / EST story sounds pretty clean to me. Would you do IKE first, and if the other node has no LDevID, kick off EAP/EST? 

> after the system is moved, is now wrong.  Maybe the system didn't move,
> but just had a new interface attached, and the existing LDevID is wrong for
> *that* interface.

It's a system requirement. 
1) A device must *know* what its IDevID is. It must also know if it DOESN'T have an IDevID.
2) Anything that came through the bootstrap process we're defining here is by definition an LDevID, what I call the "domain certificate". That's clear. 
3) That leaves the case where an operator installs a certificate by other means. And I guess we have two cases here: 
   a) this is really meant as an IDevID: Example: integrator buys white label cheap boxes, resells them under his name to various customers, that will use their own LDevID. 
   b) it's meant as an LDevID: Example: SP pre-installs devices for specific customers. 

Bottom line: When installing certs through other means than AN, we need to be able to distinguish. 
 
> where a National Security Letter forces the vendor's hand).

Let's not call this "replace", but "disable". Then the above distinction remain correct, and we just have to think about how to disable.

The IDevID is exclusively used after a factory reset. Once enrolled in a domain, it's only the LDevID that's used, and renewed when needed. 

So we could define a mechanism, where, after successful enrolment into a domain, the admin can change the behaviour of the device. 

Thinking about this, we don't want to "disable" nor "replace", but  we want to change the startup behaviour. We want to say "henceforth, you will NO LONGER require an authorization token." And flag in internal systems (registrar, etc) that the IDevID is no longer trusted, and that we don't consult the MASA (for this or all devices). That's it, then I have no more links with the vendor.

Now, this has a lot of security consequences, and I'd really want to look closely at them, so not sure we want to actually go down this route, but technically it looks possible to me. 

> without touching the device before shutting it down from the place it is.

Agreed, and I call that a "feature" :-) 

Re-location to another place in the same domain works anyway, no problem. When plugging the device into another domain, you move the device physically anyway, so a factory reset is perfectly acceptable. 

And in the way it is currently, nobody can hijack a device into another domain without physical access. That's a very nice security feature to have!! 

> Wouldn't that be a denial of service?

What if I unplug the device? Much easier and much more efficient :-) 
And, re-enrolment is actually also automatic, so this isn't a good DoS attack, compared to unplugging. 
 
> I agree, as long as it's within the same ACP (and the ACP isn't partitioned in a
> pathological way), then the move not a problem.

OK.
 
> IDevID), then the IKEv2 process just uses it, and the enrollment process isn't
> necessary.

This now makes sense with your explanation on how you'd use IKE. 

So, the main questions at hand now are (in my head): 
1 - whether we can/should use IKEv2 in a modified form for adjacency discovery (leave alone everything else for now!). In that function, it must also show AN nodes from other domains, and be able to build an adjacency table with that information. 
(the fact that on discovery of a neighbour in the same domain, you can now move straight to establishing the IPsec tunnels is not really the question for this point, but certainly elegant)
2 - How we'd have to modify IKE. 
3 - How this would integrate with the enrolment process. Would you still suggest EAP/EST, and keep things separate? 

And of course, once we have answers to those questions, compare to a GRASP approach. 

Good discussion!! Thanks, lots of good input! 
Michael

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Sep 2015 10:09:20 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    >> Both look like: IP1 / ESP / IP2 / ulp In IPsec tunnel mode:
    >> XXXXXXXXXXXXXXX In IPsec transport mode: YYYYYYYYYY

    > Yes, I think you're right, it's been a while that I looked at the
    > details. BTW, I suggest to use GRE rather than IPIP. Costs 4 bytes, but
    > gives more flexibility. Thoughts?

I don't object, but I see that flexibility as an interoperability hurdle.
How does having an extra layer-2 header help us at all?

I note that IKE could offer different things, which provides for some degree
off transition/upgrade if we found a use for GRE.

    >> src/dst of IP2 match the policy (the X part).  Since we will run a
    >> routing protocol on top, and the addresses will be assigned inside, we
    >> can't even know what the addresses are going to be, and we can't just
    >> guess the entire /48 (or /64) of the ULA, because that's not precise
    >> enough for IPsec.

    > I'm not arguing about transport mode, I think you're right, but just
    > for my understanding: Why would a policy "any to any" not be sufficient
    > here? Seems to me that would do the job?

The "any to any" policy results in creation of a default route on many
systems, because the policy negotiated determines what traffic goes into the
tunnel.

    >> If we let GRASP talk to the bare wire, we open up GRASP to new kinds
    >> of attacks that it wouldn't otherwise see if it's always inside the
    >> ACP.

    > That is true. On the other hand, I think we'll end up in situations
    > where an ASA will talk to another ASA over the data plane, in which
    > case that might happen anyway.

    > The other thought is: Well, there will have to be some negotiation
    > before setting up a tunnel, using protocol x. So we need to secure
    > protocol x, whatever it is, against DoS, spoofing etc, as much as we
    > can. Why does it matter whether x is GRASP or another protocol? Because
    > some checks may not be needed if it's ACP only and the implementation
    > would be more complex? But then, having another protocol just moves
    > that complexity?

Because IKEv2 is *already* secured against these things.

    > If you're sitting on a subnet where an IPsec gateway is connected,
    > you'd probably confuse the hell out of that, so we'd need a different
    > port to run on.

I actually doubt it binds the link-layer multicast address.
But, we certainly could ask for a different port number anyway.

    > + in a different domain: How would it respond?

Actually, one can't know if you are in the same domain or not until you see
the identities, which IKEv2 sends in the (encrypted) I2/R2 messages.
So the last three cases are identical.  That's also good because it means
that a not-yet-enrolled node doesn't necessarily reveal that fact.

    > 1) A device must *know* what its IDevID is. It must also know if it

If it doesn't have an IDevID at all, then that's fine.
But, given a certificate, how can it know it's a domain certificate?
They are all:
     Issuer FOO says that Public Key BAR belongs to DN BAZ.

Only if you know if "FOO" is a domain certificate can you know what's going
on.

    > 2) Anything that came through the bootstrap process we're defining here
    > is by definition an LDevID, what I call the "domain
    > certificate". That's clear.

I disagree, the process might replace/update the IDevID.
That's explicitely supported in 802.1AR.

    > 3) That leaves the case where an operator installs a certificate by
    > other means. And I guess we have two cases here:
    > a) this is really meant as an IDevID: Example: integrator buys white
    > label cheap boxes, resells them under his name to various customers,
    > that will use their own LDevID.

Sure.  But that can be done via ANIMA bootstrap protocol.
And customer A can easily resell the box to customer B.

    > to be able to distinguish.

I just don't think it matters.

    >> The reason to replace the IDevID is to avoid being vulnerable to an
    >> attack by the vendor (or an attack where the vendor's CA is
    >> compromised, or an attack where a National Security Letter forces the
    >> vendor's hand).

    > Let's not call this "replace", but "disable". Then the above
    > distinction remain correct, and we just have to think about how to
    > disable.

802.1AR supports replace, rather explicitely.

    > The IDevID is exclusively used after a factory reset. Once enrolled in
    > a domain, it's only the LDevID that's used, and renewed when needed.

Are you saying that after a factor reset that the disabled IDevID will become
enabled again?

    > Thinking about this, we don't want to "disable" nor "replace", but  we
    > want to change the startup behaviour. We want to say "henceforth, you
    > will NO LONGER require an authorization token." And flag in internal

The word "require" is wrong --  it should be "accept"

    > Now, this has a lot of security consequences, and I'd really want to
    > look closely at them, so not sure we want to actually go down this
    > route, but technically it looks possible to me.

    >> If it does that then the system can never be relocated, repurposed or
    >> sold without touching the device before shutting it down from the
    >> place it is.

    > Agreed, and I call that a "feature" :-)

I sure do not.
I'm pretty sure no military or humanitarian organization that wants to do
rapid deployment would want this feature.

    > Re-location to another place in the same domain works anyway, no
    > problem. When plugging the device into another domain, you move the
    > device physically anyway, so a factory reset is perfectly acceptable.

    > And in the way it is currently, nobody can hijack a device into another
    > domain without physical access. That's a very nice security feature to
    > have!!

Physical access is not a problem for many devices we care about :-)

    > attack, compared to unplugging.

If loss of power is a concern, you can deal with that using internal
batteries.  Every home alarm system has that battery locked inside the box.

    >> If the domain cert is already there via other means (perhaps installed
    >> as the IDevID), then the IKEv2 process just uses it, and the
    >> enrollment process isn't necessary.

    > 1 - whether we can/should use IKEv2 in a modified form for adjacency
    > discovery (leave alone everything else for now!). In that function, it
    > must also show AN nodes from other domains, and be able to build an
    > adjacency table with that information.

    > (the fact that on discovery of a neighbour in the same domain, you can
    > now move straight to establishing the IPsec tunnels is not really the
    > question for this point, but certainly elegant)

    > 3 - How this would integrate with the enrolment process. Would you
    > still suggest EAP/EST, and keep things separate?

Yes, I think that I'd still use EAP/EST, although I have some qualms about
how silly it is to run TLS inside IKEv2, but that's the reality of EST.

    > Good discussion!! Thanks, lots of good input!

yes!

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 11 Sep 2015 07:23:09 -0700

Tunnel mode sounds right.

The problem with encap really is that there will be different optimized
HW-forwardable encaps in different spaces. Most likely 802.1ae on
"switch" equipment and maybe IPsec over GRE across routers. Just the Cisco
example. For interop, we need an MTI (mandatory to implement). I fear that
IPsec (with either GRE or IPIP) is not a good MTI. <whatever> (IPsec, etc..)
on top of UDP would make it possible to get through most NAT/FW and to
implement in userland/unprivileged apps.

Toerless

On Fri, Sep 11, 2015 at 08:11:29AM +0000, Michael Behringer (mbehring) wrote:
> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

-- 
---
Toerless Eckert, [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Sep 2015 08:09:46 +1200

Just one point in line...

> That is true. On the other hand, I think we'll end up in situations where an ASA will talk to another ASA over the data plane, in which case that might happen anyway. 

GRASP currently requires TLS for this case (except for the outbound discovery
multicast, if needed).

   Brian

> .

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Sep 2015 19:53:03 -0400

> implement in userland/unprivileged apps.

ESP already runs over UDP, and runs through NAT and FW already.
I don't think that this matters though as these are all hop-by-hop links.
I think you are very confused here.

We are discussing what the IPsec policy for the thing that lives inside the
tunnel. As for what is easy to implement on hardware; I think that this
irrelevant, as the ACP is better implemented on the control plane CPU, in
order to be free to completely reprogram the data plane ASICs.

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 13 Sep 2015 17:44:22 -0700

inline,

> ESP already runs over UDP, and runs through NAT and FW already.

Ok, good point. RFC3948 ?!

> order to be free to completely reprogram the data plane ASICs.

Depends really on how one wants to use the ACP. I do agree that
the MTI should be one that's most portable. IPsec+RFC3948 might be
that. How would you compare it to dTLS ?

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Sep 2015 15:43:06 +1200

> that. How would you compare it to dTLS ?

Are we really requiring the ACP to cross NAT or firewalls inside an autonomic
domain? Sorry, I just don't see that. I thought all ACP packets would be link
local, with ACP nodes forwarding between links. There are no NATs or firewalls
in that picture.

Also where does DTLS fit in (rather than TLS)? (Secure multicast?)

   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 13 Sep 2015 21:24:10 -0700

> Also where does DTLS fit in (rather than TLS)? (Secure multicast?)

I have no strong opiniuon about NAT. passing through FW might be quite
useful for OAM operations. But more fundamentally, solutions over UDP
make it most easily portable. Thats why (d)TLS or ESP over UDP are
interesting IMHO.

I don't like to put IP packets (which is whats inside 
ACP) on top of a flow-controlled reliable connection. That just leads
to terrible performance behavior because of congestion control inside
congestion control (for any reliable connection inside ACP).

I do like to put GARP into TLS directly though. I was wondering if one
could start with a TLS connection for GARP, inherit the security association
for dTLS of ACP as the MTI and use GRP to optionally negotiate a better
ACP encryption than dTLS.

Cheers
    Toerless

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Sep 2015 10:18:33 -0400

Brian E Carpenter <[email-masked]> wrote:
    > Are we really requiring the ACP to cross NAT or firewalls inside an
    > autonomic domain? Sorry, I just don't see that. I thought all ACP
    > packets would be link local, with ACP nodes forwarding between
    > links. There are no NATs or firewalls in that picture.

+10.
I don't understand Toerless' point either.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Sep 2015 07:56:21 +1200

> congestion control (for any reliable connection inside ACP).

Yes, good point.

> ACP encryption than dTLS.

GRASP can certainly use TLS directly and that's what I expect will happen for
any inter-domain use of GRASP anyway.

    Brian