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

<teemu.savolainen@nokia.com> Tue, 28 April 2009 14:24 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 40A6E3A70C8 for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 28 Apr 2009 07:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.008
X-Spam-Level:
X-Spam-Status: No, score=-5.008 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 vaexBeAYnZtm for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 28 Apr 2009 07:24:30 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C4103A6910 for <v6ops-archive@lists.ietf.org>; Tue, 28 Apr 2009 07:24:30 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1Lyo9b-0004FA-Rt for v6ops-data0@psg.com; Tue, 28 Apr 2009 14:19:23 +0000
Received: from [192.100.122.233] (helo=mgw-mx06.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <teemu.savolainen@nokia.com>) id 1Lyo9P-0004Dq-I1 for v6ops@ops.ietf.org; Tue, 28 Apr 2009 14:19:17 +0000
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3SEIm9r018451; Tue, 28 Apr 2009 17:18:48 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 17:18:35 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 17:18:22 +0300
Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 28 Apr 2009 16:18:22 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Tue, 28 Apr 2009 16:18:22 +0200
From: teemu.savolainen@nokia.com
To: dwing@cisco.com, fred@cisco.com, v6ops@ops.ietf.org
CC: kurtis@kurtis.pp.se, rbonica@juniper.net, Basavaraj.Patil@nokia.com, jouni.korhonen@nsn.com
Date: Tue, 28 Apr 2009 16:17:41 +0200
Subject: RE: draft-ietf-v6ops-cpe-simple-security-04 WGLC
Thread-Topic: draft-ietf-v6ops-cpe-simple-security-04 WGLC
Thread-Index: Acm94LDbhPGzIm4HRiWyaNi4/b1q9wG67OsgAA5ZdaAAwXdusA==
Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F27F2C964DF@NOK-EUMSG-01.mgdnok.nokia.com>
References: <32129337-7BED-4D7A-AF06-BC5ABB37D994@cisco.com> <18034D4D7FE9AE48BF19AB1B0EF2729F27F2C05DC3@NOK-EUMSG-01.mgdnok.nokia.com> <016701c9c506$97ff5ae0$c5f0200a@cisco.com>
In-Reply-To: <016701c9c506$97ff5ae0$c5f0200a@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Apr 2009 14:18:22.0792 (UTC) FILETIME=[300A6480:01C9C80C]
X-Nokia-AV: Clean
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

>-----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, 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