Re: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-00

Rolf Winter <Rolf.Winter@neclab.eu> Thu, 08 January 2015 15:55 UTC

Return-Path: <Rolf.Winter@neclab.eu>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6171C1A8AB7 for <pcp@ietfa.amsl.com>; Thu, 8 Jan 2015 07:55:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.612
X-Spam-Level:
X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 5ftcljAvgpMK for <pcp@ietfa.amsl.com>; Thu, 8 Jan 2015 07:55:35 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110C81A8A92 for <pcp@ietf.org>; Thu, 8 Jan 2015 07:55:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D8425108EFD; Thu, 8 Jan 2015 16:55:33 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGg5CU-D4Jrx; Thu, 8 Jan 2015 16:55:33 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id BC2C31027C7; Thu, 8 Jan 2015 16:55:29 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.139]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Thu, 8 Jan 2015 16:55:30 +0100
From: Rolf Winter <Rolf.Winter@neclab.eu>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Andreas Ripke <Andreas.Ripke@neclab.eu>, "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-00
Thread-Index: AQHQFYirmqCkNIF65US/eo5AlUyMlZyQy8oAgADs44CAJNIOEA==
Date: Thu, 08 Jan 2015 15:55:29 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D91E83B4C@PALLENE.office.hd>
References: <066.6faf9d8f2702d081360dcb658d129655@tools.ietf.org> <2D2FFE4726FAF74285C45D69FDC30E79912C7F0E@PALLENE.office.hd> <787AE7BB302AE849A7480A190F8B9330048D8C34@OPEXCLILM23.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330048D8C34@OPEXCLILM23.corporate.adroot.infra.ftgroup>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.7.0.196]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/pcp/0_JSCJi8ACQH2X8uPdvDE7y8IAg>
Subject: Re: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-00
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jan 2015 15:55:38 -0000

Hi,

regarding the 128 octet maximum. In general, I am not a fan of magic constants. I would rather prefer another solution. Instead of fixing the maximum size, the draft should suggest a configuration option for the server to set a maximum acceptable ID size and an error to return if a request exceeds that size. The other PCP RFCs have done something similar, e.g. RFC 6887 section 11 it says:

PCP servers SHOULD provide a configuration option to allow
administrators to disable MAP support if they wish.

This way, we can protect against state exhaustion and remain flexible for larger IDs in the future. Would that work?

Best,

Rolf

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB | Registered in England 2832014


> -----Original Message-----
> From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of
> mohamed.boucadair@orange.com
> Sent: Dienstag, 16. Dezember 2014 07:34
> To: Andreas Ripke; pcp@ietf.org
> Subject: Re: [pcp] #74 (third-party-id-option): Mohamed Boucadair's
> comments on draft-ietf-pcp-third-party-id-option-00
> 
> Hi Andreas,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> -----Message d'origine-----
> De : pcp [mailto:pcp-bounces@ietf.org] De la part de Andreas Ripke
> Envoyé : lundi 15 décembre 2014 17:26 À : pcp@ietf.org Objet : Re:
> [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on
> draft-ietf-pcp-third-party-id-option-00
> 
> Hi,
> 
> Med's comments contain two technical modifications.
> 
> 1. A recommended fixed maximum option length of 128 octets.
> 
> Why should we (unnecessarily?) set an explicit limit to this option?
> The fixed option length (16 octets) was changed to a variable length
> with the current draft version.
> The maximum PCP packet size is 1100 octets and the client must ensure
> not to cause an overrun according to RFC6887.
> But then, in RFC7220 the maximum variable length for the description
> option is limited to 1016 octets.
> Is there any special reason to have an explicit maximum option length
> defined?
> 
> [Med] Fixing a maximum is required to help dimensioning the server and
> to avoid exhausting server's resources. Most of the identifiers I'm
> aware of don't exceed 128 octets. Hence my recommendation to use that
> maximum.
> 
> 
> 2. The newly specified THIRD_PARTY_ID option can be used alone without
> the THIRD_PARTY option.
> 
> The THIRD_PARTY_ID option is defined as an extension to the THIRD_PARTY
> option in case the THIRD_PARTY address is not sufficient.
> Using the THIRD_PARTY_ID alone  seems to be a very special use case.
> Is there a practical application to it?
> 
> [Med] A host directly connected to a network or a CPE embedding a PCP
> client can use this option to carry the identifier. The internal IP
> address is carried in the opcode header; no need for the THIRD_PARTY in
> that case. Injecting both a THIRD_PARTY option and this one is
> deployment-specific.
> 
> Andreas
> 
> 
> > -----Original Message-----
> > From: pcp issue tracker [mailto:trac@tools.ietf.org]
> > Sent: Thursday, December 11, 2014 10:23 PM
> > To: draft-ietf-pcp-third-party-id-option@tools.ietf.org;
> > mohamed.boucadair@orange.com
> > Cc: pcp@ietf.org
> > Subject: [pcp] #74 (third-party-id-option): Mohamed Boucadair's
> > comments on
> > draft-ietf-pcp-third-party-id-option-00
> >
> > #74: Mohamed Boucadair's comments on
> > draft-ietf-pcp-third-party-id-option-
> > 00
> >
> >  Comments inline in PDF copy currently at
> >  http://research.microsoft.com/~dthaler/draft-ietf-pcp-third-party-
> id-
> >  option-00-Med.pdf
> >
> > --
> > -------------------------------------+-------------------------------
> -
> > -------------------------------------+-----
> >  Reporter:                           |      Owner:  draft-ietf-pcp-
> third-
> >   mohamed.boucadair@orange.com       |  party-id-
> option@tools.ietf.org
> >      Type:  defect                   |     Status:  new
> >  Priority:  major                    |  Milestone:  milestone1
> > Component:  third-party-id-option    |    Version:  1.0
> >  Severity:  In WG Last Call          |   Keywords:
> > -------------------------------------+-------------------------------
> -
> > -------------------------------------+-----
> >
> > Ticket URL: <https://tools.ietf.org/wg/pcp/trac/ticket/74>
> > pcp <http://tools.ietf.org/pcp/>
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp