Subject: [Anima-bootstrap] Can the proxy add information during bootstrap?

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 12 Apr 2016 16:05:20 +0000

When a new device enrols, an operator will want to know WHERE this device is connecting. This includes the proxy identity, plus the interface on the proxy. (Potentially more)

The proxy identity can be figured out by looking at the source address of the incoming packets; but the interface information needs to be added explicitly, somehow. 

I see a parallel with DHCP: I think also with our BSKI approach, the need will arise to have something like "DHCP options" that relate to the proxy. 

Can our enrolment process as described today support such proxy options? If not, I think we need to re-think... 

Michael

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Tue, 12 Apr 2016 16:30:38 +0000

Grat point. We need option 82. Lets see if this tls proxy draft from michaelR that max just mentioned can be of help or expanded.

Sent from my Samsung Captivate Glide on AT&T

"Michael Behringer (mbehring)" <[email-masked]> wrote:
When a new device enrols, an operator will want to know WHERE this device is connecting. This includes the proxy identity, plus the interface on the proxy. (Potentially more)

Michael

_______________________________________________
Anima-bootstrap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima-bootstrap

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Apr 2016 20:14:18 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    > When a new device enrols, an operator will want to know WHERE this
    > device is connecting. This includes the proxy identity, plus the
    > interface on the proxy. (Potentially more)

    > The proxy identity can be figured out by looking at the source address
    > of the incoming packets; but the interface information needs to be
    > added explicitly, somehow.

Yes, source address of encapsulating packet, and since it's an ACP, and since
the proxy negotiated via GRASP with the registrar, the registrar already
knows everything.

I don't see the problem.

    > Can our enrolment process as described today support such proxy
    > options? If not, I think we need to re-think...

I think it's a MITM attack for the proxy to add any information to the secure part.
Any information not under the security enclosure may be untrustworthy.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Apr 2016 12:46:54 +1200

> Any information not under the security enclosure may be untrustworthy.

If there's a need to discover topology, which I understood
Michael B was after, couldn't that be done after enrolment, with
no security risk?

   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 12 Apr 2016 17:48:12 -0700

Michael:

As MichaelB mentioned, it is quite normal that backend devices
try to match up new devices to some port on the connecting device,
eg: When a client connects to a switch and sends a DHCP request,
the switch adds into the request a DHCP option 82 with the name
of the switch port to which the client is connected. That triggers
on the DHCP server some policies built against the location that
client connects to.

I agree that we can not have the proxy break into the TLS connection,
but Max was mentioning that there is some data that clients add
in some initial TLS setup packet to help a proxy determine which
TLS server to connect to (connect-server ??). So there seemingly are
parts of the initial connection setup where information can be
added in the clear. So why could we not also use this trick and have
the proxy add an "option 82" type information piece to the setup packet
it sends to the registrar ? The proxy can ensure that it overrides/fixes
up any such option 82 if it receives it from the client, and the
registrar can trust the option 82 because it receives it via the
ACP.

Imagine the proxy switch has links to totally different client-side
locations.  It would be a perfect policy to reject enrollment if the device
was mixed up and sent to the wrong location.

Cheers
    toerless

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

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 12 Apr 2016 17:49:57 -0700

> Michael B was after, couldn't that be done after enrolment, with

I am sure operators would love to have the option to reject enrollment
if the device is in a wrong location. 

And yes, topology discovery for the ACP overall is one of those ASA
functions i'd love us to get to, but it wouldn't solve by itself this
issue.

Cheers
    Toerless

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Apr 2016 08:53:08 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> I think it's a MITM attack for the proxy to add any information to the
    >> secure part.  Any information not under the security enclosure may be
    >> untrustworthy.

    > If there's a need to discover topology, which I understood Michael B
    > was after, couldn't that be done after enrolment, with no security
    > risk?

yes: exactly.  In fact, after enrollment, the resulting ACP that the new node
might form might have nothing to do with the topology used for enrollment.

I see no reason for the registrar to care about enrollment topology.

Consider two 14U BFRs in adjacent cabinets that use BTLE to enroll, establish
an ACP between them, and then configure the correct lambdas to light up the
100Gb/s links between them.
A new ACP link then comes up across that link (maybe using macsec..)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Apr 2016 09:00:57 -0400

> if the device is in a wrong location.

<putting my operator hat on, [AS26227, AS26413]>

That's silly.  Either it's your device, or it's not.
Even if it is in the wrong location, enrolling the device makes sense.
Unless it's completely the wrong *model* and hasn't got any interfaces of the
right type, getting the new service online usually takes priority.
Installing a $300 8-port firewall instead of the $200 2-port firewall isn't a
disaster. If the model was close enough, you'd want to consider the cost of
shipping vs the cost difference of the devices.

You might ship the *correct* model out once you figure this out and have
remote hands swap cables later on, but that's essentially a capital
allocation question.

If you know enough in advance to know which device (down to the SN) was
supposed to be in each location, then I don't think you need/have a zero-touch
situation.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Apr 2016 09:06:03 -0400

Toerless Eckert <[email-masked]> wrote:
    > As MichaelB mentioned, it is quite normal that backend devices try to
    > match up new devices to some port on the connecting device, eg: When a
    > client connects to a switch and sends a DHCP request, the switch adds
    > into the request a DHCP option 82 with the name of the switch port to
    > which the client is connected. That triggers on the DHCP server some
    > policies built against the location that client connects to.

