Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC

Joel Jaeggli <joelja@bogus.com> Tue, 28 April 2009 14:53 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6053A70EF for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 28 Apr 2009 07:53:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level:
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGZ3caTyziml for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 28 Apr 2009 07:53:04 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3AD9F3A70E6 for <v6ops-archive@lists.ietf.org>; Tue, 28 Apr 2009 07:53:04 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1Lyog0-00075B-Tw for v6ops-data0@psg.com; Tue, 28 Apr 2009 14:52:52 +0000
Received: from [2001:418:1::81] (helo=nagasaki.bogus.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <joelja@bogus.com>) id 1Lyofi-00073G-Pl for v6ops@ops.ietf.org; Tue, 28 Apr 2009 14:52:45 +0000
Received: from [192.168.1.233] (c-98-234-53-212.hsd1.ca.comcast.net [98.234.53.212]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n3SEqTC2025366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Apr 2009 14:52:32 GMT (envelope-from joelja@bogus.com)
Message-ID: <49F7182C.5000407@bogus.com>
Date: Tue, 28 Apr 2009 07:52:28 -0700
From: Joel Jaeggli <joelja@bogus.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090409)
MIME-Version: 1.0
To: teemu.savolainen@nokia.com
CC: dwing@cisco.com, fred@cisco.com, v6ops@ops.ietf.org, kurtis@kurtis.pp.se, rbonica@juniper.net, Basavaraj.Patil@nokia.com, jouni.korhonen@nsn.com
Subject: Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC
References: <32129337-7BED-4D7A-AF06-BC5ABB37D994@cisco.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27F2C05DC3@NOK-EUMSG-01.mgdnok.nokia.com> <016701c9c506$97ff5ae0$c5f0200a@cisco.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27F2C964DF@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F27F2C964DF@NOK-EUMSG-01.mgdnok.nokia.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.94.2/9298/Tue Apr 28 11:47:45 2009 on nagasaki.bogus.com
X-Virus-Status: Clean
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

teemu.savolainen@nokia.com wrote:
>> -----Original Message-----
>> From: ext Dan Wing [mailto:dwing@cisco.com] 
>> Sent: 24 April, 2009 21:01
>>
>>> I wonder why the minimum time
>>> could not be longer for IPv6? The longer the time the less need to 
>>> activate radio for keep-alive sending (on either side of the 
>> firewall 
>>> btw - consider a case where CPE has wireless WAN). In CGN case short 
>>> timeout is understandable due need to save public ports,

Having multiple assumed possibilities for timeouts means as an
application developer you can only use the lowest one, at least if you
want your stuff to work.

> but that 
>>> probably is not an issue in simple IPv6 firewall. So why 
>> e.g. not two 
>>> hours as for TCP?
>> Two hours seems a long time to leave your door open.  
> 
> True, but my main intent was to ask why the 2 minutes time period was chosen, and not e.g. 100% longer of four minutes. 
> 
>> A longer timeout could be negotiated between the the host and 
>> its CPE router using whatever protocol exists and becomes a 
>> defacto standard on IPv6 networks (e.g., draft-woodyatt-ald, 
>> UPnP IGD version 2).
> 
> Good point - not only create pinholes for listen sessions, but also for outgoing connections.
> 
> Best regards,
> 
> 	Teemu