IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 13 April 2016 13:06 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC7212D9CA for <anima-bootstrap@ietfa.amsl.com>; Wed, 13 Apr 2016 06:06:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level:
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4H6TW5O0Gw6 for <anima-bootstrap@ietfa.amsl.com>; Wed, 13 Apr 2016 06:06:04 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A64712D9A8 for <anima-bootstrap@ietf.org>; Wed, 13 Apr 2016 06:06:04 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F06B72002A for <anima-bootstrap@ietf.org>; Wed, 13 Apr 2016 09:09:59 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9630963755 for <anima-bootstrap@ietf.org>; Wed, 13 Apr 2016 09:06:03 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "anima-bootstrap@ietf.org" <anima-bootstrap@ietf.org>
In-Reply-To: <20160413004812.GG21173@cisco.com>
References: <5c12b5d6940d4970bd3c0ad4c94b4696@XCH-RCD-006.cisco.com> <14252.1460506458@obiwan.sandelman.ca> <20160413004812.GG21173@cisco.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Wed, 13 Apr 2016 09:06:03 -0400
Message-ID: <19468.1460552763@obiwan.sandelman.ca>
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima-bootstrap/zTMUeZsByq128-XpR7W-kEJad4g>
Subject: Re: [Anima-bootstrap] Can the proxy add information during bootstrap?
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2016 13:06:06 -0000

Toerless Eckert <eckert@cisco.com> 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.

    > 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

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.

    > 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.

And then what?  Truck roll?

Devices get installed in the wrong locations regularly.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email