yes, I'm very much aware of option 82, and I've set it up and used it
regularly, even wrote DHCP relay code.
I'll note that DHCP has no other (deployed) security.
Lots of vendors DHCP relay's option-82 processing did the wrong thing.

    > but Max was mentioning that there is some data that clients add in some
    > initial TLS setup packet to help a proxy determine which TLS server to
    > connect to (connect-server ??). So there seemingly are parts of the

Are you talking about SNI?

    > initial connection setup where information can be added in the
    > clear. So why could we not also use this trick and have the proxy add
    > an "option 82" type information piece to the setup packet it sends to
    > the registrar ? The proxy can ensure that it overrides/fixes up any
    > such option 82 if it receives it from the client, and the registrar can
    > trust the option 82 because it receives it via the ACP.

Because it means the proxy is now doing deep packet inspection.

    > locations.  It would be a perfect policy to reject enrollment if the
    > device was mixed up and sent to the wrong location.

And then what?  Truck roll?

Devices get installed in the wrong locations regularly.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 13 Apr 2016 14:36:19 +0000

> Unless it's completely the wrong *model* and hasn't got any interfaces of
> the right type, getting the new service online usually takes priority.
> remote hands swap cables later on, but that's essentially a capital allocation
> question.
> 
> supposed to be in each location, then I don't think you need/have a zero-
> touch situation.

I've heard the requirement quite a few times to be able to see where in the network a device is trying to enrol. For starters, assuming you are shipping devices to install locations randomly, then you can make the link between device and target config. 

If pushed hard, you could argue against this I guess; you could argue that you can first let the device enrol, THEN check where it is. 

Just saying: I've heard this request quite a few times; we can choose to ignore it, and argue our model. But seems the operational procedures are set up that way today, and we'd fit in more easily with what's done today. 

My feeling: Unless a big issue, would be good to support the passing on of proxy information in the bootstrap protocol. 

Michael

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Apr 2016 11:18:15 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    >> If you know enough in advance to know which device (down to the SN)
    >> was supposed to be in each location, then I don't think you need/have
    >> a zero- touch situation.

    > I've heard the requirement quite a few times to be able to see where in
    > the network a device is trying to enrol. For starters, assuming you are
    > shipping devices to install locations randomly, then you can make the
    > link between device and target config.

why?  and once you reject the device, what happens next?  How does the
device communicate back to the installer: "I'm in the wrong place"
vs,  "This isn't the network I'm looking for"?
Remember: we are doing this so that the installer can be clueless.

Can you please me more precise then "I've heard"?  I'd like the real
customer belief here.

Does the customer understand the new model, or are they working on their old
DHCP thinking?

    > My feeling: Unless a big issue, would be good to support the passing on
    > of proxy information in the bootstrap protocol.

I claim you can do this with origin address.  We already have to have a
unique ACP origin address *per link* because we have to know how to return
the packets to the correct link.

I also claim it is less hassle to it via origin address, because otherwise a
network configuration has to reach out to the proxy and provision it with the
right info for each interface as to "location".

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 13 Apr 2016 15:30:51 +0000

> Can you please me more precise then "I've heard"?  I'd like the real customer
> belief here.

Need to dig - that goes several years back...
 
> Does the customer understand the new model, or are they working on their
> old DHCP thinking?
> 
> I claim you can do this with origin address.  We already have to have a unique
> ACP origin address *per link* because we have to know how to return the
> packets to the correct link.

Err... I'm not parsing that - an ACP address per link? I must have missed something. In my mental model an AN node has an ACP *loopback* but links are only addressed with link local? Can you expand? 

Michael

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 13 Apr 2016 08:55:45 -0700

MichaelR:

So, lets talk use-case:

Consider that you have edge ports going to secure and less secure locations.
(secure: links ending up on your own premises vs. those ending up on customer
 premises).  Consider you have *yuck* devices with only UDI. You only want to
give them a cert when they connect to a secure location(port). Only S-UDI into
customer-prem locations.

Consider you do have any reason to make sure devices are only deployed in ghe
right location. If device shows up in wrong location, you need an exception
re-shipment to the right location. Imagine you care about NSA interception or
the like. Handing out the certificate later is more secure.

Consider the operator in the NOC sits on a console with a GUI saying
"Device XXX (destined for location X) has connected in location Y". Enroll ?
Yes, he could always enrol, but then there is more work afterwards in for
example quarantining or changing target configs for the device.

Consider we do want to tie devices to location and put that into some extension
data of the certificate.

Cheers
    Toerless

P.S.: I am a bit preoccupied on this whole thing because i had around year 2000 a
perfect ATM-PVC based home IP connection into Cisco, and when those became too
expensive and we got IPsec VPN, our IT security introduced all type of additional
checks (like having to authenticate myself as a user on every device), and when i 
inquired with our InfoSec team they told me that for their security evaluation,
a key difference is that the prior ATM-PVC solution gave them location security,
aka: network access only went to a well known location (my home). I could refute
that argument, so i filed what became US8886934. Arguably, location info in
the cert would be one possible element to implement that patent ;-))

---

From: peter van der Stok <[email-masked]>
Date: Thu, 14 Apr 2016 09:33:38 +0200

> example quarantining or changing target configs for the device.
Yes, this is possible,
but many questions pop up:
what is the granularity of the location: room, exact coordinate.
and why burden the manufacturer, it seems more an operational 
responsibility.
What about moving these things around?

why not a installer attribute to the certificate, or an end-user, or 
anything else?

Personally I am not too happy about such specifics.
I can imagine that additional customer/installation related attributes 
can be added, but Being too specific about their use is IMO one step too 
far.

Peter