Re: [Seamoby] issue-#49: Length indicator for Router Certificate sub-option

Marco Liebsch <marco.liebsch@ccrle.nec.de> Tue, 11 May 2004 17:39 UTC

Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11190 for <seamoby-archive@odin.ietf.org>; Tue, 11 May 2004 13:39:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNb2m-0003XS-IX for seamoby-archive@odin.ietf.org; Tue, 11 May 2004 13:27:52 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BHRqMm013597 for seamoby-archive@odin.ietf.org; Tue, 11 May 2004 13:27:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNapj-0000QA-Mb for seamoby-web-archive@optimus.ietf.org; Tue, 11 May 2004 13:14:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09439 for <seamoby-web-archive@ietf.org>; Tue, 11 May 2004 13:14:21 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNaph-0005Bt-U6 for seamoby-web-archive@ietf.org; Tue, 11 May 2004 13:14:21 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNaoe-0004k7-00 for seamoby-web-archive@ietf.org; Tue, 11 May 2004 13:13:17 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNao7-0004JU-00 for seamoby-web-archive@ietf.org; Tue, 11 May 2004 13:12:43 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaZy-0004vM-S1; Tue, 11 May 2004 12:58:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNaNQ-0001ri-Pw for seamoby@optimus.ietf.org; Tue, 11 May 2004 12:45:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07695 for <seamoby@ietf.org>; Tue, 11 May 2004 12:45:04 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNaNP-0000Mg-5Y for seamoby@ietf.org; Tue, 11 May 2004 12:45:07 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNaMW-0007kG-00 for seamoby@ietf.org; Tue, 11 May 2004 12:44:13 -0400
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BNaLn-0007HL-00 for seamoby@ietf.org; Tue, 11 May 2004 12:43:27 -0400
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i4BGgtDW049799 for <seamoby@ietf.org>; Tue, 11 May 2004 18:42:56 +0200 (CEST)
Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i4BGgRYb049782 for <seamoby@ietf.org>; Tue, 11 May 2004 18:42:27 +0200 (CEST)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <marco.liebsch@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i4BGgQDW049780; Tue, 11 May 2004 18:42:27 +0200 (CEST)
Received: from ccrle.nec.de (pluto.office [10.1.1.84]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6A7A9127035; Tue, 11 May 2004 17:42:26 +0200 (CEST)
Message-ID: <40A10272.8010701@ccrle.nec.de>
Date: Tue, 11 May 2004 18:42:26 +0200
From: Marco Liebsch <marco.liebsch@ccrle.nec.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Kempf <kempf@docomolabs-usa.com>
Cc: seamoby@ietf.org
Subject: Re: [Seamoby] issue-#49: Length indicator for Router Certificate sub-option
References: <01e101c432f0$ceaf6ec0$366115ac@dcml.docomolabsusa.com>
In-Reply-To: <01e101c432f0$ceaf6ec0$366115ac@dcml.docomolabsusa.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
Content-Transfer-Encoding: 7bit
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>, <mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>, <mailto:seamoby-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

James Kempf wrote:

>All the length fields in CARD are 8 bits, which means restricts the size of
>messages to 254 bytes. This length is insufficient for certificates.
>
>An additional concern is that if the length field of the entire
>Request/Reply mesage is the same as the sub-option length field, the
>sub-option generator may want generate an option longer than would fit into
>the message, since this would be allowed by the field length. The solution
>for this in any case is for the sub-option generator code to respect the
>overall limits on the message length, in addition to the sub-option length.
>
>Proposal 1: Keep the length field size at 8 bits and make the units of
>length be 8 octets, for a maximum 1634 bits  or 2048 bytes.
>
>Proposal 2: Change the length field size to 16 bits, for a total of 65535
>bits or 8192 bytes.
>
>Suggested resolution: Proposal 2
>
>Reason: Proposal 1 could result in a maximum of up to 7 padding bytes of
>null data in an option or sub-option which is an extra overhead that is
>unnecessary and unwanted over the air.
>
>  
>
Well, this is only my opinion, but if we transmit certs of size > 1kbyte 
over the air with
a CARD Reply, who cares about 7 bytes padding... What bothers me with 
the 16-bit proposal is
that potentially the length of this sub-option can be much larger than 
the length of the option it
is encapsulated with, which is max 256 x 8bytes long. And even when 
having resolution of
1 byte with 16-bit length identifier, requirement for all sub-options is 
to take care about 32-bit
boundary alignment.
Hence, max overhead with proposal 1 is 4 bytes, right?

What do others think?

marco

>            jak
>
>
>
>_______________________________________________
>Seamoby mailing list
>Seamoby@ietf.org
>https://www1.ietf.org/mailman/listinfo/seamoby
>  
>



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby