Re: [alto] Secdir last call review of draft-ietf-alto-xdom-disc-04

Sebastian Kiesel <ietf-alto@skiesel.de> Wed, 19 December 2018 21:20 UTC

Return-Path: <sebi@gw01.ehlo.wurstkaes.de>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A71130EC9; Wed, 19 Dec 2018 13:20:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=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 YGj7b3BUD008; Wed, 19 Dec 2018 13:20:12 -0800 (PST)
Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8602E130E86; Wed, 19 Dec 2018 13:20:09 -0800 (PST)
Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.89) (envelope-from <sebi@gw01.ehlo.wurstkaes.de>) id 1gZjG8-00056y-EJ; Wed, 19 Dec 2018 22:20:04 +0100
Date: Wed, 19 Dec 2018 22:20:04 +0100
From: Sebastian Kiesel <ietf-alto@skiesel.de>
To: Liang Xia <frank.xialiang@huawei.com>
Cc: secdir@ietf.org, draft-ietf-alto-xdom-disc.all@ietf.org, ietf@ietf.org, alto@ietf.org
Message-ID: <20181219212004.3wyr4nq6mcq4c5ug@gw01.ehlo.wurstkaes.de>
References: <154346082207.13636.11710948370196493817@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <154346082207.13636.11710948370196493817@ietfa.amsl.com>
Accept-Languages: en, de
Organization: my personal mail account
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/iuojZVA_EY0LIHx0RzLj9DrG5no>
Subject: Re: [alto] Secdir last call review of draft-ietf-alto-xdom-disc-04
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2018 21:20:15 -0000

Hi,

thanks for the review!

[draft-ietf-alto-xdom-disc-04]
On Wed, Nov 28, 2018 at 07:07:02PM -0800, Liang Xia wrote:
> Reviewer: Liang Xia
> Review result: Ready
> In general, this draft is in good shape, including the security
> considerations part.
> 
> I just have some general comments or confusions for discussion as below:
>
> 1. I don't see the content about the authorization policy for alto server
> information distribution, is it necessary? 

Sorry, I'm not completely sure what that question means.

In section 6.3 we state that in all use cases we have studied so far,
the mapping from an IP address to the URI of an ALTO server (that
can give information related to that IP address) is public information.
Therefore, we do not need authentication/authorization/access control
for the XDOM procedure as such.  Once the URI is discovered and the ALTO
client has sent a query to the ALTO server, the ALTO server may do some
kind of access control and refuse to return information to the ALTO
client.

Or is it about an ISP that puts the wrong NAPTR records into their
subdomain of in-addr.arpa., thus pointing to the wrong (sombody else's)
ALTO server?  That would cause some extra load on that other ALTO
server, but the ISP would hurt himself most, as traffic distribution in
his network could become worse and/or more unpredictable.

If I completely missed your point, please clarify.

> 2. If the replied alto server
> information message is much larger than the request message, the attack can
> trigger the reflection DDoS attack using it. Does it need to be considered?

The replies with NAPTR records are somewhat larger than the queries,
but so are the replies with PTR records in the "normal" usage scenario
for in-addr.arpa.  I don't think that XDOM will make the current
situation much worse.  How could we analyze this in more detail?

Thanks
Sebastian