Re: What is the right way to do Web Services discovery?

Jared Mauch <jared@puck.nether.net> Tue, 22 November 2016 20:07 UTC

Return-Path: <jared@puck.nether.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D9F129691 for <ietf@ietfa.amsl.com>; Tue, 22 Nov 2016 12:07:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, 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 fKz5XBlW5eDg for <ietf@ietfa.amsl.com>; Tue, 22 Nov 2016 12:07:17 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3D8129762 for <ietf@ietf.org>; Tue, 22 Nov 2016 12:07:17 -0800 (PST)
Received: from [IPv6:2603:3015:3603:8e00:9591:1a75:3eab:50c1] (unknown [IPv6:2603:3015:3603:8e00:9591:1a75:3eab:50c1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id AA3875406A4; Tue, 22 Nov 2016 15:07:07 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: What is the right way to do Web Services discovery?
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <CAPt1N1n57EKc8aQM2VtUofLQLmiRcdgEVM8aboDG0mJzB93NDQ@mail.gmail.com>
Date: Tue, 22 Nov 2016 15:07:07 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <42E9FAA0-CD49-4354-A6B2-28959AC5DDA4@puck.nether.net>
References: <CAMm+LwgtJuLdL_RKJNSVNGODGj8D25nfj0jkhnBLFS=aaXG+rA@mail.gmail.com> <D98F5496-1190-41A5-9C49-77CD153934DB@puck.nether.net> <CAPt1N1n57EKc8aQM2VtUofLQLmiRcdgEVM8aboDG0mJzB93NDQ@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/DIJZZec6lLES3b4vkIYG28WqRdo>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Nov 2016 20:07:19 -0000

> On Nov 22, 2016, at 2:52 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
> I assume y'all have read RFC 6763…


I have, but $dayjob i run routers not write web browsers :-)

The key here is there are tools to do this, but it requires changing the ecosystem in how all these http transactions occur.  As a network operator this is a transparent change to me, and our DNS servers will just see the different QTYPE launched, similar to how we see both A+AAAA queries from the applications our customers operate.

The problem is as usual is educating people to move from functions like gethostbyname() to getaddrinfo() and what it would take to move people beyond the registry for port ranges, etc.. should the decision be made to go there.

I suspect nothing will change, but the indirection would help with issues seen in the DNSBUNDLED BoF held at IETF-97.  It would not exclusively resolve them, but would help in ways that DNAME and other RRTypes have not.

it’s way easier to so sin.port=(80||443); vs using dnssd related functions or doing res_query and parsing the types.

When we do DDoS mitigation and appliances send 302 to force authentication of the client there are many people who rolled their own HTTP API and didn’t implement following of the redirect and break.  We’ve been asked to then turn off the mitigation techniques if there is no good control over the calling API implementers who just claim “$Application is broken” vs “We didn’t think we needed to follow the entire HTTP specification, because we rarely see that case”

These are mostly human issues around code re-use, poor or outdated examples and commonly repeated myths combined with actual broken devices that fall into that 1% threshold I mentioned previously.

- Jared