From denglingli@gmail.com Sat Sep 1 08:18:56 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EC111E810F for ; Sat, 1 Sep 2012 08:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.451 X-Spam-Level: * X-Spam-Status: No, score=1.451 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7DsCjMkc3iv for ; Sat, 1 Sep 2012 08:18:56 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0865D11E80BA for ; Sat, 1 Sep 2012 08:18:55 -0700 (PDT) Received: by qadz3 with SMTP id z3so1676924qad.10 for ; Sat, 01 Sep 2012 08:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IROZRAhymKX+9uIpubNy+j0djKhlHts4LSJtC3nWfDA=; b=OETsBS/D6tlnxotQoyE90rLykZosyIcV2k7NkAO61T9MKi925cBtKARrL22B5AGh/R RMBIDWk7iabtM/JXZsJPNFwMsFEsJE4zM752oPS3bq0N1kRvY3zE5fGE5Ql7NwZ5VDXI 5ghukQYxOqkXWuGKFTcV86qaAk5S1FI0/vAFlj3+IOWCW/ON3oyHKqP1xFEWFw788Pwc RcnBIiKVU4Rwy0N63UD28dj0hinq+6DI1lDSrx9ElPDuOXc2eiqLL9WaTiXtBSWl/ftn oTHlRilfchNr6Vv1/517bLBRcu/Ff8VFAHQlvb1QJeLHj1Pvdo7Y41kDnNXj4OVHIc5n av+w== MIME-Version: 1.0 Received: by 10.229.135.84 with SMTP id m20mr6948428qct.89.1346512735274; Sat, 01 Sep 2012 08:18:55 -0700 (PDT) Received: by 10.49.119.168 with HTTP; Sat, 1 Sep 2012 08:18:55 -0700 (PDT) In-Reply-To: References: <1344288993.5752.47.camel@acorde.it.uc3m.es> Date: Sat, 1 Sep 2012 23:18:55 +0800 Message-ID: From: lingli deng To: Songhaibin Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "p2psip-chairs@tools.ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-rpr-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 15:18:56 -0000 +1 I read both drafts and support to move forward. Lingli 2012/8/27 Songhaibin : > I also support both RPR and DRR drafts and think they are ready to submit= . > > BR, > -Haibin > >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf= Of >> David A. Bryan >> Sent: Tuesday, August 14, 2012 10:19 PM >> To: cjbc@it.uc3m.es >> Cc: p2psip-chairs@tools.ietf.org; p2psip@ietf.org >> Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-rpr-02 >> >> Both of the routing drafts (rpr and drr) are drafts I've supported for >> a long while. I took a peek at the most recent versions, and they >> definitely appear ready to submit to me. >> >> David >> >> On Mon, Aug 6, 2012 at 4:36 PM, Carlos Jes=A8=B2s Bernardos Cano >> wrote: >> > Hi, >> > >> > Hereby we are issuing a WGLC for draft-ietf-p2psip-rpr-02. >> > >> > The WGLC will be open till the 3rd of September to give enough time fo= r >> > people to review considering the summer break. We kindly ask the WG to >> > review the document and provide comments. >> > >> > If you have no comments and think the document is ready to be submitte= d >> > to IESG, please do send a note stating that to the WG ML. >> > >> > Additional information about the document is below: >> > >> > Title : An extension to RELOAD to support Relay Peer >> > Routing >> > Author(s) : Ning Zong >> > Xingfeng Jiang >> > Roni Even >> > Yunfei Zhang >> > Filename : draft-ietf-p2psip-rpr-02.txt >> > Pages : 15 >> > Date : 2012-05-29 >> > >> > This document proposes an optional extension to RELOAD to support >> > relay peer routing mode. RELOAD recommends symmetric recursive >> > routing for routing messages. The new optional extension provides = a >> > shorter route for responses reducing the overhead on intermediary >> > peers and describes the potential cases where this extension can be >> > used. >> > >> > >> > A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-ietf-p2psip-rpr-02.txt >> > >> > >> > The IETF datatracker page for this Internet-Draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-p2psip-rpr/ >> > >> > >> > Thank you for your support. >> > >> > -- Brian and Carlos >> > >> > >> > _______________________________________________ >> > P2PSIP mailing list >> > P2PSIP@ietf.org >> > https://www.ietf.org/mailman/listinfo/p2psip >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --=20 =B5=CB=C1=E9=C0=F2/Lingli Deng =D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Researc= h Institute e-mail: denglingli@chinamobile.com tel: 15801696688-3367 mobile: 13810597148 From petithug@acm.org Sun Sep 2 10:57:57 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B16A21F849A for ; Sun, 2 Sep 2012 10:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edvsSFcPi0+E for ; Sun, 2 Sep 2012 10:57:56 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD7A21F8495 for ; Sun, 2 Sep 2012 10:57:56 -0700 (PDT) Received: from [IPv6:2601:9:4b80:32:213:d4ff:fe04:3e08] (unknown [IPv6:2601:9:4b80:32:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3F57F2047A; Sun, 2 Sep 2012 17:57:54 +0000 (UTC) Message-ID: <50439E1E.7030604@acm.org> Date: Sun, 02 Sep 2012 10:57:50 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1344288987.5752.46.camel@acorde.it.uc3m.es> In-Reply-To: <1344288987.5752.46.camel@acorde.it.uc3m.es> X-Enigmail-Version: 1.4.1 X-Enigmail-Draft-Status: 513 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: p2psip-chairs@tools.ietf.org, p2psip@ietf.org Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-drr-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 17:57:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I carefully read this I-D and I think it is ready to be submitted to the IESG. My only comment would be that, although the distinction between node, peer and client is clearly explained in section 2, their usage in the subsequent sections is less rigorous. For example section 6 uses "peer" where it should probably use node instead. Nits - ---- - - Section 1.1: s/intermediary peers ./intermediary peers./ - - Section 6.2: s/state- keeping/state-keeping/ - - Section 6.2.1: s/flag : 0x8/flag : 0x08/ s/VIA list/via_list/ - - Section 6.2.2; s/section 5.3.2.3/section 6.3.2.3/ s/Destination destination<1..2^8-1>;/Destination destinations<1..2^8-1>;/ s/section 5.5.1.1/section 6.5.1.1/ s/section 5.3.2.2/section 6.3.2.2/ s/section 5.3.1.1/section 6.3.1.1/ s/node's node-id./node's Node-ID./ (node-id used at other places in the i_D) - - Section 6.3.1: s/defined as type peer/defined as type node/ - - Section 6.4.2: s/trying to response/trying to respond/ - - Section 7.1: s/a STUN usage [I-D.ietf-behave-nat-behavior-discovery]/a STUN usage [RFC5780]/ UPnp-IGD and NAT-PMP are missing references. - - Section 9.1: Type: 0x2 Should be formatted as section 14.12 in -base. On 08/06/2012 02:36 PM, Carlos Jesús Bernardos Cano wrote: > Hi, > > Hereby we are issuing a WGLC for draft-ietf-p2psip-drr-02. > > The WGLC will be open till the 3rd of September to give enough time for > people to review considering the summer break. We kindly ask the WG to > review the document and provide comments. > > If you have no comments and think the document is ready to be submitted to > IESG, please do send a note stating that to the WG ML. > > Additional information about the document is below: > > Title : An extension to RELOAD to support Direct Response > Routing Author(s) : Ning Zong Xingfeng Jiang Roni Even Yunfei Zhang > Filename : draft-ietf-p2psip-drr-02.txt Pages : 18 Date > : 2012-05-29 > > This document proposes an optional extension to RELOAD to support direct > response routing mode. RELOAD recommends symmetric recursive routing for > routing messages. The new optional extension provides a shorter route for > responses reducing the overhead on intermediary peers and describes the > potential cases where this extension can be used. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-p2psip-drr-02.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-drr/ > > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQQ54cAAoJECnERZXWan7EAJ8QALis/HDuHw3DGcXeXBSH1o1M 32q0l48oguxME/pQeMUcU6cuwuDMzU8277irhC4zUluvcZp07XJhTNp/T/heXSe0 2vWe5O+hg+D219y3dr78Zq6+MKE/NiBiKJBIjM8jHGmQAjs++BCePhLCXBV54oe4 oCNVj46LSXQhud87HIOBDvb1Lfrx0N2TAl3EWLJ4yWSxaImTjrAhXfCHH2volz0Z lRcbSWktWUDSXna2dp4gdsArtE2oAI1Swcebknj5Epo+JoC6Okbl0j094I8o3ogr j2/p4N1H4NrZZlsn4hxJKeTBDa8/XQMiojCa/D9uro7uDgcxsROkrkxdagCxdQfD bAr35lfPLSalrWf8jcomhwHhFUTPrFPW/ShnODG9sfeUAyBGZOONikwcv+FS7VSL XLy8B4MViFQmBMBC+RB0fUlKb2P06p919l5GsfMyOuPHFPRNw1pXmOj2FVB1IC6f fl65mM7u4xT0BrutLLUqBU9+oV7XzEOBGkAnpJsoZNr0/a/2Dbw7rKP+AoQTb3Rs 9PDHibjtJOnPlsnhGWyXu7adhkKeMQ88IsaTawyMkcRxUEBRdKFzdxd6iam9VDt0 IUvCTSNKcVLxJIdxh02yfsiC3sn1qoYGnwSXCYqWL9cnJKnPqzuAOCHnPUrLCvtV INYCsR45ONXPvFUQ65Tl =ViOI -----END PGP SIGNATURE----- From petithug@acm.org Sun Sep 2 11:03:22 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EB521F84B9 for ; Sun, 2 Sep 2012 11:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXK8KqILif3u for ; Sun, 2 Sep 2012 11:03:21 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 4695621F84AE for ; Sun, 2 Sep 2012 11:03:21 -0700 (PDT) Received: from [IPv6:2601:9:4b80:32:213:d4ff:fe04:3e08] (unknown [IPv6:2601:9:4b80:32:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id D9A222047A; Sun, 2 Sep 2012 18:03:19 +0000 (UTC) Message-ID: <50439F65.1020208@acm.org> Date: Sun, 02 Sep 2012 11:03:17 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1344288993.5752.47.camel@acorde.it.uc3m.es> In-Reply-To: <1344288993.5752.47.camel@acorde.it.uc3m.es> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: p2psip-chairs@tools.ietf.org, p2psip@ietf.org Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-rpr-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 18:03:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I carefully read this I-D and I think it is ready to be submitted to the IESG. My only comment would be that, although the distinction between node, peer and client is clearly explained in section 2, their usage in the subsequent sections is less rigorous. For example section 6 uses "peer" where it should probably use node instead. Nits - ---- - - Section 6.2.2: s/node-id/Node-ID/ - - Section 6.3.1: s/type peer/type node/ - - Section 6.4.1: s/Destination list/destination_list/ s/destination list/destination_list/ - - Section 6.4.3: s/destination list/destination_list/ s/via-list/via_list/ s/destination-list/destination_list/ - - Section 8: s/out- of-band/out-of-band/ On 08/06/2012 02:36 PM, Carlos Jesús Bernardos Cano wrote: > Hi, > > Hereby we are issuing a WGLC for draft-ietf-p2psip-rpr-02. > > The WGLC will be open till the 3rd of September to give enough time for > people to review considering the summer break. We kindly ask the WG to > review the document and provide comments. > > If you have no comments and think the document is ready to be submitted to > IESG, please do send a note stating that to the WG ML. > > Additional information about the document is below: > > Title : An extension to RELOAD to support Relay Peer Routing > Author(s) : Ning Zong Xingfeng Jiang Roni Even Yunfei Zhang Filename > : draft-ietf-p2psip-rpr-02.txt Pages : 15 Date : > 2012-05-29 > > This document proposes an optional extension to RELOAD to support relay > peer routing mode. RELOAD recommends symmetric recursive routing for > routing messages. The new optional extension provides a shorter route for > responses reducing the overhead on intermediary peers and describes the > potential cases where this extension can be used. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-p2psip-rpr-02.txt > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-rpr/ > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQQ59iAAoJECnERZXWan7EircP/j0Ga7bmlltH0FTz4R6EaSMB 3I3Cm+agkNMSNKnkQT8bTBvQOwoqEJafs1pXHH4z9InXqdlETtXxZGF6firhmW9N 5KVVYx8cM1cZO0APQ5ljsQTbGHbuEiVqJz9GiWwmg1jhh+08QKlmGMdHCNffL6NQ 2GGeXsX0HCPLX0tUMGYCG/JS7qrB32r3Ia+4lvCcqN2vPPyceQx7B+bfRpuPkvLB h9plDkmk++ZNrmFcn83Ag7u9mZchpp8MWxKylK5fE7pqOT2fhMsOsJi91bGOSsmo j1SlEQYaNlyOyTsnHmYqaEBndVy7Q7KGcLaZIGi6zYpDFR4b4OoQiNkB8ru0BSdW UPFzFc5p8rcjvSN+OHp1OjrGER5bLwN5nqhyBzQnIEpbyCWfUf/aGwnvtykDu/Gj L3KcP5fBGggcbcIoHr/tb5hJF2Q+mlKDk2SyH1aePl9QyJ2wPsz70aiLZuZBnwDc mXqkqb5CRrHRdm6jVL7ehqh2qxXyP3Yufb2fy+y5+8kPwarQcrsZgNVa0qTSKN1u CwxyKnLRe4h1jmroPqaK02yCVd9TEVbmLcvwcF3g/SohTeiFryYytdurZTkHUJ66 ktjxVwrxCI+3Vxy5OCyZUXvat7ANZ3Y7Sw8O3Rq1KCtlkETr7jZVarqb3ohg/z+m ICoys3GZuUtXob40mvZp =pL0B -----END PGP SIGNATURE----- From zongning@huawei.com Sun Sep 2 21:30:48 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929BB21F846B for ; Sun, 2 Sep 2012 21:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLGGllWEeGjj for ; Sun, 2 Sep 2012 21:30:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9B96621F8466 for ; Sun, 2 Sep 2012 21:30:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJH07177; Mon, 03 Sep 2012 04:30:45 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Sep 2012 05:30:04 +0100 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Sep 2012 05:30:44 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Mon, 3 Sep 2012 12:30:37 +0800 From: Zongning To: Marc Petit-Huguenin , "cjbc@it.uc3m.es" Thread-Topic: [P2PSIP] WGLC for draft-ietf-p2psip-drr-02 Thread-Index: AQHNdBuTzPgSun1WmkmlZmID9jl1rJd2+psAgAE2pNA= Date: Mon, 3 Sep 2012 04:30:36 +0000 Message-ID: References: <1344288987.5752.46.camel@acorde.it.uc3m.es> <50439E1E.7030604@acm.org> In-Reply-To: <50439E1E.7030604@acm.org> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "p2psip-chairs@tools.ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-drr-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 04:30:48 -0000 VGhhbmtzLCBNYXJjDQoNCkkgd2lsbCByZXZpc2UgYm90aCBkcmFmdHMgYmFzZWQgb24geW91ciBj b21tZW50cy4NCg0KLU5pbmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBwMnBzaXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnAycHNpcC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YNCj4gTWFyYyBQZXRpdC1IdWd1ZW5pbg0KPiBTZW50OiBNb25kYXksIFNl cHRlbWJlciAwMywgMjAxMiAxOjU4IEFNDQo+IFRvOiBjamJjQGl0LnVjM20uZXMNCj4gQ2M6IHAy cHNpcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IHAycHNpcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW1AyUFNJUF0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1wMnBzaXAtZHJyLTAyDQo+IA0KPiAtLS0t LUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQo+IEhhc2g6IFNIQTI1Ng0KPiANCj4gSSBj YXJlZnVsbHkgcmVhZCB0aGlzIEktRCBhbmQgSSB0aGluayBpdCBpcyByZWFkeSB0byBiZSBzdWJt aXR0ZWQgdG8gdGhlIElFU0cuDQo+IA0KPiBNeSBvbmx5IGNvbW1lbnQgd291bGQgYmUgdGhhdCwg YWx0aG91Z2ggdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gbm9kZSwgcGVlcg0KPiBhbmQNCj4gY2xp ZW50IGlzIGNsZWFybHkgZXhwbGFpbmVkIGluIHNlY3Rpb24gMiwgdGhlaXIgdXNhZ2UgaW4gdGhl IHN1YnNlcXVlbnQNCj4gc2VjdGlvbnMgaXMgbGVzcyByaWdvcm91cy4gIEZvciBleGFtcGxlIHNl Y3Rpb24gNiB1c2VzICJwZWVyIiB3aGVyZSBpdCBzaG91bGQNCj4gcHJvYmFibHkgdXNlIG5vZGUg aW5zdGVhZC4NCj4gDQo+IA0KPiBOaXRzDQo+IC0gLS0tLQ0KPiANCj4gLSAtIFNlY3Rpb24gMS4x Og0KPiANCj4gcy9pbnRlcm1lZGlhcnkgcGVlcnMgLi9pbnRlcm1lZGlhcnkgcGVlcnMuLw0KPiAN Cj4gLSAtIFNlY3Rpb24gNi4yOg0KPiANCj4gcy9zdGF0ZS0ga2VlcGluZy9zdGF0ZS1rZWVwaW5n Lw0KPiANCj4gLSAtIFNlY3Rpb24gNi4yLjE6DQo+IA0KPiBzL2ZsYWcgOiAweDgvZmxhZyA6IDB4 MDgvDQo+IA0KPiBzL1ZJQSBsaXN0L3ZpYV9saXN0Lw0KPiANCj4gLSAtIFNlY3Rpb24gNi4yLjI7 DQo+IA0KPiBzL3NlY3Rpb24gNS4zLjIuMy9zZWN0aW9uIDYuMy4yLjMvDQo+IA0KPiBzL0Rlc3Rp bmF0aW9uIGRlc3RpbmF0aW9uPDEuLjJeOC0xPjsvRGVzdGluYXRpb24gZGVzdGluYXRpb25zPDEu LjJeOC0xPjsvDQo+IA0KPiBzL3NlY3Rpb24gNS41LjEuMS9zZWN0aW9uIDYuNS4xLjEvDQo+IA0K PiBzL3NlY3Rpb24gNS4zLjIuMi9zZWN0aW9uIDYuMy4yLjIvDQo+IA0KPiBzL3NlY3Rpb24gNS4z LjEuMS9zZWN0aW9uIDYuMy4xLjEvDQo+IA0KPiBzL25vZGUncyBub2RlLWlkLi9ub2RlJ3MgTm9k ZS1JRC4vDQo+IA0KPiAobm9kZS1pZCB1c2VkIGF0IG90aGVyIHBsYWNlcyBpbiB0aGUgaV9EKQ0K PiANCj4gLSAtIFNlY3Rpb24gNi4zLjE6DQo+IA0KPiBzL2RlZmluZWQgYXMgdHlwZSBwZWVyL2Rl ZmluZWQgYXMgdHlwZSBub2RlLw0KPiANCj4gLSAtIFNlY3Rpb24gNi40LjI6DQo+IA0KPiBzL3Ry eWluZyB0byByZXNwb25zZS90cnlpbmcgdG8gcmVzcG9uZC8NCj4gDQo+IC0gLSBTZWN0aW9uIDcu MToNCj4gDQo+IHMvYSBTVFVOIHVzYWdlIFtJLUQuaWV0Zi1iZWhhdmUtbmF0LWJlaGF2aW9yLWRp c2NvdmVyeV0vYSBTVFVOIHVzYWdlDQo+IFtSRkM1NzgwXS8NCj4gDQo+IFVQbnAtSUdEIGFuZCBO QVQtUE1QIGFyZSBtaXNzaW5nIHJlZmVyZW5jZXMuDQo+IA0KPiAtIC0gU2VjdGlvbiA5LjE6IFR5 cGU6IDB4Mg0KPiANCj4gU2hvdWxkIGJlIGZvcm1hdHRlZCBhcyBzZWN0aW9uIDE0LjEyIGluIC1i YXNlLg0KPiANCj4gDQo+IE9uIDA4LzA2LzIwMTIgMDI6MzYgUE0sIENhcmxvcyBKZXPDunMgQmVy bmFyZG9zIENhbm8gd3JvdGU6DQo+ID4gSGksDQo+ID4NCj4gPiBIZXJlYnkgd2UgYXJlIGlzc3Vp bmcgYSBXR0xDIGZvciBkcmFmdC1pZXRmLXAycHNpcC1kcnItMDIuDQo+ID4NCj4gPiBUaGUgV0dM QyB3aWxsIGJlIG9wZW4gdGlsbCB0aGUgM3JkIG9mIFNlcHRlbWJlciB0byBnaXZlIGVub3VnaCB0 aW1lIGZvcg0KPiA+IHBlb3BsZSB0byByZXZpZXcgY29uc2lkZXJpbmcgdGhlIHN1bW1lciBicmVh ay4gV2Uga2luZGx5IGFzayB0aGUgV0cgdG8NCj4gPiByZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBw cm92aWRlIGNvbW1lbnRzLg0KPiA+DQo+ID4gSWYgeW91IGhhdmUgbm8gY29tbWVudHMgYW5kIHRo aW5rIHRoZSBkb2N1bWVudCBpcyByZWFkeSB0byBiZSBzdWJtaXR0ZWQgdG8NCj4gPiBJRVNHLCBw bGVhc2UgZG8gc2VuZCBhIG5vdGUgc3RhdGluZyB0aGF0IHRvIHRoZSBXRyBNTC4NCj4gPg0KPiA+ IEFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGRvY3VtZW50IGlzIGJlbG93Og0KPiA+ DQo+ID4gVGl0bGUgICAgICAgICAgIDogQW4gZXh0ZW5zaW9uIHRvIFJFTE9BRCB0byBzdXBwb3J0 IERpcmVjdCBSZXNwb25zZQ0KPiA+IFJvdXRpbmcgQXV0aG9yKHMpICAgICAgIDogTmluZyBab25n IFhpbmdmZW5nIEppYW5nIFJvbmkgRXZlbiBZdW5mZWkgWmhhbmcNCj4gPiBGaWxlbmFtZSAgICAg ICAgOiBkcmFmdC1pZXRmLXAycHNpcC1kcnItMDIudHh0IFBhZ2VzICAgICAgICAgICA6IDE4IERh dGUNCj4gPiA6IDIwMTItMDUtMjkNCj4gPg0KPiA+IFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYW4g b3B0aW9uYWwgZXh0ZW5zaW9uIHRvIFJFTE9BRCB0byBzdXBwb3J0IGRpcmVjdA0KPiA+IHJlc3Bv bnNlIHJvdXRpbmcgbW9kZS4gIFJFTE9BRCByZWNvbW1lbmRzIHN5bW1ldHJpYyByZWN1cnNpdmUg cm91dGluZw0KPiBmb3INCj4gPiByb3V0aW5nIG1lc3NhZ2VzLiAgVGhlIG5ldyBvcHRpb25hbCBl eHRlbnNpb24gcHJvdmlkZXMgYSBzaG9ydGVyIHJvdXRlIGZvcg0KPiA+IHJlc3BvbnNlcyByZWR1 Y2luZyB0aGUgb3ZlcmhlYWQgb24gaW50ZXJtZWRpYXJ5IHBlZXJzIGFuZCBkZXNjcmliZXMgdGhl DQo+ID4gcG90ZW50aWFsIGNhc2VzIHdoZXJlIHRoaXMgZXh0ZW5zaW9uIGNhbiBiZSB1c2VkLg0K PiA+DQo+ID4NCj4gPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gPiBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXAycHNpcC1kcnItMDIu dHh0DQo+ID4NCj4gPiBUaGUgSUVURiBkYXRhdHJhY2tlciBwYWdlIGZvciB0aGlzIEludGVybmV0 LURyYWZ0IGlzOg0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtcDJwc2lwLWRyci8NCj4gPg0KPiA+DQo+IA0KPiAtIC0tDQo+IE1hcmMgUGV0aXQtSHVndWVu aW4NCj4gRW1haWw6IG1hcmNAcGV0aXQtaHVndWVuaW4ub3JnDQo+IEJsb2c6IGh0dHA6Ly9ibG9n Lm1hcmMucGV0aXQtaHVndWVuaW4ub3JnDQo+IFByb2ZpbGU6IGh0dHA6Ly93d3cubGlua2VkaW4u Y29tL2luL3BldGl0aHVnDQo+IC0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQo+IFZlcnNp b246IEdudVBHIHYxLjQuMTIgKEdOVS9MaW51eCkNCj4gDQo+IGlRSWNCQUVCQ0FBR0JRSlFRNTRj QUFvSkVDbkVSWlhXYW43RUFKOFFBTGlzL0hEdUh3M0RHY1hlWEJTSDENCj4gbzFNDQo+IDMycTBs NDhvZ3V4TUUvcFFlTVVjVTZjdXd1RE16VTgyNzdpcmhDNHpVbHV2Y1pwMDdYSmhUTnAvVC9oZVhT ZQ0KPiAwDQo+IDJ2V2U1TytoZytEMjE5eTNkcjc4WnE2K01LRS9OaUJpS0pCSWpNOGpIR21RQWpz KytCQ2VQaExDWEJWNTRvZQ0KPiA0DQo+IG9DTlZqNDZMU1hRaHVkODdISU9CRHZiMUxmcngwTjJU QWwzRVdMSjR5V1N4YUltVGpyQWhYZkNISDJ2b2x6MFoNCj4gbFJjYlNXa3RXVURTWG5hMmRwNGdk c0FydEUyb0FJMVN3Y2Via25qNUVwbytKb0M2T2tibDBqMDk0SThvM29ncg0KPiBqMi9wNE4xSDRO clpabHNuNGh4SktlVEJEYTgvWFFNaW9qQ2EvRDl1cm83dURnY3hzUk9rcmt4ZGFnQ3hkUWZEDQo+ IGJBcjM1bGZQTFNhbHJXZjhqY29taHdIaEZVVFByRlBXL1Nobk9ERzlzZmVVQXlCR1pPT05pa3dj ditGUzdWU0wNCj4gWEx5OEI0TVZpRlFtQk1CQytSQjBmVWxLYjJQMDZwOTE5bDVHc2ZNeU91UEhG UFJOdzFwWG1PajJGVkIxSQ0KPiBDNmYNCj4gZmw2NW1NN3U0eFQwQnJ1dExMVXFCVTkrb1Y3WHpF T0JHa0FucEpzb1pOcjAvYS8yRGJ3N3JLUCtBb1FUYjNSDQo+IHMNCj4gOVBESGlianRKT25QbHNu aEdXeVh1N2FkaGtLZU1RODhJc2FUYXd5TWtjUnhVRUJSZEtGemR4ZDZpYW05VkR0DQo+IDANCj4g SVV2Q1RTTktjVkx4SklkeGgwMnlmc2lDM3NuMXFvWUdud1NYQ1lxV0w5Y25KS25QcXp1QU9DSG5Q VXJMQ3Z0Vg0KPiBJTllDc1I0NU9OWFB2RlVRNjVUbA0KPiA9VmlPSQ0KPiAtLS0tLUVORCBQR1Ag U0lHTkFUVVJFLS0tLS0NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gUDJQU0lQIG1haWxpbmcgbGlzdA0KPiBQMlBTSVBAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCg== From t.kluge@gmx.com Mon Sep 10 23:34:07 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC80021F86F4 for ; Mon, 10 Sep 2012 23:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7i47wQcGNcq for ; Mon, 10 Sep 2012 23:34:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id C3B5A21F86EB for ; Mon, 10 Sep 2012 23:34:06 -0700 (PDT) Received: (qmail invoked by alias); 11 Sep 2012 06:34:05 -0000 Received: from p5DC57573.dip.t-dialin.net (EHLO ThomasExtreme) [93.197.117.115] by mail.gmx.net (mp031) with SMTP; 11 Sep 2012 08:34:05 +0200 X-Authenticated: #22022137 X-Provags-ID: V01U2FsdGVkX19GEHx1oIxG9KdsLnQ8+85fQTa/nG5oq2JxmIGn6t 4wJfgiUJb9Qcgb Message-ID: <1E1E1EE21BC441FABDEFADAD37A2F9FC@ThomasExtreme> From: "Thomas Kluge" To: "P2PSIP Mailing List" References: <5037C342.6040902@acm.org> In-Reply-To: <5037C342.6040902@acm.org> Date: Tue, 11 Sep 2012 08:34:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Y-GMX-Trusted: 0 Subject: Re: [P2PSIP] Extended Key Usage for RELOAD certificates X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 06:34:07 -0000 I support this as part of basic, but is should be optional. Implementors may either ignore this extended key usage or check for it, but should never reject it if it's part of the certificate. Thomas -----Ursprüngliche Nachricht----- From: Marc Petit-Huguenin Sent: Friday, August 24, 2012 8:09 PM To: P2PSIP Mailing List Subject: [P2PSIP] Extended Key Usage for RELOAD certificates From petithug@acm.org Wed Sep 12 08:23:27 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B334021F85A3 for ; Wed, 12 Sep 2012 08:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.248 X-Spam-Level: X-Spam-Status: No, score=-101.248 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_00=-2.599, MANGLED_DIET=2.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxuxYosGiT4T for ; Wed, 12 Sep 2012 08:23:27 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id BBD7A21F8554 for ; Wed, 12 Sep 2012 08:23:26 -0700 (PDT) Received: from [IPv6:2601:9:4b80:32:213:d4ff:fe04:3e08] (unknown [IPv6:2601:9:4b80:32:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id A7C8D20EA5; Wed, 12 Sep 2012 15:23:23 +0000 (UTC) Message-ID: <5050A8E9.3040003@acm.org> Date: Wed, 12 Sep 2012 08:23:21 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: Thomas Kluge References: <5037C342.6040902@acm.org> <1E1E1EE21BC441FABDEFADAD37A2F9FC@ThomasExtreme> In-Reply-To: <1E1E1EE21BC441FABDEFADAD37A2F9FC@ThomasExtreme> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Extended Key Usage for RELOAD certificates X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 15:23:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/10/2012 11:34 PM, Thomas Kluge wrote: > I support this as part of basic, but is should be optional. I now think that this should be done in a separate I-D (let's not wake the RELOAD authors up from their cryogenic statis before October 22nd :-) ), in the same way that RFC 5924 was done. > Implementors may either ignore this extended key usage or check for it, but > should never reject it if it's part of the certificate. Hmmm. What I would propose then is to define a mandatory-extension. Overlay with a configuration file containing this element MUST check for the EKU and accept/reject the certificate based on a text similar to RFC 2924 section 5. If the mandatory-extension is not present, then everything will work as it is today. If there is no disagreement, I'll prepare an Internet-Draft. I already talked to the PKIX people about the process to allocate a new EKU, but I'll allocate a provisional one in my PEN for experimentation purpose. Thanks. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQUKjoAAoJECnERZXWan7EecwQAKMgcsDQ+YBSFO27OnYaO0C3 VZN7ZZes48Qh8GN04ZtpjWXYL2rHSu4tn/eIR28U65oqqWlBzOTM1jrTqs7tii6v B7YTtqfVf6lM3ovrGZUotNZl+M+qz05hpqIk0XUObkcmm/64sMTyOZzydEjgSwKZ cKdmclaMayShznhD6qcmKk6QiRv8GAWwAO+JlPS5mt7wZXHf7ccFNtoVDsLWzY7L JwXuU3j1AxNPXoQHCdfhUHoi8wZHlTc3WW02zB0OACTc0EXL+/ZYmhLtGkeL5wiL HVzriEqjNngr6F5IKn94U70prgqllGOVDBQ7qKsOIam9qlkCl9ep1h+xHsj6NuzR Qa+LwMx13Xyu6ZpKIW6bpymWbalGa6Oh2x427usuNvPKEYFlukq5mGezGpw48IBv YiSKNEV9gEp0JHFpoQfOjHHjB+LQy6gwavXWvBlX9djkupMID+Jbbc4LB1luN1Eq g8ZhPSEelW+h4bMOBS5EZDQyGICcJwwNn9BYzktTKyGQJC3GgHBnJolCky6vGrGW AHWZaV6h4gy8gsHh4T9qHOvMEYJmxQW/Cjk4vjzB++0F9iE2l/44VOBlgDNO9pPC cadIUrRwsm8tNyTmaDT0G9wnxRDNNoyWlCWIF6p73P2XBMiX3U4nUoZBCn91/ehN 7oVNIdAHv/ZTP/Y0Xyvf =L6tg -----END PGP SIGNATURE----- From t.kluge@gmx.com Thu Sep 13 03:22:40 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F3B21F84FE for ; Thu, 13 Sep 2012 03:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkO2P0RrcaAo for ; Thu, 13 Sep 2012 03:22:40 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8362521F84FC for ; Thu, 13 Sep 2012 03:22:39 -0700 (PDT) Received: (qmail invoked by alias); 13 Sep 2012 10:22:36 -0000 Received: from unknown (EHLO ThomasWin764) [141.39.41.73] by mail.gmx.net (mp017) with SMTP; 13 Sep 2012 12:22:36 +0200 X-Authenticated: #22022137 X-Provags-ID: V01U2FsdGVkX18lyztCu60lSyw/4Sb+rOq83yVDVidmQAw/7GWnxX CmN6iXx4DxTB3n Message-ID: From: "Thomas Kluge" To: "P2PSIP Mailing List" References: <5037C342.6040902@acm.org> <1E1E1EE21BC441FABDEFADAD37A2F9FC@ThomasExtreme> <5050A8E9.3040003@acm.org> In-Reply-To: <5050A8E9.3040003@acm.org> Date: Thu, 13 Sep 2012 12:22:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Y-GMX-Trusted: 0 Subject: [P2PSIP] Extended Key Usage for RELOAD certificates X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 10:22:40 -0000 Sounds great. OK from my side. Thomas From brian.rosen@neustar.biz Mon Sep 17 10:18:52 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E134321F8737 for ; Mon, 17 Sep 2012 10:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[AWL=-1.369, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HitlRw-vYYMk for ; Mon, 17 Sep 2012 10:18:52 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 21C4121F8526 for ; Mon, 17 Sep 2012 10:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1347902444; x=1663257202; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=HKstX2U4ptlM3nUEcoW1m XzLueGTWpdwnEl9UgB32/g=; b=EDYHgK0xcq2MtQ+9LXWBTrdU+zzJjZynEc0cq 7U3nKkQCyrElS7ns+dTJp6DigRYZUSssjNHbWetyFZdfAx4pw== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.13809316; Mon, 17 Sep 2012 13:20:43 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 17 Sep 2012 13:18:48 -0400 From: "Rosen, Brian" To: P2PSIP WG Date: Mon, 17 Sep 2012 13:18:44 -0400 Thread-Topic: WGLC for draft-ietf-p2psip-diagnostics-09 Thread-Index: Ac2U+H8SEIa2c8Q8SiagpQsTNPEETg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: wntwHx4UQEjMNXXAKzbjTQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-09 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 17:18:53 -0000 We are issuing a two week Working Group Last Call for draft-ietf-p2psip-dia= gnostics-09. Please send comments to the list, including any statements you may have abo= ut the readiness of this document to be published. WGLC will close on October 2. Brian & Carlos From zongning@huawei.com Mon Sep 17 17:11:49 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BDE21E804A for ; Mon, 17 Sep 2012 17:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.187 X-Spam-Level: X-Spam-Status: No, score=-104.187 tagged_above=-999 required=5 tests=[AWL=2.413, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyKQ+2VbdG3O for ; Mon, 17 Sep 2012 17:11:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 12D7921E808C for ; Mon, 17 Sep 2012 17:11:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKT45634; Tue, 18 Sep 2012 00:11:46 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Sep 2012 01:11:27 +0100 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Sep 2012 01:11:46 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 18 Sep 2012 08:11:42 +0800 From: Zongning To: "Rosen, Brian" , P2PSIP WG Thread-Topic: WGLC for draft-ietf-p2psip-diagnostics-09 Thread-Index: Ac2U+H8SEIa2c8Q8SiagpQsTNPEETgAOXgXQ Date: Tue, 18 Sep 2012 00:11:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-09 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 00:11:49 -0000 I have read the diagnostic draft and think it is useful and well written. I= support moving it forward. -Ning > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of > Rosen, Brian > Sent: Tuesday, September 18, 2012 1:19 AM > To: P2PSIP WG > Subject: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-09 >=20 > We are issuing a two week Working Group Last Call for > draft-ietf-p2psip-diagnostics-09. >=20 > Please send comments to the list, including any statements you may have > about the readiness of this document to be published. >=20 > WGLC will close on October 2. >=20 > Brian & Carlos >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From Andre.Becker@student.kit.edu Tue Sep 18 08:37:05 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDE421E80DB for ; Tue, 18 Sep 2012 08:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJzMJzy6KsTn for ; Tue, 18 Sep 2012 08:37:04 -0700 (PDT) Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by ietfa.amsl.com (Postfix) with ESMTP id 7633121E80D6 for ; Tue, 18 Sep 2012 08:37:03 -0700 (PDT) Received: from [141.3.209.103] (scc-wkit-clx-209-103.scc.kit.edu [141.3.209.103]) by scc-mailout-02.scc.kit.edu with esmtp (Exim 4.72 #1) id 1TDzrB-0003zz-T7; Tue, 18 Sep 2012 17:37:01 +0200 Message-ID: <5058951C.1030302@student.kit.edu> Date: Tue, 18 Sep 2012 17:37:00 +0200 From: =?ISO-8859-1?Q?Andr=E9_Becker?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: p2psip@ietf.org References: <5037C342.6040902@acm.org> In-Reply-To: <5037C342.6040902@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [P2PSIP] Extended Key Usage for RELOAD certificates X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 15:37:05 -0000 Hi, I think there's a small point I don't get. You write that in the current situation the server would need two different self-signed certificates for the use case: One for signing reload certificates, one for signing https client certificates. However, in my understanding, if you self-sign a certificate, there's no one who tells you what to do or not to do with it. Especially, you may sign whatever you want. So why do you need two self-signed certificates after all? Regards, André Am 24.08.2012 20:09, schrieb Marc Petit-Huguenin: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > In summary, there is a use case for RELOAD that would benefit from having an > Extended Key Usage (RFC 5280) defined and enforced by RELOAD implementations. > > Here's the use case: An enrollment server as defined by section 11.3 > generates certificates that are used by a RELOAD implementation as client and > server certificates for the purpose of establishing (D)TLS links, and to sign > RELOAD messages and data. An enrollment server will also probably need an OAM > interface, e.g. to provision the username/password, and one natural way to > design this API is by using a RESTful API over HTTPS. Obviously access to this > API must be restricted and one way of doing this is by using client > certificate. Buying a certificate that can be used to sign client > certificates is expensive, so an alternate way is to use a self-signed > certificate as CA for this purpose (the server certificate still need to be > signed by a trusted CA), which mean that there is two self-signed CA > certificates per overlay, one for signing RELOAD certificates, and a second > one for signing HTTPS certificates. Having a RELOAD Extended Key Usage added > in each RELOAD certificate and having all RELOAD implementations verifying > that the certificates used contain this usage will permit to use the same > self-signed CA certificate for signing both RELOAD certificates and HTTPS > certificates. > > Reducing the number of self-signed certificates from two to one does not seem > that useful until one is developing an application that require to allocate a > different overlay to each user. > > There is one use case where enforcing a RELOAD Extended Key Usage can be a > problem: There is usages of RELOAD where an Overlay Link Layer using > Websocket over HTTPS could be useful, in which case an existing Websocket > implementation would probably reject a connection that is using a RELOAD > certificate. That can easily be solved by using code that is specific to RELOAD. > > So is there some support to have something this? If yes, should it be added > to -base, or developed as an extension? > > Thanks. > > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJQN8NAAAoJECnERZXWan7EDFkQANb3ajGoKZunezUCJRPXeWmy > /pCdpWRQJSJD2gQ5pEsYmVDhGTR1jES4haC6HXB7X/fTmNGlF0CEoufRpxmUcwkW > jTVCsfX2Hcb0BQcD1lKENyPgYHk9UN86QaNHBzoGIb0FPoXbfnOi8Nkvu32/pftu > XQ0nbaB9bIRKtsKA3qeFWv4tPt5d59vpLK9edUcef4Gz0EWde7mf/bOalEiKdAg2 > DBr1NfxHEsHZo/elIZuIHpW3JaSwZFVmZYs8M1AallCppR5CegJZEYLdJAaWkUQw > wS3CYTEsi+QsTomRHyfsg+rt+3/ZzRfk5eOtnSrZctxoV8xJAF6GBZbgVTiKtnHc > pA6W+1y+geAirQwGxIcKOlg5r8bSDqs07Y42yB0er0fJy+WKR9+zXKGY4DoFY28r > ovFHyaE4IMNS7FvsbcfvPBEoxAZXCfMHxEDtzLTTZdYmY4BOoM0SpGwjwbfqySVf > hJ4T/cHGESwT2JQvx3LMLFssXLGKj+dO3mwDYBxY3a2FvLcM5i5aiIKMYrmBsbnu > DMCMLTc4Z+VpR6f30vnLRIOc9Uu8laso5Tf6eCj+lCx7ncNbSiMZyk15n5PwUL8j > ITlXU5MUK0UNislPGhNynLRiqfrVAxdMGhQe+BKK3/O33CPrKxNjKcqd56EgBbQm > sDXuY52VdSbFE526hGIp > =q5qO > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Tue Sep 18 08:54:01 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BFA21F8790 for ; Tue, 18 Sep 2012 08:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.932 X-Spam-Level: X-Spam-Status: No, score=-101.932 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtMFEzKxd3x4 for ; Tue, 18 Sep 2012 08:54:00 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 235F821F8783 for ; Tue, 18 Sep 2012 08:54:00 -0700 (PDT) Received: from [IPv6:2001:5c0:1515:1100:404d:c358:2609:5dfe] (unknown [IPv6:2001:5c0:1515:1100:404d:c358:2609:5dfe]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 88ED522F5B; Tue, 18 Sep 2012 15:53:57 +0000 (UTC) Message-ID: <50589911.4000003@acm.org> Date: Tue, 18 Sep 2012 08:53:53 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: =?UTF-8?B?QW5kcsOpIEJlY2tlcg==?= References: <5037C342.6040902@acm.org> <5058951C.1030302@student.kit.edu> In-Reply-To: <5058951C.1030302@student.kit.edu> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Extended Key Usage for RELOAD certificates X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 15:54:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi André, On 09/18/2012 08:37 AM, André Becker wrote: > Hi, > > I think there's a small point I don't get. You write that in the current > situation the server would need two different self-signed certificates for > the use case: One for signing reload certificates, one for signing https > client certificates. > > However, in my understanding, if you self-sign a certificate, there's no > one who tells you what to do or not to do with it. Especially, you may sign > whatever you want. So why do you need two self-signed certificates after > all? Let's say that I use only one CA to sign both certificates for RELOAD and for the Web API. In this case, a certificate signed for the Web API can also be used for RELOAD, which is probably not a problem because it will miss the SAN part (reload URI) and will be rejected. The problem is that any certificate granted for RELOAD can also been used for the Web API, e.g. used to modify the configuration file, and letting any user do this is probably not a good idea. Adding an EKU in the RELOAD certificates permits the enrollment & configuration servers to reject a connection using these certificates, without having to use a separate CA. A specialized web server could be modified to reject certificates containing a reload URI, but because standard web servers already reject an EKU that they do not understand, it is a better solution to simply define an EKU for RELOAD. > > Regards, André > > Am 24.08.2012 20:09, schrieb Marc Petit-Huguenin: In summary, there is a > use case for RELOAD that would benefit from having an Extended Key Usage > (RFC 5280) defined and enforced by RELOAD implementations. > > Here's the use case: An enrollment server as defined by section 11.3 > generates certificates that are used by a RELOAD implementation as client > and server certificates for the purpose of establishing (D)TLS links, and > to sign RELOAD messages and data. An enrollment server will also probably > need an OAM interface, e.g. to provision the username/password, and one > natural way to design this API is by using a RESTful API over HTTPS. > Obviously access to this API must be restricted and one way of doing this > is by using client certificate. Buying a certificate that can be used to > sign client certificates is expensive, so an alternate way is to use a > self-signed certificate as CA for this purpose (the server certificate > still need to be signed by a trusted CA), which mean that there is two > self-signed CA certificates per overlay, one for signing RELOAD > certificates, and a second one for signing HTTPS certificates. Having a > RELOAD Extended Key Usage added in each RELOAD certificate and having all > RELOAD implementations verifying that the certificates used contain this > usage will permit to use the same self-signed CA certificate for signing > both RELOAD certificates and HTTPS certificates. > > Reducing the number of self-signed certificates from two to one does not > seem that useful until one is developing an application that require to > allocate a different overlay to each user. > > There is one use case where enforcing a RELOAD Extended Key Usage can be a > problem: There is usages of RELOAD where an Overlay Link Layer using > Websocket over HTTPS could be useful, in which case an existing Websocket > implementation would probably reject a connection that is using a RELOAD > certificate. That can easily be solved by using code that is specific to > RELOAD. > > So is there some support to have something this? If yes, should it be > added to -base, or developed as an extension? > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQWJkNAAoJECnERZXWan7E/OcP/3h+/qHxcTWGXANN7Y9NrjAg J0xXJ9wTqt0VaxZeMlS4sOi4SX/ecnHUebjLl69MgXlb37J8xaxlyUfDiUAPo4Ff cnmKTizYG2L783P+LdquvuZ8f7n28TrGN27L8X894QbzEORXd9G+OgrlVRYSHjmU eiq2gmqilaC77a9I9Vgqk4x0Wcft2q+rMefaWZ6vslvEvGdj3lkif4nbRJUgn/Qo NC/caWlOLV1yRkkd96XqHIw6Ucpmsk3BsfOY5F1z6ULz0d7ssKe0haQDsuoEJnsF asQiY67cqpAptTe3ovWMXd7tbVxW6uRWnuC+MM76Xh4ZHssnsX0xYDOUc6/VYzt3 KqpJMM+iHfghB8shef0TrFP9JJhC+IWr5/Ie7VyRXWK4cpiZJmjO0BoJj5FWs8Tf LHMoVWGBmzDdTqaBjQfs1yWGtWHmLiml3RK5LEZ8I30lkR8ZF2Np7PUMQ4Fuj+99 CBjfO7W+ZqQPnJVHZa/Rf3vECPsISOEdiHc2HyY0i+TBUMx1MB6+xukLzEmfnPqd 1wrPcfNo/G/sc8ngCpXtoQX1uUeB+sd+/YpUnM9qMf5GKuUVgwpvX5yBGPoW21vY DGaog2HgaVz1L0Gxh3rJnNucmRK5BJBgj8IJ1Q4ZQsiNk6HzfubFLK+uCQne8l4M m6RZUXm79wgJRqqkC57H =ILnz -----END PGP SIGNATURE----- From Andre.Becker@student.kit.edu Tue Sep 18 10:08:24 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D2421E80DD for ; Tue, 18 Sep 2012 10:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k4EwdaV3z3f for ; Tue, 18 Sep 2012 10:08:22 -0700 (PDT) Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9FD21E8056 for ; Tue, 18 Sep 2012 10:08:21 -0700 (PDT) Received: from [141.3.209.103] (scc-wkit-clx-209-103.scc.kit.edu [141.3.209.103]) by scc-mailout-02.scc.kit.edu with esmtp (Exim 4.72 #1) id 1TE1HX-0004yT-Co; Tue, 18 Sep 2012 19:08:19 +0200 Message-ID: <5058AA7E.4090806@student.kit.edu> Date: Tue, 18 Sep 2012 19:08:14 +0200 From: =?UTF-8?B?QW5kcsOpIEJlY2tlcg==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <5037C342.6040902@acm.org> <5058951C.1030302@student.kit.edu> <50589911.4000003@acm.org> In-Reply-To: <50589911.4000003@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Extended Key Usage for RELOAD certificates X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:08:24 -0000 Hi Marc, thanks for the quick explanation, I'm getting your point. Even without the OAM use case in mind I would support the idea of using an EKU to mark RELOAD certificates as what they are. From my point of view this definitley belongs into the base draft. And, as the EKU's purpose in the OAM use case isn't just to allow the RELOAD-usage, but rather to forbid others, the cleanest approach should be to make the usage of the EKU mandatory and to mark it as critical. The additional implementation effort seems acceptable to me. Regards, André Am 18.09.2012 17:53, schrieb Marc Petit-Huguenin: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi André, > > On 09/18/2012 08:37 AM, André Becker wrote: >> Hi, >> >> I think there's a small point I don't get. You write that in the current >> situation the server would need two different self-signed certificates for >> the use case: One for signing reload certificates, one for signing https >> client certificates. >> >> However, in my understanding, if you self-sign a certificate, there's no >> one who tells you what to do or not to do with it. Especially, you may sign >> whatever you want. So why do you need two self-signed certificates after >> all? > Let's say that I use only one CA to sign both certificates for RELOAD and for > the Web API. In this case, a certificate signed for the Web API can also be > used for RELOAD, which is probably not a problem because it will miss the SAN > part (reload URI) and will be rejected. The problem is that any certificate > granted for RELOAD can also been used for the Web API, e.g. used to modify the > configuration file, and letting any user do this is probably not a good idea. > Adding an EKU in the RELOAD certificates permits the enrollment & > configuration servers to reject a connection using these certificates, without > having to use a separate CA. > > A specialized web server could be modified to reject certificates containing a > reload URI, but because standard web servers already reject an EKU that they > do not understand, it is a better solution to simply define an EKU for RELOAD. > >> Regards, André >> >> Am 24.08.2012 20:09, schrieb Marc Petit-Huguenin: In summary, there is a >> use case for RELOAD that would benefit from having an Extended Key Usage >> (RFC 5280) defined and enforced by RELOAD implementations. >> >> Here's the use case: An enrollment server as defined by section 11.3 >> generates certificates that are used by a RELOAD implementation as client >> and server certificates for the purpose of establishing (D)TLS links, and >> to sign RELOAD messages and data. An enrollment server will also probably >> need an OAM interface, e.g. to provision the username/password, and one >> natural way to design this API is by using a RESTful API over HTTPS. >> Obviously access to this API must be restricted and one way of doing this >> is by using client certificate. Buying a certificate that can be used to >> sign client certificates is expensive, so an alternate way is to use a >> self-signed certificate as CA for this purpose (the server certificate >> still need to be signed by a trusted CA), which mean that there is two >> self-signed CA certificates per overlay, one for signing RELOAD >> certificates, and a second one for signing HTTPS certificates. Having a >> RELOAD Extended Key Usage added in each RELOAD certificate and having all >> RELOAD implementations verifying that the certificates used contain this >> usage will permit to use the same self-signed CA certificate for signing >> both RELOAD certificates and HTTPS certificates. >> >> Reducing the number of self-signed certificates from two to one does not >> seem that useful until one is developing an application that require to >> allocate a different overlay to each user. >> >> There is one use case where enforcing a RELOAD Extended Key Usage can be a >> problem: There is usages of RELOAD where an Overlay Link Layer using >> Websocket over HTTPS could be useful, in which case an existing Websocket >> implementation would probably reject a connection that is using a RELOAD >> certificate. That can easily be solved by using code that is specific to >> RELOAD. >> >> So is there some support to have something this? If yes, should it be >> added to -base, or developed as an extension? >> > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJQWJkNAAoJECnERZXWan7E/OcP/3h+/qHxcTWGXANN7Y9NrjAg > J0xXJ9wTqt0VaxZeMlS4sOi4SX/ecnHUebjLl69MgXlb37J8xaxlyUfDiUAPo4Ff > cnmKTizYG2L783P+LdquvuZ8f7n28TrGN27L8X894QbzEORXd9G+OgrlVRYSHjmU > eiq2gmqilaC77a9I9Vgqk4x0Wcft2q+rMefaWZ6vslvEvGdj3lkif4nbRJUgn/Qo > NC/caWlOLV1yRkkd96XqHIw6Ucpmsk3BsfOY5F1z6ULz0d7ssKe0haQDsuoEJnsF > asQiY67cqpAptTe3ovWMXd7tbVxW6uRWnuC+MM76Xh4ZHssnsX0xYDOUc6/VYzt3 > KqpJMM+iHfghB8shef0TrFP9JJhC+IWr5/Ie7VyRXWK4cpiZJmjO0BoJj5FWs8Tf > LHMoVWGBmzDdTqaBjQfs1yWGtWHmLiml3RK5LEZ8I30lkR8ZF2Np7PUMQ4Fuj+99 > CBjfO7W+ZqQPnJVHZa/Rf3vECPsISOEdiHc2HyY0i+TBUMx1MB6+xukLzEmfnPqd > 1wrPcfNo/G/sc8ngCpXtoQX1uUeB+sd+/YpUnM9qMf5GKuUVgwpvX5yBGPoW21vY > DGaog2HgaVz1L0Gxh3rJnNucmRK5BJBgj8IJ1Q4ZQsiNk6HzfubFLK+uCQne8l4M > m6RZUXm79wgJRqqkC57H > =ILnz > -----END PGP SIGNATURE----- From petithug@acm.org Tue Sep 18 10:47:44 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A69021F8559 for ; Tue, 18 Sep 2012 10:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.024 X-Spam-Level: X-Spam-Status: No, score=-102.024 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrsyi4rBcymy for ; Tue, 18 Sep 2012 10:47:43 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 02B5B21F855B for ; Tue, 18 Sep 2012 10:47:43 -0700 (PDT) Received: from [IPv6:2001:5c0:1515:1100:404d:c358:2609:5dfe] (unknown [IPv6:2001:5c0:1515:1100:404d:c358:2609:5dfe]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3E02322F5B; Tue, 18 Sep 2012 17:47:40 +0000 (UTC) Message-ID: <5058B3B9.8010800@acm.org> Date: Tue, 18 Sep 2012 10:47:37 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: =?UTF-8?B?QW5kcsOpIEJlY2tlcg==?= References: <5037C342.6040902@acm.org> <5058951C.1030302@student.kit.edu> <50589911.4000003@acm.org> <5058AA7E.4090806@student.kit.edu> In-Reply-To: <5058AA7E.4090806@student.kit.edu> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Extended Key Usage for RELOAD certificates X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 17:47:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/18/2012 10:08 AM, André Becker wrote: > Hi Marc, > > thanks for the quick explanation, I'm getting your point. Even without the > OAM use case in mind I would support the idea of using an EKU to mark > RELOAD certificates as what they are. From my point of view this definitley > belongs into the base draft. And, as the EKU's purpose in the OAM use case > isn't just to allow the RELOAD-usage, but rather to forbid others, the > cleanest approach should be to make the usage of the EKU mandatory and to > mark it as critical. The additional implementation effort seems acceptable > to me. OK, that's a different opinion than Thomas', so we need more discussion on the specific point of having it in -base or as an extension. Because I want to make it as painless as possible to the -base authors, I'll still publish my draft as an extension, so the -base author can just copy and paste the text if we all agree to put this in -base. As for my opinion on this subject, I agree that -base is the right place to put this, but seeing that the things we agreed on nearly 2 months ago in Vancouver still did not make it in the spec, I fear that the only path to success is an extension. > > Regards, André > > Am 18.09.2012 17:53, schrieb Marc Petit-Huguenin: Hi André, > > On 09/18/2012 08:37 AM, André Becker wrote: >>>> Hi, >>>> >>>> I think there's a small point I don't get. You write that in the >>>> current situation the server would need two different self-signed >>>> certificates for the use case: One for signing reload certificates, >>>> one for signing https client certificates. >>>> >>>> However, in my understanding, if you self-sign a certificate, there's >>>> no one who tells you what to do or not to do with it. Especially, you >>>> may sign whatever you want. So why do you need two self-signed >>>> certificates after all? > Let's say that I use only one CA to sign both certificates for RELOAD and > for the Web API. In this case, a certificate signed for the Web API can > also be used for RELOAD, which is probably not a problem because it will > miss the SAN part (reload URI) and will be rejected. The problem is that > any certificate granted for RELOAD can also been used for the Web API, e.g. > used to modify the configuration file, and letting any user do this is > probably not a good idea. Adding an EKU in the RELOAD certificates permits > the enrollment & configuration servers to reject a connection using these > certificates, without having to use a separate CA. > > A specialized web server could be modified to reject certificates > containing a reload URI, but because standard web servers already reject an > EKU that they do not understand, it is a better solution to simply define > an EKU for RELOAD. > >>>> Regards, André >>>> >>>> Am 24.08.2012 20:09, schrieb Marc Petit-Huguenin: In summary, there >>>> is a use case for RELOAD that would benefit from having an Extended >>>> Key Usage (RFC 5280) defined and enforced by RELOAD implementations. >>>> >>>> Here's the use case: An enrollment server as defined by section >>>> 11.3 generates certificates that are used by a RELOAD implementation >>>> as client and server certificates for the purpose of establishing >>>> (D)TLS links, and to sign RELOAD messages and data. An enrollment >>>> server will also probably need an OAM interface, e.g. to provision >>>> the username/password, and one natural way to design this API is by >>>> using a RESTful API over HTTPS. Obviously access to this API must be >>>> restricted and one way of doing this is by using client certificate. >>>> Buying a certificate that can be used to sign client certificates is >>>> expensive, so an alternate way is to use a self-signed certificate as >>>> CA for this purpose (the server certificate still need to be signed >>>> by a trusted CA), which mean that there is two self-signed CA >>>> certificates per overlay, one for signing RELOAD certificates, and a >>>> second one for signing HTTPS certificates. Having a RELOAD Extended >>>> Key Usage added in each RELOAD certificate and having all RELOAD >>>> implementations verifying that the certificates used contain this >>>> usage will permit to use the same self-signed CA certificate for >>>> signing both RELOAD certificates and HTTPS certificates. >>>> >>>> Reducing the number of self-signed certificates from two to one does >>>> not seem that useful until one is developing an application that >>>> require to allocate a different overlay to each user. >>>> >>>> There is one use case where enforcing a RELOAD Extended Key Usage can >>>> be a problem: There is usages of RELOAD where an Overlay Link Layer >>>> using Websocket over HTTPS could be useful, in which case an existing >>>> Websocket implementation would probably reject a connection that is >>>> using a RELOAD certificate. That can easily be solved by using code >>>> that is specific to RELOAD. >>>> >>>> So is there some support to have something this? If yes, should it >>>> be added to -base, or developed as an extension? >>>> > -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: > http://blog.marc.petit-huguenin.org Profile: > http://www.linkedin.com/in/petithug > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQWLO0AAoJECnERZXWan7EK/wP/3bx2C6rWnXKlUqVK8HNnKwy 91j0JMKYfMkGNV6cguWYNeARqEyOJVEgFSTKBWkMWyS3AURFeWkiU9HousYSKNUU eJ5Fpl2JAibiQfVBdoojk3kfD2qG6SUxvyXe9jRbIwI7c/uEFyZzcYX9440QRTrP Gsl2ZPCDgOTciBrrVPeZz/pzTce0u+Y89PiuWsQoH+6zP7fVqIeeEM0FvnPT2JwQ 9vnxS1jhzEvr8vemAbr0yZRUvnprMHj7o1XMdvbsiAgPgo8hXWL2jWEl0WLXaGgj gisxOFBszThV1+HZ1+u3lmCO9mgebm/KUJckk7uHCI0nqfy9XwLDEOvARNaURsyL c4Hiy6qqvPJWnEsdmL5GOtmYFmwI5OO4cuGAFbWtIzRf9yC7aMySMz+XvK6xx9sz qcuULVaHIIxpPYIS+HSwhIy7HK2X3NAfMG0vqI/1RVr2jODmHGOWWq9zqWSEWhA5 7uhxZ2gOnvl0U5g8UM8G5HdLrJO6v0an14ANvA+AuaHyiJ6VO4Y7UUQ4xWYawTR0 7nYe3HS1/twCxbP88RuMusROlG9RzMG8/w4wwFuF5UESDNWUjBHY+V1G0QNcuwqE jYKSDfhZ/UPHTYn3ieRuoJW2QUslNkp9nUCMxzPel5cZoKhYQhz5aK+j/qmjH27e vTM0VVZdOsZL5TkgVuyX =wphE -----END PGP SIGNATURE----- From petithug@acm.org Thu Sep 20 09:29:48 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632D221F871A for ; Thu, 20 Sep 2012 09:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.291 X-Spam-Level: X-Spam-Status: No, score=-102.291 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMI89wfHyIV2 for ; Thu, 20 Sep 2012 09:29:47 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE9D21F873E for ; Thu, 20 Sep 2012 09:29:47 -0700 (PDT) Received: from [IPv6:2601:9:4b80:32:cff:d0b7:621d:62d9] (unknown [IPv6:2601:9:4b80:32:cff:d0b7:621d:62d9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 21F6720785 for ; Thu, 20 Sep 2012 16:29:41 +0000 (UTC) Message-ID: <505B4472.3070400@acm.org> Date: Thu, 20 Sep 2012 09:29:38 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Anycast support in RELOAD, again X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 16:29:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 In Vancouver we decided[1] to remove the support for multicast/anycast/broadcast in the RELOAD spec, following a discussion back in Taipei about problems for supporting anycast. I thought a bit more about the anycast problem, and I found a solution to this problem that is simple and so that would permit to keep the text in -base. To summarize the problem, a bootstrap node cannot be directly running on an anycast address because the real destination can change at any time, and that would break DTLS. That can be solved by adding the IP address of a bootstrap node not running on the anycast address in the PingResponse, but unfortunately this is not a compatible change. There is other problems with this approach, related to the fact that the Ping must be sent without DTLS (naked Ping). But, as per -base section 6.5.1.4, all RELOAD nodes are also STUN servers, so the naked Ping can be replaced by a STUN connectivity check. The nice thing about STUN is that the support for anycast is already there, as a STUN server running on an anycast address will respond with a 300 Try Alternate with an ALTERNATE-SERVER attribute containing the IP address of the non-anycast node. So the whole problem can be solved by just saying in -base that any connection to the bootstrap servers must start with a STUN connectivity check. The first IP address to successfully respond (i.e. after processing the 300), is the one where the DTLS/TLS connection must be established to start sending the RELOAD messages. [1] https://www.ietf.org/proceedings/84/minutes/minutes-84-p2psip [2] https://www.ietf.org/proceedings/82/minutes/minutes-82-p2psip - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQW0RwAAoJECnERZXWan7EZRsP/jDXiBZQBHBJAD8qP2CFp7a7 wQ5xF5Ms5F1NCyciC5q6ufYs3Yj8ipwQ1cx9vJAJ6E72j1f4ZLMiNxy9Dr750peD kK/KAvj5cSMgpp56al+G4J3pdnrIPwx/trRncdX3OAsq8Rtn2GO8lyMFw7RdHK/i wrnZCrSa8e2a2jtt/0Ip7xpnaazgkQKn8x9McoQMtPuy2mrUrmZX2uPvLKnc6UQ+ zl0OfI62PKMv/IryGU9fRIx2vVGRMdu1AgXoIP0jtDnkUo19jcWe3/7ZWzOFeCpT tQaIHhDmSyOZ4EVhYTHHLTT42O0BsO/fdgwKT3PvJJQCEPRi16S36oQzS33tWD6h bEaGFKeC9QotWq2FHaH/38Cqr+nuIB4azBEpEEwErzWGiy0lPSWiL8sJ7TaTSugJ NS5ocDUngf8tZ/3o+sGPypLRMW71BSHvFkWmJ36HuA4Yzg7M68YZto/kw3RdW/J8 G02COfsf2w0131QPoRUQLQgSOHz6ZP7aiwuqrmKyRhxp1jgaVW1iFY0mOzJI+Nw7 omRr0Htw1BghfoBkEGWHejH6cymB2ld1+vvwSHgMryC4rLuPrdLBiBf6isFp0xLi FKiRVYL3pb4rNrzu2KjaiE6Wv6FhR/Ysdo+XsbxH+jRcfSXLz3i5B65O+wcr0Alj Eu1SX15X9nY+FAC2DmjZ =x01n -----END PGP SIGNATURE----- From petithug@acm.org Tue Sep 25 09:52:34 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EB521F86A5 for ; Tue, 25 Sep 2012 09:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtZ9oSRrbD9a for ; Tue, 25 Sep 2012 09:52:33 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id B08FD1F0C86 for ; Tue, 25 Sep 2012 09:52:32 -0700 (PDT) Received: from [IPv6:2601:9:4b80:32:38d2:f535:75:9ea2] (unknown [IPv6:2601:9:4b80:32:38d2:f535:75:9ea2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6FE032047D; Tue, 25 Sep 2012 16:52:30 +0000 (UTC) Message-ID: <5061E14C.4090908@acm.org> Date: Tue, 25 Sep 2012 09:52:28 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.7) Gecko/20120922 Icedove/10.0.7 MIME-Version: 1.0 To: "Rosen, Brian" References: In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-09 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 16:52:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I carefully read this I-D, and I found a lot of nits, which make it difficult to read. I think that this draft is ready to be submitted to the IESG, but I would like to start a discussion on one specific point, security. The draft is very light on the discussion about who is authorized to do what. Obviously some of the information that can be requested are sensitive, and I am afraid that without having a mechanism for authorization in the document, implementers will be reluctant to add it to their implementation. I think especially of SOFTWARE_VERSION, but there can be future Diagnostics Kinds that are not for general availability. So I would suggest to define in the spec an additional mechanism to restrict the access to some Kinds: The idea would be to add an extension in the configuration file to authorize access to these Diagnostics Kinds only to a specific list of Node-IDs (in a similar way that signer node-IDs are authorized to sign kind and configuration elements in signer and king-signer elements. Nits ==== - - The title, abstract and section 1 uses the acronym "P2PSIP", but in fact what is described is not limited to P2PSIP (i.e. the usage of draft-ietf-p2psip-sip) but can be applied to any usage of RELOAD. So I would recommend to change P2PSIP to P2P. - - Section 4: Path_Track This is used inconsistently in the whole document. I would suggest to change it to PathTrack everywhere, with the request structure named PathTrackReq and the answer PathTrackAns. The message code names (path_track_req and path_track_ans) are correct. - - The meaning of peer, node and client is well defined in draft-ietf-p2psip-base, but the usage of these words is not consistent in this document. I would suggest to check every instance and change them if needed. For example in Section 4, last paragraph, "... must be only provided to authorized peers." should be "... must be only provided to authorized nodes.", and so on... - - Section 4.2, last paragraph: "There have been proposal on the list..." This kind of language probably does not have its place in a normative section. Move this to an annex. - - Section 4.3: Move to an Annex (see above) - - Section 5.1.1, title: s/DiagnosticRequest/DiagnosticsRequest/ - - Section 5.1.1, structure: I think that this would make it clearer that there can be more than one DiagnosticExtension: enum { (2^16-1) } DiagnosticExtensionRequestType; struct { DiagnosticExtensionRequestType type; opaque diagnostic_extension_contents<0..2^32-1>; } DiagnosticExtension; struct { uint64 expiration; uint64 timestamp_initiated; uint64 dMFlags; DiagnosticExtension diagnostic_extensions<0..2^32-1>; } DiagnosticsRequest; - - Section 5.1.1, 7th paragraph "the flags can be extended by standard action." Add a cross reference to the correct subsection in section 9 (IANA Considerations). - - Section 5.1.2, title: s/DiagnosticResponse/DiagnosticsResponse/ - - Section 5.1.3, second paragraph: s/and other bits Must be cleared/nd other bits must be cleared/ - - Section 5.1.3: I would suggest to provide the structure (in the presentation language defined by RELOAD section 6.3.1) for all the types defined in this section, if interoperability between implementations is wanted. - - Section 5.1.3: SOFTWARE_VERSION: I would suggest to change the example to something more anonymous. As for the format itself, this draft may be of some help: http://www.ietf.org/internet-drafts/draft-karcz-uuas-00.txt - - Section 5.1.3: MACHINE_UPTIME s/the nodes has been/the node has been/ - - Section 5.1.3: MEMORY-FOOTPRINT s/32 -bit/32-bit/ - - Section 5.1.3: INSTANCES_STORED s/The array is index by/The array is indexed by/ - - Section 5.1.3: UNDERLAY_HOP s/for diagnostics purpose./for diagnostics purpose)./ - - Section 5.1.4, 2nd paragraph s/Editor's Note: The self-tuning/The self-tuning/ - - Section 5.2, second paragraph s/Section 5.3.3/Section 6.3.3/ - - Section 5.2, third paragraph: "If a peer does not extend the extension,..." Does not make sense. - - Section 5.3, second paragraph s/Route_Query/RouteQuery/ - - Section 5.3.1 s/compressed id/opaque ID/ - - Section 5.5.1, first paragraph, "The sender MUST include the dMFlags field" This field is not longer optional, so this text is useless. - - Section 5.5.1, first paragraph, "...but MUST include the field" Same than above. - - Section 5.5.1, second paragraph s/diagnostic ping/diagnostic Ping/ - - Section 5.5.1, 2nd and 3rd paragraphs: s/NodeId/Node-ID/ s/ResourceID/Resource-ID/ - - Section 5.5.2, second paragraph "contain the Error code followed by the subcode..." What is this subcode? - - Section 5.5.3, 3rd paragraph "will represent 100-hops" Where does this 100-hops come from? - - Section 5.5.3, 5th paragraph "subcode and description" What is this subcode? - - Section 5.5.3, 5th paragraph s/with the Error Code 1 "Error_Unauthorized"./with the Error Code 2 Error_Forbidden./ - - Section 5.5.4, 2nd paragraph: Remove this paragraph. - - Section 5.5.4, 3rd paragraph: s/Inspect/PathTrack/ - - Section 6.1 s/WEMA_BYTES_RCVD/EWMA_BYTES_RCVD/ - - Section 6.2 s/StatusInfo/STATUS_INFO/ - - Section 6.3 s/Inspect/PathTrack/ s/InspectReq/PathTrackReq/ - - Section 9 I find the way the registries are organized makes them difficult to understand. It would be better to have one registry merging 9.1, 9.2 and 9.6, with the following columns: - - Diagnostic Kind Type (from 9.2, same than diagnostic information from 9.6) - - diagnostic flag (from 9.6, can be empty) - - Code (from 9.2) - - Diagnostic Extension Name (from 9.1, can be empty) - - Code (from 9.1, empty if the previous cell is empty) - - Specification (from 9.1, 9.2 and 9.6) Another alternative is to have one registry for the dMFlags kinds, and another for the extensions Kinds, and perhaps use different RFC 5226 requirements. Private and experimental uses should also be documented. On 09/17/2012 10:18 AM, Rosen, Brian wrote: > We are issuing a two week Working Group Last Call for > draft-ietf-p2psip-diagnostics-09. > > Please send comments to the list, including any statements you may have > about the readiness of this document to be published. > > WGLC will close on October 2. > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQYeFKAAoJECnERZXWan7E68kQAJamA99TW0I/MdPwrOEzjEBI kX+qcAiDr6UTWwMaUfwq/gbVH2WHz32zLPiwKSY4axjmWoEvw7dsgBhfdDWKbsTH abgRnlxF0CbvNgoUi8d9BENCvZXkcTewIJdEpsV5oQ1w9wKjJX75XG/ggdrvrclh pGY1+Jglqv7ZKeTzGnHNaC0mVgMcJPK1mdr8lUrwn9M+Pmfi8Mk7nHy0XnvdkXa0 NG4bt/9pWKc92zhVIHatu+61+oWu1b8VHOK/5i6+Ajl439efNMJZS3qYup5gReFF zVMyDAcPKEMNAZq/+gbNgkpeH3VARAsDTM6NhrDo4w3vrxkV/NL/TC7v5bDVVJz0 wE+6d+B2l3oKnHAqPXv5vpVLDg/0DeI8A620kIEsMRPdcvLm/oej1KQnDgtS5NMW 3flVKJ4vzWzzDe8TH4V4JEttj9BsbV+3eyI49Cu4WEKnaJAFBRz1pjGiyHs8hxap /9LhpimxDhWQ9X9ly5duLeF0hnIgFKDVqndAMIFMvAxeIl7rgX4OOUBnsUmONdsp 5Frva8NdWwCHYnY+ocjZ1gPzePjIyVvYiPX5bLl3ATcpw3PrN4d6lBWnZKMMvcdS qH+9BUIdxVxh6haXf6Q6YD2QkTfaQs8c6357LIyvbED3z9X9yiFV4fHtSQCKogD1 0B1wQs3SHrsm6+QOd2NB =R959 -----END PGP SIGNATURE----- From haibin.song@huawei.com Thu Sep 27 18:04:46 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7310221F856D for ; Thu, 27 Sep 2012 18:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.143 X-Spam-Level: X-Spam-Status: No, score=-6.143 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tkle9315aKV1 for ; Thu, 27 Sep 2012 18:04:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A5DEC21F855D for ; Thu, 27 Sep 2012 18:04:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALC76133; Fri, 28 Sep 2012 01:04:43 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 02:03:57 +0100 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 02:04:42 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Fri, 28 Sep 2012 09:04:35 +0800 From: Songhaibin To: Marc Petit-Huguenin , "Rosen, Brian" Thread-Topic: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-09 Thread-Index: Ac2U+H8SEIa2c8Q8SiagpQsTNPEETgGApgcAAIYjZgA= Date: Fri, 28 Sep 2012 01:04:34 +0000 Message-ID: References: <5061E14C.4090908@acm.org> In-Reply-To: <5061E14C.4090908@acm.org> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: P2PSIP WG Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-09 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 01:04:46 -0000 Hi Marc, Thank you very much for the feedback. See inline. > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of > Marc Petit-Huguenin > Sent: Wednesday, September 26, 2012 12:52 AM > To: Rosen, Brian > Cc: P2PSIP WG > Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-09 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > I carefully read this I-D, and I found a lot of nits, which make it diffi= cult > to read. I think that this draft is ready to be submitted to the IESG, b= ut I > would like to start a discussion on one specific point, security. >=20 Thanks, the document will double checked and updated. > The draft is very light on the discussion about who is authorized to do w= hat. > Obviously some of the information that can be requested are sensitive, a= nd I > am afraid that without having a mechanism for authorization in the docume= nt, > implementers will be reluctant to add it to their implementation. =20 Good point! >I think > especially of SOFTWARE_VERSION, but there can be future Diagnostics Kinds= that > are not for general availability. So I would suggest to define in the spec an > additional mechanism to restrict the access to some Kinds: >=20 > The idea would be to add an extension in the configuration file to author= ize > access to these Diagnostics Kinds only to a specific list of Node-IDs (in= a > similar way that signer node-IDs are authorized to sign kind and configur= ation > elements in signer and king-signer elements. >=20 This should work. Could this lead to the over dynamic of the configuration = file? Another option is for each Kind, just stored these signed IDs as a va= lue in the overlay. BR, -Haibin >=20 > Nits > =3D=3D=3D=3D >=20 > - - The title, abstract and section 1 uses the acronym "P2PSIP", but in f= act > what is described is not limited to P2PSIP (i.e. the usage of > draft-ietf-p2psip-sip) but can be applied to any usage of RELOAD. So I w= ould > recommend to change P2PSIP to P2P. >=20 > - - Section 4: Path_Track >=20 > This is used inconsistently in the whole document. I would suggest to ch= ange > it to PathTrack everywhere, with the request structure named PathTrackReq= and > the answer PathTrackAns. The message code names (path_track_req and > path_track_ans) are correct. >=20 > - - The meaning of peer, node and client is well defined in > draft-ietf-p2psip-base, but the usage of these words is not consistent in= this > document. I would suggest to check every instance and change them if > needed. > For example in Section 4, last paragraph, "... must be only provided to > authorized peers." should be "... must be only provided to authorized > nodes.", and so on... >=20 > - - Section 4.2, last paragraph: "There have been proposal on the list..= ." >=20 > This kind of language probably does not have its place in a normative sec= tion. > Move this to an annex. >=20 > - - Section 4.3: Move to an Annex (see above) >=20 > - - Section 5.1.1, title: >=20 > s/DiagnosticRequest/DiagnosticsRequest/ >=20 > - - Section 5.1.1, structure: >=20 > I think that this would make it clearer that there can be more than one > DiagnosticExtension: >=20 > enum { (2^16-1) } DiagnosticExtensionRequestType; >=20 > struct { > DiagnosticExtensionRequestType type; > opaque diagnostic_extension_contents<0..2^32-1>; > } DiagnosticExtension; >=20 > struct { > uint64 expiration; > uint64 timestamp_initiated; > uint64 dMFlags; > DiagnosticExtension diagnostic_extensions<0..2^32-1>; > } DiagnosticsRequest; >=20 > - - Section 5.1.1, 7th paragraph "the flags can be extended by standard a= ction." >=20 > Add a cross reference to the correct subsection in section 9 (IANA > Considerations). >=20 > - - Section 5.1.2, title: >=20 > s/DiagnosticResponse/DiagnosticsResponse/ >=20 > - - Section 5.1.3, second paragraph: >=20 > s/and other bits Must be cleared/nd other bits must be cleared/ >=20 > - - Section 5.1.3: >=20 > I would suggest to provide the structure (in the presentation language de= fined > by RELOAD section 6.3.1) for all the types defined in this section, if > interoperability between implementations is wanted. >=20 > - - Section 5.1.3: SOFTWARE_VERSION: I would suggest to change the examp= le > to > something more anonymous. As for the format itself, this draft may be of= some > help: >=20 > http://www.ietf.org/internet-drafts/draft-karcz-uuas-00.txt >=20 > - - Section 5.1.3: MACHINE_UPTIME >=20 > s/the nodes has been/the node has been/ >=20 > - - Section 5.1.3: MEMORY-FOOTPRINT >=20 > s/32 -bit/32-bit/ >=20 > - - Section 5.1.3: INSTANCES_STORED >=20 > s/The array is index by/The array is indexed by/ >=20 > - - Section 5.1.3: UNDERLAY_HOP >=20 > s/for diagnostics purpose./for diagnostics purpose)./ >=20 > - - Section 5.1.4, 2nd paragraph >=20 > s/Editor's Note: The self-tuning/The self-tuning/ >=20 > - - Section 5.2, second paragraph >=20 > s/Section 5.3.3/Section 6.3.3/ >=20 > - - Section 5.2, third paragraph: "If a peer does not extend the extensio= n,..." >=20 > Does not make sense. >=20 > - - Section 5.3, second paragraph >=20 > s/Route_Query/RouteQuery/ >=20 > - - Section 5.3.1 >=20 > s/compressed id/opaque ID/ >=20 > - - Section 5.5.1, first paragraph, "The sender MUST include the dMFlags = field" >=20 > This field is not longer optional, so this text is useless. >=20 > - - Section 5.5.1, first paragraph, "...but MUST include the field" >=20 > Same than above. >=20 > - - Section 5.5.1, second paragraph >=20 > s/diagnostic ping/diagnostic Ping/ >=20 > - - Section 5.5.1, 2nd and 3rd paragraphs: >=20 > s/NodeId/Node-ID/ > s/ResourceID/Resource-ID/ >=20 > - - Section 5.5.2, second paragraph "contain the Error code followed by t= he > subcode..." >=20 > What is this subcode? >=20 > - - Section 5.5.3, 3rd paragraph "will represent 100-hops" >=20 > Where does this 100-hops come from? >=20 > - - Section 5.5.3, 5th paragraph "subcode and description" >=20 > What is this subcode? >=20 > - - Section 5.5.3, 5th paragraph >=20 > s/with the Error Code 1 "Error_Unauthorized"./with the Error Code 2 > Error_Forbidden./ >=20 > - - Section 5.5.4, 2nd paragraph: >=20 > Remove this paragraph. >=20 > - - Section 5.5.4, 3rd paragraph: >=20 > s/Inspect/PathTrack/ >=20 > - - Section 6.1 >=20 > s/WEMA_BYTES_RCVD/EWMA_BYTES_RCVD/ >=20 > - - Section 6.2 >=20 > s/StatusInfo/STATUS_INFO/ >=20 > - - Section 6.3 >=20 > s/Inspect/PathTrack/ > s/InspectReq/PathTrackReq/ >=20 > - - Section 9 >=20 > I find the way the registries are organized makes them difficult to under= stand. >=20 > It would be better to have one registry merging 9.1, 9.2 and 9.6, with th= e > following columns: >=20 > - - Diagnostic Kind Type (from 9.2, same than diagnostic information from= 9.6) > - - diagnostic flag (from 9.6, can be empty) > - - Code (from 9.2) > - - Diagnostic Extension Name (from 9.1, can be empty) > - - Code (from 9.1, empty if the previous cell is empty) > - - Specification (from 9.1, 9.2 and 9.6) >=20 > Another alternative is to have one registry for the dMFlags kinds, and an= other > for the extensions Kinds, and perhaps use different RFC 5226 requirements= . >=20 > Private and experimental uses should also be documented. >=20 >=20 > On 09/17/2012 10:18 AM, Rosen, Brian wrote: > > We are issuing a two week Working Group Last Call for > > draft-ietf-p2psip-diagnostics-09. > > > > Please send comments to the list, including any statements you may have > > about the readiness of this document to be published. > > > > WGLC will close on October 2. > > >=20 > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) >=20 > iQIcBAEBCAAGBQJQYeFKAAoJECnERZXWan7E68kQAJamA99TW0I/MdPwrOEzjEBI > kX+qcAiDr6UTWwMaUfwq/gbVH2WHz32zLPiwKSY4axjmWoEvw7dsgBhfdDWKbs > TH > abgRnlxF0CbvNgoUi8d9BENCvZXkcTewIJdEpsV5oQ1w9wKjJX75XG/ggdrvrclh > pGY1+Jglqv7ZKeTzGnHNaC0mVgMcJPK1mdr8lUrwn9M+Pmfi8Mk7nHy0XnvdkXa0 > NG4bt/9pWKc92zhVIHatu+61+oWu1b8VHOK/5i6+Ajl439efNMJZS3qYup5gReFF > zVMyDAcPKEMNAZq/+gbNgkpeH3VARAsDTM6NhrDo4w3vrxkV/NL/TC7v5bDVVJ > z0 > wE+6d+B2l3oKnHAqPXv5vpVLDg/0DeI8A620kIEsMRPdcvLm/oej1KQnDgtS5NMW > 3flVKJ4vzWzzDe8TH4V4JEttj9BsbV+3eyI49Cu4WEKnaJAFBRz1pjGiyHs8hxap > /9LhpimxDhWQ9X9ly5duLeF0hnIgFKDVqndAMIFMvAxeIl7rgX4OOUBnsUmONds > p > 5Frva8NdWwCHYnY+ocjZ1gPzePjIyVvYiPX5bLl3ATcpw3PrN4d6lBWnZKMMvcdS > qH+9BUIdxVxh6haXf6Q6YD2QkTfaQs8c6357LIyvbED3z9X9yiFV4fHtSQCKogD1 > 0B1wQs3SHrsm6+QOd2NB > =3DR959 > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip