Re: [radext] WGLC for draft-ietf-radext-bigger-packets-01

Alan DeKok <aland@deployingradius.com> Wed, 22 October 2014 14:55 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3891ACD31 for <radext@ietfa.amsl.com>; Wed, 22 Oct 2014 07:55:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 Z8HsUGLsKyRi for <radext@ietfa.amsl.com>; Wed, 22 Oct 2014 07:55:05 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 19E231ACD2E for <radext@ietf.org>; Wed, 22 Oct 2014 07:55:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 764AE2240E39; Wed, 22 Oct 2014 16:54:34 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai6AN2ipoywc; Wed, 22 Oct 2014 16:54:34 +0200 (CEST)
Received: from Thor.local (69-165-156-239.dsl.teksavvy.com [69.165.156.239]) by power.freeradius.org (Postfix) with ESMTPSA id 9BA1D2240363; Wed, 22 Oct 2014 16:54:33 +0200 (CEST)
Message-ID: <5447C529.5060609@deployingradius.com>
Date: Wed, 22 Oct 2014 10:54:33 -0400
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Sam Hartman <hartmans@painless-security.com>
References: <54476510.10903@gmail.com> <5447BEA3.60805@deployingradius.com> <tsltx2wkvwq.fsf@mit.edu>
In-Reply-To: <tsltx2wkvwq.fsf@mit.edu>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/IRrOWdvwprgZH9ubwNHzwmiQ040
Cc: "radext@ietf.org" <radext@ietf.org>, Jouni Korhonen <jouni.nospam@gmail.com>, Stefan Winter <stefan.winter@restena.lu>
Subject: Re: [radext] WGLC for draft-ietf-radext-bigger-packets-01
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Oct 2014 14:55:12 -0000

Sam Hartman wrote:
> If you want to pretend we live in a post-data-types world and start that
> world now I'd be delighted.

  I'm all for that.  Call it an "integer" attribute as per RFC 2865
Section 5, and we're done.

> I can see two choices.
> Pick one, or pick the one that is appropriate for what you're responding
> to.

  It's hard to know which packet type is being responded to.

> I don't think it matters that much, no.
> If it does you can see which of the packets you sent is bigger than the
> response length you just got.

  That might be hard work, if the client is sending 100's of 1000's of
packets.  The packets will be sorted by socket, IPs, ports, etc.  Not by
size.

> I'd really rather not do that; it seems rather complex and I'd really
> like to try and find a way to make this mechanism simple.

  I'd prefer to not overload Access-Reject or Accounting-Response.
Those are for *normal* situations.  i.e. they do signaling for users,
not for protocol errors.

  That means we need a new packet code.

> Let's explore how important it is that clients be able to match the
> too-big packet and if so how difficult that ends up being.

  TBH, the simplest thing would be to include the original packet code
in a new attribute.  That way the peer receiving the packet knows how to
find the original.  It can match code, src/dst IP, src/dst port.

  And change the name of the packet code. A generic name is much
prettier than a specific one.

  i.e.:

Packet code == Protocol-Error
   Attribute-TBD = Access-Request
   Error-Cause = Packet-Too-Big
   Response-Length = 8192

  The packet signing rules should be the same as for Access-Accept, I
think.  i.e. copy the original vector to the response vector and sign.
Even if the original was Accounting-Request.

  I think that's simple, has minimal changes to the document, and has
minimal changes to existing implementations.

  Alan DeKok.