From nobody Wed Jan 2 11:35:42 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269F6130F05; Wed, 2 Jan 2019 11:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDedAdyoG4US; Wed, 2 Jan 2019 11:35:40 -0800 (PST) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6F4130F07; Wed, 2 Jan 2019 11:35:38 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id m8so39502041itk.0; Wed, 02 Jan 2019 11:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5XkMLRnjXoLJ8cT2Yw23EvBfIrovL9W8xvWjDmmj4Pg=; b=Y+NzKEN1R4NsIEGT7R4oiKvvrtdvMqQUTyCLo9K67qppXzvRdFSvuxpyq+P3K2y8ac rIZN1DynYIhDv41yzWEJAMVitbK+AysuoVvLMvklSQjF9F3Knq8vGLul4aqZo29SMKz/ VAGA33236oyJkK6hMTsTPDmA/IvwVzcueuDojNDL51wcGKKZtSrzOJQYqXdg0I2rXCfd DxJVgvv8MWRCYf1IaoAN1AeQyd57yNxgDJMqTdEMSzi7PrOMCrwStvnRw6pjjBZ5ayCs a6pBuBjOCl+5R6qftVuQlZwLKalqqGlJo2pfurgYh+88FDMD8QbGOfIw/NoI4YcJYdqK SfMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5XkMLRnjXoLJ8cT2Yw23EvBfIrovL9W8xvWjDmmj4Pg=; b=SJWiB+mWNn66PGtQRCYnfsf8ROpuXNGAMYBbWa1A3uHcgGEpS4wNGgtDYBsluZFjZ3 VMlwdbd55QCpuVQdf/77fZE0wvJYrX0wIJZKaPEk7clDUNwvE2AMKZKGcCHjjYQbYG7M uFFlfvgJcQ4QArGwIPYn86g9/Wft1dzjal+BjAP/aEfbINh0SLXwyIluTE2K/yClO44J hD8DrmAcsXaB/jvuuOONDqLx1cDABcVBiimHZ6JXndkIz91TMMKmDUzx/lqdpQX+md9M ebgHLxKeJQyflx++m2bbzuEFVyGErAXF62boKw7NVmyFv9extGEt+h49P8687zzh6jrS hntA== X-Gm-Message-State: AA+aEWaYf883wSFbd1+//n7DeLGv/HSx3Xaf7qdoalTijReOzhEMp+VD 1BjoKtJ+qTviz/ImuK+WOwmMMAWbNRWZ37CThjs+DwdN X-Google-Smtp-Source: AFSGD/UPAIrs4dWm0rxDtjmNVdVhbxBgSQvPbXXJgsVqWUJnrsek5M2BfZZoHCv0tTxVWb+vBTcsDZzrGtXgYEKVypE= X-Received: by 2002:a24:89:: with SMTP id 131mr27278082ita.105.1546457737704; Wed, 02 Jan 2019 11:35:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Donald Eastlake Date: Wed, 2 Jan 2019 14:35:26 -0500 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: multipart/alternative; boundary="0000000000001dbc90057e7ec0d3" Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-dtls - failed X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2019 19:35:41 -0000 --0000000000001dbc90057e7ec0d3 Content-Type: text/plain; charset="UTF-8" Hi, I'm going to declare this WG Last Call to have failed. There was insufficient support indicated and there has been discussion on preserving crypto state and co-existence with hmac including port numbers. I should also do a Shepherd review of the draft. After these things are cleared up, we can issue a new WG Last Call that I think will have a higher chance of success. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Wed, Nov 7, 2018 at 8:16 PM Donald Eastlake wrote: > This message begins a Working Group Last Call for draft-ietf-babel-dtls-01 > running through November 26th. Please indicate whether you think this draft > is ready for publication as an RFC. Comments on the draft are also welcome. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail.com > --0000000000001dbc90057e7ec0d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'm going to d= eclare this WG Last Call to have failed. There was insufficient support ind= icated and there has been discussion on preserving crypto state and co-exis= tence with hmac including port numbers. I should also do a Shepherd review = of the draft. After these things are cleared up, we can issue a new WG Last= Call that I think will have a higher chance of success.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E= . Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A01424 Pro Shop Court, = Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.com


On Wed, Nov 7, 2018 at 8:16 PM Donald Eas= tlake <d3e3e3@gmail.com> wrot= e:
This message begins a Working Group Last Call for draft-ietf-babel-dtls= -01 running through November 26th. Please indicate whether you think this d= raft is ready for publication as an RFC. Comments on the draft are also wel= come.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= =C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A01424 Pr= o Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.com
--0000000000001dbc90057e7ec0d3-- From nobody Wed Jan 2 15:23:16 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9800124BE5 for ; Wed, 2 Jan 2019 15:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpkc6WpgqzHF for ; Wed, 2 Jan 2019 15:23:12 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98951130E51 for ; Wed, 2 Jan 2019 15:23:12 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x02L5mM8028685; Wed, 2 Jan 2019 16:14:59 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2ps4ew0vcv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 02 Jan 2019 16:14:59 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x02LEwY8013049; Wed, 2 Jan 2019 16:14:58 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x02LEsZA012968; Wed, 2 Jan 2019 16:14:54 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 7D3864048C34; Wed, 2 Jan 2019 21:14:54 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30488.vci.att.com (Service) with ESMTPS id 690004048C32; Wed, 2 Jan 2019 21:14:54 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0415.000; Wed, 2 Jan 2019 16:14:54 -0500 From: "STARK, BARBARA H" To: "'Mahesh Jethanandani'" , Juliusz Chroboczek CC: Babel at IETF Thread-Topic: [babel] info-model: message log Thread-Index: AdSXyYnBQkQrNQ5OTYeO5Bd7aNbDmQCcr+YAAOaIy4ABPlBSwA== Date: Wed, 2 Jan 2019 21:14:53 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF7E186@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF65C81@GAALPA1MSGUSRBF.ITServices.sbc.com> <87efa9legt.wl-jch@irif.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.199.172] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-02_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901020185 Archived-At: Subject: Re: [babel] info-model: message log X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2019 23:23:15 -0000 Getting back to this after the holidays... > >> Here is my suggestion for having a message log: > > > >> babel-message-log is: > >> A reference or url link to a file that contains a timestamped log of > >> messages received and sent on babel-udp-port on all interfaces. File f= ormat > >> MUST be readable by Wireshark 1.8 or later and use the applicable file= format > >> extension in the filename. Logging is enabled / disabled by babel-mess= age- > >> log-enable. > > > > Wireshark supports multiple formats, I'm not sure that it's a good > > idea to allow all of the formats supported by Wireshark. Why not? Not that I'm arguing strongly for allowing all formats; just that = I can't convince myself of a strong argument against it. I'm fine with a mo= re limited set, but don't want to be too limiting. Personally, I'm fine wit= h anything that I can get an easy-to-use, free, good parser for and that ca= n provide all the info. > > I'm not intimately familiar with the capture packet formats. The > > pcapng file format appears to be the preferred format for wireshark, > > but the internet-draft is expired since 2014; what's more, I'm not > > sure it's supported by libpcap. Per https://wiki.wireshark.org/Development/LibpcapFileFormat (with a last e= dited date from 2015): "It is widely accepted that the libpcap file format serves its purpose but = lacks some useful features. There's a next generation pcap file format docu= mented at the pcapng specification Git repository. The new format supplies = many of the capabilities listed in "Drawbacks" above. Wireshark currently has the ability to read and write pcapng files, and doe= s so by default, although doesn't support all of the capabilities of the fi= les. Libpcap 1.1.0 and later have a limited ability to read them as well, a= lthough libpcap doesn't yet supporting writing them." =20 > Would agree that the capture format is a pcap file. I will not be surpris= ed if > Wireshark does not understand Babel protocol, particularly if no one has > defined it in libpcap. Not too difficult to add though. The RFC6126 dissector exists: https://www.wireshark.org/docs/dfref/b/babel.= html I'm hopeful someone will contribute the updated dissector once the new RFC = is published... > > The traditional libpcap format is documented here: > > > > > > > > and it's likely to be supported by any tool in existence. Unless > > somebody has good technical reasons to avoid libpcap, I suggest we > > should mandate that format. Apparently, libpcap is said (by https://wiki.wireshark.org/Development/Libp= capFileFormat) to have the following drawbacks: "The libpcap format is very simple, one of the reasons that it has gained s= uch a wide usage. Unfortunately it misses a few things which would be helpf= ul: nanosecond time resolution user comments: "shows connection breakdown starting at packet 1432" interface information (like the network card manufacturer) packet drop count (and probably other counts as well)" I don't find any of these to be showstoppers for this proposed use. But I g= o back to my original premise that I'm struggling to figure out why there's= a need to limit the file format. Barbara > > > > -- Juliusz > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org >=20 > Mahesh Jethanandani > mjethanandani@gmail.com From nobody Thu Jan 3 06:41:19 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B9112F1A6 for ; Thu, 3 Jan 2019 06:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MpkkHhMhmKp for ; Thu, 3 Jan 2019 06:41:15 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E732512F1A5 for ; Thu, 3 Jan 2019 06:41:15 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x03EZbHT026703 for ; Thu, 3 Jan 2019 09:41:15 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2psm6v89k2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 03 Jan 2019 09:41:15 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x03EfEqg019458 for ; Thu, 3 Jan 2019 09:41:14 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x03Ef9gW019374 for ; Thu, 3 Jan 2019 09:41:09 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id BAD3E4014066 for ; Thu, 3 Jan 2019 14:41:09 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30487.vci.att.com (Service) with ESMTPS id A8CE34014055 for ; Thu, 3 Jan 2019 14:41:09 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0415.000; Thu, 3 Jan 2019 09:41:09 -0500 From: "STARK, BARBARA H" To: Babel at IETF Thread-Topic: hmac info model elements Thread-Index: AdSi6E9jJwLKz5kXQlCy2NNONpdJZQ== Date: Thu, 3 Jan 2019 14:41:09 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-03_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901030129 Archived-At: Subject: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 14:41:18 -0000 I'm looking at what's needed in the info model for HMAC. I don't think the Index and PC of the Interface and Neighbor tables need to= (or should) be exposed in the info model. We had discussed previously that keys should not be readable -- only add an= d delete keys. In this case, it's good for a non-readable parameter to have= a "nickname" or index to reference it with. And it can be useful to know w= hen the key was added. In my experience, these sorts of shared keys are mod= eled as strings. Appendix A (incremental deployment and key rotation) indicates it should be= possible to configure a mode where authenticated packets are sent but all = packets are accepted. Multiple HMAC algorithms are possible. The draft doesn't say how the nodes = know which algorithm is being used (if multiple are implemented). The draft= does say that only one HMAC is calculated per key. Is it assumed the algor= ithm choice is configured? Should the challenge expiry timer be configurable? I've decided to have completely separate HMAC and DTLS objects, because the= y're very different now that I have detailed designs to work with. I'm adding an "operation" datatype to support key and cert manipulation. Th= is is intended to be consistent with YANG "action" datatype. Proposed HMAC model: add to top level information-obj: babel-hmac-algorithms (enumerated list of supported HMAC computation algori= thms) security-hmac-obj security-hmac-enable (boolean: enable / disable this instance) security-hmac-mode (Boolean: do or don't authenticate received packets) security-hmac-algorithm (string: one of the supported HMAC algorithms) security-interfaces (string list of references to interfaces-obj: the int= erfaces this instance applies to; if empty, it applies to all interfaces) security-add-hmac-key (operation: inputs (reference name, key)) =20 hmac-key-obj key-name (string: reference name) key-date (datetime: timestamp when key was added) delete-key (operation) check-key (operation: inputs (string, HMAC of string)) ; the node = does its own HMAC computation of the input string and compares this to the = input HMAC of string; if the computed and input HMAC are the same the opera= tion succeeds. Thoughts? Barbara From nobody Thu Jan 3 08:46:32 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F9C131169 for ; Thu, 3 Jan 2019 08:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTiFQiZIgmgo for ; Thu, 3 Jan 2019 08:46:29 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2441C131159 for ; Thu, 3 Jan 2019 08:46:28 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x03GkI8C004106; Thu, 3 Jan 2019 17:46:18 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D8B6D3E429; Thu, 3 Jan 2019 17:46:23 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id jNDj-IbbU67O; Thu, 3 Jan 2019 17:46:22 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7E4F23E427; Thu, 3 Jan 2019 17:46:20 +0100 (CET) Date: Thu, 03 Jan 2019 17:46:20 +0100 Message-ID: <87va35lmeb.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mahesh Jethanandani Cc: "STARK, BARBARA H" , Babel at IETF In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DF65C81@GAALPA1MSGUSRBF.ITServices.sbc.com> <87efa9legt.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 03 Jan 2019 17:46:18 +0100 (CET) X-Miltered: at korolev with ID 5C2E3C5A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C2E3C5A.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C2E3C5A.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] info-model: message log X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 16:46:31 -0000 > I will not be surprised if Wireshark does not understand Babel protocol, Both tcpdump and Wireshark understand Babel. That was one of the first things we did after we got our first working prototype. > particularly if no one has defined it in libpcap. That has nothing to do with libpcap -- libpcap handles Babel packets as it would any other IPv6 packets, interpreting the application-layer protocol happens in the application (Wireshark or tcpdump). -- Juliusz From nobody Thu Jan 3 08:54:21 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0ED13110E for ; Thu, 3 Jan 2019 08:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uGdqjKUGSmp for ; Thu, 3 Jan 2019 08:54:17 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C1F131183 for ; Thu, 3 Jan 2019 08:54:17 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x03Gs8sL007143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Jan 2019 17:54:08 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x03Gs9v5011964; Thu, 3 Jan 2019 17:54:09 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 91B5A3E580; Thu, 3 Jan 2019 17:54:13 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id BvqSAxdFwA11; Thu, 3 Jan 2019 17:54:12 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 191A03E57D; Thu, 3 Jan 2019 17:54:12 +0100 (CET) Date: Thu, 03 Jan 2019 17:54:12 +0100 Message-ID: <87tviplm17.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF7E186@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF65C81@GAALPA1MSGUSRBF.ITServices.sbc.com> <87efa9legt.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF7E186@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 03 Jan 2019 17:54:08 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 03 Jan 2019 17:54:09 +0100 (CET) X-Miltered: at korolev with ID 5C2E3E30.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5C2E3E31.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C2E3E30.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5C2E3E31.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C2E3E30.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5C2E3E31.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] info-model: message log X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 16:54:19 -0000 >>> Wireshark supports multiple formats, I'm not sure that it's a good >>> idea to allow all of the formats supported by Wireshark. > Why not? Suppose that I want to write a management tool for Babel routers. I need a small, well-defined set of dump formats that I need to implement in my tool and be sure that I can grok the output of all correct implementations. > Personally, I'm fine with anything that I can get an easy-to-use, free, > good parser for and that can provide all the info. Right. > I don't find any of these to be showstoppers for this proposed use. But > I go back to my original premise that I'm struggling to figure out why > there's a need to limit the file format. If we want tool authors to write tools that parse the format, we need to mandate just one or two formats. So I'd suggest one of the following: 1. mandate pcap; 2. mandate pcapng; 3. allow both pcap or pcapng. Allowing more than two formats is a bad idea IMHO. -- Juliusz From nobody Thu Jan 3 10:29:56 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A80213123D for ; Thu, 3 Jan 2019 10:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GANxfsAhONhG for ; Thu, 3 Jan 2019 10:29:54 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0482C13123C for ; Thu, 3 Jan 2019 10:29:53 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x03ITDfY012402; Thu, 3 Jan 2019 19:29:13 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 73B1B3F5DF; Thu, 3 Jan 2019 19:29:19 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id pUBCnoPoKT2L; Thu, 3 Jan 2019 19:29:17 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 421413F5D8; Thu, 3 Jan 2019 19:29:16 +0100 (CET) Date: Thu, 03 Jan 2019 19:29:16 +0100 Message-ID: <87o98xlhmr.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 03 Jan 2019 19:29:13 +0100 (CET) X-Miltered: at korolev with ID 5C2E5479.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C2E5479.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C2E5479.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 18:29:55 -0000 > Multiple HMAC algorithms are possible. The draft doesn't say how the > nodes know which algorithm is being used (if multiple are implemented). It's a local configuration issue, and therefore out of scope for the protocol description. > The draft does say that only one HMAC is calculated per key. Is it > assumed the algorithm choice is configured? Yes. > Should the challenge expiry timer be configurable? No. It's an implementation detail, and any value between a few seconds and a few minutes will do. > security-hmac-obj [...] > security-interfaces (string list of references to interfaces-obj: the > interfaces this instance applies to; if empty, it applies to all > interfaces) Hmm... that got me confused for a while, but I see what you're doing here. > security-add-hmac-key (operation: inputs (reference name, key)) > hmac-key-obj > key-name (string: reference name) > key-date (datetime: timestamp when key was added) Please make key-date optional. -- Juliusz From nobody Thu Jan 3 11:09:10 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDFE131270 for ; Thu, 3 Jan 2019 11:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zr1fG0FV10Ca for ; Thu, 3 Jan 2019 11:09:08 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633CB13126F for ; Thu, 3 Jan 2019 11:09:08 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x03J8vbf026431; Thu, 3 Jan 2019 20:08:57 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C68193FBA1; Thu, 3 Jan 2019 20:09:02 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id fogIi5AEn-gX; Thu, 3 Jan 2019 20:09:00 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B339C3FB9E; Thu, 3 Jan 2019 20:09:00 +0100 (CET) Date: Thu, 03 Jan 2019 20:09:00 +0100 Message-ID: <87muohlfsj.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: "STARK, BARBARA H" , Babel at IETF In-Reply-To: <5720979F-C0D2-4291-B4D6-653B28E77D4B@kapsi.fi> References: <2D09D61DDFA73D4C884805CC7865E6114DF65C81@GAALPA1MSGUSRBF.ITServices.sbc.com> <87efa9legt.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF7E186@GAALPA1MSGUSRBF.ITServices.sbc.com> <87tviplm17.wl-jch@irif.fr> <5720979F-C0D2-4291-B4D6-653B28E77D4B@kapsi.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 03 Jan 2019 20:08:57 +0100 (CET) X-Miltered: at korolev with ID 5C2E5DC9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C2E5DC9.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C2E5DC9.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] info-model: message log X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 19:09:10 -0000 > I vote one format for implementation simplicity. I do not really know > which one. pcap is much simpler. pcapng supports nanosecond timestamps, comments, vendor-defined TLVs, and bidirectional scanning. While it looks reasonably easy to generate, it's a little more challenging to parse in its full generality. Heck, even Wireshark doesn't :-/ (Note that picking a dump format doesn't mean we can parse it -- there's the small matter of the encapsulation used, which could be 802.2, radiotap, raw IPv6, or something else. Do we need to specify that?) -- Juliusz From nobody Thu Jan 3 12:59:04 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EBD130F04 for ; Thu, 3 Jan 2019 12:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6g8_Mz-_gXjE for ; Thu, 3 Jan 2019 12:59:00 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416BA126BED for ; Thu, 3 Jan 2019 12:59:00 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1546549107; bh=Zzh4Gk6nFQr0SKALMQb5PP02ua0uVmDKgoKGLn7Bycs=; h=From:To:Subject:In-Reply-To:References:Date:From; b=dR5VKE1TviUICQq3RAe2zlRbMzAmYg0fmb2UdOEN6o+CKo6NVTxDogOCl0a54eb9f cJinipxg7A5FCaLsKRwyzlIcEyRDGMAzR7mVLYvTsuwrva7rD9h4XPcwYynjl17Cw4 NCtdLJa6CyXoNiBmYrsKJmRggo7xdyRMwEA03OdFlpfUnA632oyrTxBr9JaausmZyL 8EObdNojIHeDBAUXIUsY7oHcKkOmJ4LG9DSaU3Zn94t99hu+RA76VLs8pMbRvyXDHw aedHVZRXi4oGOUzKKURgLJvs5TSbRloeyWMTQXdY7B7Ta/tDUw40KRKnjnon/8Owyg vhzpmq/5d2+aQ== To: "STARK\, BARBARA H" , Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Thu, 03 Jan 2019 21:58:25 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87a7khxxu6.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 20:59:03 -0000 "STARK, BARBARA H" writes: > I'm looking at what's needed in the info model for HMAC. > > I don't think the Index and PC of the Interface and Neighbor tables need to (or should) be exposed in the info model. > We had discussed previously that keys should not be readable -- only add and delete keys. In this case, it's good for a non-readable parameter to have a "nickname" or index to reference it with. And it can be useful to know when the key was added. In my experience, these sorts of shared keys are modeled as strings. > Appendix A (incremental deployment and key rotation) indicates it should be possible to configure a mode where authenticated packets are sent but all packets are accepted. > Multiple HMAC algorithms are possible. The draft doesn't say how the nodes know which algorithm is being used (if multiple are implemented). The draft does say that only one HMAC is calculated per key. Is it assumed the algorithm choice is configured? > Should the challenge expiry timer be configurable? > I've decided to have completely separate HMAC and DTLS objects, because they're very different now that I have detailed designs to work with. > I'm adding an "operation" datatype to support key and cert manipulation. This is intended to be consistent with YANG "action" datatype. > > Proposed HMAC model: > add to top level information-obj: > babel-hmac-algorithms (enumerated list of supported HMAC computation algorithms) > > security-hmac-obj > security-hmac-enable (boolean: enable / disable this instance) > security-hmac-mode (Boolean: do or don't authenticate received > packets) How do those two interact? > security-hmac-algorithm (string: one of the supported HMAC algorithms) > security-interfaces (string list of references to interfaces-obj: the interfaces this instance applies to; if empty, it applies to all interfaces) > security-add-hmac-key (operation: inputs (reference name, key)) > hmac-key-obj IMO, we'll need two per-key booleans as well: "use for authentication" and "use for signing". They should be set independent of each other. -Toke From nobody Thu Jan 3 13:25:42 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395CA130F0A for ; Thu, 3 Jan 2019 13:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uBTIQPtH8WK for ; Thu, 3 Jan 2019 13:25:38 -0800 (PST) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550B9126BED for ; Thu, 3 Jan 2019 13:25:38 -0800 (PST) Received: by mail-pf1-x444.google.com with SMTP id c73so17228050pfe.13 for ; Thu, 03 Jan 2019 13:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vZY6tQN+lalcVSg7cwDQsPRDXc1ANQDhOwu3qSeweN4=; b=UjbpTfZfkeoWs3SFFoXYzl5Yt4NBLPG2uYtKl90oDzfUl/uqpcRETGlC8kVutzV4bQ VI126n8K1viZ8ZExvllPZAw/PaUOw3MD4ai5gMLBWeTNp0ZN5nKsvZmMi/+aH3zWxnNK hgn5tez2IzB0Hy+gtIr9yhZj9zPtVzZWwSFMTJ42YfH8pmXQEdmFQ110IIm1rWdsvxw9 lVZp026q4N7JDsB5RM0lpGCzkR3BLoISmqSkHNN00fcaGThqv1YdjzrlnwJsVibdFvn7 hzY0wRZiWE5tJ5TbMteRsefwoov4gy2EHQnQwu659UTs/d0m1N1GcqWy1/HGsZ0uFHZk HVgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vZY6tQN+lalcVSg7cwDQsPRDXc1ANQDhOwu3qSeweN4=; b=BiFtdM3EfgT214Qkd70CGDAqK1fnPdjeqrZTVpci5DKMzUfAaE5KJEjuo2G891w7u/ 4QJRGGJCpl/mbDEfr2ZNWTwC3A80qbT0dt7WzPiyMw76StRPZNfqzVNiIxxKwiUsk2x/ FAKk+Dj5UKt5zaW8qgAoeSPwHeiDBgm3HXr0kuw6j6KXN4Lo33DYV/3nB7kzPOvI6TIt iKhrtrtINNqMvquelxLVMq5k+kplINWbulogYzCXxZ/p2vhWnVtBuAb7IkmRjfD9xrXI HBjwrGbIaYQ61Wp8upBJPbAw4TZM3Gq/0d4jyNWwG5YS/IPgF3bmgNqN/pH5CaDfNgHW ENTg== X-Gm-Message-State: AJcUukcOtPy04R7pHDRTB9fEwi+pTFCLV5C16Ipq6EIV9FbqaJEnV4by 8JHJgYds4WbHlRufaShMSYk= X-Google-Smtp-Source: ALg8bN4lPmSAgUgB0ScPANxqBXs55MAi4yEFNkX9EVgF8tYpv7KWMzQt0lGacwjfH63KOv7R7klJRA== X-Received: by 2002:a62:c583:: with SMTP id j125mr50204791pfg.37.1546550737761; Thu, 03 Jan 2019 13:25:37 -0800 (PST) Received: from [10.33.122.97] ([66.170.99.2]) by smtp.gmail.com with ESMTPSA id n70sm88513250pfi.185.2019.01.03.13.25.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Jan 2019 13:25:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Thu, 3 Jan 2019 13:25:35 -0800 Cc: Babel at IETF Content-Transfer-Encoding: quoted-printable Message-Id: <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 21:25:40 -0000 > On Jan 3, 2019, at 6:41 AM, STARK, BARBARA H wrote: >=20 > I'm looking at what's needed in the info model for HMAC. >=20 > I don't think the Index and PC of the Interface and Neighbor tables = need to (or should) be exposed in the info model. > We had discussed previously that keys should not be readable -- only = add and delete keys. In this case, it's good for a non-readable = parameter to have a "nickname" or index to reference it with. And it can = be useful to know when the key was added. In my experience, these sorts = of shared keys are modeled as strings. I would think the keys are modeled as binary. > Appendix A (incremental deployment and key rotation) indicates it = should be possible to configure a mode where authenticated packets are = sent but all packets are accepted. > Multiple HMAC algorithms are possible. The draft doesn't say how the = nodes know which algorithm is being used (if multiple are implemented). = The draft does say that only one HMAC is calculated per key. Is it = assumed the algorithm choice is configured? > Should the challenge expiry timer be configurable? > I've decided to have completely separate HMAC and DTLS objects, = because they're very different now that I have detailed designs to work = with. > I'm adding an "operation" datatype to support key and cert = manipulation. This is intended to be consistent with YANG "action" = datatype. Is the idea that there is both an input and an output expected for key = and cert manipulation? If it is input only, i.e. configuring key and = cert., then you would not need an action type. Having said that, in the = examples you give below, I expect delete to be an action.=20 I am not clear on the =E2=80=98check-key=E2=80=99 operation. I would = expect that the device is either enabled or disabled to check for HMAC. = If enabled, and when a packet is received, the receiver will compute the = HMAC (using the key configured for it) on the packet and compare it what = is in the packet. If the HMAC compariosn fails, the receiver will drop = the packet, and log a count of dropped packets because of mismatch. Why = would the management plane need to perform a =E2=80=98check-key=E2=80=99 = operation? >=20 > Proposed HMAC model: > add to top level information-obj: > babel-hmac-algorithms (enumerated list of supported HMAC computation = algorithms) >=20 > security-hmac-obj > security-hmac-enable (boolean: enable / disable this instance) > security-hmac-mode (Boolean: do or don't authenticate received = packets) I have the same question as Toke here. > security-hmac-algorithm (string: one of the supported HMAC = algorithms) You mean one of the enum values defined above. Thanks for putting this together. > security-interfaces (string list of references to interfaces-obj: the = interfaces this instance applies to; if empty, it applies to all = interfaces) > security-add-hmac-key (operation: inputs (reference name, key)) =20 > hmac-key-obj > key-name (string: reference name) > key-date (datetime: timestamp when key was added) > delete-key (operation) > check-key (operation: inputs (string, HMAC of string)) ; the = node does its own HMAC computation of the input string and compares this = to the input HMAC of string; if the computed and input HMAC are the same = the operation succeeds. >=20 > Thoughts? > Barbara >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel Mahesh Jethanandani mjethanandani@gmail.com From nobody Thu Jan 3 13:47:06 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D211312FF; Thu, 3 Jan 2019 13:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBQQO3fkFN-1; Thu, 3 Jan 2019 13:47:02 -0800 (PST) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB10130FAF; Thu, 3 Jan 2019 13:47:02 -0800 (PST) Received: by mail-pf1-x431.google.com with SMTP id c123so17275292pfb.0; Thu, 03 Jan 2019 13:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ejYZaWpYVQv+U0YQrNJMGIdSzvXUr3MufhCYBMXsaBU=; b=Yg/YuADiQCPMfFofxlbb9ZBPIQCFc6nSLBc5lx5ta4dzZtuIPFG8WakaONkkAjX12T /2KrAaoRFBjkfVnSU5U9s+rlxhQjmVV6nuwOXfBYQ+4avTfq7EuJ4Nb7LpijO0mEbh+M 3oj+yWl+GTMQ8V32K2Cr4AL3TQ593wfJhCOaDBDZT/jhlawxhbYm7UsTTQZmdRbTms8H f/3W5Zs0LdR9NsO6ZmNSQQVD5QCDJWyDt3Z0/Z67kciRygpEOiWoI2Uvbgh4IcKLdznJ FCUi/VuhCwKSL6RmQso02CE4MxIFzHmD47/RwwVzoGvLkTe15IpMovM8ZRN1drRjPWUc Jf2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ejYZaWpYVQv+U0YQrNJMGIdSzvXUr3MufhCYBMXsaBU=; b=rLOh6K2sDkSQ2oeMT19ABbD0gG8Kztcg+5Fu3BYrbhLVVz0Cgprd1h5/z94gWftdcx obLuK7fOt/e5ppPoIlG7m7wkyXAla2++RgA1LQnwuMrQmK/cMTYfoIOt/vq61WU2C7YD 3lzN1Ii8K2eoSjcQGbBoARhEUAhEhGYcfN6Rljlae0xZ4nUFMg2ggOhFRd8pOfDBCtfG ekVwEJQw1hfOIHnka3ORtJ5P3FjMWXpkw152P5/vYk7CzqteCSaRatwUbq2Zrj9uA5Qn yXGT5qjgjTBTzQjht/4qQhJD3BRqzuMXj4BLPIJNJ+OxLb4Uc+Lr4OCwVs8NZsU2+wI3 yKDA== X-Gm-Message-State: AJcUukcW+FVkgkBjWJKuTmI8yhBOagRao7tkLRNX1qP5+rjeS4d6FtwC EhBS0dZ0f5apS51f7D0rA0b7XAxlarAYSsmAkEBCuoAA X-Google-Smtp-Source: ALg8bN5YW13smVueTFb+UGEjanPeEbVzGTYc74xbNA+Ps35klOstQHJSUyC1uLcfbry7N6DcMn8zshd/Mxne+Wd5ka8= X-Received: by 2002:a62:5658:: with SMTP id k85mr49460346pfb.231.1546552022109; Thu, 03 Jan 2019 13:47:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Thu, 3 Jan 2019 13:46:50 -0800 Message-ID: To: Donald Eastlake Cc: Babel at IETF , babel-chairs Content-Type: multipart/alternative; boundary="000000000000e79a57057e94b3a4" Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-dtls - failed X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 21:47:05 -0000 --000000000000e79a57057e94b3a4 Content-Type: text/plain; charset="UTF-8" Hi Donald, I was honestly quite surprised by your email, as I had interpreted the last call discussions to be more positive. To discuss your points in more detail: > insufficient support indicated I think this might be due to most WG participants having already shown support for this document in the past. I did not see anyone arguing not to publish. > discussion on preserving crypto state This was discussed on the list and there was pretty immediate consensus that adding some text would address the issue entirely. I've now added that text . However, I don't think the lack of that text warranted failing the WG last call. > co-existence with hmac including port numbers I'm not sure what you are referring to, could you elaborate please? > I should also do a Shepherd review of the draft That would be much appreciated, your comments on the other drafts have helped improve them. Hopefully we can resolve this shortly, I don't think there is much standing in the way of us declaring last call for this draft. Thanks, David On Wed, Jan 2, 2019 at 11:35 AM Donald Eastlake wrote: > Hi, > > I'm going to declare this WG Last Call to have failed. There was > insufficient support indicated and there has been discussion on preserving > crypto state and co-existence with hmac including port numbers. I should > also do a Shepherd review of the draft. After these things are cleared up, > we can issue a new WG Last Call that I think will have a higher chance of > success. > > Thanks, > Donald > =============================== > Donald E.. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail.com > > > On Wed, Nov 7, 2018 at 8:16 PM Donald Eastlake wrote: > >> This message begins a Working Group Last Call for >> draft-ietf-babel-dtls-01 running through November 26th. Please indicate >> whether you think this draft is ready for publication as an RFC. Comments >> on the draft are also welcome. >> >> Thanks, >> Donald >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 1424 Pro Shop Court, Davenport, FL 33896 USA >> d3e3e3@gmail.com >> > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000e79a57057e94b3a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Donald,

I was honestly quite surprised by y= our email, as I had interpreted the last call discussions to be more positi= ve. To discuss your points in more detail:

> in= sufficient support indicated

I think this might be= due to most WG participants having already shown support for this document= in the past. I did not see anyone arguing not to publish.

>=C2=A0discussion on preserving crypto state

This was discussed on the list and there was pretty immediate consen= sus that adding some text would address the issue entirely. I've now added that text. However, I don't think the lac= k of that text warranted failing the WG last call.

>=C2=A0co-existence with hmac including port numbers

I'm not sure what you are referring to, could you elaborate plea= se?

>=C2=A0I should also do a Shepherd review o= f the draft

That would be much appreciated, your c= omments on the other drafts have helped improve them.

<= div>Hopefully we can resolve this shortly, I don't think there is much = standing in the way of us declaring last call for this draft.
Thanks,
David


On Wed, Jan 2, 2019 at 11:35 AM Donald E= astlake <d3e3e3@gm= ail.com> wrote:
Hi,

I'm goi= ng to declare this WG Last Call to have failed. There was insufficient supp= ort indicated and there has been discussion on preserving crypto state and = co-existence with hmac including port numbers. I should also do a Shepherd = review of the draft. After these things are cleared up, we can issue a new = WG Last Call that I think will have a higher chance of success.
<= br clear=3D"all">
Thanks,
Donald
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
=C2=A0Donald E.. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2= =A01424 Pro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.com


On Wed, Nov 7, 201= 8 at 8:16 PM Donald Eastlake <d3e3e3@gmail.com> wrote:
This message begins a Working Group Last Call = for draft-ietf-babel-dtls-01 running through November 26th. Please indicate= whether you think this draft is ready for publication as an RFC. Comments = on the draft are also welcome.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= =C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A01424 Pr= o Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.com
_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000e79a57057e94b3a4-- From nobody Thu Jan 3 14:42:47 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16E313134A for ; Thu, 3 Jan 2019 14:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dI6FlUE9zvxQ for ; Thu, 3 Jan 2019 14:42:44 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55CBC131346 for ; Thu, 3 Jan 2019 14:42:44 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x03MZ1Fb040342; Thu, 3 Jan 2019 17:42:43 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2psr3pwk30-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Jan 2019 17:42:43 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x03MggFo013965; Thu, 3 Jan 2019 17:42:42 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x03MgaBZ013860; Thu, 3 Jan 2019 17:42:36 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id D25694014066; Thu, 3 Jan 2019 22:42:36 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30487.vci.att.com (Service) with ESMTPS id BFB004014055; Thu, 3 Jan 2019 22:42:36 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0415.000; Thu, 3 Jan 2019 17:42:36 -0500 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" , Markus Stenberg CC: Babel at IETF Thread-Topic: [babel] info-model: message log Thread-Index: AdSXyYnBQkQrNQ5OTYeO5Bd7aNbDmQCcr+YAAOaIy4ABPlBSwAA3y64AAARvUoAAAEXiAAAD1qlw Date: Thu, 3 Jan 2019 22:42:36 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF82217@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF65C81@GAALPA1MSGUSRBF.ITServices.sbc.com> <87efa9legt.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF7E186@GAALPA1MSGUSRBF.ITServices.sbc.com> <87tviplm17.wl-jch@irif.fr> <5720979F-C0D2-4291-B4D6-653B28E77D4B@kapsi.fi> <87muohlfsj.wl-jch@irif.fr> In-Reply-To: <87muohlfsj.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.218.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-03_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=614 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901030191 Archived-At: Subject: Re: [babel] info-model: message log X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 22:42:46 -0000 > > I vote one format for implementation simplicity. I do not really know > > which one. >=20 > pcap is much simpler. OK. And by "pcap", we mean libpcap per https://wiki.wireshark.org/Developme= nt/LibpcapFileFormat?=20 I'm fine with that. =20 "The libpcap file format (https://wiki.wireshark.org/Development/LibpcapFil= eFormat) with ".pcap" file extension MUST be supported for message log file= s."? Note that supporting message log files is optional, so this is conditi= onally mandatory. =20 > pcapng supports nanosecond timestamps, comments, vendor-defined TLVs, > and bidirectional scanning. While it looks reasonably easy to generate, = it's a > little more challenging to parse in its full generality. Heck, even Wire= shark > doesn't :-/ >=20 > (Note that picking a dump format doesn't mean we can parse it -- there's = the > small matter of the encapsulation used, which could be 802.2, radiotap, r= aw > IPv6, or something else. Do we need to specify that?) Encapsulation is the job of the management protocol. The info model will al= low the file to be exposed either as a URL (in which case encapsulation is = specified by that URL; e.g., "https:\\/mylogfiles/babell= og.pcap") or as a file known to the info model that can be gotten using a m= anagement protocol operation. Barbara From nobody Thu Jan 3 14:55:14 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B214131355 for ; Thu, 3 Jan 2019 14:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WtAQVW8_p5x for ; Thu, 3 Jan 2019 14:55:10 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD86130DE3 for ; Thu, 3 Jan 2019 14:55:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 43W3Cf2FfPz17JcZ; Thu, 3 Jan 2019 14:55:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1546556110; bh=eVVw0c2cqwF41AsC18tPC5c/9pozCPLX6KLTvvqrek8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VSj9/G7Q5h/6+FOBQt1Q1pk+zhIVyr0ksBi+8eiLdJEuIsbjMSr2vFvshgvH/9A+g ZF60t8N61ZGUKM+X64xiS29nqKw6owdvMw1VZNXWoSKG0kIBXb5R4peTe6czNqlsex V2+w+MVmXxvpI1s1foF733irmVbAK/B5bMkkCThg= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 43W3Cc5Yc7z17JcW; Thu, 3 Jan 2019 14:55:07 -0800 (PST) To: "STARK, BARBARA H" , 'Juliusz Chroboczek' , Markus Stenberg Cc: Babel at IETF References: <2D09D61DDFA73D4C884805CC7865E6114DF65C81@GAALPA1MSGUSRBF.ITServices.sbc.com> <87efa9legt.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF7E186@GAALPA1MSGUSRBF.ITServices.sbc.com> <87tviplm17.wl-jch@irif.fr> <5720979F-C0D2-4291-B4D6-653B28E77D4B@kapsi.fi> <87muohlfsj.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF82217@GAALPA1MSGUSRBF.ITServices.sbc.com> From: "Joel M. Halpern" Message-ID: <4b9fe6be-38cf-6659-a032-5df7c98193bc@joelhalpern.com> Date: Thu, 3 Jan 2019 17:55:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF82217@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [babel] info-model: message log X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 22:55:13 -0000 Is that URL a stable referent? Or might the wireshark folks change what is documented there (as they evolve). For an RFC, particularly for something we are mandating, the definition has to be stable. Yours, Joel On 1/3/19 5:42 PM, STARK, BARBARA H wrote: >>> I vote one format for implementation simplicity. I do not really know >>> which one. >> >> pcap is much simpler. > > OK. And by "pcap", we mean libpcap per https://wiki.wireshark.org/Development/LibpcapFileFormat? > I'm fine with that. > "The libpcap file format (https://wiki.wireshark.org/Development/LibpcapFileFormat) with ".pcap" file extension MUST be supported for message log files."? Note that supporting message log files is optional, so this is conditionally mandatory. > >> pcapng supports nanosecond timestamps, comments, vendor-defined TLVs, >> and bidirectional scanning. While it looks reasonably easy to generate, it's a >> little more challenging to parse in its full generality. Heck, even Wireshark >> doesn't :-/ >> >> (Note that picking a dump format doesn't mean we can parse it -- there's the >> small matter of the encapsulation used, which could be 802.2, radiotap, raw >> IPv6, or something else. Do we need to specify that?) > > Encapsulation is the job of the management protocol. The info model will allow the file to be exposed either as a URL (in which case encapsulation is specified by that URL; e.g., "https:\\/mylogfiles/babellog.pcap") or as a file known to the info model that can be gotten using a management protocol operation. > > Barbara > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > From nobody Thu Jan 3 17:11:49 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4068E1313B6; Thu, 3 Jan 2019 17:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwEUwX0qQLzq; Thu, 3 Jan 2019 17:11:45 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26E613133D; Thu, 3 Jan 2019 17:11:44 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x041Ba5Q016474; Fri, 4 Jan 2019 02:11:36 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 655DE42360; Fri, 4 Jan 2019 02:11:42 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id VrE-8Q27DuK3; Fri, 4 Jan 2019 02:11:40 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5BBF14235E; Fri, 4 Jan 2019 02:11:37 +0100 (CET) Date: Fri, 04 Jan 2019 02:11:37 +0100 Message-ID: <87lg41ns52.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Donald Eastlake , babel-chairs , Babel at IETF In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 04 Jan 2019 02:11:36 +0100 (CET) X-Miltered: at korolev with ID 5C2EB2C8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C2EB2C8.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C2EB2C8.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-dtls - failed X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 01:11:47 -0000 Dear Donald, I am just as surprised as David by your decision to fail the last call. >> insufficient support indicated > I think this might be due to most WG participants having already shown support > for this document in the past. I did not see anyone arguing not to publish. As far as I am aware, everyone agrees that Babel-DTLS should be published, in order to satisfy those use cases that are not served by Babel-HMAC (asymmetric keying and confidentiality). >> discussion on preserving crypto state > This was discussed on the list and there was pretty immediate consensus that > adding some text would address the issue entirely. I've now added that text. > However, I don't think the lack of that text warranted failing the WG last > call. This is not a wholly hypothetical vulnerability, and the fix is a single paragraph of text, a simple copy-paste from the latest revision of the Babel-HMAC draft. >> co-existence with hmac including port numbers > I'm not sure what you are referring to, could you elaborate please? I too would appreciate a clarification. -- Juliusz From nobody Thu Jan 3 19:39:04 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E45A130F0B; Thu, 3 Jan 2019 19:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ti0mUnX0u5L0; Thu, 3 Jan 2019 19:39:01 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95EF130E3F; Thu, 3 Jan 2019 19:39:00 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id k7so28610210iob.6; Thu, 03 Jan 2019 19:39:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/vZVt1/D3148Y4nb+OV4ek3wVTlAumDpC5RGPwg8gR4=; b=Ylv1F3FOTrVMqRpQGecnaEKlCxVDE6f1wvarGQFP+CAy+9z8X2q3HkQDmLcBM8NhMU niCJ6dDcFoV9Q/0JvvSTQsKfjSPVhYJnGMds22Hf6EbDRM/FU01uEPh1LY5Ro9XkFHjM KIcrTwfdrrDljRNhk7Sn9wI3pbdvkb0VZybdzMcxpNxKDREL5hOw6O1fkJKLc6O3/r0q dNmmFZhxv4siTSEw75XUboncUfSrxuqliX0acxwnSsiYfGR3ERDKYhnLYHoZANd3Lmjh 8wdDaq1Pil9FACyaYaJi0ZjRzK+fNo8tbk0nmbXihuOrsLpvWlGNYsipbOmcdbr4SGDJ lrrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/vZVt1/D3148Y4nb+OV4ek3wVTlAumDpC5RGPwg8gR4=; b=TOB5W/WC5A2eZ6YgSLEoXNS4Hl1//OOQzZeJkQf9F6sbEu9g2DQeFNA3p+6dU2wjc2 ZnR1ugIOvD79e44Zba4+teGLpe2Zjs64TaKXAjRstsvHmvqxtcyD+V2WFpdwELjZQqJY Pdaohvb/XEWUSqtsENWNsyq2bC/nsGQn26yoFAlWG6RJ1Qv+W52nxNWs4o3KEYB0YTqY lE0s3nsD7MKG07fTD2OPX4w8BNt8RfIAPlhxwmwy90l7c0SvF0UbBp7Eqlq+Z+XrKd7k 2FBpOc6sWA0HJFL+bBd+4HpkVOkm2k4/qkP8BKfxu7PxmyE7P4IQn5rqipFqzTjFa+8G GeVA== X-Gm-Message-State: AJcUukfDUyI1i07BHO4y8pwYG8CiZYK+qn+OAP3rJw9Pk+Y3X3AjcSVQ EPL6GR9iBGA/3LuLvKrAZAiW7+mh7sGpWyWqYXo= X-Google-Smtp-Source: ALg8bN7RCa6PfqJlXsMbbYnt9mUNav3jQ6vSm41JGB1K8DvdIC5m8o3FseR2GRQMksJ7ZbEqyaSFGNMI8sVwowGpiDo= X-Received: by 2002:a6b:e919:: with SMTP id u25mr36072591iof.132.1546573139787; Thu, 03 Jan 2019 19:38:59 -0800 (PST) MIME-Version: 1.0 References: <87lg41ns52.wl-jch@irif.fr> In-Reply-To: <87lg41ns52.wl-jch@irif.fr> From: Donald Eastlake Date: Thu, 3 Jan 2019 22:38:48 -0500 Message-ID: To: Juliusz Chroboczek , David Schinazi Cc: babel-chairs , Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-dtls - failed X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 03:39:03 -0000 Hi, On Thu, Jan 3, 2019 at 8:11 PM Juliusz Chroboczek wrote: > > Dear Donald, > > I am just as surprised as David by your decision to fail the last call. > > >> insufficient support indicated > > > I think this might be due to most WG participants having already shown support > > for this document in the past. I did not see anyone arguing not to publish. > > As far as I am aware, everyone agrees that Babel-DTLS should be published, > in order to satisfy those use cases that are not served by Babel-HMAC > (asymmetric keying and confidentiality). Perhaps I should have been more verbose. I meant "insufficient support indicated on the mailing list in response to the WG Last Call". While I believe it is legitimate for a WG Chair to take into account other traffic on the mailing list and support shown in face-to-face meetings, the call I posted didn't, for example, say there appeared to be consensus and ask if there was any opposition. The message I posted was a typical WG LC that asked for people to respond if they supported or opposed publication: https://www.ietf.org/mail-archive/web/babel/current/msg01570.html True, there were no opposition responses. But it is also true there were zero responses indicating support. There were two responses but neither expressed an opinion on publication. If there were any problems later with a WG declaration of consensus, say an appeal, what do you think the initial conclusion would be based on an examination of the Babel WG mailing list? > >> discussion on preserving crypto state > > > This was discussed on the list and there was pretty immediate consensus that > > adding some text would address the issue entirely. I've now added that text. > > However, I don't think the lack of that text warranted failing the WG last > > call. > > This is not a wholly hypothetical vulnerability, and the fix is a single > paragraph of text, a simple copy-paste from the latest revision of the > Babel-HMAC draft. Guess I should have stopped when I was ahead. But, while technical changes can be made after the declaration of WG consensus, they are procedurally more normal if made before the declaration of WG consensus. And subsequent declaration of WG consensus provide an especially solid confirmation of the change. > >> co-existence with hmac including port numbers > > > I'm not sure what you are referring to, could you elaborate please? As I recall I noticed some discussion of the port number(s) to be used by Babel over DTLS that had not been fully resolved. > I too would appreciate a clarification. I am confident that after minor improvements, the draft will pass a subsequent WG LC. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com > -- Juliusz From nobody Thu Jan 3 22:00:04 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF707130F66; Thu, 3 Jan 2019 22:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8jKeeRmFt9J; Thu, 3 Jan 2019 21:59:59 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF36F130F65; Thu, 3 Jan 2019 21:59:59 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id w6so17030404pgl.6; Thu, 03 Jan 2019 21:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0thyn88ztAj5LpWrg0PZO4r2kY6gIe7dhcsaUgXKuw4=; b=B2IdkdA+YtfuITBD/U6WW0qwg7rfnCCDb7iy6KWeciKfUF0poGCXM7JcV8/SU6Aqem QZZ4RdOGfFFX04fPoRkHvSj1As5KB7y7xFmJxLGAOQTv8o8FMNC7NVtxY2+oxQspYnnQ QTqw80PnTx6OcQyuAWarqfClbLCn1X0y+1xLn0RXoWAMOdKJjywArT9Cbo9BE6wXpqPQ kR8vB/49fBqJo7Y7gUjdpEFoIHdFkp+c9BfO9ZHUFYjuflAPTAI2aW7uOuFgFIfEFZWm axbQEu1NiVcnYunqqPk5wLjr/B2JG5l3M4wEHMO2Kix5yYNReAfPpkAfWdVL+VigI4ef oX5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0thyn88ztAj5LpWrg0PZO4r2kY6gIe7dhcsaUgXKuw4=; b=AJv1HTCl5xP0q7GEPOQ9Hsu5STlFyXwJnDkjQgBB4MO0fcRk0zBdELzU9pDZ/7+OXV QBIbR74f469xp2O56uKjBfipYOG1gOB52d8S+QnEACMCzTrfk5vryXomMUenxiv2tTQP Rsi1E8nvjFwdbqsztHUbqLuPlgeL0dBBanig/X3v8fXWXOaBcQz7XCykvTTjUSaH5nUv 78k18K75ub6/nL0M9GaFA9WaU8dIL6QziuQGrOjKMSPicz3wC5JHLYGnH2iNdLIRr7Yr bPYvdql3PirGe6pRm6ZglFPsQQLe7JMgvssDPETfUAnOzS0SP6Lpf5H5lPNhwCafOn6y Tp0g== X-Gm-Message-State: AJcUukdjYR1+Jq3d/3Mx382y6Q75ssWXh7ecFM/pnqVoPmDYg0QDnB/k ADfPfvNSc8Qguv+gohU7FLZSBdzsW33BtkRdyXhMyPW8 X-Google-Smtp-Source: ALg8bN5m4okS/l84LmoH+t66MI8XQu1+6Inr6TEZ4z/o0VhNhcfa0pWr509za6eFDMLJYzydBLPrzb60q9DADe4IVNo= X-Received: by 2002:a63:7e1a:: with SMTP id z26mr35670154pgc.216.1546581599007; Thu, 03 Jan 2019 21:59:59 -0800 (PST) MIME-Version: 1.0 References: <87lg41ns52.wl-jch@irif.fr> In-Reply-To: From: David Schinazi Date: Thu, 3 Jan 2019 21:59:47 -0800 Message-ID: To: Donald Eastlake Cc: Juliusz Chroboczek , babel-chairs , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000d338fa057e9b9697" Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-dtls - failed X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 06:00:02 -0000 --000000000000d338fa057e9b9697 Content-Type: text/plain; charset="UTF-8" Hi Donald, Thanks for elaborating. > As I recall I noticed some discussion of the port number(s) to be used by Babel over DTLS that had not been fully resolved. The port number discussion was resolved in October 2018 and the output was added to draft-ietf-babel-dtls-01. If you know of anything else outstanding, could you please send us details? > I am confident that after minor improvements, the draft will pass a subsequent WG LC. Could you please send us a specific list of requested minor improvements, so we can start the new WG LC? Thanks, David On Thu, Jan 3, 2019 at 7:39 PM Donald Eastlake wrote: > Hi, > > On Thu, Jan 3, 2019 at 8:11 PM Juliusz Chroboczek wrote: > > > > Dear Donald, > > > > I am just as surprised as David by your decision to fail the last call. > > > > >> insufficient support indicated > > > > > I think this might be due to most WG participants having already shown > support > > > for this document in the past. I did not see anyone arguing not to > publish. > > > > As far as I am aware, everyone agrees that Babel-DTLS should be > published, > > in order to satisfy those use cases that are not served by Babel-HMAC > > (asymmetric keying and confidentiality). > > Perhaps I should have been more verbose. I meant "insufficient support > indicated on the mailing list in response to the WG Last Call". While > I believe it is legitimate for a WG Chair to take into account other > traffic on the mailing list and support shown in face-to-face > meetings, the call I posted didn't, for example, say there appeared to > be consensus and ask if there was any opposition. The message I posted > was a typical WG LC that asked for people to respond if they supported > or opposed publication: > https://www.ietf.org/mail-archive/web/babel/current/msg01570.html > True, there were no opposition responses. But it is also true there > were zero responses indicating support. There were two responses but > neither expressed an opinion on publication. If there were any > problems later with a WG declaration of consensus, say an appeal, what > do you think the initial conclusion would be based on an examination > of the Babel WG mailing list? > > > >> discussion on preserving crypto state > > > > > This was discussed on the list and there was pretty immediate > consensus that > > > adding some text would address the issue entirely. I've now added that > text. > > > However, I don't think the lack of that text warranted failing the WG > last > > > call. > > > > This is not a wholly hypothetical vulnerability, and the fix is a single > > paragraph of text, a simple copy-paste from the latest revision of the > > Babel-HMAC draft. > > Guess I should have stopped when I was ahead. But, while technical > changes can be made after the declaration of WG consensus, they are > procedurally more normal if made before the declaration of WG > consensus. And subsequent declaration of WG consensus provide an > especially solid confirmation of the change. > > > >> co-existence with hmac including port numbers > > > > > I'm not sure what you are referring to, could you elaborate please? > > As I recall I noticed some discussion of the port number(s) to be used > by Babel over DTLS that had not been fully resolved. > > > I too would appreciate a clarification. > > I am confident that after minor improvements, the draft will pass a > subsequent WG LC. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail.com > > > -- Juliusz > --000000000000d338fa057e9b9697 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dona= ld,

Thanks for elaborating.

> As I recall I noticed some discussion of the port number(s) to be us= ed by Babel over DTLS that had not been fully resolved.
The port number discussion was resolved in October 2018 and the= output was added to=C2=A0draft-ietf-babel-dtls-01. If you know of anything= else outstanding, could you please send us details?

> I am confident that after minor improvements, the draft will pass a= subsequent WG LC.

Could you please send us a spec= ific list of requested minor improvements, so we can start the new WG LC?

Thanks,
David

<= /div>

On Thu, Ja= n 3, 2019 at 7:39 PM Donald Eastlake <d3e3e3@gmail.com> wrote:
Hi,

On Thu, Jan 3, 2019 at 8:11 PM Juliusz Chroboczek <jch@irif.fr> wrote:
>
> Dear Donald,
>
> I am just as surprised as David by your decision to fail the last call= .
>
> >> insufficient support indicated
>
> > I think this might be due to most WG participants having already = shown support
> > for this document in the past. I did not see anyone arguing not t= o publish.
>
> As far as I am aware, everyone agrees that Babel-DTLS should be publis= hed,
> in order to satisfy those use cases that are not served by Babel-HMAC<= br> > (asymmetric keying and confidentiality).

Perhaps I should have been more verbose. I meant "insufficient support=
indicated on the mailing list in response to the WG Last Call". While<= br> I believe it is legitimate for a WG Chair to take into account other
traffic on the mailing list and support shown in face-to-face
meetings, the call I posted didn't, for example, say there appeared to<= br> be consensus and ask if there was any opposition. The message I posted
was a typical WG LC that asked for people to respond if they supported
or opposed publication:
https://www.ietf.org/mail-archive/w= eb/babel/current/msg01570.html
True, there were no opposition responses. But it is also true there
were zero responses indicating support. There were two responses but
neither expressed an opinion on publication. If there were any
problems later with a WG declaration of consensus, say an appeal, what
do you think the initial conclusion would be based on an examination
of the Babel WG mailing list?

> >> discussion on preserving crypto state
>
> > This was discussed on the list and there was pretty immediate con= sensus that
> > adding some text would address the issue entirely. I've now a= dded that text.
> > However, I don't think the lack of that text warranted failin= g the WG last
> > call.
>
> This is not a wholly hypothetical vulnerability, and the fix is a sing= le
> paragraph of text, a simple copy-paste from the latest revision of the=
> Babel-HMAC draft.

Guess I should have stopped when I was ahead. But, while technical
changes can be made after the declaration of WG consensus, they are
procedurally more normal if made before the declaration of WG
consensus. And subsequent declaration of WG consensus provide an
especially solid confirmation of the change.

> >> co-existence with hmac including port numbers
>
> > I'm not sure what you are referring to, could you elaborate p= lease?

As I recall I noticed some discussion of the port number(s) to be used
by Babel over DTLS that had not been fully resolved.

> I too would appreciate a clarification.

I am confident that after minor improvements, the draft will pass a
subsequent WG LC.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A01424 Pro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.co= m

> -- Juliusz
--000000000000d338fa057e9b9697-- From nobody Fri Jan 4 05:35:15 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BDE1295D8 for ; Fri, 4 Jan 2019 05:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN3HekXnKJos for ; Fri, 4 Jan 2019 05:35:13 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07573128D0C for ; Fri, 4 Jan 2019 05:35:12 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x04DYtsF000775 for ; Fri, 4 Jan 2019 08:35:12 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2pt80rrqru-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 04 Jan 2019 08:35:11 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x04DZBs8030598 for ; Fri, 4 Jan 2019 08:35:11 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x04DZ5Lm030426 for ; Fri, 4 Jan 2019 08:35:07 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id EAEB740002C1 for ; Fri, 4 Jan 2019 13:35:05 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30488.vci.att.com (Service) with ESMTPS id D25F74048C3B for ; Fri, 4 Jan 2019 13:35:05 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0415.000; Fri, 4 Jan 2019 08:35:05 -0500 From: "STARK, BARBARA H" To: Babel at IETF Thread-Topic: minor DTLS comment Thread-Index: AdSkL1vol8xv1+2PTJSCJUACYAMkyw== Date: Fri, 4 Jan 2019 13:35:04 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF82DC1@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.254.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-04_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=437 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901040120 Archived-At: Subject: [babel] minor DTLS comment X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 13:35:14 -0000 Since the DTLS draft is still open for comments, I do have a small one abou= t how the UDP ports are characterized. The IANA assigned ports are default values, and need to be portrayed as suc= h. It's allowed (or should be) for deployed instances to use other values. = This is pretty much true of all protocols. Certainly the base babel protoco= l allows other values to be used (which is why the homenet babel profile ma= ndated use of 6696). Maybe instead of All Babel over DTLS nodes MUST act as DTLS servers on the "babel- dtls" port (UDP port TBD), and MUST listen for traffic on the unencrypted "babel" port (UDP port 6696). say All Babel over DTLS nodes MUST act as DTLS servers on the "babel- dtls" port, and MUST listen for traffic on the unencrypted "babel" port. The IANA-assigned values of 6696 for the "babel" port and=20 TBD for the "babel-dtls" port SHOULD be used. Barbara From nobody Fri Jan 4 06:25:00 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0ED412D4EA for ; Fri, 4 Jan 2019 06:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flRBr2gShL10 for ; Fri, 4 Jan 2019 06:24:57 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BBF1128CF2 for ; Fri, 4 Jan 2019 06:24:57 -0800 (PST) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x04EGYI5011390; Fri, 4 Jan 2019 09:24:56 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2pt60cmav0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Jan 2019 09:24:56 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x04EOtiE008956; Fri, 4 Jan 2019 09:24:55 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x04EOqTY008918; Fri, 4 Jan 2019 09:24:53 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 25A7A4048C22; Fri, 4 Jan 2019 14:24:52 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30485.vci.att.com (Service) with ESMTPS id 1100940002B5; Fri, 4 Jan 2019 14:24:52 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0415.000; Fri, 4 Jan 2019 09:24:51 -0500 From: "STARK, BARBARA H" To: "'Joel M. Halpern'" , "'Juliusz Chroboczek'" , Markus Stenberg CC: Babel at IETF Thread-Topic: [babel] info-model: message log Thread-Index: AdSXyYnBQkQrNQ5OTYeO5Bd7aNbDmQCcr+YAAOaIy4ABPlBSwAA3y64AAARvUoAAAEXiAAAD1qlwAAQO1QAAFENCkA== Date: Fri, 4 Jan 2019 14:24:51 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF82F58@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF65C81@GAALPA1MSGUSRBF.ITServices.sbc.com> <87efa9legt.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF7E186@GAALPA1MSGUSRBF.ITServices.sbc.com> <87tviplm17.wl-jch@irif.fr> <5720979F-C0D2-4291-B4D6-653B28E77D4B@kapsi.fi> <87muohlfsj.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF82217@GAALPA1MSGUSRBF.ITServices.sbc.com> <4b9fe6be-38cf-6659-a032-5df7c98193bc@joelhalpern.com> In-Reply-To: <4b9fe6be-38cf-6659-a032-5df7c98193bc@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.254.227] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901040126 Archived-At: Subject: Re: [babel] info-model: message log X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 14:24:59 -0000 PiBJcyB0aGF0IFVSTCBhIHN0YWJsZSByZWZlcmVudD8gIE9yIG1pZ2h0IHRoZSB3aXJlc2hhcmsg Zm9sa3MgY2hhbmdlIHdoYXQgaXMNCj4gZG9jdW1lbnRlZCB0aGVyZSAoYXMgdGhleSBldm9sdmUp Lg0KDQpUaGV5J3ZlIGJlZW4gc3RhYmxlIGZvciAzIHllYXJzIGFuZCBzZWVtIHRvIHVuZGVyc3Rh bmQgdGhhdCBjaGFuZ2luZyB0aGUgImxpYnBjYXAiIGZvcm1hdCB3b3VsZCBub3QgYmUgYSBnb29k IHRoaW5nIGJlY2F1c2Ugb2YgaXRzIHN1cHBvcnQgaW4gbW9yZSB0aGFuIGp1c3Qgd2lyZXNoYXJr LiBSYXRoZXIsIHRoZXkndmUgdHJpZWQgdG8gZXZvbHZlIGJ5IGRlZmluaW5nIGEgbmV3IGZvcm1h dCAocGNhcG5nKS4NCg0KPiBGb3IgYW4gUkZDLCBwYXJ0aWN1bGFybHkgZm9yIHNvbWV0aGluZyB3 ZSBhcmUgbWFuZGF0aW5nLCB0aGUgZGVmaW5pdGlvbiBoYXMgdG8NCj4gYmUgc3RhYmxlLg0KDQpD b25kaXRpb25hbGx5IG1hbmRhdG9yeSBpc24ndCBxdWl0ZSB0aGUgc2FtZSBhcyBtYW5kYXRvcnku IFRoZSBjb25kaXRpb24gaXMgImlmIGNyZWF0aW5nIGEgbWVzc2FnZSBsb2cgaXMgc3VwcG9ydGVk Ii4gU3VwcG9ydGluZyBjcmVhdGlvbiBvZiBhIG1lc3NhZ2UgbG9nIGlzIG9wdGlvbmFsLiBBbHNv LCB0aGVyZSdzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIChjb25kaXRpb25hbGx5KSBtYW5kYXRvcnkg dG8gdXNlIHZzLiBzdXBwb3J0LiBJJ20gb25seSBzdWdnZXN0aW5nIG1hbmRhdG9yeSB0byBzdXBw b3J0IHRoaXMgZmlsZSBmb3JtYXQuIEkgdGhpbmsgaW1wbGVtZW50YXRpb25zIG5lZWQgdG8gYmUg ZnJlZSB0byBzdXBwb3J0IChhbmQgdXNlKSBvdGhlciBmaWxlIGZvcm1hdHMsIGFzIHdlbGwuIA0K DQpCdXQsIEkgYWdyZWUgdGhhdCBzdGFiaWxpdHkgaXMgZGVzaXJhYmxlLg0KQXMgSSBzZWUgaXQs IG9wdGlvbnMgYXJlOg0KMS4gRGVjaWRlIGFueXdheSB0aGF0IHRoZSBXaXJlc2hhcmsgcmVmZXJl bmNlIGlzIGdvb2QgZW5vdWdoIGZvciB0aGlzIHB1cnBvc2UuDQoyLiBEZWZpbmUgYSBkaWZmZXJl bnQgZm9ybWF0ICh3b24ndCBoYXBwZW47IG5vdCBhIHJlYWwgb3B0aW9uKQ0KMy4gVXNlIGEgZGlm ZmVyZW50IGFscmVhZHktZGVmaW5lZCBzdGFibGUgZm9ybWF0IChkb2Vzbid0IGV4aXN0OyBub3Qg YSByZWFsIG9wdGlvbikNCjQuIENvcHkgdGhlIGxpYnBjYXAgZm9ybWF0IGRlZmluaXRpb24gaW50 byB0aGlzIGRyYWZ0ICh3aXRoIHByb3BlciBhdHRyaWJ1dGlvbiB0byBXaXJlc2hhcms7IHdvdWxk IHdlIG5lZWQgdG8gZ2V0IHBlcm1pc3Npb24gZnJvbSBXaXJlc2hhcmsgdG8gY29weSBpdD8pDQo1 LiBSZW1vdmUgYW55IGFuZCBhbGwgc3VnZ2VzdGlvbnMgdGhhdCBpdCBtaWdodCBiZSBwb3NzaWJs ZSBmb3IgYSBtZXNzYWdlIGxvZyB0byBiZSBnZW5lcmF0ZWQgKHdoaWxlIEkgZmluZCBtZXNzYWdl IGxvZ3MgdG8gYmUgdmFsdWFibGUgaW4gdHJvdWJsZS1zaG9vdGluZyBhbmQgYW0gYXdhcmUgb2Yg bWFueSBkZXZpY2VzIHRoYXQgc3VjY2Vzc2Z1bGx5IHByb3ZpZGUgc3VjaCBsb2dzIHdpdGggYXBw YXJlbnQgZWFzZSwgSSdtIHN0YXJ0aW5nIHRvIHRoaW5rIGl0J3MgbW9yZSB0cm91YmxlIHRoYW4g aXQncyB3b3J0aCB0byBpbmNsdWRlIG9uZSBhcyBhbiBvcHRpb25hbCBlbGVtZW50IGluIHRoaXMg aW5mbyBtb2RlbCkNCjYuIExlYXZlIHRoZSBvcHRpb25hbCBtZXNzYWdlIGxvZyBidXQgcmVtb3Zl IGFsbCBtZW50aW9uIG9mIGhvdyB0byBmb3JtYXQgdGhlIGZpbGUgKGFueWJvZHkgd2hvIHN1cHBv cnRzIHRoZSBtZXNzYWdlIGxvZyBpcyBsaWtlbHkgdG8gdXNlIGxpYnBjYXAgYW55d2F5LCBhbmQg dGhpcyB3YXkgdGhlcmUncyBubyBwb3RlbnRpYWxseS11bnN0YWJsZSByZWZlcmVuY2VzIG9yIHBs YWdpYXJpemVkIGNvbnRlbnQgaW4gYW4gSUVURiBSRkM7IHRoZXJlIGlzIHRoZSBkYW5nZXIgb2Yg bGFjayBvZiBpbnRlcm9wZXJhYmlsaXR5KQ0KDQpJJ20gb3BlbiB0byBvdGhlciBvcHRpb25zLiBT byBsb25nIGFzIHRoZXkncmUgc2ltcGxlLiBJZiB0aGV5IGFyZW4ndCBzaW1wbGUsIEkgdGhpbmsg b3B0aW9uIDUgaXMgdGhlIGJlc3QgYXBwcm9hY2guIEknbSBub3Qgd2lsbGluZyB0byBwdXQgYSBs b3Qgb2YgZWZmb3J0IGludG8gdGhpcy4NCg0KQmFyYmFyYQ0KDQo+IFlvdXJzLA0KPiBKb2VsDQo+ IA0KPiBPbiAxLzMvMTkgNTo0MiBQTSwgU1RBUkssIEJBUkJBUkEgSCB3cm90ZToNCj4gPj4+IEkg dm90ZSBvbmUgZm9ybWF0IGZvciBpbXBsZW1lbnRhdGlvbiBzaW1wbGljaXR5LiAgSSBkbyBub3Qg cmVhbGx5DQo+ID4+PiBrbm93IHdoaWNoIG9uZS4NCj4gPj4NCj4gPj4gcGNhcCBpcyBtdWNoIHNp bXBsZXIuDQo+ID4NCj4gPiBPSy4gQW5kIGJ5ICJwY2FwIiwgd2UgbWVhbiBsaWJwY2FwIHBlciA8 dXJsPg0KPiA+IA0KPiA+IEknbSBmaW5lIHdpdGggdGhhdC4NCj4gPiAiVGhlIGxpYnBjYXAgZmls ZSBmb3JtYXQNCj4gKDx1cmw+KSB3aXRoICIucGNhcCIgZmlsZSBleHRlbnNpb24gTVVTVCBiZSBz dXBwb3J0ZWQgZm9yIG1lc3NhZ2UgbG9nDQo+IGZpbGVzLiI/IE5vdGUgdGhhdCBzdXBwb3J0aW5n IG1lc3NhZ2UgbG9nIGZpbGVzIGlzIG9wdGlvbmFsLCBzbyB0aGlzIGlzDQo+IGNvbmRpdGlvbmFs bHkgbWFuZGF0b3J5Lg0KPiA+DQo+ID4+IHBjYXBuZyBzdXBwb3J0cyBuYW5vc2Vjb25kIHRpbWVz dGFtcHMsIGNvbW1lbnRzLCB2ZW5kb3ItZGVmaW5lZA0KPiBUTFZzLA0KPiA+PiBhbmQgYmlkaXJl Y3Rpb25hbCBzY2FubmluZy4gIFdoaWxlIGl0IGxvb2tzIHJlYXNvbmFibHkgZWFzeSB0bw0KPiA+ PiBnZW5lcmF0ZSwgaXQncyBhIGxpdHRsZSBtb3JlIGNoYWxsZW5naW5nIHRvIHBhcnNlIGluIGl0 cyBmdWxsDQo+ID4+IGdlbmVyYWxpdHkuICBIZWNrLCBldmVuIFdpcmVzaGFyayBkb2Vzbid0IDot Lw0KPiA+Pg0KPiA+PiAoTm90ZSB0aGF0IHBpY2tpbmcgYSBkdW1wIGZvcm1hdCBkb2Vzbid0IG1l YW4gd2UgY2FuIHBhcnNlIGl0IC0tDQo+ID4+IHRoZXJlJ3MgdGhlIHNtYWxsIG1hdHRlciBvZiB0 aGUgZW5jYXBzdWxhdGlvbiB1c2VkLCB3aGljaCBjb3VsZCBiZQ0KPiA+PiA4MDIuMiwgcmFkaW90 YXAsIHJhdyBJUHY2LCBvciBzb21ldGhpbmcgZWxzZS4gIERvIHdlIG5lZWQgdG8gc3BlY2lmeQ0K PiA+PiB0aGF0PykNCj4gPg0KPiA+IEVuY2Fwc3VsYXRpb24gaXMgdGhlIGpvYiBvZiB0aGUgbWFu YWdlbWVudCBwcm90b2NvbC4gVGhlIGluZm8gbW9kZWwgd2lsbA0KPiBhbGxvdyB0aGUgZmlsZSB0 byBiZSBleHBvc2VkIGVpdGhlciBhcyBhIFVSTCAoaW4gd2hpY2ggY2FzZSBlbmNhcHN1bGF0aW9u IGlzDQo+IHNwZWNpZmllZCBieSB0aGF0IFVSTDsgZS5nLiwgImh0dHBzOlxcPHJvdXRlciBJUA0K PiBhZGRyZXNzPi9teWxvZ2ZpbGVzL2JhYmVsbG9nLnBjYXAiKSBvciBhcyBhIGZpbGUga25vd24g dG8gdGhlIGluZm8gbW9kZWwNCj4gdGhhdCBjYW4gYmUgZ290dGVuIHVzaW5nIGEgbWFuYWdlbWVu dCBwcm90b2NvbCBvcGVyYXRpb24uDQo+ID4NCj4gPiBCYXJiYXJhDQo+ID4NCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGJhYmVsIG1haWxp bmcgbGlzdA0KPiA+IGJhYmVsQGlldGYub3JnDQo= From nobody Fri Jan 4 08:22:45 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784D5130E0C for ; Fri, 4 Jan 2019 08:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo2UsdNv74A5 for ; Fri, 4 Jan 2019 08:22:41 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8A2130E0F for ; Fri, 4 Jan 2019 08:22:41 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x04GG9DH046432; Fri, 4 Jan 2019 11:22:33 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2ptafmgwcn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Jan 2019 11:22:33 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x04GMVop002867; Fri, 4 Jan 2019 11:22:31 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x04GMTZ1002856; Fri, 4 Jan 2019 11:22:29 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id D91D74013D2E; Fri, 4 Jan 2019 16:22:29 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30484.vci.att.com (Service) with ESMTPS id C49B44013D2F; Fri, 4 Jan 2019 16:22:29 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0415.000; Fri, 4 Jan 2019 11:22:29 -0500 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: Babel at IETF Thread-Topic: [babel] hmac info model elements Thread-Index: AdSi6E9jJwLKz5kXQlCy2NNONpdJZQA09T8AACFGxRA= Date: Fri, 4 Jan 2019 16:22:29 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF83139@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <87o98xlhmr.wl-jch@irif.fr> In-Reply-To: <87o98xlhmr.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.254.227] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-04_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901040141 Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 16:22:44 -0000 PiA+IE11bHRpcGxlIEhNQUMgYWxnb3JpdGhtcyBhcmUgcG9zc2libGUuIFRoZSBkcmFmdCBkb2Vz bid0IHNheSBob3cgdGhlDQo+ID4gbm9kZXMga25vdyB3aGljaCBhbGdvcml0aG0gaXMgYmVpbmcg dXNlZCAoaWYgbXVsdGlwbGUgYXJlIGltcGxlbWVudGVkKS4NCj4gDQo+IEl0J3MgYSBsb2NhbCBj b25maWd1cmF0aW9uIGlzc3VlLCBhbmQgdGhlcmVmb3JlIG91dCBvZiBzY29wZSBmb3IgdGhlIHBy b3RvY29sDQo+IGRlc2NyaXB0aW9uLg0KPg0KPiA+IFRoZSBkcmFmdCBkb2VzIHNheSB0aGF0IG9u bHkgb25lIEhNQUMgaXMgY2FsY3VsYXRlZCBwZXIga2V5LiBJcyBpdA0KPiA+IGFzc3VtZWQgdGhl IGFsZ29yaXRobSBjaG9pY2UgaXMgY29uZmlndXJlZD8NCj4gDQo+IFllcy4NCg0KR29vZCAtLSBJ IHdhc24ndCBzdWdnZXN0aW5nIGl0IHNob3VsZCBiZSBpbiB0aGUgcHJvdG9jb2wgZGVzY3JpcHRp b24uIEkgd2FzIGp1c3QgcmVhZGluZyB0aHJvdWdoIHRoZSBkcmFmdCB0byBmaW5kIHRoaW5ncyB0 aGF0IG1pZ2h0IG5lZWQgdG8gYmUgY29uZmlndXJlZCBhbmQgdGhlcmVmb3JlIHN1cHBvcnRlZCBp biB0aGUgaW5mbyBtb2RlbC4gSXQgc291bmRzIGxpa2Ugd2UgYWdyZWUgSE1BQyBhbGdvcml0aG0g c2VsZWN0aW9uIGlzIHN1Y2ggYSB0aGluZy4g8J+Yig0KDQo+ID4gU2hvdWxkIHRoZSBjaGFsbGVu Z2UgZXhwaXJ5IHRpbWVyIGJlIGNvbmZpZ3VyYWJsZT8NCj4gDQo+IE5vLiAgSXQncyBhbiBpbXBs ZW1lbnRhdGlvbiBkZXRhaWwsIGFuZCBhbnkgdmFsdWUgYmV0d2VlbiBhIGZldyBzZWNvbmRzIGFu ZA0KPiBhIGZldyBtaW51dGVzIHdpbGwgZG8uDQoNCkdvb2QuIEkgZGlkbid0IHJlYWxseSB0aGlu ayBzbyBlaXRoZXIgYnV0IHdhbnRlZCB0byBjaGVjay4NCg0KPiA+IHNlY3VyaXR5LWhtYWMtb2Jq DQo+IA0KPiBbLi4uXQ0KPiANCj4gPiAgIHNlY3VyaXR5LWludGVyZmFjZXMgKHN0cmluZyBsaXN0 IG9mIHJlZmVyZW5jZXMgdG8gaW50ZXJmYWNlcy1vYmo6IHRoZQ0KPiA+ICAgaW50ZXJmYWNlcyB0 aGlzIGluc3RhbmNlIGFwcGxpZXMgdG87IGlmIGVtcHR5LCBpdCBhcHBsaWVzIHRvIGFsbA0KPiA+ ICAgaW50ZXJmYWNlcykNCj4gDQo+IEhtbS4uLiB0aGF0IGdvdCBtZSBjb25mdXNlZCBmb3IgYSB3 aGlsZSwgYnV0IEkgc2VlIHdoYXQgeW91J3JlIGRvaW5nIGhlcmUuDQoNCkdvb2Q/IE15IGdvYWwg aXMgdG8gbWFrZSBpdCBlYXN5IGZvciBhIHNpbXBsZSBpbXBsZW1lbnRhdGlvbiB0byBqdXN0IHN1 cHBvcnQgSE1BQyBlaXRoZXIgZW5hYmxlZCAob24gYWxsIGludGVyZmFjZXMpIG9yIGRpc2FibGVk LCB3aXRoIGEgc2luZ2xlIHNldCBvZiBrZXlzOyBidXQgdG8gYWxsb3cgZm9yIGltcGxlbWVudGF0 aW9ucyB3aGVyZSBITUFDIGNhbiBiZSBlbmFibGVkL2Rpc2FibGVkIHBlciBpbnRlcmZhY2UgKG9y IHNldCBvZiBpbnRlcmZhY2VzKSBhbmQgd2l0aCBkaWZmZXJlbnQga2V5cyBwZXIgaW50ZXJmYWNl IChzZXQpLiBFdmVuIHdpdGggdGhlIG1vcmUgY29tcGxleCBpbXBsZW1lbnRhdGlvbiwgaXQgc2hv dWxkIHN0aWxsIGJlIGVhc3kgdG8gZW5hYmxlIEhNQUMgYWNyb3NzIGFsbCBpbnRlcmZhY2VzIHdp dGggYSBzaW5nbGUgc2V0IG9mIGtleXMuIFRoZSBzaW1wbGUgaW1wbGVtZW50YXRpb24gd291bGRu J3QgZXZlbiBuZWVkIHRvIGltcGxlbWVudCB0aGUgc2VjdXJpdHktaW50ZXJmYWNlcyBwYXJhbWV0 ZXIgLS0gd2hlcmUgYWJzZW5jZSBvZiB0aGUgcGFyYW1ldGVyIG1lYW5zIHRoZSBzYW1lIHRoaW5n IGFzIGFuIGVtcHR5IHN0cmluZyAoaS5lLiwgdGhpcyBpbnN0YW5jZSBvZiB0aGUgSE1BQyBzZWN1 cml0eSBvYmplY3QgYXBwbGllcyB0byBhbGwgaW50ZXJmYWNlcykuDQogDQo+ID4gICBzZWN1cml0 eS1hZGQtaG1hYy1rZXkgKG9wZXJhdGlvbjogaW5wdXRzIChyZWZlcmVuY2UgbmFtZSwga2V5KSkN Cj4gPiAgICAgIGhtYWMta2V5LW9iag0KPiA+ICAgICAgICAgIGtleS1uYW1lIChzdHJpbmc6IHJl ZmVyZW5jZSBuYW1lKQ0KPiA+ICAgICAgICAgIGtleS1kYXRlIChkYXRldGltZTogdGltZXN0YW1w IHdoZW4ga2V5IHdhcyBhZGRlZCkNCj4gDQo+IFBsZWFzZSBtYWtlIGtleS1kYXRlIG9wdGlvbmFs Lg0KDQpZZXMsIEkgYWdyZWUuIA0KQmFyYmFyYQ0KIA0KPiAtLSBKdWxpdXN6DQo= From nobody Fri Jan 4 11:41:00 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D18130E8D for ; Fri, 4 Jan 2019 11:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfmvUinsUgBl for ; Fri, 4 Jan 2019 11:40:57 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD80130E85 for ; Fri, 4 Jan 2019 11:40:56 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id t13so17833467ply.13 for ; Fri, 04 Jan 2019 11:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qhgr7IMsTfg4Wpz9BDnpq2U2h+ZTyNgtWKvFmQ6QjRU=; b=ctywvEBsn5JVnaVw37WxV0aImwHAAVheAo1a02CjfhtL9J6H/u+DXRwoWV6Vnru12C tY2+WtNi3u+shOQrv0E7Vl97q5pTSx6nOZffkUKOMvbyf4Q0E497FCx+eGUB285BXMs3 VNatTV9hhPKLYW+OC+J0TTdqg4KsaiNOF395VfxRaCcuC0ZFlcx3mBg+OHwWwqIl26e9 p2OkxDLWRqgAkq76UD1+noa12v6KwXkg3aC3bHr4ir2DCCJcbDqLYSZd6P8avCBSf7wp fu+4zOTWXTYICKuDBt9Klelq/tJhD5xSzmDzitxLdcAvzWwGDdmY/grLhMc+g9GSUASs jZXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qhgr7IMsTfg4Wpz9BDnpq2U2h+ZTyNgtWKvFmQ6QjRU=; b=MO/INyOIGh2Zm0PdPkq1zvsSw8gVtU2EHAmXsLs1NRAjqUUmqIz0vnPCRbOLoCMfnC Fx8jVX347/DclMFk8HWRa71z/Bm1k26BHroSuDpUbqcl4nz0KaJhUcDZgJyISXekAF8o 7+O1djQQYSx3RvDch5sU5alnygAlxUeRd8BnwNN0ZJku1m53oFkU9Yebzh9Np0DmmXnw GOVU6RHk+QVgp0Ayt5uXWeQoLjgOVRAnvimefgMqK6lEuLxfK7h2gokdBeDoanhiGOw2 7LnPTx3/U0bxR49aiO7U4Fztp56gszeegBhjiOysyk42YaNBKiwBCTe2CJqGdEO6zAiq 46Tw== X-Gm-Message-State: AJcUukdeNQFKM474hBsza7HojB5NnlwLsHsJo3NicsGXH49cSHkCD0ax 3rkCnVFv/M41CpgZg0L6Kbt4xeJOq5TluYAoH9I= X-Google-Smtp-Source: ALg8bN4nuy4QXf0fZixN9lEkp6VREe3/vxdxq2R6Gf9xTksQfOcMyMLobbh3vzfCekcqRLRRC3ep75DuKM3BX9AnO2c= X-Received: by 2002:a17:902:50e:: with SMTP id 14mr51627763plf.141.1546630856400; Fri, 04 Jan 2019 11:40:56 -0800 (PST) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DF82DC1@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF82DC1@GAALPA1MSGUSRBF.ITServices.sbc.com> From: David Schinazi Date: Fri, 4 Jan 2019 11:40:44 -0800 Message-ID: To: "STARK, BARBARA H" Cc: Babel at IETF Content-Type: multipart/alternative; boundary="000000000000cb629f057ea70e68" Archived-At: Subject: Re: [babel] minor DTLS comment X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 19:40:59 -0000 --000000000000cb629f057ea70e68 Content-Type: text/plain; charset="UTF-8" Thanks for your comment, Barbara. I agree with you, and have added the following text: https://github.com/jech/babel-drafts/commit/a5a372a942ebc7951b2847d88123d75ab8169f2f Please let us know if you feel it addresses your comment. Thanks, David On Fri, Jan 4, 2019 at 5:35 AM STARK, BARBARA H wrote: > Since the DTLS draft is still open for comments, I do have a small one > about how the UDP ports are characterized. > The IANA assigned ports are default values, and need to be portrayed as > such. It's allowed (or should be) for deployed instances to use other > values. This is pretty much true of all protocols. Certainly the base babel > protocol allows other values to be used (which is why the homenet babel > profile mandated use of 6696). > > Maybe instead of > All Babel over DTLS nodes MUST act as DTLS servers on the "babel- > dtls" port (UDP port TBD), and MUST listen for traffic on the > unencrypted "babel" port (UDP port 6696). > > say > All Babel over DTLS nodes MUST act as DTLS servers on the "babel- > dtls" port, and MUST listen for traffic on the > unencrypted "babel" port. > The IANA-assigned values of 6696 for the "babel" port and > TBD for the "babel-dtls" port SHOULD be used. > > Barbara > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000cb629f057ea70e68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your comment, Barbara. I agree= with you, and have added the following text:

Please let us know if you feel it a= ddresses your comment.

Thanks,
David

On Fri, Jan 4= , 2019 at 5:35 AM STARK, BARBARA H <bs= 7652@att.com> wrote:
Since the DTLS draft is still open for comments, I do have a sm= all one about how the UDP ports are characterized.
The IANA assigned ports are default values, and need to be portrayed as suc= h. It's allowed (or should be) for deployed instances to use other valu= es. This is pretty much true of all protocols. Certainly the base babel pro= tocol allows other values to be used (which is why the homenet babel profil= e mandated use of 6696).

Maybe instead of
=C2=A0 =C2=A0All Babel over DTLS nodes MUST act as DTLS servers on the &quo= t;babel-
=C2=A0 =C2=A0dtls" port (UDP port TBD), and MUST listen for traffic on= the
=C2=A0 =C2=A0unencrypted "babel" port (UDP port 6696).

say
=C2=A0 =C2=A0All Babel over DTLS nodes MUST act as DTLS servers on the &quo= t;babel-
=C2=A0 =C2=A0dtls" port, and MUST listen for traffic on the
=C2=A0 =C2=A0unencrypted "babel" port.
=C2=A0 =C2=A0The IANA-assigned values of 6696 for the "babel" por= t and
=C2=A0 =C2=A0TBD for the "babel-dtls" port SHOULD be used.

Barbara


_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000cb629f057ea70e68-- From nobody Fri Jan 4 11:51:50 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8080B130E89 for ; Fri, 4 Jan 2019 11:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMX4drfOHH_r for ; Fri, 4 Jan 2019 11:51:46 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994E0130E85 for ; Fri, 4 Jan 2019 11:51:46 -0800 (PST) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x04Jmip6005316; Fri, 4 Jan 2019 14:51:45 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2ptcu423n6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Jan 2019 14:51:45 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x04Jpi8U022761; Fri, 4 Jan 2019 14:51:44 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x04Jpe1l022701; Fri, 4 Jan 2019 14:51:40 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id CAB8F4014663; Fri, 4 Jan 2019 19:51:40 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30483.vci.att.com (Service) with ESMTPS id B6696401468D; Fri, 4 Jan 2019 19:51:40 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0415.000; Fri, 4 Jan 2019 14:51:40 -0500 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?=27Toke_H=F8iland-J=F8rgensen=27?= , "Babel at IETF" Thread-Topic: [babel] hmac info model elements Thread-Index: AdSi6E9jJwLKz5kXQlCy2NNONpdJZQA6KsCAACSwLUA= Date: Fri, 4 Jan 2019 19:51:39 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF83500@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <87a7khxxu6.fsf@toke.dk> In-Reply-To: <87a7khxxu6.fsf@toke.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.254.227] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=745 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901040168 Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 19:51:49 -0000 > > Appendix A (incremental deployment and key rotation) indicates it shoul= d > be possible to configure a mode where authenticated packets are sent but = all > packets are accepted. ... > > Proposed HMAC model: > > add to top level information-obj: > > babel-hmac-algorithms (enumerated list of supported HMAC computation > algorithms) > > > > security-hmac-obj > > security-hmac-enable (boolean: enable / disable this instance) > > security-hmac-mode (Boolean: do or don't authenticate received > > packets) >=20 > How do those two interact? If an HMAC instance is disabled it's as if this instance doesn't exist. Its= keys and hmac-mode values are irrelevant (don't care), and it causes no HM= AC to be sent, expected, or checked, and no challenges to be responded to o= r sent. If an HMAC instance is enabled (and there is at least one key to use for si= gning), then authenticated packets are always sent. The hmac-mode toggles whether or not received packets are checked, for an e= nabled HMAC instance.=20 > > security-hmac-algorithm (string: one of the supported HMAC algorithms= ) > > security-interfaces (string list of references to interfaces-obj: the > interfaces this instance applies to; if empty, it applies to all interfac= es) > > security-add-hmac-key (operation: inputs (reference name, key)) > > hmac-key-obj >=20 > IMO, we'll need two per-key booleans as well: "use for authentication" > and "use for signing". They should be set independent of each other. OK. We could do this either with 2 Booleans or with a single enumeration (s= ign-only, check-only, sign-and-check, [would an "unused" value also be need= ed?]). Would people prefer Booleans or an enumeration? I'm fine either way,= but find enumerations easier for people to read and understand. Barbara =20 > -Toke From nobody Fri Jan 4 11:54:47 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C14130E89 for ; Fri, 4 Jan 2019 11:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOaTBVOs5BtM for ; Fri, 4 Jan 2019 11:54:44 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C271D130E85 for ; Fri, 4 Jan 2019 11:54:42 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x04JmgHq044937; Fri, 4 Jan 2019 14:54:42 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2ptd1thq9p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Jan 2019 14:54:41 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x04Jsew8026584; Fri, 4 Jan 2019 14:54:40 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x04JsYE1026469; Fri, 4 Jan 2019 14:54:34 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 290A34014055; Fri, 4 Jan 2019 19:54:34 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30487.vci.att.com (Service) with ESMTPS id 12EC840006BF; Fri, 4 Jan 2019 19:54:34 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0415.000; Fri, 4 Jan 2019 14:54:33 -0500 From: "STARK, BARBARA H" To: "'Mahesh Jethanandani'" CC: Babel at IETF Thread-Topic: [babel] hmac info model elements Thread-Index: AdSi6E9jJwLKz5kXQlCy2NNONpdJZQA7HaOAAB1GhjA= Date: Fri, 4 Jan 2019 19:54:32 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> In-Reply-To: <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.254.227] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901040168 Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 19:54:46 -0000 PiA+IFdlIGhhZCBkaXNjdXNzZWQgcHJldmlvdXNseSB0aGF0IGtleXMgc2hvdWxkIG5vdCBiZSBy ZWFkYWJsZSAtLSBvbmx5IGFkZA0KPiBhbmQgZGVsZXRlIGtleXMuIEluIHRoaXMgY2FzZSwgaXQn cyBnb29kIGZvciBhIG5vbi1yZWFkYWJsZSBwYXJhbWV0ZXIgdG8gaGF2ZQ0KPiBhICJuaWNrbmFt ZSIgb3IgaW5kZXggdG8gcmVmZXJlbmNlIGl0IHdpdGguIEFuZCBpdCBjYW4gYmUgdXNlZnVsIHRv IGtub3cNCj4gd2hlbiB0aGUga2V5IHdhcyBhZGRlZC4gSW4gbXkgZXhwZXJpZW5jZSwgdGhlc2Ug c29ydHMgb2Ygc2hhcmVkIGtleXMgYXJlDQo+IG1vZGVsZWQgYXMgc3RyaW5ncy4NCj4gDQo+IEkg d291bGQgdGhpbmsgdGhlIGtleXMgYXJlIG1vZGVsZWQgYXMgYmluYXJ5Lg0KDQpUaGF0IGRlcGVu ZHMgb24gaG93IHdlIGdlbmVyYWxseSBleHBlY3QgdGhlIGtleXMgdG8gYmUgZ2VuZXJhdGVkLiBJ ZiB3ZSB0aGluayB0aGV5J2xsIGJlIHJhbmRvbWx5IGdlbmVyYXRlZCBieSBhIGNlbnRyYWxpemVk IG1hY2hpbmUsIHRoZW4gYmluYXJ5IG1ha2VzIHNlbnNlLiBJZiB3ZSB0aGluayB0aGV5J2xsIGJl IGNyZWF0ZWQgYnkgYSBodW1hbiBiZWluZyB3aG8gd2lsbCBpbnB1dCB0aGVtIHRocm91Z2ggYSBr ZXlib2FyZCwgdGhlbiBzdHJpbmcgbWFrZXMgc2Vuc2UuIEkgd2FzIHRoaW5raW5nIHRoZSBsYXR0 ZXIgd291bGQgYmUgbW9yZSBjb21tb24uIEknbSBjdXJpb3VzIHdoYXQgb3RoZXJzIHRoaW5rPw0K IA0KPiA+IEFwcGVuZGl4IEEgKGluY3JlbWVudGFsIGRlcGxveW1lbnQgYW5kIGtleSByb3RhdGlv bikgaW5kaWNhdGVzIGl0IHNob3VsZA0KPiBiZSBwb3NzaWJsZSB0byBjb25maWd1cmUgYSBtb2Rl IHdoZXJlIGF1dGhlbnRpY2F0ZWQgcGFja2V0cyBhcmUgc2VudCBidXQgYWxsDQo+IHBhY2tldHMg YXJlIGFjY2VwdGVkLg0KPiA+IE11bHRpcGxlIEhNQUMgYWxnb3JpdGhtcyBhcmUgcG9zc2libGUu IFRoZSBkcmFmdCBkb2Vzbid0IHNheSBob3cgdGhlDQo+IG5vZGVzIGtub3cgd2hpY2ggYWxnb3Jp dGhtIGlzIGJlaW5nIHVzZWQgKGlmIG11bHRpcGxlIGFyZSBpbXBsZW1lbnRlZCkuIFRoZQ0KPiBk cmFmdCBkb2VzIHNheSB0aGF0IG9ubHkgb25lIEhNQUMgaXMgY2FsY3VsYXRlZCBwZXIga2V5LiBJ cyBpdCBhc3N1bWVkIHRoZQ0KPiBhbGdvcml0aG0gY2hvaWNlIGlzIGNvbmZpZ3VyZWQ/DQo+ID4g U2hvdWxkIHRoZSBjaGFsbGVuZ2UgZXhwaXJ5IHRpbWVyIGJlIGNvbmZpZ3VyYWJsZT8NCj4gPiBJ J3ZlIGRlY2lkZWQgdG8gaGF2ZSBjb21wbGV0ZWx5IHNlcGFyYXRlIEhNQUMgYW5kIERUTFMgb2Jq ZWN0cywgYmVjYXVzZQ0KPiB0aGV5J3JlIHZlcnkgZGlmZmVyZW50IG5vdyB0aGF0IEkgaGF2ZSBk ZXRhaWxlZCBkZXNpZ25zIHRvIHdvcmsgd2l0aC4NCj4gPiBJJ20gYWRkaW5nIGFuICJvcGVyYXRp b24iIGRhdGF0eXBlIHRvIHN1cHBvcnQga2V5IGFuZCBjZXJ0IG1hbmlwdWxhdGlvbi4NCj4gVGhp cyBpcyBpbnRlbmRlZCB0byBiZSBjb25zaXN0ZW50IHdpdGggWUFORyAiYWN0aW9uIiBkYXRhdHlw ZS4NCj4gDQo+IElzIHRoZSBpZGVhIHRoYXQgdGhlcmUgaXMgYm90aCBhbiBpbnB1dCBhbmQgYW4g b3V0cHV0IGV4cGVjdGVkIGZvciBrZXkgYW5kDQo+IGNlcnQgbWFuaXB1bGF0aW9uPyBJZiBpdCBp cyBpbnB1dCBvbmx5LCBpLmUuIGNvbmZpZ3VyaW5nIGtleSBhbmQgY2VydC4sIHRoZW4geW91DQo+ IHdvdWxkIG5vdCBuZWVkIGFuIGFjdGlvbiB0eXBlLiBIYXZpbmcgc2FpZCB0aGF0LCBpbiB0aGUg ZXhhbXBsZXMgeW91IGdpdmUNCj4gYmVsb3csIEkgZXhwZWN0IGRlbGV0ZSB0byBiZSBhbiBhY3Rp b24uDQoNClRoZSBvbmx5IG91dHB1dCBuZWVkZWQgaXMgdGhlIHJlc3VsdCBvZiB0aGUgb3BlcmF0 aW9uIChzdWNjZXNzIG9yIGZhaWx1cmUpLiANCkFzIEkgdGhpbmsgYWJvdXQgd2h5IEJCRiB3ZW50 IHdpdGggYW4gb3BlcmF0aW9uIGZvciBhZGRpbmcvZGVsZXRpbmcgYSBYLjUwOSBjZXJ0LCBJIHJl YWxpemUgaXQgaGFkIHRvIGRvIHdpdGggdGhpbmdzIHJlbGF0ZWQgdG8gaXRzIGJlaW5nIGFuIFgu NTA5IGNlcnQgYW5kIG5vdCBhICJjcmVkZW50aWFsIi4gU28gSSB0aGluayBJIGFncmVlIHdpdGgg eW91IGhlcmUgdGhhdCBmb3IgYW4gSE1BQyBrZXksIHRoZSByZWd1bGFyIG1vZGVsIG1hbmlwdWxh dGlvbiBtZWNoYW5pc21zIGFyZSBmaW5lIChpbmNsdWRpbmcgZm9yIGRlbGV0ZSkgYW5kIHRoZSBr ZXkgY2FuIGp1c3QgYmUgbm90ZWQgYXMgbm9uLXJlYWRhYmxlLg0KIA0KPiBJIGFtIG5vdCBjbGVh ciBvbiB0aGUg4oCYY2hlY2sta2V54oCZIG9wZXJhdGlvbi4gSSB3b3VsZCBleHBlY3QgdGhhdCB0 aGUgZGV2aWNlIGlzDQo+IGVpdGhlciBlbmFibGVkIG9yIGRpc2FibGVkIHRvIGNoZWNrIGZvciBI TUFDLiBJZiBlbmFibGVkLCBhbmQgd2hlbiBhIHBhY2tldA0KPiBpcyByZWNlaXZlZCwgdGhlIHJl Y2VpdmVyIHdpbGwgY29tcHV0ZSB0aGUgSE1BQyAodXNpbmcgdGhlIGtleSBjb25maWd1cmVkDQo+ IGZvciBpdCkgb24gdGhlIHBhY2tldCBhbmQgY29tcGFyZSBpdCB3aGF0IGlzIGluIHRoZSBwYWNr ZXQuIElmIHRoZSBITUFDDQo+IGNvbXBhcmlvc24gZmFpbHMsIHRoZSByZWNlaXZlciB3aWxsIGRy b3AgdGhlIHBhY2tldCwgYW5kIGxvZyBhIGNvdW50IG9mDQo+IGRyb3BwZWQgcGFja2V0cyBiZWNh dXNlIG9mIG1pc21hdGNoLiBXaHkgd291bGQgdGhlIG1hbmFnZW1lbnQgcGxhbmUNCj4gbmVlZCB0 byBwZXJmb3JtIGEg4oCYY2hlY2sta2V54oCZIG9wZXJhdGlvbj8NCg0KV2UncmUgbWFraW5nIHRo ZSBrZXkgbm9uLXJlYWRhYmxlLCBvbmNlIHdyaXR0ZW4uIFRoZSBjaGVjay1rZXkgb3BlcmF0aW9u IGdpdmVzIHRoZSByb3V0ZXIgc29tZXRoaW5nIHRvIGhhc2gsIGFuZCBhIGhhc2ggb2YgdGhhdCBz b21ldGhpbmcgdGhhdCB5b3UndmUgY3JlYXRlZCBvbiB5b3VyIGVuZCAodXNpbmcgd2hhdCB5b3Ug dGhpbmsgdGhlIGtleSBpcyksIGFuZCBhc2tzIHRoZSByb3V0ZXIgaWYgdGhlIGhhc2ggaXQgY3Jl YXRlcyBpcyB0aGUgc2FtZSBhcyB0aGUgaGFzaCB5b3UgY3JlYXRlZC4gSWYgeWVzLCB0aGVuIHlv dSBrbm93ICgxKSB0aGUga2V5IGlzIHdoYXQgeW91IHRoaW5rIGl0IGlzLCBhbmQgKDIpIHRoZSBo YXNoIGlzIGJlaW5nIGNvbXB1dGVkIHVzaW5nIHRoZSBhbGdvcml0aG0geW91IHRoaW5rIGl0IGlz IHVzaW5nLiBJZiB0aGUgSE1BQyBjb21wYXJpc29uIGlzIGNvbnNpc3RlbnRseSBmYWlsaW5nLCB0 aGlzIGNhbiBiZSBhIHVzZWZ1bCB0cm91Ymxlc2hvb3RpbmcgbWVjaGFuaXNtIChlc3BlY2lhbGx5 IHdoZW4gc2V0dGluZyB1cCBhIG5ldyBuZXR3b3JrIHVzaW5nIHJvdXRlcnMgd2l0aCBkaWZmZXJl bnQgaW1wbGVtZW50YXRpb25zKS4gSnVzdCBrbm93aW5nIHRoZSBwYWNrZXQgaXMgZ2V0dGluZyBk cm9wcGVkIGRvZXNuJ3QgdGVsbCB5b3UgbXVjaC4gVGhlcmUgYXJlIG1hbnkgdGhpbmdzIHRoYXQg Y291bGQgY2F1c2UgZHJvcHBhZ2UuDQpCdXQgdGhpcyB3b3VsZCBiZSBvcHRpb25hbCB0byBzdXBw b3J0LiBBbmQgSSB3b24ndCBpbnNpc3Qgb24gaXQgaWYgb3RoZXJzIGRvbid0IHRoaW5rIGl0J3Mg YSBnb29kIGlkZWEuDQpJdCdzIHNpbWlsYXIgdG8gYSBmaW5nZXJwcmludCBjb21wYXJpc29uIGRv bmUgZm9yIGFuIFguNTA5IGNlcnRpZmljYXRlLg0KIA0KPiA+IFByb3Bvc2VkIEhNQUMgbW9kZWw6 DQo+ID4gYWRkIHRvIHRvcCBsZXZlbCBpbmZvcm1hdGlvbi1vYmo6DQo+ID4gYmFiZWwtaG1hYy1h bGdvcml0aG1zIChlbnVtZXJhdGVkIGxpc3Qgb2Ygc3VwcG9ydGVkIEhNQUMgY29tcHV0YXRpb24N Cj4gPiBhbGdvcml0aG1zKQ0KPiA+DQo+ID4gc2VjdXJpdHktaG1hYy1vYmoNCj4gPiAgc2VjdXJp dHktaG1hYy1lbmFibGUgKGJvb2xlYW46IGVuYWJsZSAvIGRpc2FibGUgdGhpcyBpbnN0YW5jZSkN Cj4gPiBzZWN1cml0eS1obWFjLW1vZGUgKEJvb2xlYW46IGRvIG9yIGRvbid0IGF1dGhlbnRpY2F0 ZSByZWNlaXZlZA0KPiA+IHBhY2tldHMpDQo+IA0KPiBJIGhhdmUgdGhlIHNhbWUgcXVlc3Rpb24g YXMgVG9rZSBoZXJlLg0KDQpPSy4gSSd2ZSBzZW50IGEgcmVwbHkgdG8gVG9rZSdzIGVtYWlsLg0K DQo+ID4gIHNlY3VyaXR5LWhtYWMtYWxnb3JpdGhtIChzdHJpbmc6IG9uZSBvZiB0aGUgc3VwcG9y dGVkIEhNQUMNCj4gPiBhbGdvcml0aG1zKQ0KPiANCj4gWW91IG1lYW4gb25lIG9mIHRoZSBlbnVt IHZhbHVlcyBkZWZpbmVkIGFib3ZlLg0KDQpZZXMuDQogDQo+IFRoYW5rcyBmb3IgcHV0dGluZyB0 aGlzIHRvZ2V0aGVyLg0KPiANCj4gPiAgc2VjdXJpdHktaW50ZXJmYWNlcyAoc3RyaW5nIGxpc3Qg b2YgcmVmZXJlbmNlcyB0byBpbnRlcmZhY2VzLW9iajogdGhlDQo+ID4gaW50ZXJmYWNlcyB0aGlz IGluc3RhbmNlIGFwcGxpZXMgdG87IGlmIGVtcHR5LCBpdCBhcHBsaWVzIHRvIGFsbCBpbnRlcmZh Y2VzKQ0KPiBzZWN1cml0eS1hZGQtaG1hYy1rZXkgKG9wZXJhdGlvbjogaW5wdXRzIChyZWZlcmVu Y2UgbmFtZSwga2V5KSkNCj4gPiAgICAgaG1hYy1rZXktb2JqDQo+ID4gICAgICAgICBrZXktbmFt ZSAoc3RyaW5nOiByZWZlcmVuY2UgbmFtZSkNCj4gPiAgICAgICAgIGtleS1kYXRlIChkYXRldGlt ZTogdGltZXN0YW1wIHdoZW4ga2V5IHdhcyBhZGRlZCkNCj4gPiAgICAgICAgIGRlbGV0ZS1rZXkg KG9wZXJhdGlvbikNCj4gPiAgICAgICAgIGNoZWNrLWtleSAob3BlcmF0aW9uOiBpbnB1dHMgKHN0 cmluZywgSE1BQyBvZiBzdHJpbmcpKSA7IHRoZSBub2RlIGRvZXMNCj4gaXRzIG93biBITUFDIGNv bXB1dGF0aW9uIG9mIHRoZSBpbnB1dCBzdHJpbmcgYW5kIGNvbXBhcmVzIHRoaXMgdG8gdGhlIGlu cHV0DQo+IEhNQUMgb2Ygc3RyaW5nOyBpZiB0aGUgY29tcHV0ZWQgYW5kIGlucHV0IEhNQUMgYXJl IHRoZSBzYW1lIHRoZSBvcGVyYXRpb24NCj4gc3VjY2VlZHMuDQo+ID4NCj4gPiBUaG91Z2h0cz8N Cj4gPiBCYXJiYXJhDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IGJhYmVsIG1haWxpbmcgbGlzdA0KPiA+IGJhYmVsQGlldGYub3Jn DQo+IA0KPiBNYWhlc2ggSmV0aGFuYW5kYW5pDQo+IG1qZXRoYW5hbmRhbmlAZ21haWwuY29tDQo= From nobody Fri Jan 4 12:02:58 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821E9130EC0 for ; Fri, 4 Jan 2019 12:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fd1qSAAlaDK for ; Fri, 4 Jan 2019 12:02:48 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D0E130EC7 for ; Fri, 4 Jan 2019 12:02:44 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id e5so41565675qtr.12 for ; Fri, 04 Jan 2019 12:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZGF72+rzkq+e91cmdBH31kdtS3hQLuHtgYEsbzwB8uo=; b=ahwD8xAzN111n3GIiO6630IOSCJ0dWzijoVaEZwE9b44qKVOojf2Snz+NJKdXdu8Qd 1JYHQA2vYyLim2GzfBkymfTzp+G0xXbOCV4gvPIg8YNmx9S8p/varda2Zk7J3aShKWZF TS77v+Gye4U7JxumKmJaJ34pTW1DG3Y0OBbIuihnJdnIg3JwDIYntPI4RntGrDN8fvC3 Pdcz+81L/qDTq4KTqlmcOfaBVDR68z32PU7uXgnMlGJGEHZp4x4TNtEgGZuxiREG8RL+ +Sdgl46uCWHd61MkPHskkgI+0kLWPRpGNmuCVEMF+9k/fykgd7eDKwmkOhQtvhUIM9RA EfRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZGF72+rzkq+e91cmdBH31kdtS3hQLuHtgYEsbzwB8uo=; b=BXNUILAI6SlEyTfTSCTPr+oAf90BYYoPdZn1QDUfzyqjSwUWIGhgAEws7qCOWntoKE bEYzVVfLuoAn4UVVHja+AivX1xKZ0isiG+5aDmeDpzdK8OfnV6Ol4z3Uu9UfhTK2HmLt TNARhYnleBWMWdPIHBxZs7C7lIF14fI4GDQjdSk4vCgFU9szXdWqRqFskeUJ26BFyuPS AHD0xO0OFaRLkf3AhacCbCcdO809qcy9nszdCh9cAYArN+iacWQw8yjuOCRm0AbEgG4a +7r20mnumhY1Vv32gauGOaqeDAFr4tdT4DatFfoVyUIxLFXsbjMGAbNYAjvi68tWAVEO MDBw== X-Gm-Message-State: AA+aEWYd5D9qaCCNrKuf2N0bM1WIMxITvIPJzRW/xIIvc4rmYSS9epa/ bUq4c3YtdRMkmHaNWEGDbdSkvzW/M7sVY+XsB1s= X-Google-Smtp-Source: AFSGD/XdsnducWudcN8qOsoEtXdUgHbZQTOOe+1FKoCaYX8qQTWF7hlyCeQGy8Laab+1xauATqsZ1BffJYCYypd8yg4= X-Received: by 2002:ac8:326a:: with SMTP id y39mr51807220qta.175.1546632162905; Fri, 04 Jan 2019 12:02:42 -0800 (PST) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Dave Taht Date: Fri, 4 Jan 2019 12:02:30 -0800 Message-ID: To: "STARK, BARBARA H" Cc: Mahesh Jethanandani , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 20:02:56 -0000 On Fri, Jan 4, 2019 at 11:54 AM STARK, BARBARA H wrote: > > > > We had discussed previously that keys should not be readable -- only = add > > and delete keys. In this case, it's good for a non-readable parameter t= o have > > a "nickname" or index to reference it with. And it can be useful to kno= w > > when the key was added. In my experience, these sorts of shared keys ar= e > > modeled as strings. > > > > I would think the keys are modeled as binary. > > That depends on how we generally expect the keys to be generated. If we t= hink they'll be randomly generated by a centralized machine, then binary ma= kes sense. If we think they'll be created by a human being who will input t= hem through a keyboard, then string makes sense. I was thinking the latter = would be more common. I'm curious what others think? What I wanted was a representation that was standard and unambiguous. 0xdeadbeef for a hex representation, base64 (https://tools.ietf.org/html/rfc4648#page-7) or ( http://docs.ros.org/diamondback/api/wpa_supplicant/html/base64_8c.html ) for all else. > > > Appendix A (incremental deployment and key rotation) indicates it sho= uld > > be possible to configure a mode where authenticated packets are sent bu= t all > > packets are accepted. > > > Multiple HMAC algorithms are possible. The draft doesn't say how the > > nodes know which algorithm is being used (if multiple are implemented).= The > > draft does say that only one HMAC is calculated per key. Is it assumed = the > > algorithm choice is configured? > > > Should the challenge expiry timer be configurable? > > > I've decided to have completely separate HMAC and DTLS objects, becau= se > > they're very different now that I have detailed designs to work with. > > > I'm adding an "operation" datatype to support key and cert manipulati= on. > > This is intended to be consistent with YANG "action" datatype. > > > > Is the idea that there is both an input and an output expected for key = and > > cert manipulation? If it is input only, i.e. configuring key and cert.,= then you > > would not need an action type. Having said that, in the examples you gi= ve > > below, I expect delete to be an action. > > The only output needed is the result of the operation (success or failure= ). > As I think about why BBF went with an operation for adding/deleting a X.5= 09 cert, I realize it had to do with things related to its being an X.509 c= ert and not a "credential". So I think I agree with you here that for an HM= AC key, the regular model manipulation mechanisms are fine (including for d= elete) and the key can just be noted as non-readable. > > > I am not clear on the =E2=80=98check-key=E2=80=99 operation. I would ex= pect that the device is > > either enabled or disabled to check for HMAC. If enabled, and when a pa= cket > > is received, the receiver will compute the HMAC (using the key configur= ed > > for it) on the packet and compare it what is in the packet. If the HMAC > > compariosn fails, the receiver will drop the packet, and log a count of > > dropped packets because of mismatch. Why would the management plane > > need to perform a =E2=80=98check-key=E2=80=99 operation? > > We're making the key non-readable, once written. The check-key operation = gives the router something to hash, and a hash of that something that you'v= e created on your end (using what you think the key is), and asks the route= r if the hash it creates is the same as the hash you created. If yes, then = you know (1) the key is what you think it is, and (2) the hash is being com= puted using the algorithm you think it is using. If the HMAC comparison is = consistently failing, this can be a useful troubleshooting mechanism (espec= ially when setting up a new network using routers with different implementa= tions). Just knowing the packet is getting dropped doesn't tell you much. T= here are many things that could cause droppage. > But this would be optional to support. And I won't insist on it if others= don't think it's a good idea. > It's similar to a fingerprint comparison done for an X.509 certificate. > > > > Proposed HMAC model: > > > add to top level information-obj: > > > babel-hmac-algorithms (enumerated list of supported HMAC computation > > > algorithms) > > > > > > security-hmac-obj > > > security-hmac-enable (boolean: enable / disable this instance) > > > security-hmac-mode (Boolean: do or don't authenticate received > > > packets) > > > > I have the same question as Toke here. > > OK. I've sent a reply to Toke's email. > > > > security-hmac-algorithm (string: one of the supported HMAC > > > algorithms) > > > > You mean one of the enum values defined above. > > Yes. > > > Thanks for putting this together. > > > > > security-interfaces (string list of references to interfaces-obj: th= e > > > interfaces this instance applies to; if empty, it applies to all inte= rfaces) > > security-add-hmac-key (operation: inputs (reference name, key)) > > > hmac-key-obj > > > key-name (string: reference name) > > > key-date (datetime: timestamp when key was added) > > > delete-key (operation) > > > check-key (operation: inputs (string, HMAC of string)) ; the = node does > > its own HMAC computation of the input string and compares this to the i= nput > > HMAC of string; if the computed and input HMAC are the same the operati= on > > succeeds. > > > > > > Thoughts? > > > Barbara > > > > > > _______________________________________________ > > > babel mailing list > > > babel@ietf.org > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Fri Jan 4 12:07:24 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F352130E50 for ; Fri, 4 Jan 2019 12:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrti3EXuFLVL for ; Fri, 4 Jan 2019 12:07:20 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B2F130E89 for ; Fri, 4 Jan 2019 12:07:20 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x04K6tRf031518; Fri, 4 Jan 2019 15:07:19 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2ptd1tj2j4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Jan 2019 15:07:18 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x04K7GCt023419; Fri, 4 Jan 2019 15:07:17 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x04K7BI2023255; Fri, 4 Jan 2019 15:07:11 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id D9FC64014060; Fri, 4 Jan 2019 20:07:11 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30487.vci.att.com (Service) with ESMTPS id C3E4840135EA; Fri, 4 Jan 2019 20:07:11 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0415.000; Fri, 4 Jan 2019 15:07:11 -0500 From: "STARK, BARBARA H" To: "'David Schinazi'" CC: Babel at IETF Thread-Topic: [babel] minor DTLS comment Thread-Index: AdSkL1vol8xv1+2PTJSCJUACYAMkywAX+64AAAnjvdA= Date: Fri, 4 Jan 2019 20:07:11 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF8360C@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF82DC1@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.254.227] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114DF8360CGAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-04_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901040170 Archived-At: Subject: Re: [babel] minor DTLS comment X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 20:07:22 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114DF8360CGAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG1tLg0KIiBCYWJlbCBvdmVyIERUTFMgb3BlcmF0ZXMgb24gYSBkaWZmZXJlbnQgcG9ydCB0aGFu IHVuZW5jcnlwdGVkIEJhYmVsLg0KQWxsIEJhYmVsIG92ZXIgRFRMUyBub2RlcyBNVVNUIGFjdCBh cyBEVExTIHNlcnZlcnMgb24gYSBjb25maWd1cmVkIHBvcnQsIGFuZA0KTVVTVCBsaXN0ZW4gZm9y IHVuZW5jcnlwdGVkIEJhYmVsIHRyYWZmaWMgb24gYSBkaXN0aW5jdCBjb25maWd1cmVkIHBvcnQu 4oCdDQoNCkFuIGltcGxlbWVudGF0aW9uIGRvZXNu4oCZdCBoYXZlIHRvIGFsbG93IGZvciBjb25m aWd1cmF0aW9uIG9mIHBvcnRzLiBUaGV5IGNvdWxkIGp1c3QgYmUgaGFyZC1jb2RlZC4NCkkgZG9u 4oCZdCBsaWtlIHRoYXQgSSBuZWVkIHRoZSBjb250ZXh0IG9mIHRoZSBmaXJzdCBzZW50ZW5jZSB0 byB1bmRlcnN0YW5kIHVuYW1iaWd1b3VzbHkgd2hhdCB0aGUgc2Vjb25kIHBvcnQgaXMg4oCcZGlz dGluY3TigJ0gZnJvbSAoaS5lLiwgZGlzdGluY3QgZnJvbSB0aGUgdW5lbmNyeXB0ZWQgQmFiZWwg cG9ydCkuDQoNCkhvdyBhYm91dCBqdXN0IOKAnCBCYWJlbCBvdmVyIERUTFMgTVVTVCBvcGVyYXRl IG9uIGEgZGlmZmVyZW50IHBvcnQgdGhhbiB1bmVuY3J5cHRlZCBCYWJlbC7igJ0gPw0KDQpCYXJi YXJhDQoNCkZyb206IERhdmlkIFNjaGluYXppIDxkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+DQpT ZW50OiBGcmlkYXksIEphbnVhcnkgMDQsIDIwMTkgMjo0MSBQTQ0KVG86IFNUQVJLLCBCQVJCQVJB IEggPGJzNzY1MkBhdHQuY29tPg0KQ2M6IEJhYmVsIGF0IElFVEYgPGJhYmVsQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtiYWJlbF0gbWlub3IgRFRMUyBjb21tZW50DQoNClRoYW5rcyBmb3IgeW91 ciBjb21tZW50LCBCYXJiYXJhLiBJIGFncmVlIHdpdGggeW91LCBhbmQgaGF2ZSBhZGRlZCB0aGUg Zm9sbG93aW5nIHRleHQ6DQpodHRwczovL2dpdGh1Yi5jb20vamVjaC9iYWJlbC1kcmFmdHMvY29t bWl0L2E1YTM3MmE5NDJlYmM3OTUxYjI4NDdkODgxMjNkNzVhYjgxNjlmMmY8aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX2plY2hf YmFiZWwtMkRkcmFmdHNfY29tbWl0X2E1YTM3MmE5NDJlYmM3OTUxYjI4NDdkODgxMjNkNzVhYjgx NjlmMmYmZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9TG9HemhDLThzYzhTWThU cTR2cmZvZyZtPXRGODVTNWxOSGhvMXZ0b0F1WXFTcjR4TkFxZDNtRG9WbldUMHR6VWNHXzQmcz1J QTFWNUxuSGd3dHJIR2o3czAxWXBZQ0NiRy02WHo0eERuSXEwS29teWs4JmU9Pg0KDQpQbGVhc2Ug bGV0IHVzIGtub3cgaWYgeW91IGZlZWwgaXQgYWRkcmVzc2VzIHlvdXIgY29tbWVudC4NCg0KVGhh bmtzLA0KRGF2aWQNCg0KT24gRnJpLCBKYW4gNCwgMjAxOSBhdCA1OjM1IEFNIFNUQVJLLCBCQVJC QVJBIEggPGJzNzY1MkBhdHQuY29tPG1haWx0bzpiczc2NTJAYXR0LmNvbT4+IHdyb3RlOg0KU2lu Y2UgdGhlIERUTFMgZHJhZnQgaXMgc3RpbGwgb3BlbiBmb3IgY29tbWVudHMsIEkgZG8gaGF2ZSBh IHNtYWxsIG9uZSBhYm91dCBob3cgdGhlIFVEUCBwb3J0cyBhcmUgY2hhcmFjdGVyaXplZC4NClRo ZSBJQU5BIGFzc2lnbmVkIHBvcnRzIGFyZSBkZWZhdWx0IHZhbHVlcywgYW5kIG5lZWQgdG8gYmUg cG9ydHJheWVkIGFzIHN1Y2guIEl0J3MgYWxsb3dlZCAob3Igc2hvdWxkIGJlKSBmb3IgZGVwbG95 ZWQgaW5zdGFuY2VzIHRvIHVzZSBvdGhlciB2YWx1ZXMuIFRoaXMgaXMgcHJldHR5IG11Y2ggdHJ1 ZSBvZiBhbGwgcHJvdG9jb2xzLiBDZXJ0YWlubHkgdGhlIGJhc2UgYmFiZWwgcHJvdG9jb2wgYWxs b3dzIG90aGVyIHZhbHVlcyB0byBiZSB1c2VkICh3aGljaCBpcyB3aHkgdGhlIGhvbWVuZXQgYmFi ZWwgcHJvZmlsZSBtYW5kYXRlZCB1c2Ugb2YgNjY5NikuDQoNCk1heWJlIGluc3RlYWQgb2YNCiAg IEFsbCBCYWJlbCBvdmVyIERUTFMgbm9kZXMgTVVTVCBhY3QgYXMgRFRMUyBzZXJ2ZXJzIG9uIHRo ZSAiYmFiZWwtDQogICBkdGxzIiBwb3J0IChVRFAgcG9ydCBUQkQpLCBhbmQgTVVTVCBsaXN0ZW4g Zm9yIHRyYWZmaWMgb24gdGhlDQogICB1bmVuY3J5cHRlZCAiYmFiZWwiIHBvcnQgKFVEUCBwb3J0 IDY2OTYpLg0KDQpzYXkNCiAgIEFsbCBCYWJlbCBvdmVyIERUTFMgbm9kZXMgTVVTVCBhY3QgYXMg RFRMUyBzZXJ2ZXJzIG9uIHRoZSAiYmFiZWwtDQogICBkdGxzIiBwb3J0LCBhbmQgTVVTVCBsaXN0 ZW4gZm9yIHRyYWZmaWMgb24gdGhlDQogICB1bmVuY3J5cHRlZCAiYmFiZWwiIHBvcnQuDQogICBU aGUgSUFOQS1hc3NpZ25lZCB2YWx1ZXMgb2YgNjY5NiBmb3IgdGhlICJiYWJlbCIgcG9ydCBhbmQN CiAgIFRCRCBmb3IgdGhlICJiYWJlbC1kdGxzIiBwb3J0IFNIT1VMRCBiZSB1c2VkLg0KDQpCYXJi YXJhDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CmJhYmVsIG1haWxpbmcgbGlzdA0KYmFiZWxAaWV0Zi5vcmc8bWFpbHRvOmJhYmVsQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iYWJlbDxodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX2JhYmVsJmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZy PUxvR3poQy04c2M4U1k4VHE0dnJmb2cmbT10Rjg1UzVsTkhobzF2dG9BdVlxU3I0eE5BcWQzbURv Vm5XVDB0elVjR180JnM9MHYzY25VV3hLVUhWWVhEeEdKTXdkS2ZyMTlkQzFiTTdYTEY1WTNhelJI OCZlPT4NCg== --_000_2D09D61DDFA73D4C884805CC7865E6114DF8360CGAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IbW0uIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+JnF1b3Q7IEJhYmVsIG92ZXIgRFRMUyBvcGVyYXRlcyBvbiBhIGRpZmZlcmVudCBwb3J0 IHRoYW4gdW5lbmNyeXB0ZWQgQmFiZWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BbGwgQmFiZWwgb3ZlciBEVExTIG5vZGVzIE1VU1QgYWN0IGFzIERUTFMgc2VydmVycyBv biBhIGNvbmZpZ3VyZWQgcG9ydCwgYW5kPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5NVVNUIGxpc3RlbiBmb3IgdW5lbmNyeXB0ZWQgQmFiZWwgdHJhZmZpYyBvbiBhIGRpc3Rp bmN0IGNvbmZpZ3VyZWQgcG9ydC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW4gaW1wbGVt ZW50YXRpb24gZG9lc27igJl0IGhhdmUgdG8gYWxsb3cgZm9yIGNvbmZpZ3VyYXRpb24gb2YgcG9y dHMuIFRoZXkgY291bGQganVzdCBiZSBoYXJkLWNvZGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBkb27igJl0IGxpa2UgdGhhdCBJIG5lZWQgdGhlIGNvbnRleHQgb2Yg dGhlIGZpcnN0IHNlbnRlbmNlIHRvIHVuZGVyc3RhbmQgdW5hbWJpZ3VvdXNseSB3aGF0IHRoZSBz ZWNvbmQgcG9ydCBpcyDigJxkaXN0aW5jdOKAnSBmcm9tIChpLmUuLCBkaXN0aW5jdCBmcm9tIHRo ZSB1bmVuY3J5cHRlZCBCYWJlbCBwb3J0KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IGFi b3V0IGp1c3Qg4oCcIEJhYmVsIG92ZXIgRFRMUyBNVVNUIG9wZXJhdGUgb24gYSBkaWZmZXJlbnQg cG9ydCB0aGFuIHVuZW5jcnlwdGVkIEJhYmVsLuKAnSA/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJhcmJhcmE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gRGF2aWQgU2No aW5hemkgJmx0O2RzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+ IEZyaWRheSwgSmFudWFyeSAwNCwgMjAxOSAyOjQxIFBNPGJyPg0KPGI+VG86PC9iPiBTVEFSSywg QkFSQkFSQSBIICZsdDticzc2NTJAYXR0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEJhYmVsIGF0 IElFVEYgJmx0O2JhYmVsQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2Jh YmVsXSBtaW5vciBEVExTIGNvbW1lbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnQsIEJhcmJhcmEuIEkg YWdyZWUgd2l0aCB5b3UsIGFuZCBoYXZlIGFkZGVkIHRoZSBmb2xsb3dpbmcgdGV4dDo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21famVj aF9iYWJlbC0yRGRyYWZ0c19jb21taXRfYTVhMzcyYTk0MmViYzc5NTFiMjg0N2Q4ODEyM2Q3NWFi ODE2OWYyZiZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1M b0d6aEMtOHNjOFNZOFRxNHZyZm9nJmFtcDttPXRGODVTNWxOSGhvMXZ0b0F1WXFTcjR4TkFxZDNt RG9WbldUMHR6VWNHXzQmYW1wO3M9SUExVjVMbkhnd3RySEdqN3MwMVlwWUNDYkctNlh6NHhEbklx MEtvbXlrOCZhbXA7ZT0iPmh0dHBzOi8vZ2l0aHViLmNvbS9qZWNoL2JhYmVsLWRyYWZ0cy9jb21t aXQvYTVhMzcyYTk0MmViYzc5NTFiMjg0N2Q4ODEyM2Q3NWFiODE2OWYyZjwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIGxldCB1 cyBrbm93IGlmIHlvdSBmZWVsIGl0IGFkZHJlc3NlcyB5b3VyIGNvbW1lbnQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRnJpLCBKYW4gNCwgMjAxOSBhdCA1OjM1IEFNIFNUQVJLLCBCQVJCQVJBIEggJmx0OzxhIGhy ZWY9Im1haWx0bzpiczc2NTJAYXR0LmNvbSI+YnM3NjUyQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlNpbmNlIHRoZSBEVExTIGRyYWZ0IGlzIHN0aWxsIG9wZW4gZm9yIGNvbW1lbnRzLCBJIGRvIGhh dmUgYSBzbWFsbCBvbmUgYWJvdXQgaG93IHRoZSBVRFAgcG9ydHMgYXJlIGNoYXJhY3Rlcml6ZWQu PGJyPg0KVGhlIElBTkEgYXNzaWduZWQgcG9ydHMgYXJlIGRlZmF1bHQgdmFsdWVzLCBhbmQgbmVl ZCB0byBiZSBwb3J0cmF5ZWQgYXMgc3VjaC4gSXQncyBhbGxvd2VkIChvciBzaG91bGQgYmUpIGZv ciBkZXBsb3llZCBpbnN0YW5jZXMgdG8gdXNlIG90aGVyIHZhbHVlcy4gVGhpcyBpcyBwcmV0dHkg bXVjaCB0cnVlIG9mIGFsbCBwcm90b2NvbHMuIENlcnRhaW5seSB0aGUgYmFzZSBiYWJlbCBwcm90 b2NvbCBhbGxvd3Mgb3RoZXIgdmFsdWVzIHRvIGJlIHVzZWQNCiAod2hpY2ggaXMgd2h5IHRoZSBo b21lbmV0IGJhYmVsIHByb2ZpbGUgbWFuZGF0ZWQgdXNlIG9mIDY2OTYpLjxicj4NCjxicj4NCk1h eWJlIGluc3RlYWQgb2Y8YnI+DQombmJzcDsgJm5ic3A7QWxsIEJhYmVsIG92ZXIgRFRMUyBub2Rl cyBNVVNUIGFjdCBhcyBEVExTIHNlcnZlcnMgb24gdGhlICZxdW90O2JhYmVsLTxicj4NCiZuYnNw OyAmbmJzcDtkdGxzJnF1b3Q7IHBvcnQgKFVEUCBwb3J0IFRCRCksIGFuZCBNVVNUIGxpc3RlbiBm b3IgdHJhZmZpYyBvbiB0aGU8YnI+DQombmJzcDsgJm5ic3A7dW5lbmNyeXB0ZWQgJnF1b3Q7YmFi ZWwmcXVvdDsgcG9ydCAoVURQIHBvcnQgNjY5NikuPGJyPg0KPGJyPg0Kc2F5PGJyPg0KJm5ic3A7 ICZuYnNwO0FsbCBCYWJlbCBvdmVyIERUTFMgbm9kZXMgTVVTVCBhY3QgYXMgRFRMUyBzZXJ2ZXJz IG9uIHRoZSAmcXVvdDtiYWJlbC08YnI+DQombmJzcDsgJm5ic3A7ZHRscyZxdW90OyBwb3J0LCBh bmQgTVVTVCBsaXN0ZW4gZm9yIHRyYWZmaWMgb24gdGhlPGJyPg0KJm5ic3A7ICZuYnNwO3VuZW5j cnlwdGVkICZxdW90O2JhYmVsJnF1b3Q7IHBvcnQuPGJyPg0KJm5ic3A7ICZuYnNwO1RoZSBJQU5B LWFzc2lnbmVkIHZhbHVlcyBvZiA2Njk2IGZvciB0aGUgJnF1b3Q7YmFiZWwmcXVvdDsgcG9ydCBh bmQgPGJyPg0KJm5ic3A7ICZuYnNwO1RCRCBmb3IgdGhlICZxdW90O2JhYmVsLWR0bHMmcXVvdDsg cG9ydCBTSE9VTEQgYmUgdXNlZC48YnI+DQo8YnI+DQpCYXJiYXJhPGJyPg0KPGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpiYWJl bCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86YmFiZWxAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5iYWJlbEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2JhYmVsJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2 aklnJmFtcDtyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmYW1wO209dEY4NVM1bE5IaG8xdnRvQXVZ cVNyNHhOQXFkM21Eb1ZuV1QwdHpVY0dfNCZhbXA7cz0wdjNjblVXeEtVSFZZWER4R0pNd2RLZnIx OWRDMWJNN1hMRjVZM2F6Ukg4JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYmFiZWw8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2D09D61DDFA73D4C884805CC7865E6114DF8360CGAALPA1MSGUSRBF_-- From nobody Fri Jan 4 12:26:27 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D4A130E8F for ; Fri, 4 Jan 2019 12:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kpf8TvZ_kFQl for ; Fri, 4 Jan 2019 12:26:23 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B42D9130E89 for ; Fri, 4 Jan 2019 12:26:23 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id d19so41656817qtq.9 for ; Fri, 04 Jan 2019 12:26:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=duTYf7B/BA5MPb87qP4Mz/b2ZxpgkTjQvAG3hsta1iU=; b=stbcmZgnRDkhvVZxc8XWvcnFK3sE+uVBVCC2kdGHVF8uC1RbbPj/E/fBUV/aOW2+Kb L3Z66dgaNOJEA1CHF0C7vcWPQqgm9bHvOmRW7qArEvLkN4TInwuo1nQ8NU9bliJ2DccM VnzYc/RI7ZS2baA9IiBkQxV2JgjiSVCfZDo8zwqCcCTgZ6NjQPi+O8lV3eM8HhxvR8Bb lJxMMnGiyn21TEjMBjN4p1YiK9yz6jGV+NDh6QGLoCm2jxc3nhm6h7gTQi+nA4+qfASg NeODPfb3xie0T4dYCK+iv+AfKurBpFwSoz2uJuFmWIAFxbPXIYpv9iTGWnUb/Gz2jcuN kR7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=duTYf7B/BA5MPb87qP4Mz/b2ZxpgkTjQvAG3hsta1iU=; b=PSgMmsfcFlCv7NIAsd+0U4MzUIc5VPFH9i+FCbCwJqlYq4JhwJyXaRreRWCynXCuzF JLY17sk8rcsvENDYPLoyjwk9VnuAye/6Z0eJtT41zBxg0QVM92CUrTmdcSNR5EzJelAf gtEyXS3ztajGFviXEIe0IQf2r+9Du7b1REV0K8nnFP6HPiVC1Bk7eIpa+HIg9bZPhpCM Sizn2frRqgSZoRgkqluwHHqCR2XaD7gCHqnkAUfy3jtb7ijVoGYuUqH0HrFhc0qPzlms J9cn9greNxCUyUfcmCWsRZ9NiG1rmO8+QkfumF5h0QXwB9rC+fElJNfMUAOa/pp06Jwz apuw== X-Gm-Message-State: AJcUukfbnvk6D5qxBJxvQR7ka+QzvRwQDoXwMfVosFuViVHvVQcgq/5S HJhmxspBpFqZtMhW/8O5ah3g3Y/v9xtWFJ+bcgc= X-Google-Smtp-Source: ALg8bN6/UJ4rnaZXY4s8SywTRVpSOi6xKMxRTCeAwvWi0yZuXFAYLXfuf8lT3Q2QZvhrnhhnb3RBiy1XA+udYFWMwu4= X-Received: by 2002:a0c:8a5a:: with SMTP id 26mr51212055qvu.94.1546633582647; Fri, 04 Jan 2019 12:26:22 -0800 (PST) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DF82DC1@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF8360C@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF8360C@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Dave Taht Date: Fri, 4 Jan 2019 12:26:10 -0800 Message-ID: To: "STARK, BARBARA H" Cc: David Schinazi , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] minor DTLS comment X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 20:26:26 -0000 On Fri, Jan 4, 2019 at 12:07 PM STARK, BARBARA H wrote: > > Hmm. > > " Babel over DTLS operates on a different port than unencrypted Babel. > > All Babel over DTLS nodes MUST act as DTLS servers on a configured port, = and > > MUST listen for unencrypted Babel traffic on a distinct configured port.= =E2=80=9D > > > > An implementation doesn=E2=80=99t have to allow for configuration of port= s. They could just be hard-coded. > > I don=E2=80=99t like that I need the context of the first sentence to und= erstand unambiguously what the second port is =E2=80=9Cdistinct=E2=80=9D fr= om (i.e., distinct from the unencrypted Babel port). > > > > How about just =E2=80=9C Babel over DTLS MUST operate on a different port= than unencrypted Babel.=E2=80=9D ? > Sure. (I had proposed at one point that the dtls version operate over udp_lite or even dccp, on the same port number, but have since discovered osx doesn't support either) > > Barbara > > > > From: David Schinazi > Sent: Friday, January 04, 2019 2:41 PM > To: STARK, BARBARA H > Cc: Babel at IETF > Subject: Re: [babel] minor DTLS comment > > > > Thanks for your comment, Barbara. I agree with you, and have added the fo= llowing text: > > https://github.com/jech/babel-drafts/commit/a5a372a942ebc7951b2847d88123d= 75ab8169f2f > > > > Please let us know if you feel it addresses your comment. > > > > Thanks, > > David > > > > On Fri, Jan 4, 2019 at 5:35 AM STARK, BARBARA H wrote: > > Since the DTLS draft is still open for comments, I do have a small one ab= out how the UDP ports are characterized. > The IANA assigned ports are default values, and need to be portrayed as s= uch. It's allowed (or should be) for deployed instances to use other values= . This is pretty much true of all protocols. Certainly the base babel proto= col allows other values to be used (which is why the homenet babel profile = mandated use of 6696). > > Maybe instead of > All Babel over DTLS nodes MUST act as DTLS servers on the "babel- > dtls" port (UDP port TBD), and MUST listen for traffic on the > unencrypted "babel" port (UDP port 6696). > > say > All Babel over DTLS nodes MUST act as DTLS servers on the "babel- > dtls" port, and MUST listen for traffic on the > unencrypted "babel" port. > The IANA-assigned values of 6696 for the "babel" port and > TBD for the "babel-dtls" port SHOULD be used. > > Barbara > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Fri Jan 4 12:35:28 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE43130E8F for ; Fri, 4 Jan 2019 12:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVbSMXXiOCcl for ; Fri, 4 Jan 2019 12:35:24 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B8AE1200D7 for ; Fri, 4 Jan 2019 12:35:24 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1546634090; bh=sruLINbRIWe95BBjyR5rTW4o+2uDd5UpPemOXdulEvg=; h=From:To:Subject:In-Reply-To:References:Date:From; b=P8zbR5VW2ZxX0wdLlq3LgzloHiJPnxkwlM+K8/nTKJz06tm8+Us1+UBL32wPCsZVc eRQbwLssMlyQTKHhJ/RSwOR79DPXvU0LyBeYsAb48iLKfaQHU0YSnwXXHiXHsSwZKl PS+avRhp8V/EuK63G5ueBlH6HBW0Uq60n4HBIvBNJ9Y9UAqKTMsxLeEmUirFY/Nu6N 7ehR79WH6SK8unichabsrkh5OCI8mBNUNSHaiH7so+DMKxO9FC1v5JfaZNAcHq8lih bsvxDtbtyyt5DaH0VZGNYB3UynVeXG633wi8Oiv4uB9iTPVjy+zirRGOEjntk+M8IL IywYb2pN9mdoQ== To: "STARK\, BARBARA H" , Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF83500@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <87a7khxxu6.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF83500@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Fri, 04 Jan 2019 21:34:45 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87bm4wyxei.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 20:35:26 -0000 "STARK, BARBARA H" writes: >> > Appendix A (incremental deployment and key rotation) indicates it should >> be possible to configure a mode where authenticated packets are sent but all >> packets are accepted. > ... >> > Proposed HMAC model: >> > add to top level information-obj: >> > babel-hmac-algorithms (enumerated list of supported HMAC computation >> algorithms) >> > >> > security-hmac-obj >> > security-hmac-enable (boolean: enable / disable this instance) >> > security-hmac-mode (Boolean: do or don't authenticate received >> > packets) >> >> How do those two interact? > > If an HMAC instance is disabled it's as if this instance doesn't exist. Its keys and hmac-mode values are irrelevant (don't care), and it causes no HMAC to be sent, expected, or checked, and no challenges to be responded to or sent. > If an HMAC instance is enabled (and there is at least one key to use for signing), then authenticated packets are always sent. > The hmac-mode toggles whether or not received packets are checked, for > an enabled HMAC instance. As I noted I think the setting of whether to check or not should be per-key; not sure it makes sense to have another global toggle? A global off switch may be useful, though... >> > security-hmac-algorithm (string: one of the supported HMAC algorithms) >> > security-interfaces (string list of references to interfaces-obj: the >> interfaces this instance applies to; if empty, it applies to all interfaces) >> > security-add-hmac-key (operation: inputs (reference name, key)) >> > hmac-key-obj >> >> IMO, we'll need two per-key booleans as well: "use for authentication" >> and "use for signing". They should be set independent of each other. > > OK. We could do this either with 2 Booleans or with a single > enumeration (sign-only, check-only, sign-and-check, [would an "unused" > value also be needed?]). Would people prefer Booleans or an > enumeration? I'm fine either way, but find enumerations easier for > people to read and understand. No strong opinion, but I think you are right that an enumeration is easier to understand. The 'unused' state would be, e.g., for keys that are retired but not removed entirely (in case they need to be re-enabled later). -Toke From nobody Fri Jan 4 12:38:43 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D158D130E9A for ; Fri, 4 Jan 2019 12:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROZjoJa4kbKn for ; Fri, 4 Jan 2019 12:38:41 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D891200D7 for ; Fri, 4 Jan 2019 12:38:41 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1546634317; bh=7yITfTNeCH9MsTae+dfiYgpR5U6aULaARNjlyAT1W40=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=GP9eksrudJQ63TjSTk3mh5OzwCD0D+2gJhU0i0Ehy/5D8RH82lj8P3TNmShepEYWC v54PtBnwZtOIZ77QYW+9WuPUGVW7Ua2Zt9B/zHED5OkJQJjhA2S7LI7mtRNogNLofJ 3VN0M+v1rTLas2fniRQkkRHB87vDGYmSuOS+gl2ZXtoFRT7/hqWoTpJNa3csdzXX+W ALf+st3Fa4EKCOpkOqBD7OWEBPvDUfhZffCFOx6MApx/wujApt56LMxCRy7wPGjD/Q iKy/+vPas08XDRowRVmEDIYMg13qAahA6FVE/xqr4G7UQFxeUNTcSYAM6LB1EuTSc8 PRQ4ehYlDxXEg== To: "STARK\, BARBARA H" , 'Mahesh Jethanandani' Cc: Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Fri, 04 Jan 2019 21:38:33 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <878t00yx86.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 20:38:43 -0000 "STARK, BARBARA H" writes: >> > We had discussed previously that keys should not be readable -- only add >> and delete keys. In this case, it's good for a non-readable parameter to have >> a "nickname" or index to reference it with. And it can be useful to know >> when the key was added. In my experience, these sorts of shared keys are >> modeled as strings. >> >> I would think the keys are modeled as binary. > > That depends on how we generally expect the keys to be generated. If > we think they'll be randomly generated by a centralized machine, then > binary makes sense. If we think they'll be created by a human being > who will input them through a keyboard, then string makes sense. I was > thinking the latter would be more common. I'm curious what others > think? Bird uses an unencoded string... -Toke From nobody Fri Jan 4 14:03:00 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EDF1271FF for ; Fri, 4 Jan 2019 14:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SSv7m_iVSvT for ; Fri, 4 Jan 2019 14:02:56 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E560130E9A for ; Fri, 4 Jan 2019 14:02:54 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x04M2g59005882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Jan 2019 23:02:43 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x04M2iN7001251; Fri, 4 Jan 2019 23:02:44 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 669BD4CD62; Fri, 4 Jan 2019 23:02:48 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id vfZEHh7o_e1j; Fri, 4 Jan 2019 23:02:46 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 951384CD60; Fri, 4 Jan 2019 23:02:46 +0100 (CET) Date: Fri, 04 Jan 2019 23:02:46 +0100 Message-ID: <87tvio2i9l.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'Mahesh Jethanandani'" , Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 04 Jan 2019 23:02:43 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 04 Jan 2019 23:02:44 +0100 (CET) X-Miltered: at korolev with ID 5C2FD802.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5C2FD804.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C2FD802.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5C2FD804.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C2FD802.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5C2FD804.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 22:02:59 -0000 >> In my experience, these sorts of shared keys are modeled as strings. >> I would think the keys are modeled as binary. > That depends on how we generally expect the keys to be generated. If we > think they'll be randomly generated by a centralized machine, then > binary makes sense. If we think they'll be created by a human being who > will input them through a keyboard, then string makes sense. I was > thinking the latter would be more common. I'm curious what others think? There's a third model -- locally generated from a passphrase on the local host (e.g. using a PSK). -- Juliusz From nobody Fri Jan 4 15:08:38 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0708B130EA1 for ; Fri, 4 Jan 2019 15:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PsxoxVali3B for ; Fri, 4 Jan 2019 15:08:35 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30A0B126BED for ; Fri, 4 Jan 2019 15:08:34 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id y1so18030284plp.9 for ; Fri, 04 Jan 2019 15:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YQFkf5qCXt+IesIZLJNjoRygZzyQyTM8IS8yJaqwjgw=; b=DBg7pv68BX19tsE7nZ19fGgrLZGRYiaAv6HGj6cCuZGI8T+2dckroWkKIoGpLeOZIg PEfPAndH/Jv0CcreAzoqW5p7HPdqOhKr5D42J9E/BlxZj4lB7eYn5wR3yDr7wHI6SVDM J+NSrX5Y6QsWsTVucJEI3bJ3WbwMdHbKwjKGPz1iAP5/VWzBcHad/GQ+c6VEJ+kfPP2Q nTkngq0eMTOLd15VS8NS/NCffYiTUL0UoHS00R9IlDQnN6iqIAhBRja25yi7+oXzVWbM 2AWnYXVVQvCgi66cOLPUjeNe+A23tn+NnUwFCLaWXmmju1iqNR0hdRmhOT451iB8bSnv ZaUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YQFkf5qCXt+IesIZLJNjoRygZzyQyTM8IS8yJaqwjgw=; b=Y1MNBO7LihuzmZFxaoz3LuSKcXwJrzLuNydaLFXiqICeSvKAClT5/286yhLX6ELPuE XVDaOIiNjWiWwvZaTwbyiU57Odskk9T6nrr8zLmrg78rUTnlAL3t90I1mctoow1i8/nH y0Ljf2APdb8UEX7YjPX49Oyzf4ag/pxdIP9mQ0SoDM4FL+9P4GcHuhNyRJyh2hIz0YxC L5tqsOSHX1SHp0u7/P+CFboDrr57oKe3UvJAJK+ZmzWsEOeUJ1frLetXYFSgWfP/rUua SMIvZF3KXVaYy0tVbAYHoDopRkBcPbXc5LGoFmpTr7DoHa3lqHHZTBY0XnVQ9PTNygvj qyeg== X-Gm-Message-State: AJcUukenCax9PSnErLScNE40gzMxOUOaNZVL9i1DxZk8lGZ14j0d7iNQ oCz+6HGIB6+Ejk7YMBu9vxE= X-Google-Smtp-Source: ALg8bN6Tigj7l3z7nlmBPtQREWvZt2n88co3Yj7WpF24iewKtWRKx9E2Fb5S1eovC+UNjtKwNh4Uqw== X-Received: by 2002:a17:902:ba8b:: with SMTP id k11mr52253442pls.177.1546643314326; Fri, 04 Jan 2019 15:08:34 -0800 (PST) Received: from [10.33.122.97] ([66.170.99.2]) by smtp.gmail.com with ESMTPSA id a195sm111918778pfa.7.2019.01.04.15.08.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Jan 2019 15:08:32 -0800 (PST) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B80312C5-F546-4374-BB3E-07E22E8B0A43" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 4 Jan 2019 15:08:31 -0800 In-Reply-To: Cc: "STARK, BARBARA H" , Babel at IETF To: Dave Taht References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 23:08:38 -0000 --Apple-Mail=_B80312C5-F546-4374-BB3E-07E22E8B0A43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 4, 2019, at 12:02 PM, Dave Taht wrote: >=20 > On Fri, Jan 4, 2019 at 11:54 AM STARK, BARBARA H > wrote: >>=20 >>>> We had discussed previously that keys should not be readable -- = only add >>> and delete keys. In this case, it's good for a non-readable = parameter to have >>> a "nickname" or index to reference it with. And it can be useful to = know >>> when the key was added. In my experience, these sorts of shared keys = are >>> modeled as strings. >>>=20 >>> I would think the keys are modeled as binary. >>=20 >> That depends on how we generally expect the keys to be generated. If = we think they'll be randomly generated by a centralized machine, then = binary makes sense. If we think they'll be created by a human being who = will input them through a keyboard, then string makes sense. I was = thinking the latter would be more common. I'm curious what others think? >=20 > What I wanted was a representation that was standard and unambiguous. > 0xdeadbeef for a hex representation, base64 > (https://tools.ietf.org/html/rfc4648#page-7 = ) or ( > http://docs.ros.org/diamondback/api/wpa_supplicant/html/base64_8c.html = > ) for all else. YANG does not have a data type for base64. It uses base64 as an = encoding, e.g. binary data is encoded as base64 for transmission over = the wire. But you do not represent/configure the data using base64 in = YANG. The choices would be string or binary. >>>> Appendix A (incremental deployment and key rotation) indicates it = should >>> be possible to configure a mode where authenticated packets are sent = but all >>> packets are accepted. >>>> Multiple HMAC algorithms are possible. The draft doesn't say how = the >>> nodes know which algorithm is being used (if multiple are = implemented). The >>> draft does say that only one HMAC is calculated per key. Is it = assumed the >>> algorithm choice is configured? >>>> Should the challenge expiry timer be configurable? >>>> I've decided to have completely separate HMAC and DTLS objects, = because >>> they're very different now that I have detailed designs to work = with. >>>> I'm adding an "operation" datatype to support key and cert = manipulation. >>> This is intended to be consistent with YANG "action" datatype. >>>=20 >>> Is the idea that there is both an input and an output expected for = key and >>> cert manipulation? If it is input only, i.e. configuring key and = cert., then you >>> would not need an action type. Having said that, in the examples you = give >>> below, I expect delete to be an action. >>=20 >> The only output needed is the result of the operation (success or = failure). >> As I think about why BBF went with an operation for adding/deleting a = X.509 cert, I realize it had to do with things related to its being an = X.509 cert and not a "credential". So I think I agree with you here that = for an HMAC key, the regular model manipulation mechanisms are fine = (including for delete) and the key can just be noted as non-readable. >>=20 >>> I am not clear on the =E2=80=98check-key=E2=80=99 operation. I would = expect that the device is >>> either enabled or disabled to check for HMAC. If enabled, and when a = packet >>> is received, the receiver will compute the HMAC (using the key = configured >>> for it) on the packet and compare it what is in the packet. If the = HMAC >>> compariosn fails, the receiver will drop the packet, and log a count = of >>> dropped packets because of mismatch. Why would the management plane >>> need to perform a =E2=80=98check-key=E2=80=99 operation? >>=20 >> We're making the key non-readable, once written. The check-key = operation gives the router something to hash, and a hash of that = something that you've created on your end (using what you think the key = is), and asks the router if the hash it creates is the same as the hash = you created. If yes, then you know (1) the key is what you think it is, = and (2) the hash is being computed using the algorithm you think it is = using. If the HMAC comparison is consistently failing, this can be a = useful troubleshooting mechanism (especially when setting up a new = network using routers with different implementations). Just knowing the = packet is getting dropped doesn't tell you much. There are many things = that could cause droppage. >> But this would be optional to support. And I won't insist on it if = others don't think it's a good idea. >> It's similar to a fingerprint comparison done for an X.509 = certificate. >>=20 >>>> Proposed HMAC model: >>>> add to top level information-obj: >>>> babel-hmac-algorithms (enumerated list of supported HMAC = computation >>>> algorithms) >>>>=20 >>>> security-hmac-obj >>>> security-hmac-enable (boolean: enable / disable this instance) >>>> security-hmac-mode (Boolean: do or don't authenticate received >>>> packets) >>>=20 >>> I have the same question as Toke here. >>=20 >> OK. I've sent a reply to Toke's email. >>=20 >>>> security-hmac-algorithm (string: one of the supported HMAC >>>> algorithms) >>>=20 >>> You mean one of the enum values defined above. >>=20 >> Yes. >>=20 >>> Thanks for putting this together. >>>=20 >>>> security-interfaces (string list of references to interfaces-obj: = the >>>> interfaces this instance applies to; if empty, it applies to all = interfaces) >>> security-add-hmac-key (operation: inputs (reference name, key)) >>>> hmac-key-obj >>>> key-name (string: reference name) >>>> key-date (datetime: timestamp when key was added) >>>> delete-key (operation) >>>> check-key (operation: inputs (string, HMAC of string)) ; the = node does >>> its own HMAC computation of the input string and compares this to = the input >>> HMAC of string; if the computed and input HMAC are the same the = operation >>> succeeds. >>>>=20 >>>> Thoughts? >>>> Barbara >>>>=20 >>>> _______________________________________________ >>>> babel mailing list >>>> babel@ietf.org >>>=20 >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel = >=20 >=20 >=20 > --=20 >=20 > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_B80312C5-F546-4374-BB3E-07E22E8B0A43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 4, 2019, at 12:02 PM, Dave Taht <dave.taht@gmail.com>= wrote:

On Fri, Jan 4, 2019 at 11:54 AM = STARK, BARBARA H <bs7652@att.com> wrote:

We had = discussed previously that keys should not be readable -- only add
and delete keys. In this case, it's good for a = non-readable parameter to have
a "nickname" or index to = reference it with. And it can be useful to know
when the = key was added. In my experience, these sorts of shared keys are
modeled as strings.

I would = think the keys are modeled as binary.

That depends on how we generally expect the keys to be = generated. If we think they'll be randomly generated by a centralized = machine, then binary makes sense. If we think they'll be created by a = human being who will input them through a keyboard, then string makes = sense. I was thinking the latter would be more common. I'm curious what = others think?

What I wanted was a representation that was standard and = unambiguous.
0xdeadbeef = for a hex representation, base64
(https://tools.ietf.org/html/rfc4648#page-7) or (
http://docs.ros.org/diamondback/api/wpa_supplicant/html/base64_= 8c.html
) for all = else.

YANG does = not have a data type for base64. It uses base64 as an encoding, e.g. = binary data is encoded as base64 for transmission over the wire. But you = do not represent/configure the data using base64 in YANG. The choices = would be string or binary.

Appendix A (incremental = deployment and key rotation) indicates it should
be possible to configure a mode where = authenticated packets are sent but all
packets are = accepted.
Multiple = HMAC algorithms are possible. The draft doesn't say how the
nodes know which algorithm is being used (if = multiple are implemented). The
draft does say that only = one HMAC is calculated per key. Is it assumed the
algorithm = choice is configured?
Should the challenge expiry timer be configurable?
I've decided to have completely separate HMAC and DTLS = objects, because
they're very different now = that I have detailed designs to work with.
I'm adding an "operation" datatype to support = key and cert manipulation.
This is intended = to be consistent with YANG "action" datatype.

Is the idea that there is both an input and an output = expected for key and
cert manipulation? If it is input = only, i.e. configuring key and cert., then you
would not = need an action type. Having said that, in the examples you give
below, I expect delete to be an action.

The only output needed is the = result of the operation (success or failure).
As I think = about why BBF went with an operation for adding/deleting a X.509 cert, I = realize it had to do with things related to its being an X.509 cert and = not a "credential". So I think I agree with you here that for an HMAC = key, the regular model manipulation mechanisms are fine (including for = delete) and the key can just be noted as non-readable.

I am not clear on the = =E2=80=98check-key=E2=80=99 operation. I would expect that the device = is
either enabled or disabled to check for HMAC. If = enabled, and when a packet
is received, the receiver will = compute the HMAC (using the key configured
for it) on the = packet and compare it what is in the packet. If the HMAC
compariosn fails, the receiver will drop the packet, and log = a count of
dropped packets because of mismatch. Why would = the management plane
need to perform a =E2=80=98check-key=E2= =80=99 operation?

We're making = the key non-readable, once written. The check-key operation gives the = router something to hash, and a hash of that something that you've = created on your end (using what you think the key is), and asks the = router if the hash it creates is the same as the hash you created. If = yes, then you know (1) the key is what you think it is, and (2) the hash = is being computed using the algorithm you think it is using. If the HMAC = comparison is consistently failing, this can be a useful troubleshooting = mechanism (especially when setting up a new network using routers with = different implementations). Just knowing the packet is getting dropped = doesn't tell you much. There are many things that could cause = droppage.
But this would be optional to support. And I = won't insist on it if others don't think it's a good idea.
It's similar to a fingerprint comparison done for an X.509 = certificate.

Proposed HMAC model:
add to top level information-obj:
babel-hmac-algorithms (enumerated list of supported HMAC = computation
algorithms)

security-hmac-obj
security-hmac-enable = (boolean: enable / disable this instance)
security-hmac-mode= (Boolean: do or don't authenticate received
packets)

I have the same question as Toke = here.

OK. I've sent a reply to = Toke's email.

security-hmac-algorithm = (string: one of the supported HMAC
algorithms)

You mean one of the enum values = defined above.

Yes.

Thanks = for putting this together.

security-interfaces (string list of references = to interfaces-obj: the
interfaces this instance applies = to; if empty, it applies to all interfaces)
security-add-hmac-key (operation: inputs = (reference name, key))
   hmac-key-obj
       key-name (string: = reference name)
       key-date (datetime: = timestamp when key was added)
       delete-key = (operation)
       check-key = (operation: inputs (string, HMAC of string)) ; the node does
its own HMAC computation of the input string and = compares this to the input
HMAC of string; if the computed = and input HMAC are the same the operation
succeeds.

Thoughts?
Barbara

_______________________________________________
babel mailing list
babel@ietf.org

Mahesh Jethanandani
mjethanandani@gmail.com
_______________________________________________babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel



-- 
Dave T=C3=A4ht
CTO, TekLibre, LLC
http://www.teklibre.comTel: = 1-831-205-9740

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_B80312C5-F546-4374-BB3E-07E22E8B0A43-- From nobody Fri Jan 4 15:13:03 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49C0130EA8 for ; Fri, 4 Jan 2019 15:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_qyC6bFpvxs for ; Fri, 4 Jan 2019 15:12:57 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF06126BED for ; Fri, 4 Jan 2019 15:12:57 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id s198so18077486pgs.2 for ; Fri, 04 Jan 2019 15:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wU0IEiNgiplJEFNv6lRs7/rJZ1M4fPZgcYs+gweIh0Y=; b=TT5IGiAOtsrvmoCKM/wGIC5P/Tgkv/qLji2rZ2nHEa2uuUy8n+uLdJoCAKhP1m2px6 DyChWOf1riyJLJkNXzm4ft3Gd2xA5gx6C7VZu9pbRz5eeXOiqreQxYk2372/N2RJRmtB AfDUuvIeCd1zO6bzXvoBcqA1X5gaBtLx5y31cskkRgoov1IekpUQooycVnUw4btgKZ/U szYv77tzHLsUGa3OaiV/xH1bYnia+03VPQH+5BpCNJVIWYWKqzhg91cpQNxsOkce0P1I Hxb3Ao5APL2POS+0Zaus9MARTEcxBDbv1+nGaGJ0Q3/s9qQAqXsYyokPoulUfczJePDT +OSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=wU0IEiNgiplJEFNv6lRs7/rJZ1M4fPZgcYs+gweIh0Y=; b=h4bfIBCU1FvSY/yU7Dbq01tXYmnOcnGQvA5LolBc2KjGy+mjedcwAs7MwV8qVSRY3W PBP9Srl6BnLvGSYdnq21ZsNQDLcAP5U/Mrc1tEPqAIctS7aYb4Ptg/OItgP2hGRFkSD9 YBlMEu6ebnwaoh6iDltLNkQQGcguSD/qc3TnRcsnKd2ymglL12TNuSceKqSJtsrWeXg0 ki2jNRoMVxp7ISVjFCt2CPhrYt2HBnZME9gq9YVXWCfP5YRIWZwGRy+ot4/ThQtlD5h5 RDUai7n4arBtmhvJcnfZ5FXhqt6zxPSDFML6AeRn2N6FCpKPhBb/bMEuUY0/45RXaHjh X1ZQ== X-Gm-Message-State: AJcUukdxXhxHi0RiMi7y/P1WOtf+OQelx+oinoxdGs+oIWwef5NycSWv 8q78GkyYEC01ns8+lfdEPHc= X-Google-Smtp-Source: ALg8bN49OU2WLcOYCv/x0lmaVlFtigKMkh5Tt+2Gihg9G+cTvpDwuuUTGEb2ZNLfqGUriSRKJTOqQA== X-Received: by 2002:a63:cd11:: with SMTP id i17mr3234734pgg.345.1546643576849; Fri, 04 Jan 2019 15:12:56 -0800 (PST) Received: from [10.33.122.97] ([66.170.99.2]) by smtp.gmail.com with ESMTPSA id 19sm114868558pfs.108.2019.01.04.15.12.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Jan 2019 15:12:55 -0800 (PST) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0DBDB6A3-BDD9-492A-95BA-86FEA2F0C140" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 4 Jan 2019 15:12:53 -0800 In-Reply-To: Cc: "STARK, BARBARA H" , Babel at IETF To: Dave Taht References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 23:13:00 -0000 --Apple-Mail=_0DBDB6A3-BDD9-492A-95BA-86FEA2F0C140 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 4, 2019, at 3:08 PM, Mahesh Jethanandani = wrote: >=20 >=20 >=20 >> On Jan 4, 2019, at 12:02 PM, Dave Taht > wrote: >>=20 >> On Fri, Jan 4, 2019 at 11:54 AM STARK, BARBARA H > wrote: >>>=20 >>>>> We had discussed previously that keys should not be readable -- = only add >>>> and delete keys. In this case, it's good for a non-readable = parameter to have >>>> a "nickname" or index to reference it with. And it can be useful to = know >>>> when the key was added. In my experience, these sorts of shared = keys are >>>> modeled as strings. >>>>=20 >>>> I would think the keys are modeled as binary. >>>=20 >>> That depends on how we generally expect the keys to be generated. If = we think they'll be randomly generated by a centralized machine, then = binary makes sense. If we think they'll be created by a human being who = will input them through a keyboard, then string makes sense. I was = thinking the latter would be more common. I'm curious what others think? >>=20 >> What I wanted was a representation that was standard and unambiguous. >> 0xdeadbeef for a hex representation, base64 >> (https://tools.ietf.org/html/rfc4648#page-7 = ) or ( >> = http://docs.ros.org/diamondback/api/wpa_supplicant/html/base64_8c.html = >> ) for all else. >=20 > YANG does not have a data type for base64. It uses base64 as an = encoding, e.g. binary data is encoded as base64 for transmission over = the wire. But you do not represent/configure the data using base64 in = YANG. The choices would be string or binary. Sorry. I should have added that RFC8177, YANG Key Chain, models keys as = either string or hexadecimal (not binary). choice key-string-style { description "Key string styles"; case keystring { leaf keystring { type string; description "Key string in ASCII format."; } } case hexadecimal { if-feature "hex-key-string"; leaf hexadecimal-string { type yang:hex-string; description "Key in hexadecimal string format. When compared to ASCII, specification in hexadecimal affords greater key entropy with the same number of internal key-string octets. Additionally, it discourages usage of well-known words or numbers."; } } } >=20 >>>>> Appendix A (incremental deployment and key rotation) indicates it = should >>>> be possible to configure a mode where authenticated packets are = sent but all >>>> packets are accepted. >>>>> Multiple HMAC algorithms are possible. The draft doesn't say how = the >>>> nodes know which algorithm is being used (if multiple are = implemented). The >>>> draft does say that only one HMAC is calculated per key. Is it = assumed the >>>> algorithm choice is configured? >>>>> Should the challenge expiry timer be configurable? >>>>> I've decided to have completely separate HMAC and DTLS objects, = because >>>> they're very different now that I have detailed designs to work = with. >>>>> I'm adding an "operation" datatype to support key and cert = manipulation. >>>> This is intended to be consistent with YANG "action" datatype. >>>>=20 >>>> Is the idea that there is both an input and an output expected for = key and >>>> cert manipulation? If it is input only, i.e. configuring key and = cert., then you >>>> would not need an action type. Having said that, in the examples = you give >>>> below, I expect delete to be an action. >>>=20 >>> The only output needed is the result of the operation (success or = failure). >>> As I think about why BBF went with an operation for adding/deleting = a X.509 cert, I realize it had to do with things related to its being an = X.509 cert and not a "credential". So I think I agree with you here that = for an HMAC key, the regular model manipulation mechanisms are fine = (including for delete) and the key can just be noted as non-readable. >>>=20 >>>> I am not clear on the =E2=80=98check-key=E2=80=99 operation. I = would expect that the device is >>>> either enabled or disabled to check for HMAC. If enabled, and when = a packet >>>> is received, the receiver will compute the HMAC (using the key = configured >>>> for it) on the packet and compare it what is in the packet. If the = HMAC >>>> compariosn fails, the receiver will drop the packet, and log a = count of >>>> dropped packets because of mismatch. Why would the management plane >>>> need to perform a =E2=80=98check-key=E2=80=99 operation? >>>=20 >>> We're making the key non-readable, once written. The check-key = operation gives the router something to hash, and a hash of that = something that you've created on your end (using what you think the key = is), and asks the router if the hash it creates is the same as the hash = you created. If yes, then you know (1) the key is what you think it is, = and (2) the hash is being computed using the algorithm you think it is = using. If the HMAC comparison is consistently failing, this can be a = useful troubleshooting mechanism (especially when setting up a new = network using routers with different implementations). Just knowing the = packet is getting dropped doesn't tell you much. There are many things = that could cause droppage. >>> But this would be optional to support. And I won't insist on it if = others don't think it's a good idea. >>> It's similar to a fingerprint comparison done for an X.509 = certificate. >>>=20 >>>>> Proposed HMAC model: >>>>> add to top level information-obj: >>>>> babel-hmac-algorithms (enumerated list of supported HMAC = computation >>>>> algorithms) >>>>>=20 >>>>> security-hmac-obj >>>>> security-hmac-enable (boolean: enable / disable this instance) >>>>> security-hmac-mode (Boolean: do or don't authenticate received >>>>> packets) >>>>=20 >>>> I have the same question as Toke here. >>>=20 >>> OK. I've sent a reply to Toke's email. >>>=20 >>>>> security-hmac-algorithm (string: one of the supported HMAC >>>>> algorithms) >>>>=20 >>>> You mean one of the enum values defined above. >>>=20 >>> Yes. >>>=20 >>>> Thanks for putting this together. >>>>=20 >>>>> security-interfaces (string list of references to interfaces-obj: = the >>>>> interfaces this instance applies to; if empty, it applies to all = interfaces) >>>> security-add-hmac-key (operation: inputs (reference name, key)) >>>>> hmac-key-obj >>>>> key-name (string: reference name) >>>>> key-date (datetime: timestamp when key was added) >>>>> delete-key (operation) >>>>> check-key (operation: inputs (string, HMAC of string)) ; = the node does >>>> its own HMAC computation of the input string and compares this to = the input >>>> HMAC of string; if the computed and input HMAC are the same the = operation >>>> succeeds. >>>>>=20 >>>>> Thoughts? >>>>> Barbara >>>>>=20 >>>>> _______________________________________________ >>>>> babel mailing list >>>>> babel@ietf.org >>>>=20 >>>> Mahesh Jethanandani >>>> mjethanandani@gmail.com >>> _______________________________________________ >>> babel mailing list >>> babel@ietf.org >>> https://www.ietf.org/mailman/listinfo/babel = >>=20 >>=20 >>=20 >> --=20 >>=20 >> Dave T=C3=A4ht >> CTO, TekLibre, LLC >> http://www.teklibre.com >> Tel: 1-831-205-9740 >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_0DBDB6A3-BDD9-492A-95BA-86FEA2F0C140 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 4, 2019, at 3:08 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:



On Jan 4, 2019, at 12:02 PM, Dave Taht <dave.taht@gmail.com>= wrote:

On Fri, Jan 4, 2019 at 11:54 AM = STARK, BARBARA H <bs7652@att.com> wrote:

We had = discussed previously that keys should not be readable -- only add
and delete keys. In this case, it's good for a = non-readable parameter to have
a "nickname" or index to = reference it with. And it can be useful to know
when the = key was added. In my experience, these sorts of shared keys are
modeled as strings.

I would = think the keys are modeled as binary.

That depends on how we generally expect the keys to be = generated. If we think they'll be randomly generated by a centralized = machine, then binary makes sense. If we think they'll be created by a = human being who will input them through a keyboard, then string makes = sense. I was thinking the latter would be more common. I'm curious what = others think?

What I wanted was a representation that was standard and = unambiguous.
0xdeadbeef = for a hex representation, base64
(https://tools.ietf.org/html/rfc4648#page-7) or (
http://docs.ros.org/diamondback/api/wpa_supplicant/html/base64_= 8c.html
) for all = else.

YANG does not have a data type for base64. It uses = base64 as an encoding, e.g. binary data is encoded as base64 for = transmission over the wire. But you do not represent/configure the data = using base64 in YANG. The choices would be string or = binary.

Sorry. I = should have added that RFC8177, YANG Key Chain, models keys as either = string or hexadecimal (not binary).

             =
choice key-string-style {
               description
                 "Key string styles";
                case keystring {
                  leaf keystring {
                   type string;
                   description
                     "Key string in ASCII format.";
                 }
               }
               case hexadecimal {
                 if-feature "hex-key-string";
                 leaf hexadecimal-string {
                   type yang:hex-string;
                   description
                     "Key in hexadecimal string format.  When compared
                      to ASCII, specification in hexadecimal affords
                      greater key entropy with the same number of
                      internal key-string octets.  Additionally, it
                      discourages usage of well-known words or
                      numbers.";
                 }
               }
             }


Appendix A (incremental deployment and key rotation) = indicates it should
be possible to configure = a mode where authenticated packets are sent but all
packets = are accepted.
Multiple = HMAC algorithms are possible. The draft doesn't say how the
nodes know which algorithm is being used (if = multiple are implemented). The
draft does say that only = one HMAC is calculated per key. Is it assumed the
algorithm = choice is configured?
Should the challenge expiry timer be configurable?
I've decided to have completely separate HMAC and DTLS = objects, because
they're very different now = that I have detailed designs to work with.
I'm adding an "operation" datatype to support = key and cert manipulation.
This is intended = to be consistent with YANG "action" datatype.

Is the idea that there is both an input and an output = expected for key and
cert manipulation? If it is input = only, i.e. configuring key and cert., then you
would not = need an action type. Having said that, in the examples you give
below, I expect delete to be an action.

The only output needed is the = result of the operation (success or failure).
As I think = about why BBF went with an operation for adding/deleting a X.509 cert, I = realize it had to do with things related to its being an X.509 cert and = not a "credential". So I think I agree with you here that for an HMAC = key, the regular model manipulation mechanisms are fine (including for = delete) and the key can just be noted as non-readable.

I am not clear on the = =E2=80=98check-key=E2=80=99 operation. I would expect that the device = is
either enabled or disabled to check for HMAC. If = enabled, and when a packet
is received, the receiver will = compute the HMAC (using the key configured
for it) on the = packet and compare it what is in the packet. If the HMAC
compariosn fails, the receiver will drop the packet, and log = a count of
dropped packets because of mismatch. Why would = the management plane
need to perform a =E2=80=98check-key=E2= =80=99 operation?

We're making = the key non-readable, once written. The check-key operation gives the = router something to hash, and a hash of that something that you've = created on your end (using what you think the key is), and asks the = router if the hash it creates is the same as the hash you created. If = yes, then you know (1) the key is what you think it is, and (2) the hash = is being computed using the algorithm you think it is using. If the HMAC = comparison is consistently failing, this can be a useful troubleshooting = mechanism (especially when setting up a new network using routers with = different implementations). Just knowing the packet is getting dropped = doesn't tell you much. There are many things that could cause = droppage.
But this would be optional to support. And I = won't insist on it if others don't think it's a good idea.
It's similar to a fingerprint comparison done for an X.509 = certificate.

Proposed HMAC model:
add to top level information-obj:
babel-hmac-algorithms (enumerated list of supported HMAC = computation
algorithms)

security-hmac-obj
security-hmac-enable = (boolean: enable / disable this instance)
security-hmac-mode= (Boolean: do or don't authenticate received
packets)

I have the same question as Toke = here.

OK. I've sent a reply to = Toke's email.

security-hmac-algorithm = (string: one of the supported HMAC
algorithms)

You mean one of the enum values = defined above.

Yes.

Thanks = for putting this together.

security-interfaces (string list of references = to interfaces-obj: the
interfaces this instance applies = to; if empty, it applies to all interfaces)
security-add-hmac-key (operation: inputs = (reference name, key))
   hmac-key-obj
       key-name (string: = reference name)
       key-date (datetime: = timestamp when key was added)
       delete-key = (operation)
       check-key = (operation: inputs (string, HMAC of string)) ; the node does
its own HMAC computation of the input string and = compares this to the input
HMAC of string; if the computed = and input HMAC are the same the operation
succeeds.

Thoughts?
Barbara

_______________________________________________
babel mailing list
babel@ietf.org

Mahesh Jethanandani
mjethanandani@gmail.com
_______________________________________________babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel



-- 
Dave T=C3=A4ht
CTO, TekLibre, LLC
http://www.teklibre.comTel: = 1-831-205-9740

Mahesh Jethanandani
mjethanandani@gmail.com




Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_0DBDB6A3-BDD9-492A-95BA-86FEA2F0C140-- From nobody Sun Jan 6 21:17:52 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBEE128CF3; Sun, 6 Jan 2019 21:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z50C1QCdtAYr; Sun, 6 Jan 2019 21:17:49 -0800 (PST) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78021274D0; Sun, 6 Jan 2019 21:17:48 -0800 (PST) Received: by mail-it1-x136.google.com with SMTP id m62so8989466ith.5; Sun, 06 Jan 2019 21:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=zB3a4eQrtGCYfIqP5jHiBsoXm/aKbMJ5GbU4aJt+H4A=; b=ELp5z7OliVuwVmeHtSCh/frbSwicnXQkePhgvVPxzIukiT7FrrjN3G1Ih69NUa3oas KDFrksbpT7RowRYptet75iPcxxVyPdBfyb85yoPspFyohXko7HRCGcxC1j848Y0ZhQ16 T7BOxSI4wvEyzXZdqiGCF3ez7cEeDJa3JpkTZEvtINb+pXqUHgditI4eK/mmxOGehuBG Pc+A1s2jfBJJEf3YLTvRkluL8lmvN4Wxkv0ni1hj05Vp8LPHEmGSENg/TCnktntEiwwe 409bpcOXyIQf6yZOghaKjzcHL+UwoQIi5VASElzPT1YcFlbMrtTa31PQwWm9XjX9y6fG nT+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=zB3a4eQrtGCYfIqP5jHiBsoXm/aKbMJ5GbU4aJt+H4A=; b=bGD/XnIBrV5Mm2iTBDlgIYyNi1OYGuX8RqaHufGTQTPH2Zba2eHCUvEMb7rqtS10AJ sY6vYN3/KsddC1xDky8e+adpiEHDLFeatL4ynxWuUUP7gLAZI3gGJyi0nXdkGDPZCq8n hRwKHZmJY9AuXZbx2FPc6ACymrktaO21/lK0YfyvjDcKX/48YyUIEtNVInjMAWGmx3/4 q3xb6auF9Yn/mSd+AscZ+8varPePf/8982Tj26ki/4SVq+KbJKW8UVumfrQi7MFtklvL zkzqZqyaBNEICClD8WEXcCLF9d/xNzk/F0Me3PnJ96PitfWoHymZmD0FzHbcp3y2KyMU aD+Q== X-Gm-Message-State: AJcUukcjH8lPgB1CMQqi25pZON3Z3SJGTy0mgQPOETBw7GjlpKbFrGyf Rh92IXUPpdmX3JXz+IW+aVJcTnkfVmrKDKV3mJxtnBDYEK0= X-Google-Smtp-Source: ALg8bN51CWg/6lqHdaSprM1CVGhG661eCupaXkZrtuSlkWylHqxfoshD8UZCkwEMEhM8euBDxr0PvMPfEROSQms8tG0= X-Received: by 2002:a24:89:: with SMTP id 131mr6039258ita.105.1546838267873; Sun, 06 Jan 2019 21:17:47 -0800 (PST) MIME-Version: 1.0 From: Donald Eastlake Date: Mon, 7 Jan 2019 00:17:36 -0500 Message-ID: To: Babel at IETF Cc: draft-ietf-babel-dtls@ietf.org, babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] Shepherd's review of draft-ietf-babel-dtls-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 05:17:51 -0000 Hi, Here are some comments on the draft: Abstract and Introduction: Replace "describes" with "specifies". Section 2.1, top of page 4, says "When a node receives a new DTLS connection, it MUST verify the source IP address, and reject the connection if the address is not an IPv6 link-local address." Would it be correct to replace this with "When a node receives a new DTLS connection, it MUST verify that the source IP address is an IPv6 link-local address; if it is not, it MUST reject the connection." or is there some other sort of verification it must do? Last paragraph of Section 2.3: I'm not sure about "unprotected implementation of Babel". Maybe "Babel implementation without DTLS support". Also, the reference to replacing "TLV"s seems odd. Can't there be multiple TLVs in a message? Maybe "replacing any multicast Babel routing protocol message with unicast transmission of the message to each known neighbor except that neighbor discovery Hello TLVs MUST still be multicast." or something like that. IANA Considerations: As are probably aware, Section 8.1.1 of RFC 6335 is about applying for port numbers (and service names, which would, as you say, be "babel-dtls" in this case). A completed application template could be included as an appendix, though that is not necessary. Security Considerations, first sentence: Maybe "The interaction" -> "Confidential interaction". Security Considerations and rfc6126bis seem to say that Babel can run over IPv4 but the last paragraph of Section 2.1 seems to be limited to IPv6. I'm not sure why Performance Considerations is an Appendix rather than a section of the main text. But I guess it's OK either way. Minor wording suggestions, adopt or ignore as you choose: Abstract and Introduction: in the first line, insert "base" before "Babel Routing Protocol". Section 1.2: Delete "very". Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com From nobody Mon Jan 7 08:23:18 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26245130F0E for ; Mon, 7 Jan 2019 08:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtSg-_-n6vTw for ; Mon, 7 Jan 2019 08:23:15 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F4A130F04 for ; Mon, 7 Jan 2019 08:23:15 -0800 (PST) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x07GHXhN048329; Mon, 7 Jan 2019 11:23:14 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2pv8x9tgy4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Jan 2019 11:23:14 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x07GNCck017221; Mon, 7 Jan 2019 11:23:13 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x07GN5Gc017042; Mon, 7 Jan 2019 11:23:05 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id E2EAF401468E; Mon, 7 Jan 2019 16:23:05 +0000 (GMT) Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (unknown [130.8.218.153]) by zlp30483.vci.att.com (Service) with ESMTPS id CF35F401466C; Mon, 7 Jan 2019 16:23:05 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0415.000; Mon, 7 Jan 2019 11:23:05 -0500 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'Mahesh Jethanandani'" , Babel at IETF Thread-Topic: [babel] hmac info model elements Thread-Index: AdSi6E9jJwLKz5kXQlCy2NNONpdJZQA7HaOAAB1GhjAAFlCHAAB9AEdg Date: Mon, 7 Jan 2019 16:23:04 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF8669E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87tvio2i9l.wl-jch@irif.fr> In-Reply-To: <87tvio2i9l.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.202.237] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-07_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=538 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901070142 Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 16:23:17 -0000 Coming back to modeling of HMAC keys (and PSKs) after the weekend... Juliusz said: "There's a third model -- locally generated from a passphrase= on the local host (e.g. using a PSK)."=20 If I understand this correctly, this is actually what I thought we wo= uld be doing (though I would use the word "derived" instead of "generated",= because "derive" to me implies the same result will always be had at the e= nd of the derivation, while "generated" may have a random aspect). Example:= WPA (for Wi-Fi, using SHA-1) uses an alphanumeric passphrase / pre-shared = key (PSK) (and SSID) that are provided to Wi-Fi endpoints, somehow (various= possible methods of providing). The PSK (and SSID) are first converted to = Unicode representation of the alphanumeric characters, before being used to= derive the HMAC-SHA1 key using the RFC 2898 PBKDF2 pseudorandom function. = This is the model I've been envisioning would be used for babel (except we = have SHA-256 instead of SHA-1).=20 Toke said: "Bird uses an unencoded string..."=20 I'm not sure what "unencoded" means here? But this sounds like maybe = the entered string is a "passphrase" / PSK, like what's used for Wi-Fi, whi= ch is then used to derive the HMAC key using Unicode encoding? Dave wants hex or base64. By this, I'm thinking Dave is actually talking about the HMAC key its= elf (exactly 256 bits)? Mahesh said: "RFC8177, YANG Key Chain, models keys as either string or hexa= decimal". Now that I've been reading up on HMAC keys -- I think if we're modeli= ng the actual key, it should be hex. If a PSK, then string. If I'm understanding all of this, I think (?) I'm agreeing with Juliusz and= that the info model should support supplying a string PSK, and it should b= e called something like "hmac-psk" so it's not confused with the HMAC key. = We could also allow for supplying the actual HMAC key, which I think should= be hex. I'm fine with or without supporting the actual HMAC key in the inf= o model. I think PSK is important. Barbara > -----Original Message----- > From: Juliusz Chroboczek > Sent: Friday, January 04, 2019 5:03 PM > To: STARK, BARBARA H > Cc: 'Mahesh Jethanandani' ; Babel at IETF > > Subject: Re: [babel] hmac info model elements >=20 > >> In my experience, these sorts of shared keys are modeled as strings. >=20 > >> I would think the keys are modeled as binary. >=20 > > That depends on how we generally expect the keys to be generated. If > > we think they'll be randomly generated by a centralized machine, then > > binary makes sense. If we think they'll be created by a human being > > who will input them through a keyboard, then string makes sense. I was > > thinking the latter would be more common. I'm curious what others think= ? >=20 > There's a third model -- locally generated from a passphrase on the local= host > (e.g. using a PSK). >=20 > -- Juliusz From nobody Mon Jan 7 08:35:51 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864BF130F3A for ; Mon, 7 Jan 2019 08:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aX7RPYHfhgoI for ; Mon, 7 Jan 2019 08:35:40 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6AD2130F59 for ; Mon, 7 Jan 2019 08:35:40 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1546878937; bh=W3HGZCwLr7cs9Ww6XcGdMD1PyrBML8o89aj8CNGwXlA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=AnoPBfT9tzAJUM+S09ZZa2EdG0V/A+dm9G1ZDw5qy366qwh8qsodJelBpiXnDCnk1 jJtxqxOgWj1dwoHcF5F5RfuffM0T7xQclnJACjby/SNA9olnqguQXT6xI9QEOGE3PS OwmToeEBxj/0m9epO+oZ33LmkuegIXlmnsOtnSHkh3tvt3GTLI05H3SXJ92m0jhkvn SAxkiPZKzP3XBydbgWAWVND2CgC5MPY1QXsacXcN5y/jac5KOimlB6FIt7NnX5rcDk ZHFrN/fwzMj33FfFr8NXVe4XkBfyJa2Od0CVG58h9DkHwsQiJlrRsZc68fyaUqKSFc QEgoYkURQAprg== To: "STARK\, BARBARA H" , 'Juliusz Chroboczek' Cc: 'Mahesh Jethanandani' , Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF8669E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87tvio2i9l.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF8669E@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Mon, 07 Jan 2019 17:35:36 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k1jgwhlz.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 16:35:50 -0000 "STARK, BARBARA H" writes: > Toke said: "Bird uses an unencoded string..." > I'm not sure what "unencoded" means here? But this sounds like > maybe the entered string is a "passphrase" / PSK, like what's used for > Wi-Fi, which is then used to derive the HMAC key using Unicode > encoding? Nope, no derivation, just the raw ASCII bytes from the string used as an HMAC key, zero-padded to the block size. Unless the supplied ASCII string is longer than the block size, in which case it is hashed first. However, looking at the code again, this is actually controlled by the protocol, so if we were to specify something different for Babel, that would be doable as well... And I think agreeing on a mechanism would probably be a good idea to ensure interoperability. -Toke From nobody Mon Jan 7 09:06:34 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A557C130F7F for ; Mon, 7 Jan 2019 09:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5-CV963TRNA for ; Mon, 7 Jan 2019 09:06:30 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60B7130F72 for ; Mon, 7 Jan 2019 09:06:30 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id d19so1211506qtq.9 for ; Mon, 07 Jan 2019 09:06:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=C7dChZcKnLw85I+mt+Ve0q76XYGvHcAke66R1PWGwm0=; b=qmEzjKNVF+B0+mbrd2MNsQXfIFOXngq8ifL0EV5W+PP6o8huVEl7JHiYm94Vi5kZNK cgNlSy18x/tyDz+gNOselt7c+rm3eshv7wecWMMqiVRTAtxZKPRlrW4SkXl0ylGD6qBh WIbM9okGybcJzy3zwocVOqbzOlUUSVTXShG7UQwC9wD2zsaoWKsqviJO5BRqZuqM8Xqm M524fXlfuQa3DqzdYo3MGSRwBncNNp9Us7L5yZNAThwRKTPAWO7uPQTaFQez+d9aliUR Cnw/TPh4eIkpglnHA+jUvrEyfU+t2Vh0jXpfWlb5HHNfhldzYX2WTuu/hQQpWaq1uNUK RYRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=C7dChZcKnLw85I+mt+Ve0q76XYGvHcAke66R1PWGwm0=; b=SxYjGbpXTr08NZSLGRbPGssMvPYKEOWy9h7KWkGbok90mrc9dcY2adilfhY6oXTjlK CbPqZ0REzAh4Oge1upYWjibVtMBk2EFEsDzXVbDG76F2YUl5M+s1juSpPjskA6ngfc4F 7tFUY/QVfrHTJE/I4MU6fIBymHSxo80MVm3roFuTHjlJB1cLMhZBXlzyIRfNS4+njIMe HaCHBORTJr0k5hrlq1akZvHroGjfo78OfGn36wUXYVSjmx/61SulAKVOrk/3ZHidkpY1 9RI89fIs6UmMEydQGQ+8vLVMechNiiindlBUti7XnFTQhGtveahXA42us4mWyw5kHlPn 8sAA== X-Gm-Message-State: AA+aEWb6cNpr4vTJ3twKsE9pkBoWOHMa44qw8tnJRfznZqh8slTCGcOz YWnu2yyfOQOO+hJU7J3GL5ve2bl7vSsFtOGB0Xs= X-Google-Smtp-Source: ALg8bN7GHMADHiPiO6Cvq0b8h9wPilQzjMfSTGFWmlBEPJDV0SeEsIlcjwpGxmA7/cSLRKOaFqhrFLUkYB7F+ZF3qVM= X-Received: by 2002:ac8:5314:: with SMTP id t20mr59279693qtn.328.1546880789483; Mon, 07 Jan 2019 09:06:29 -0800 (PST) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87tvio2i9l.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF8669E@GAALPA1MSGUSRBF.ITServices.sbc.com> <87k1jgwhlz.fsf@toke.dk> In-Reply-To: <87k1jgwhlz.fsf@toke.dk> From: Dave Taht Date: Mon, 7 Jan 2019 09:06:16 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: "STARK, BARBARA H" , Juliusz Chroboczek , Mahesh Jethanandani , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 17:06:33 -0000 On Mon, Jan 7, 2019 at 8:35 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > "STARK, BARBARA H" writes: > > > Toke said: "Bird uses an unencoded string..." > > I'm not sure what "unencoded" means here? But this sounds like > > maybe the entered string is a "passphrase" / PSK, like what's used for > > Wi-Fi, which is then used to derive the HMAC key using Unicode > > encoding? > > Nope, no derivation, just the raw ASCII bytes from the string used as an > HMAC key, zero-padded to the block size. Unless the supplied ASCII > string is longer than the block size, in which case it is hashed > first. ^^^^^^ ???? So you are saying an overlong key is transmuted into something else entirely, not truncated? > However, looking at the code again, this is actually controlled by the > protocol, so if we were to specify something different for Babel, that > would be doable as well... And I think agreeing on a mechanism would > probably be a good idea to ensure interoperability. yea! Maybe I'm old, but the WEP failure vs the WPA success came down in part to the human readability of the key. (I note that I'm actually unhappy we ended up with encrypted wifi itself, as it's bad for spectrum management etc, but not today) > > -Toke > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Mon Jan 7 11:11:50 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04884131006 for ; Mon, 7 Jan 2019 11:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9-n0x4VcWNw for ; Mon, 7 Jan 2019 11:11:46 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F1412426E for ; Mon, 7 Jan 2019 11:11:46 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1546888303; bh=phbuvLDKJ9u/1khEDECbCXGy1WjT6ExU2oxwSPRMZ7s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CzCs6PEfVG7EBvxZ94fsGanWWD3IXNJ5Wg1y8ouTk/WbKU1KPkFuIAi75HreM4etX ChEiz4U9IfQqFrXu3r61tHro4TZf/7RxoR+bb/RRTWmsypXKU8O/uYLhCBZP+1kyeq u39f7HbQ46XSWy0LlstqWoqs2SE/FG9a7qce6EcsaoK3qrI2w8dvuipAp2jp1tEKpl 4NcDgukZjr0RCRzwiegnlo5S8qEhxcB/QvI1/mpQPb+qWwui7q7Ll9kk6ysbmFcaq5 n4+lNm8mLAtUTdJ+fvOGK5Ht1awJfB7dgTOCMcGXcwLoKQvHScp0sp9X7oPmrQldah Vf73RdSJzEeDw== To: Dave Taht Cc: "STARK\, BARBARA H" , Juliusz Chroboczek , Mahesh Jethanandani , Babel at IETF In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87tvio2i9l.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF8669E@GAALPA1MSGUSRBF.ITServices.sbc.com> <87k1jgwhlz.fsf@toke.dk> Date: Mon, 07 Jan 2019 20:11:39 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87ef9owadw.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 19:11:49 -0000 Dave Taht writes: > On Mon, Jan 7, 2019 at 8:35 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >> "STARK, BARBARA H" writes: >> >> > Toke said: "Bird uses an unencoded string..." >> > I'm not sure what "unencoded" means here? But this sounds like >> > maybe the entered string is a "passphrase" / PSK, like what's used for >> > Wi-Fi, which is then used to derive the HMAC key using Unicode >> > encoding? >> >> Nope, no derivation, just the raw ASCII bytes from the string used as an >> HMAC key, zero-padded to the block size. Unless the supplied ASCII >> string is longer than the block size, in which case it is hashed >> first. > > ^^^^^^ ???? So you are saying an overlong key is transmuted into > something else entirely, not truncated? Yup, that would appear to be the case: https://gitlab.labs.nic.cz/labs/bird/blob/master/lib/mac.c#L105 -Toke From nobody Mon Jan 7 12:56:19 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B119126DBF for ; Mon, 7 Jan 2019 12:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWoz1B9ymxwA for ; Mon, 7 Jan 2019 12:56:14 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8545D124D68 for ; Mon, 7 Jan 2019 12:56:14 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id t13so697717ply.13 for ; Mon, 07 Jan 2019 12:56:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fPl/rZQw9w6jMfT13Wzu8fN10sV57RBNNY7xXrEfK5s=; b=oBS1Dz1MNa/1NCOyerfCTRwJTBjq/LlrCJ6oZ+pD1kjH8O7BBPw4eHy+fT3P6KYJkO EgiMDEQRCM0eAQ+IONoiC1Nn1eXRAqS92WG+aS+NFdWpPpor5QzItdyY6M3JKhPpD+Ui gF61XFWcWjeMCJ9eexcDV3ckecpvfaoXmu3tFZAtWidEOFKeX6GGv5Kf44SmS0NWH8A6 8T9kq5OtJgvjEp3pxRsn6Uc060g2hPnLMsB3C1R7MOjYqjGFtvdO8kri+TlL05whu3Bs /BrXMsBsNJnkXGccitbSKWFtxII84Oxfycj7zgdikbbdCmWzBk89UBOx+/qSX9kK2YU+ U4KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fPl/rZQw9w6jMfT13Wzu8fN10sV57RBNNY7xXrEfK5s=; b=j0GjmABsY8h3pUfabTYiev/QG1iW3dDesWO+8jDPAKV5VxGbkcJngoU/hoDMQBbFjN j/KffM27qNGgAKrw4nbyOXrzynm7Mb1vJJqjyOqcM/hY8CBrBJM2/JTNDgsodZ0guZ0r 3nshlsDGs6AKPrCtbFUrXG1R0JxkKtMfs5jc/+wn3FqsalD/yawxvFjoHn8cPrpZ+rOr wVX6RRw0OLBX2el6fKCTED5qL0uDxx4gOA6rlsmqPalCaYbSNiCeyhk+TNMAQC4Xfxl0 njIicAhnOpQ9x2hiFTLLIwRQsBdi2VylvatMFuSKDUlga/30D/Ydr9+3YW8rQwGyo4YJ rJkQ== X-Gm-Message-State: AJcUukefRaZ2vTAlGKT56upzEl0BjBk/NdfnRbtv17Zd5L5ZWk75ur/c BbGd3I9mFWb8TcGF7XkYLCQhtDijlSMkJbHdQ+U= X-Google-Smtp-Source: ALg8bN6zgotdKIeI1QNyPHhVKgJcLukqiCQuNggHhHxCbWQtyTvAgWmzqhx7osVsWN6ZMgIGKV+Qd4Zre7ufPQajDdM= X-Received: by 2002:a17:902:d01:: with SMTP id 1mr63548971plu.127.1546894573936; Mon, 07 Jan 2019 12:56:13 -0800 (PST) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DF82DC1@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF8360C@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: From: David Schinazi Date: Mon, 7 Jan 2019 12:56:02 -0800 Message-ID: To: Dave Taht Cc: "STARK, BARBARA H" , Babel at IETF Content-Type: multipart/alternative; boundary="00000000000095a397057ee4758a" Archived-At: Subject: Re: [babel] minor DTLS comment X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 20:56:17 -0000 --00000000000095a397057ee4758a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Barbara, how about this slightly more pedantic option? Babel over DTLS operates on a different port than unencrypted Babel. All Babel over DTLS nodes MUST act as DTLS servers on a DTLS port, and MUST listen for unencrypted Babel traffic on an unencrypted port, which MUST be distinct from the DTLS port. The default port for Babel over DTLS is registered with IANA as the "babel-dtls" port (UDP port TBD), and the unencrypted port is registered as the "babel" port (UDP port 6696). Nodes SHOULD use these default ports. https://github.com/jech/babel-drafts/commit/c90cc8204691254e7051405acf6a100= 88d42cdfd (Dave, running Babel over alternate transport protocols sounds like interesting future work outside the scope of this draft) Thanks, David On Fri, Jan 4, 2019 at 12:26 PM Dave Taht wrote: > On Fri, Jan 4, 2019 at 12:07 PM STARK, BARBARA H wrote: > > > > Hmm. > > > > " Babel over DTLS operates on a different port than unencrypted Babel. > > > > All Babel over DTLS nodes MUST act as DTLS servers on a configured port= , > and > > > > MUST listen for unencrypted Babel traffic on a distinct configured port= .=E2=80=9D > > > > > > > > An implementation doesn=E2=80=99t have to allow for configuration of po= rts. They > could just be hard-coded. > > > > I don=E2=80=99t like that I need the context of the first sentence to u= nderstand > unambiguously what the second port is =E2=80=9Cdistinct=E2=80=9D from (i.= e., distinct from > the unencrypted Babel port). > > > > > > > > How about just =E2=80=9C Babel over DTLS MUST operate on a different po= rt than > unencrypted Babel.=E2=80=9D ? > > > > Sure. > > (I had proposed at one point that the dtls version operate over > udp_lite or even dccp, on the same port number, but have since > discovered osx doesn't support either) > > > > Barbara > > > > > > > > From: David Schinazi > > Sent: Friday, January 04, 2019 2:41 PM > > To: STARK, BARBARA H > > Cc: Babel at IETF > > Subject: Re: [babel] minor DTLS comment > > > > > > > > Thanks for your comment, Barbara. I agree with you, and have added the > following text: > > > > > https://github.com/jech/babel-drafts/commit/a5a372a942ebc7951b2847d88123d= 75ab8169f2f > > > > > > > > Please let us know if you feel it addresses your comment. > > > > > > > > Thanks, > > > > David > > > > > > > > On Fri, Jan 4, 2019 at 5:35 AM STARK, BARBARA H wrote: > > > > Since the DTLS draft is still open for comments, I do have a small one > about how the UDP ports are characterized. > > The IANA assigned ports are default values, and need to be portrayed as > such. It's allowed (or should be) for deployed instances to use other > values. This is pretty much true of all protocols. Certainly the base bab= el > protocol allows other values to be used (which is why the homenet babel > profile mandated use of 6696). > > > > Maybe instead of > > All Babel over DTLS nodes MUST act as DTLS servers on the "babel- > > dtls" port (UDP port TBD), and MUST listen for traffic on the > > unencrypted "babel" port (UDP port 6696). > > > > say > > All Babel over DTLS nodes MUST act as DTLS servers on the "babel- > > dtls" port, and MUST listen for traffic on the > > unencrypted "babel" port. > > The IANA-assigned values of 6696 for the "babel" port and > > TBD for the "babel-dtls" port SHOULD be used. > > > > Barbara > > > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://www.ietf.org/mailman/listinfo/babel > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://www.ietf.org/mailman/listinfo/babel > > > > -- > > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 > --00000000000095a397057ee4758a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Barbara, how abou= t this slightly more pedantic option?

Babel over DTLS operates on a different port t= han unencrypted Babel.
All Babel over DTLS nodes MUST= act as DTLS servers on a DTLS port, and MUST
listen = for unencrypted Babel traffic on an unencrypted port, which MUST be
distinct from the DTLS port.=C2=A0 The default port for Babe= l over DTLS is
registered with IANA as the "babe= l-dtls" port (UDP port TBD), and the
unencrypted= port is registered as the "babel" port (UDP port 6696).
Nodes SHOULD use these default ports.

https://github.com/jech/babel-drafts/commit/c90cc82= 04691254e7051405acf6a10088d42cdfd

(Dave, r= unning Babel over alternate transport protocols sounds like interesting fut= ure work outside the scope of this draft)

Thanks,<= /div>
David

On Fri, Jan 4, 2019 at 12:26 PM Dave Taht <dave.taht@gmail.com> wrote:
On Fri, Jan 4, 2019 at 12:07 PM ST= ARK, BARBARA H <bs76= 52@att.com> wrote:
>
> Hmm.
>
> " Babel over DTLS operates on a different port than unencrypted B= abel.
>
> All Babel over DTLS nodes MUST act as DTLS servers on a configured por= t, and
>
> MUST listen for unencrypted Babel traffic on a distinct configured por= t.=E2=80=9D
>
>
>
> An implementation doesn=E2=80=99t have to allow for configuration of p= orts. They could just be hard-coded.
>
> I don=E2=80=99t like that I need the context of the first sentence to = understand unambiguously what the second port is =E2=80=9Cdistinct=E2=80=9D= from (i.e., distinct from the unencrypted Babel port).
>
>
>
> How about just =E2=80=9C Babel over DTLS MUST operate on a different p= ort than unencrypted Babel.=E2=80=9D ?
>

Sure.

(I had proposed at one point that the dtls version operate over
udp_lite or even dccp, on the same port number, but have since
discovered osx doesn't support either)
>
> Barbara
>
>
>
> From: David Schinazi <dschinazi.ietf@gmail.com>
> Sent: Friday, January 04, 2019 2:41 PM
> To: STARK, BARBARA H <bs7652@att.com>
> Cc: Babel at IETF <babel@ietf.org>
> Subject: Re: [babel] minor DTLS comment
>
>
>
> Thanks for your comment, Barbara. I agree with you, and have added the= following text:
>
> https://git= hub.com/jech/babel-drafts/commit/a5a372a942ebc7951b2847d88123d75ab8169f2f
>
>
>
> Please let us know if you feel it addresses your comment.
>
>
>
> Thanks,
>
> David
>
>
>
> On Fri, Jan 4, 2019 at 5:35 AM STARK, BARBARA H <bs7652@att.com> wrote:
>
> Since the DTLS draft is still open for comments, I do have a small one= about how the UDP ports are characterized.
> The IANA assigned ports are default values, and need to be portrayed a= s such. It's allowed (or should be) for deployed instances to use other= values. This is pretty much true of all protocols. Certainly the base babe= l protocol allows other values to be used (which is why the homenet babel p= rofile mandated use of 6696).
>
> Maybe instead of
>=C2=A0 =C2=A0 All Babel over DTLS nodes MUST act as DTLS servers on the= "babel-
>=C2=A0 =C2=A0 dtls" port (UDP port TBD), and MUST listen for traff= ic on the
>=C2=A0 =C2=A0 unencrypted "babel" port (UDP port 6696).
>
> say
>=C2=A0 =C2=A0 All Babel over DTLS nodes MUST act as DTLS servers on the= "babel-
>=C2=A0 =C2=A0 dtls" port, and MUST listen for traffic on the
>=C2=A0 =C2=A0 unencrypted "babel" port.
>=C2=A0 =C2=A0 The IANA-assigned values of 6696 for the "babel"= ; port and
>=C2=A0 =C2=A0 TBD for the "babel-dtls" port SHOULD be used. >
> Barbara
>
>
> _______________________________________________
> babel mailing list
> babel@ietf.org=
> https://www.ietf.org/mailman/listinfo/babel
>
> _______________________________________________
> babel mailing list
> babel@ietf.org=
> https://www.ietf.org/mailman/listinfo/babel



--

Dave T=C3=A4ht
CTO, TekLibre, LLC
ht= tp://www.teklibre.com
Tel: 1-831-205-9740
--00000000000095a397057ee4758a-- From nobody Mon Jan 7 12:58:02 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998B712D84C for ; Mon, 7 Jan 2019 12:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6ACuPtuWDdi for ; Mon, 7 Jan 2019 12:57:57 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7949B124D68 for ; Mon, 7 Jan 2019 12:57:57 -0800 (PST) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id x07Ktpb8014154; Mon, 7 Jan 2019 15:57:57 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2pve0j8fvk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Jan 2019 15:57:56 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x07Kvskh029488; Mon, 7 Jan 2019 15:57:55 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x07Kvn3s029384; Mon, 7 Jan 2019 15:57:49 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 4829D4048C2F; Mon, 7 Jan 2019 20:57:49 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30485.vci.att.com (Service) with ESMTPS id 31A284048C1E; Mon, 7 Jan 2019 20:57:49 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0415.000; Mon, 7 Jan 2019 15:57:49 -0500 From: "STARK, BARBARA H" To: "'David Schinazi'" , Dave Taht CC: Babel at IETF Thread-Topic: [babel] minor DTLS comment Thread-Index: AdSkL1vol8xv1+2PTJSCJUACYAMkywAX+64AAAnjvdD//72TAIAEv1cAgABTWtA= Date: Mon, 7 Jan 2019 20:57:48 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF86D80@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF82DC1@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF8360C@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.202.237] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114DF86D80GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-07_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901070173 Archived-At: Subject: Re: [babel] minor DTLS comment X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 20:58:01 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114DF86D80GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V0ZNDQpCYXJiYXJhDQoNCkZyb206IGJhYmVsIDxiYWJlbC1ib3VuY2VzQGlldGYub3JnPiBPbiBC ZWhhbGYgT2YgRGF2aWQgU2NoaW5hemkNClNlbnQ6IE1vbmRheSwgSmFudWFyeSAwNywgMjAxOSAz OjU2IFBNDQpUbzogRGF2ZSBUYWh0IDxkYXZlLnRhaHRAZ21haWwuY29tPg0KQ2M6IFNUQVJLLCBC QVJCQVJBIEggPGJzNzY1MkBhdHQuY29tPjsgQmFiZWwgYXQgSUVURiA8YmFiZWxAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW2JhYmVsXSBtaW5vciBEVExTIGNvbW1lbnQNCg0KVGhhbmtzIEJhcmJh cmEsIGhvdyBhYm91dCB0aGlzIHNsaWdodGx5IG1vcmUgcGVkYW50aWMgb3B0aW9uPw0KDQpCYWJl bCBvdmVyIERUTFMgb3BlcmF0ZXMgb24gYSBkaWZmZXJlbnQgcG9ydCB0aGFuIHVuZW5jcnlwdGVk IEJhYmVsLg0KQWxsIEJhYmVsIG92ZXIgRFRMUyBub2RlcyBNVVNUIGFjdCBhcyBEVExTIHNlcnZl cnMgb24gYSBEVExTIHBvcnQsIGFuZCBNVVNUDQpsaXN0ZW4gZm9yIHVuZW5jcnlwdGVkIEJhYmVs IHRyYWZmaWMgb24gYW4gdW5lbmNyeXB0ZWQgcG9ydCwgd2hpY2ggTVVTVCBiZQ0KZGlzdGluY3Qg ZnJvbSB0aGUgRFRMUyBwb3J0LiAgVGhlIGRlZmF1bHQgcG9ydCBmb3IgQmFiZWwgb3ZlciBEVExT IGlzDQpyZWdpc3RlcmVkIHdpdGggSUFOQSBhcyB0aGUgImJhYmVsLWR0bHMiIHBvcnQgKFVEUCBw b3J0IFRCRCksIGFuZCB0aGUNCnVuZW5jcnlwdGVkIHBvcnQgaXMgcmVnaXN0ZXJlZCBhcyB0aGUg ImJhYmVsIiBwb3J0IChVRFAgcG9ydCA2Njk2KS4NCk5vZGVzIFNIT1VMRCB1c2UgdGhlc2UgZGVm YXVsdCBwb3J0cy4NCg0KaHR0cHM6Ly9naXRodWIuY29tL2plY2gvYmFiZWwtZHJhZnRzL2NvbW1p dC9jOTBjYzgyMDQ2OTEyNTRlNzA1MTQwNWFjZjZhMTAwODhkNDJjZGZkPGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9qZWNoX2Jh YmVsLTJEZHJhZnRzX2NvbW1pdF9jOTBjYzgyMDQ2OTEyNTRlNzA1MTQwNWFjZjZhMTAwODhkNDJj ZGZkJmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy04c2M4U1k4VHE0 dnJmb2cmbT1UcEhTd3NkVzI5MnhublQ5Q0Zoa1pGd2JQUDVRajhXTTNDcDlOWlZreU5RJnM9ZG1C OXdEekZuamZ3TG1rSHEtNHhtTWJEMUh5UWtiZDB2eU1KTi1SMmFwMCZlPT4NCg0KKERhdmUsIHJ1 bm5pbmcgQmFiZWwgb3ZlciBhbHRlcm5hdGUgdHJhbnNwb3J0IHByb3RvY29scyBzb3VuZHMgbGlr ZSBpbnRlcmVzdGluZyBmdXR1cmUgd29yayBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRyYWZ0 KQ0KDQpUaGFua3MsDQpEYXZpZA0KDQpPbiBGcmksIEphbiA0LCAyMDE5IGF0IDEyOjI2IFBNIERh dmUgVGFodCA8ZGF2ZS50YWh0QGdtYWlsLmNvbTxtYWlsdG86ZGF2ZS50YWh0QGdtYWlsLmNvbT4+ IHdyb3RlOg0KT24gRnJpLCBKYW4gNCwgMjAxOSBhdCAxMjowNyBQTSBTVEFSSywgQkFSQkFSQSBI IDxiczc2NTJAYXR0LmNvbTxtYWlsdG86YnM3NjUyQGF0dC5jb20+PiB3cm90ZToNCj4NCj4gSG1t Lg0KPg0KPiAiIEJhYmVsIG92ZXIgRFRMUyBvcGVyYXRlcyBvbiBhIGRpZmZlcmVudCBwb3J0IHRo YW4gdW5lbmNyeXB0ZWQgQmFiZWwuDQo+DQo+IEFsbCBCYWJlbCBvdmVyIERUTFMgbm9kZXMgTVVT VCBhY3QgYXMgRFRMUyBzZXJ2ZXJzIG9uIGEgY29uZmlndXJlZCBwb3J0LCBhbmQNCj4NCj4gTVVT VCBsaXN0ZW4gZm9yIHVuZW5jcnlwdGVkIEJhYmVsIHRyYWZmaWMgb24gYSBkaXN0aW5jdCBjb25m aWd1cmVkIHBvcnQu4oCdDQo+DQo+DQo+DQo+IEFuIGltcGxlbWVudGF0aW9uIGRvZXNu4oCZdCBo YXZlIHRvIGFsbG93IGZvciBjb25maWd1cmF0aW9uIG9mIHBvcnRzLiBUaGV5IGNvdWxkIGp1c3Qg YmUgaGFyZC1jb2RlZC4NCj4NCj4gSSBkb27igJl0IGxpa2UgdGhhdCBJIG5lZWQgdGhlIGNvbnRl eHQgb2YgdGhlIGZpcnN0IHNlbnRlbmNlIHRvIHVuZGVyc3RhbmQgdW5hbWJpZ3VvdXNseSB3aGF0 IHRoZSBzZWNvbmQgcG9ydCBpcyDigJxkaXN0aW5jdOKAnSBmcm9tIChpLmUuLCBkaXN0aW5jdCBm cm9tIHRoZSB1bmVuY3J5cHRlZCBCYWJlbCBwb3J0KS4NCj4NCj4NCj4NCj4gSG93IGFib3V0IGp1 c3Qg4oCcIEJhYmVsIG92ZXIgRFRMUyBNVVNUIG9wZXJhdGUgb24gYSBkaWZmZXJlbnQgcG9ydCB0 aGFuIHVuZW5jcnlwdGVkIEJhYmVsLuKAnSA/DQo+DQoNClN1cmUuDQoNCihJIGhhZCBwcm9wb3Nl ZCBhdCBvbmUgcG9pbnQgdGhhdCB0aGUgZHRscyB2ZXJzaW9uIG9wZXJhdGUgb3Zlcg0KdWRwX2xp dGUgb3IgZXZlbiBkY2NwLCBvbiB0aGUgc2FtZSBwb3J0IG51bWJlciwgYnV0IGhhdmUgc2luY2UN CmRpc2NvdmVyZWQgb3N4IGRvZXNuJ3Qgc3VwcG9ydCBlaXRoZXIpDQo+DQo+IEJhcmJhcmENCj4N Cj4NCj4NCj4gRnJvbTogRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbTxt YWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tPj4NCj4gU2VudDogRnJpZGF5LCBKYW51YXJ5 IDA0LCAyMDE5IDI6NDEgUE0NCj4gVG86IFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQuY29t PG1haWx0bzpiczc2NTJAYXR0LmNvbT4+DQo+IENjOiBCYWJlbCBhdCBJRVRGIDxiYWJlbEBpZXRm Lm9yZzxtYWlsdG86YmFiZWxAaWV0Zi5vcmc+Pg0KPiBTdWJqZWN0OiBSZTogW2JhYmVsXSBtaW5v ciBEVExTIGNvbW1lbnQNCj4NCj4NCj4NCj4gVGhhbmtzIGZvciB5b3VyIGNvbW1lbnQsIEJhcmJh cmEuIEkgYWdyZWUgd2l0aCB5b3UsIGFuZCBoYXZlIGFkZGVkIHRoZSBmb2xsb3dpbmcgdGV4dDoN Cj4NCj4gaHR0cHM6Ly9naXRodWIuY29tL2plY2gvYmFiZWwtZHJhZnRzL2NvbW1pdC9hNWEzNzJh OTQyZWJjNzk1MWIyODQ3ZDg4MTIzZDc1YWI4MTY5ZjJmPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9qZWNoX2JhYmVsLTJEZHJh ZnRzX2NvbW1pdF9hNWEzNzJhOTQyZWJjNzk1MWIyODQ3ZDg4MTIzZDc1YWI4MTY5ZjJmJmQ9RHdN RmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmbT1U cEhTd3NkVzI5MnhublQ5Q0Zoa1pGd2JQUDVRajhXTTNDcDlOWlZreU5RJnM9UDFVLXR0N09FZC1R Q21SdWR1M0JEa1NBN19mWU5EUW44Q3ZpTHF5TWp1QSZlPT4NCj4NCj4NCj4NCj4gUGxlYXNlIGxl dCB1cyBrbm93IGlmIHlvdSBmZWVsIGl0IGFkZHJlc3NlcyB5b3VyIGNvbW1lbnQuDQo+DQo+DQo+ DQo+IFRoYW5rcywNCj4NCj4gRGF2aWQNCj4NCj4NCj4NCj4gT24gRnJpLCBKYW4gNCwgMjAxOSBh dCA1OjM1IEFNIFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQuY29tPG1haWx0bzpiczc2NTJA YXR0LmNvbT4+IHdyb3RlOg0KPg0KPiBTaW5jZSB0aGUgRFRMUyBkcmFmdCBpcyBzdGlsbCBvcGVu IGZvciBjb21tZW50cywgSSBkbyBoYXZlIGEgc21hbGwgb25lIGFib3V0IGhvdyB0aGUgVURQIHBv cnRzIGFyZSBjaGFyYWN0ZXJpemVkLg0KPiBUaGUgSUFOQSBhc3NpZ25lZCBwb3J0cyBhcmUgZGVm YXVsdCB2YWx1ZXMsIGFuZCBuZWVkIHRvIGJlIHBvcnRyYXllZCBhcyBzdWNoLiBJdCdzIGFsbG93 ZWQgKG9yIHNob3VsZCBiZSkgZm9yIGRlcGxveWVkIGluc3RhbmNlcyB0byB1c2Ugb3RoZXIgdmFs dWVzLiBUaGlzIGlzIHByZXR0eSBtdWNoIHRydWUgb2YgYWxsIHByb3RvY29scy4gQ2VydGFpbmx5 IHRoZSBiYXNlIGJhYmVsIHByb3RvY29sIGFsbG93cyBvdGhlciB2YWx1ZXMgdG8gYmUgdXNlZCAo d2hpY2ggaXMgd2h5IHRoZSBob21lbmV0IGJhYmVsIHByb2ZpbGUgbWFuZGF0ZWQgdXNlIG9mIDY2 OTYpLg0KPg0KPiBNYXliZSBpbnN0ZWFkIG9mDQo+ICAgIEFsbCBCYWJlbCBvdmVyIERUTFMgbm9k ZXMgTVVTVCBhY3QgYXMgRFRMUyBzZXJ2ZXJzIG9uIHRoZSAiYmFiZWwtDQo+ICAgIGR0bHMiIHBv cnQgKFVEUCBwb3J0IFRCRCksIGFuZCBNVVNUIGxpc3RlbiBmb3IgdHJhZmZpYyBvbiB0aGUNCj4g ICAgdW5lbmNyeXB0ZWQgImJhYmVsIiBwb3J0IChVRFAgcG9ydCA2Njk2KS4NCj4NCj4gc2F5DQo+ ICAgIEFsbCBCYWJlbCBvdmVyIERUTFMgbm9kZXMgTVVTVCBhY3QgYXMgRFRMUyBzZXJ2ZXJzIG9u IHRoZSAiYmFiZWwtDQo+ICAgIGR0bHMiIHBvcnQsIGFuZCBNVVNUIGxpc3RlbiBmb3IgdHJhZmZp YyBvbiB0aGUNCj4gICAgdW5lbmNyeXB0ZWQgImJhYmVsIiBwb3J0Lg0KPiAgICBUaGUgSUFOQS1h c3NpZ25lZCB2YWx1ZXMgb2YgNjY5NiBmb3IgdGhlICJiYWJlbCIgcG9ydCBhbmQNCj4gICAgVEJE IGZvciB0aGUgImJhYmVsLWR0bHMiIHBvcnQgU0hPVUxEIGJlIHVzZWQuDQo+DQo+IEJhcmJhcmEN Cj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gYmFiZWwgbWFpbGluZyBsaXN0DQo+IGJhYmVsQGlldGYub3JnPG1haWx0bzpiYWJlbEBpZXRm Lm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iYWJlbDxodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX2JhYmVsJmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWlj dmpJZyZyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmbT1UcEhTd3NkVzI5MnhublQ5Q0Zoa1pGd2JQ UDVRajhXTTNDcDlOWlZreU5RJnM9TEYtTzNrdld5YXVqRVVDSlNpSkhBRjJINWtNMkZoUE54QWNm NTlKNzRGdyZlPT4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gYmFiZWwgbWFpbGluZyBsaXN0DQo+IGJhYmVsQGlldGYub3JnPG1haWx0bzpi YWJlbEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9i YWJlbDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2JhYmVsJmQ9RHdNRmFRJmM9TEZZWi1vOV9I VU1lTVRTUWljdmpJZyZyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmbT1UcEhTd3NkVzI5MnhublQ5 Q0Zoa1pGd2JQUDVRajhXTTNDcDlOWlZreU5RJnM9TEYtTzNrdld5YXVqRVVDSlNpSkhBRjJINWtN MkZoUE54QWNmNTlKNzRGdyZlPT4NCg0KDQoNCi0tDQoNCkRhdmUgVMOkaHQNCkNUTywgVGVrTGli cmUsIExMQw0KaHR0cDovL3d3dy50ZWtsaWJyZS5jb208aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy50ZWtsaWJyZS5jb20mZD1Ed01GYVEmYz1M RllaLW85X0hVTWVNVFNRaWN2aklnJnI9TG9HemhDLThzYzhTWThUcTR2cmZvZyZtPVRwSFN3c2RX MjkyeG5uVDlDRmhrWkZ3YlBQNVFqOFdNM0NwOU5aVmt5TlEmcz1lRE8wOEE3WjFKWFlXYlFhNzct V2FoWDV5RGVWX1FPWHQzZ0RVVjJiZkNRJmU9Pg0KVGVsOiAxLTgzMS0yMDUtOTc0MA0K --_000_2D09D61DDFA73D4C884805CC7865E6114DF86D80GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X Rk08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhcmJhcmE8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gYmFiZWwgJmx0O2JhYmVsLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpEYXZpZCBTY2hpbmF6aTxicj4NCjxiPlNl bnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMDcsIDIwMTkgMzo1NiBQTTxicj4NCjxiPlRvOjwvYj4g RGF2ZSBUYWh0ICZsdDtkYXZlLnRhaHRAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gU1RB UkssIEJBUkJBUkEgSCAmbHQ7YnM3NjUyQGF0dC5jb20mZ3Q7OyBCYWJlbCBhdCBJRVRGICZsdDti YWJlbEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtiYWJlbF0gbWlub3Ig RFRMUyBjb21tZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgQmFyYmFyYSwgaG93IGFib3V0IHRoaXMgc2xpZ2h0bHkg bW9yZSBwZWRhbnRpYyBvcHRpb24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYWJlbCBvdmVyIERUTFMgb3BlcmF0ZXMgb24gYSBk aWZmZXJlbnQgcG9ydCB0aGFuIHVuZW5jcnlwdGVkIEJhYmVsLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsIEJhYmVsIG92ZXIgRFRMUyBub2Rl cyBNVVNUIGFjdCBhcyBEVExTIHNlcnZlcnMgb24gYSBEVExTIHBvcnQsIGFuZCBNVVNUPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5saXN0ZW4gZm9y IHVuZW5jcnlwdGVkIEJhYmVsIHRyYWZmaWMgb24gYW4gdW5lbmNyeXB0ZWQgcG9ydCwgd2hpY2gg TVVTVCBiZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+ZGlzdGluY3QgZnJvbSB0aGUgRFRMUyBwb3J0LiZuYnNwOyBUaGUgZGVmYXVsdCBwb3J0IGZv ciBCYWJlbCBvdmVyIERUTFMgaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnJlZ2lzdGVyZWQgd2l0aCBJQU5BIGFzIHRoZSAmcXVvdDtiYWJlbC1k dGxzJnF1b3Q7IHBvcnQgKFVEUCBwb3J0IFRCRCksIGFuZCB0aGU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnVuZW5jcnlwdGVkIHBvcnQgaXMgcmVn aXN0ZXJlZCBhcyB0aGUgJnF1b3Q7YmFiZWwmcXVvdDsgcG9ydCAoVURQIHBvcnQgNjY5NikuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob2RlcyBT SE9VTEQgdXNlIHRoZXNlIGRlZmF1bHQgcG9ydHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9qZWNoX2JhYmVsLTJE ZHJhZnRzX2NvbW1pdF9jOTBjYzgyMDQ2OTEyNTRlNzA1MTQwNWFjZjZhMTAwODhkNDJjZGZkJmFt cDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPUxvR3poQy04c2M4 U1k4VHE0dnJmb2cmYW1wO209VHBIU3dzZFcyOTJ4bm5UOUNGaGtaRndiUFA1UWo4V00zQ3A5TlpW a3lOUSZhbXA7cz1kbUI5d0R6Rm5qZndMbWtIcS00eG1NYkQxSHlRa2JkMHZ5TUpOLVIyYXAwJmFt cDtlPSI+aHR0cHM6Ly9naXRodWIuY29tL2plY2gvYmFiZWwtZHJhZnRzL2NvbW1pdC9jOTBjYzgy MDQ2OTEyNTRlNzA1MTQwNWFjZjZhMTAwODhkNDJjZGZkPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oRGF2ZSwgcnVubmluZyBCYWJlbCBv dmVyIGFsdGVybmF0ZSB0cmFuc3BvcnQgcHJvdG9jb2xzIHNvdW5kcyBsaWtlIGludGVyZXN0aW5n IGZ1dHVyZSB3b3JrIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQpPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBGcmksIEphbiA0LCAyMDE5IGF0IDEyOjI2IFBNIERhdmUgVGFodCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRhdmUudGFodEBnbWFpbC5jb20iPmRhdmUudGFodEBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDQsIDIwMTkgYXQgMTI6MDcgUE0gU1RBUkssIEJBUkJB UkEgSCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJzNzY1MkBhdHQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YnM3NjUyQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIbW0uPGJy Pg0KJmd0Ozxicj4NCiZndDsgJnF1b3Q7IEJhYmVsIG92ZXIgRFRMUyBvcGVyYXRlcyBvbiBhIGRp ZmZlcmVudCBwb3J0IHRoYW4gdW5lbmNyeXB0ZWQgQmFiZWwuPGJyPg0KJmd0Ozxicj4NCiZndDsg QWxsIEJhYmVsIG92ZXIgRFRMUyBub2RlcyBNVVNUIGFjdCBhcyBEVExTIHNlcnZlcnMgb24gYSBj b25maWd1cmVkIHBvcnQsIGFuZDxicj4NCiZndDs8YnI+DQomZ3Q7IE1VU1QgbGlzdGVuIGZvciB1 bmVuY3J5cHRlZCBCYWJlbCB0cmFmZmljIG9uIGEgZGlzdGluY3QgY29uZmlndXJlZCBwb3J0LuKA nTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQW4gaW1wbGVtZW50YXRp b24gZG9lc27igJl0IGhhdmUgdG8gYWxsb3cgZm9yIGNvbmZpZ3VyYXRpb24gb2YgcG9ydHMuIFRo ZXkgY291bGQganVzdCBiZSBoYXJkLWNvZGVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgZG9u4oCZ dCBsaWtlIHRoYXQgSSBuZWVkIHRoZSBjb250ZXh0IG9mIHRoZSBmaXJzdCBzZW50ZW5jZSB0byB1 bmRlcnN0YW5kIHVuYW1iaWd1b3VzbHkgd2hhdCB0aGUgc2Vjb25kIHBvcnQgaXMg4oCcZGlzdGlu Y3TigJ0gZnJvbSAoaS5lLiwgZGlzdGluY3QgZnJvbSB0aGUgdW5lbmNyeXB0ZWQgQmFiZWwgcG9y dCkuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIb3cgYWJvdXQganVz dCDigJwgQmFiZWwgb3ZlciBEVExTIE1VU1Qgb3BlcmF0ZSBvbiBhIGRpZmZlcmVudCBwb3J0IHRo YW4gdW5lbmNyeXB0ZWQgQmFiZWwu4oCdID88YnI+DQomZ3Q7PGJyPg0KPGJyPg0KU3VyZS48YnI+ DQo8YnI+DQooSSBoYWQgcHJvcG9zZWQgYXQgb25lIHBvaW50IHRoYXQgdGhlIGR0bHMgdmVyc2lv biBvcGVyYXRlIG92ZXI8YnI+DQp1ZHBfbGl0ZSBvciBldmVuIGRjY3AsIG9uIHRoZSBzYW1lIHBv cnQgbnVtYmVyLCBidXQgaGF2ZSBzaW5jZTxicj4NCmRpc2NvdmVyZWQgb3N4IGRvZXNuJ3Qgc3Vw cG9ydCBlaXRoZXIpPGJyPg0KJmd0Ozxicj4NCiZndDsgQmFyYmFyYTxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgRnJvbTogRGF2aWQgU2NoaW5hemkgJmx0OzxhIGhyZWY9 Im1haWx0bzpkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kc2NoaW5h emkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCiZndDsgU2VudDogRnJpZGF5LCBKYW51YXJ5 IDA0LCAyMDE5IDI6NDEgUE08YnI+DQomZ3Q7IFRvOiBTVEFSSywgQkFSQkFSQSBIICZsdDs8YSBo cmVmPSJtYWlsdG86YnM3NjUyQGF0dC5jb20iIHRhcmdldD0iX2JsYW5rIj5iczc2NTJAYXR0LmNv bTwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzogQmFiZWwgYXQgSUVURiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmJhYmVsQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YmFiZWxAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCiZndDsgU3ViamVjdDogUmU6IFtiYWJlbF0gbWlub3IgRFRMUyBjb21tZW50PGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MgZm9yIHlvdXIgY29tbWVudCwg QmFyYmFyYS4gSSBhZ3JlZSB3aXRoIHlvdSwgYW5kIGhhdmUgYWRkZWQgdGhlIGZvbGxvd2luZyB0 ZXh0Ojxicj4NCiZndDs8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9qZWNoX2JhYmVsLTJEZHJh ZnRzX2NvbW1pdF9hNWEzNzJhOTQyZWJjNzk1MWIyODQ3ZDg4MTIzZDc1YWI4MTY5ZjJmJmFtcDtk PUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPUxvR3poQy04c2M4U1k4 VHE0dnJmb2cmYW1wO209VHBIU3dzZFcyOTJ4bm5UOUNGaGtaRndiUFA1UWo4V00zQ3A5TlpWa3lO USZhbXA7cz1QMVUtdHQ3T0VkLVFDbVJ1ZHUzQkRrU0E3X2ZZTkRRbjhDdmlMcXlNanVBJmFtcDtl PSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9naXRodWIuY29tL2plY2gvYmFiZWwtZHJhZnRz L2NvbW1pdC9hNWEzNzJhOTQyZWJjNzk1MWIyODQ3ZDg4MTIzZDc1YWI4MTY5ZjJmPC9hPjxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgUGxlYXNlIGxldCB1cyBrbm93IGlm IHlvdSBmZWVsIGl0IGFkZHJlc3NlcyB5b3VyIGNvbW1lbnQuPGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MsPGJyPg0KJmd0Ozxicj4NCiZndDsgRGF2aWQ8YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIEZyaSwgSmFuIDQsIDIwMTkg YXQgNTozNSBBTSBTVEFSSywgQkFSQkFSQSBIICZsdDs8YSBocmVmPSJtYWlsdG86YnM3NjUyQGF0 dC5jb20iIHRhcmdldD0iX2JsYW5rIj5iczc2NTJAYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4N CiZndDs8YnI+DQomZ3Q7IFNpbmNlIHRoZSBEVExTIGRyYWZ0IGlzIHN0aWxsIG9wZW4gZm9yIGNv bW1lbnRzLCBJIGRvIGhhdmUgYSBzbWFsbCBvbmUgYWJvdXQgaG93IHRoZSBVRFAgcG9ydHMgYXJl IGNoYXJhY3Rlcml6ZWQuPGJyPg0KJmd0OyBUaGUgSUFOQSBhc3NpZ25lZCBwb3J0cyBhcmUgZGVm YXVsdCB2YWx1ZXMsIGFuZCBuZWVkIHRvIGJlIHBvcnRyYXllZCBhcyBzdWNoLiBJdCdzIGFsbG93 ZWQgKG9yIHNob3VsZCBiZSkgZm9yIGRlcGxveWVkIGluc3RhbmNlcyB0byB1c2Ugb3RoZXIgdmFs dWVzLiBUaGlzIGlzIHByZXR0eSBtdWNoIHRydWUgb2YgYWxsIHByb3RvY29scy4gQ2VydGFpbmx5 IHRoZSBiYXNlIGJhYmVsIHByb3RvY29sIGFsbG93cyBvdGhlciB2YWx1ZXMgdG8gYmUgdXNlZA0K ICh3aGljaCBpcyB3aHkgdGhlIGhvbWVuZXQgYmFiZWwgcHJvZmlsZSBtYW5kYXRlZCB1c2Ugb2Yg NjY5NikuPGJyPg0KJmd0Ozxicj4NCiZndDsgTWF5YmUgaW5zdGVhZCBvZjxicj4NCiZndDsmbmJz cDsgJm5ic3A7IEFsbCBCYWJlbCBvdmVyIERUTFMgbm9kZXMgTVVTVCBhY3QgYXMgRFRMUyBzZXJ2 ZXJzIG9uIHRoZSAmcXVvdDtiYWJlbC08YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBkdGxzJnF1b3Q7 IHBvcnQgKFVEUCBwb3J0IFRCRCksIGFuZCBNVVNUIGxpc3RlbiBmb3IgdHJhZmZpYyBvbiB0aGU8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB1bmVuY3J5cHRlZCAmcXVvdDtiYWJlbCZxdW90OyBwb3J0 IChVRFAgcG9ydCA2Njk2KS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBzYXk8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyBBbGwgQmFiZWwgb3ZlciBEVExTIG5vZGVzIE1VU1QgYWN0IGFzIERUTFMgc2VydmVy cyBvbiB0aGUgJnF1b3Q7YmFiZWwtPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgZHRscyZxdW90OyBw b3J0LCBhbmQgTVVTVCBsaXN0ZW4gZm9yIHRyYWZmaWMgb24gdGhlPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgdW5lbmNyeXB0ZWQgJnF1b3Q7YmFiZWwmcXVvdDsgcG9ydC48YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyBUaGUgSUFOQS1hc3NpZ25lZCB2YWx1ZXMgb2YgNjY5NiBmb3IgdGhlICZxdW90O2Jh YmVsJnF1b3Q7IHBvcnQgYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgVEJEIGZvciB0aGUgJnF1 b3Q7YmFiZWwtZHRscyZxdW90OyBwb3J0IFNIT1VMRCBiZSB1c2VkLjxicj4NCiZndDs8YnI+DQom Z3Q7IEJhcmJhcmE8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGJhYmVsIG1haWxpbmcg bGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmJhYmVsQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+YmFiZWxAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2JhYmVsJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2 aklnJmFtcDtyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmYW1wO209VHBIU3dzZFcyOTJ4bm5UOUNG aGtaRndiUFA1UWo4V00zQ3A5TlpWa3lOUSZhbXA7cz1MRi1PM2t2V3lhdWpFVUNKU2lKSEFGMkg1 a00yRmhQTnhBY2Y1OUo3NEZ3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iYWJlbDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg YmFiZWwgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86YmFiZWxAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5iYWJlbEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fYmFiZWwmYW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVot bzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9TG9HemhDLThzYzhTWThUcTR2cmZvZyZhbXA7bT1UcEhT d3NkVzI5MnhublQ5Q0Zoa1pGd2JQUDVRajhXTTNDcDlOWlZreU5RJmFtcDtzPUxGLU8za3ZXeWF1 akVVQ0pTaUpIQUYySDVrTTJGaFBOeEFjZjU5Sjc0RncmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JhYmVsPC9hPjxicj4NCjxi cj4NCjxicj4NCjxicj4NCi0tIDxicj4NCjxicj4NCkRhdmUgVMOkaHQ8YnI+DQpDVE8sIFRla0xp YnJlLCBMTEM8YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cC0zQV9fd3d3LnRla2xpYnJlLmNvbSZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZ Wi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1Mb0d6aEMtOHNjOFNZOFRxNHZyZm9nJmFtcDttPVRw SFN3c2RXMjkyeG5uVDlDRmhrWkZ3YlBQNVFqOFdNM0NwOU5aVmt5TlEmYW1wO3M9ZURPMDhBN1ox SlhZV2JRYTc3LVdhaFg1eURlVl9RT1h0M2dEVVYyYmZDUSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vd3d3LnRla2xpYnJlLmNvbTwvYT48YnI+DQpUZWw6IDEtODMxLTIwNS05NzQwPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_2D09D61DDFA73D4C884805CC7865E6114DF86D80GAALPA1MSGUSRBF_-- From nobody Mon Jan 7 13:19:18 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3109412D4F0; Mon, 7 Jan 2019 13:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3902ek7hzEN; Mon, 7 Jan 2019 13:19:14 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA54312D7EA; Mon, 7 Jan 2019 13:19:14 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id p8so751544plo.2; Mon, 07 Jan 2019 13:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=euB53XSBz7PtzdcOqBzWS20+YqPNh68dp+mQynUVL/s=; b=kURiIUYdSTnG629ywf+m31B53RsQx/RTNYlABgtPtAFoQJY+JHadEo56Nw73WHVeYe wJnuY/TQj1l96kwBh1+itfvY/K9y/krNY26Pitd1Qy2Rkm07IO7fWNRxG5/PrNs2Rx7e 3tZ+9mT7GSBsl2LZTj/OS5CilQH9N7m0NUQQXaNTnaRde5yVhP+eicvB4wbzuMbgnmRH ZEgB0NmzrEEPA5mOw5XgtXJRz8ffIMT/KJDw+E5Zdfq/ojs7bWUS/MALSJrGdupaYitD ihGSvcDC1Udty2oqooPj7W+9NB9uauKUgtxiR8tEdgJkYMzijar6J6nuE8t14Ca0uldn d1CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=euB53XSBz7PtzdcOqBzWS20+YqPNh68dp+mQynUVL/s=; b=IuAna86muxUj/M/k2wivq1faYJpo93Nlb/Bia93wQm0w7r+V9sexmPsQnECe9uLaLj ZdD71r1+yobP2s9U0EFY9eQYGJb1xzl+4FRADIv/om9x9e1EWvxyvhQ5dC0sLu2UdOTE Ce7NlFE04IrYYszgrph3oFgGxnLSAJjSWU0nHiW2+scEvvitRFCzQwkbNnL4vLr9R2+/ 5lvK8dKlnghZMKfJhv7HV3WXrmP4S6asxHM6ZWss+UqpP18ee+hvZ063WWNUxQes0FSM E4W7sDRLgxQzRyhBnVjEbryZTWp/+Tx+jlRV6IUv5iZb5pkq7pMDehZQPDk+WQWoZ2iU pxdw== X-Gm-Message-State: AJcUukf7LZSRGuLfjoYAkWuLeZ3qC69D4vhpxYGhDPVwSEH1kvTfn8wF /8f73lexnSwbnWOMQ5yRgj86RalQZv9k5VI7KUM= X-Google-Smtp-Source: ALg8bN53Qqa8vukb/QYcECp7VvGW68CLj8b1H0+ME0Zi0fV0cAvbOvFkh+bRdzLcJFEBDuk4+1ri9iF9fjSAieHwltc= X-Received: by 2002:a17:902:bd86:: with SMTP id q6mr60964356pls.16.1546895954237; Mon, 07 Jan 2019 13:19:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Mon, 7 Jan 2019 13:19:03 -0800 Message-ID: To: Donald Eastlake Cc: Babel at IETF , draft-ietf-babel-dtls@ietf.org, babel-chairs Content-Type: multipart/alternative; boundary="000000000000db5f32057ee4c78f" Archived-At: Subject: Re: [babel] Shepherd's review of draft-ietf-babel-dtls-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 21:19:17 -0000 --000000000000db5f32057ee4c78f Content-Type: text/plain; charset="UTF-8" Thank you for your comments, Donald. I've addressed them in this commit: https://github.com/jech/babel-drafts/commit/9214e3fc8947d28c41f9f7cd761f107a185d2771 Please let us know what you think. We could publish the git version and restart the WGLC if you think we're ready. Thanks, David Detailed responses inline: On Sun, Jan 6, 2019 at 9:17 PM Donald Eastlake wrote: > Hi, > > Here are some comments on the draft: > > Abstract and Introduction: Replace "describes" with "specifies". > Done Section 2.1, top of page 4, says "When a node receives a new DTLS > connection, it MUST verify the source IP address, and reject the > connection if the address is not an IPv6 link-local address." Would it > be correct to replace this with "When a node receives a new DTLS > connection, it MUST verify that the source IP address is an IPv6 > link-local address; if it is not, it MUST reject the connection." or > is there some other sort of verification it must do? > Done. Your change was correct. > Last paragraph of Section 2.3: I'm not sure about "unprotected > implementation of Babel". Maybe "Babel implementation without DTLS > support". Done. > Also, the reference to replacing "TLV"s seems odd. Can't > there be multiple TLVs in a message? Maybe "replacing any multicast > Babel routing protocol message with unicast transmission of the > message to each known neighbor except that neighbor discovery Hello > TLVs MUST still be multicast." or something like that. > Not quite, since some TLVs such as IHU wouldn't contain the same contents sent unicast vs multicast. I've clarified the text. > IANA Considerations: As are probably aware, Section 8.1.1 of RFC 6335 > is about applying for port numbers (and service names, which would, as > you say, be "babel-dtls" in this case). A completed application > template could be included as an appendix, though that is not > necessary. > I was thinking of asking IANA for early codepoint assignment once the document has gone through WGLC. > Security Considerations, first sentence: Maybe "The interaction" -> > "Confidential interaction". > Done Security Considerations and rfc6126bis seem to say that Babel can run > over IPv4 but the last paragraph of Section 2.1 seems to be limited to > IPv6. > Good point, removed mention of IPv4 here. > I'm not sure why Performance Considerations is an Appendix rather than > a section of the main text. But I guess it's OK either way. > I think the idea was that these considerations are not normative so they were placed in an appendix to match the spirit of RFC6126. > Minor wording suggestions, adopt or ignore as you choose: > > Abstract and Introduction: in the first line, insert "base" before > "Babel Routing Protocol". > I personally find "base" odd, I'll let my co-authors comment. > Section 1.2: Delete "very". > Done. --000000000000db5f32057ee4c78f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your comme= nts, Donald. I've addressed them in this commit:

Please let us know what=C2=A0you think. We could publish the git = version and restart the WGLC if you think we're ready.

Thanks,
David

Detailed responses inline:

On Sun, Jan 6, 2019 at 9:17 = PM Donald Eastlake <d3e3e3@gmail.com= > wrote:
= Hi,

Here are some comments on the draft:

Abstract and Introduction: Replace "describes" with "specifi= es".

Done=C2=A0

Section 2.1, top of page 4, says "When a node receives a new DTLS
connection, it MUST verify the source IP address, and reject the
connection if the address is not an IPv6 link-local address." Would it=
be correct to replace this with "When a node receives a new DTLS
connection, it MUST verify that the source IP address is an IPv6
link-local address; if it is not, it MUST reject the connection." or is there some other sort of verification it must do?
<= br>
Done. Your change was correct.
=C2=A0
Last paragraph of Section 2.3: I'm not sure about "unprotected
implementation of Babel". Maybe "Babel implementation without DTL= S
support".

Done.
=C2=A0
=
Also, the reference to re= placing "TLV"s seems odd. Can't
there be multiple TLVs in a message? Maybe "replacing any multicast Babel routing protocol message with unicast transmission of the
message to each known neighbor except that neighbor discovery Hello
TLVs MUST still be multicast." or something like that.

Not quite, since some TLVs such as IHU wouldn't co= ntain the same contents sent unicast vs multicast. I've clarified the t= ext.
=C2=A0
Security Considerations, first sentence: Maybe "The interaction" = ->
"Confidential interaction".

D= one=C2=A0

Security Considerations and rfc6126bis seem to say that Babel can run
over IPv4 but the last paragraph of Section 2.1 seems to be limited to
IPv6.

Good point, removed mention of IP= v4 here.
=C2=A0
I'm not sure why Performance Considerations is an Appendix rather than<= br> a section of the main text. But I guess it's OK either way.

I think the idea was that these considerations are= not normative so they were placed in an appendix to match the spirit of RF= C6126.
=C2=A0
Minor wording suggestions, adopt or ignore as you choose:

Abstract and Introduction: in the first line, insert "base" befor= e
"Babel Routing Protocol".

I p= ersonally find "base" odd, I'll let my co-authors comment.
=C2=A0
Section 1.2: Delete "very".

D= one.
--000000000000db5f32057ee4c78f-- From nobody Mon Jan 7 13:43:40 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1043112D4F0 for ; Mon, 7 Jan 2019 13:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAA_qSqmPRIk for ; Mon, 7 Jan 2019 13:43:36 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD03A12D7EA for ; Mon, 7 Jan 2019 13:43:35 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id t33so2234549qtt.4 for ; Mon, 07 Jan 2019 13:43:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5F9QR09LZFySAUtGaWww1e6DaX1coLjVu8GSMY+5kA8=; b=YO3RZ2vc1CKSyEbHHAg3Zp5KYSgtudqaAmFe855NXeeDuSGJIi5niOvWG+udRC1tJk dYJxBL3UsWXbLy6YpvH4X2RE823Lh3xjPO82heoageRD+YRXERoZ7y7Jv5C/6MhlJ9+D 1hQmXk4P88cQrPjzP9w5ABRHpy0LrrrP11Lx5ZK9bi/A11sxMUfS/QljFXbZTM73UrRT pFgovpju6VQkER5KaIXtCawSJn6kwt4xr/Km0WZ2m+jMM87UDggJyPGp+PIU1blrS7ZP 6ltypw3yNeCUp+4rsL8TSswLoq9ZgTtys52ptky16YnUytPTf24US3CU8t8gVx2i0wR0 +2EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5F9QR09LZFySAUtGaWww1e6DaX1coLjVu8GSMY+5kA8=; b=lkLhqZ/Y7H0yfYT5UMYhSeMNVEwTCsSVWZmG0lgJBoNJahpD/YLD2l6xBjoO72ea1X Hic5a1PmjolJ3Yfso/lA9iW9rdt+eHyjk8NnamUjaHzCQTbTx/S6QcphFid/e6b1AHZj NksqERcIQhAomEXKe3OcftKU1f6NosWS8Mui7TGf6WJha0edqnlppaL+HdVLAS/zEQMI BJIw2ITAPLRJ1KHvnbTiuygYcoyqUEZVOk5UDKB+m4yn2ncukvaxXK3mZpwv44/F0zN8 beeozdMSCyf/BPtk3JfgGa5QC2lp8FyakPw9rtIGdYNid7Z6zxxb6SwErvI+Lg2RY4Mq 4wBg== X-Gm-Message-State: AJcUuke4obm3CmwMyDHuyBLhLSt/WhqeIfkv1uVakl7DynT4rS5M+Ry7 q8yzhBRLz5vwHDR7VuaNqHUqrFsdHGcATV91YCk= X-Google-Smtp-Source: ALg8bN7mCZAu/uO5C+QO3akFOA3IVRPzQHubKt3Nf5NuzhpIOaxh1QPF7Yxdlylv3TWSnR9O9KyJjguqeehTzbymH0k= X-Received: by 2002:a0c:aa56:: with SMTP id e22mr63748868qvb.158.1546897414815; Mon, 07 Jan 2019 13:43:34 -0800 (PST) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DF82DC1@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF8360C@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: From: Dave Taht Date: Mon, 7 Jan 2019 13:43:22 -0800 Message-ID: To: David Schinazi Cc: "STARK, BARBARA H" , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] minor DTLS comment X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 21:43:38 -0000 On Mon, Jan 7, 2019 at 12:56 PM David Schinazi w= rote: > > Thanks Barbara, how about this slightly more pedantic option? > > Babel over DTLS operates on a different port than unencrypted Babel. > All Babel over DTLS nodes MUST act as DTLS servers on a DTLS port, and MU= ST > listen for unencrypted Babel traffic on an unencrypted port, which MUST b= e > distinct from the DTLS port. The default port for Babel over DTLS is > registered with IANA as the "babel-dtls" port (UDP port TBD), and the in /etc/services it's: http and https smtpd and smtpds etc. "s" rather than -dtls? > unencrypted port is registered as the "babel" port (UDP port 6696). > Nodes SHOULD use these default ports. > > https://github.com/jech/babel-drafts/commit/c90cc8204691254e7051405acf6a1= 0088d42cdfd > > (Dave, running Babel over alternate transport protocols sounds like inter= esting future work outside the scope of this draft) babeld has worked over udp-lite for me, for nearly a decade now with a 2 line patch. Not ever got around to testing osx til last week. Seemed ideal to replace the crc with a hmac. :( but in light of the osx limitation, sadly request that YAUP, (Yet Another UDP port) be requested from iana. We still have some major congestion control issues to sort out. tcp/tls any= one? /me hides > > Thanks, > David > > On Fri, Jan 4, 2019 at 12:26 PM Dave Taht wrote: >> >> On Fri, Jan 4, 2019 at 12:07 PM STARK, BARBARA H wrote: >> > >> > Hmm. >> > >> > " Babel over DTLS operates on a different port than unencrypted Babel. >> > >> > All Babel over DTLS nodes MUST act as DTLS servers on a configured por= t, and >> > >> > MUST listen for unencrypted Babel traffic on a distinct configured por= t.=E2=80=9D >> > >> > >> > >> > An implementation doesn=E2=80=99t have to allow for configuration of p= orts. They could just be hard-coded. >> > >> > I don=E2=80=99t like that I need the context of the first sentence to = understand unambiguously what the second port is =E2=80=9Cdistinct=E2=80=9D= from (i.e., distinct from the unencrypted Babel port). >> > >> > >> > >> > How about just =E2=80=9C Babel over DTLS MUST operate on a different p= ort than unencrypted Babel.=E2=80=9D ? >> > >> >> Sure. >> >> (I had proposed at one point that the dtls version operate over >> udp_lite or even dccp, on the same port number, but have since >> discovered osx doesn't support either) >> > >> > Barbara >> > >> > >> > >> > From: David Schinazi >> > Sent: Friday, January 04, 2019 2:41 PM >> > To: STARK, BARBARA H >> > Cc: Babel at IETF >> > Subject: Re: [babel] minor DTLS comment >> > >> > >> > >> > Thanks for your comment, Barbara. I agree with you, and have added the= following text: >> > >> > https://github.com/jech/babel-drafts/commit/a5a372a942ebc7951b2847d881= 23d75ab8169f2f >> > >> > >> > >> > Please let us know if you feel it addresses your comment. >> > >> > >> > >> > Thanks, >> > >> > David >> > >> > >> > >> > On Fri, Jan 4, 2019 at 5:35 AM STARK, BARBARA H wrote= : >> > >> > Since the DTLS draft is still open for comments, I do have a small one= about how the UDP ports are characterized. >> > The IANA assigned ports are default values, and need to be portrayed a= s such. It's allowed (or should be) for deployed instances to use other val= ues. This is pretty much true of all protocols. Certainly the base babel pr= otocol allows other values to be used (which is why the homenet babel profi= le mandated use of 6696). >> > >> > Maybe instead of >> > All Babel over DTLS nodes MUST act as DTLS servers on the "babel- >> > dtls" port (UDP port TBD), and MUST listen for traffic on the >> > unencrypted "babel" port (UDP port 6696). >> > >> > say >> > All Babel over DTLS nodes MUST act as DTLS servers on the "babel- >> > dtls" port, and MUST listen for traffic on the >> > unencrypted "babel" port. >> > The IANA-assigned values of 6696 for the "babel" port and >> > TBD for the "babel-dtls" port SHOULD be used. >> > >> > Barbara >> > >> > >> > _______________________________________________ >> > babel mailing list >> > babel@ietf.org >> > https://www.ietf.org/mailman/listinfo/babel >> > >> > _______________________________________________ >> > babel mailing list >> > babel@ietf.org >> > https://www.ietf.org/mailman/listinfo/babel >> >> >> >> -- >> >> Dave T=C3=A4ht >> CTO, TekLibre, LLC >> http://www.teklibre.com >> Tel: 1-831-205-9740 --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Mon Jan 7 13:47:47 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8937512D7EA for ; Mon, 7 Jan 2019 13:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEs96ha8JW3M for ; Mon, 7 Jan 2019 13:47:45 -0800 (PST) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482D412D4F0 for ; Mon, 7 Jan 2019 13:47:45 -0800 (PST) Received: by mail-pf1-x431.google.com with SMTP id b85so818827pfc.3 for ; Mon, 07 Jan 2019 13:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wT95Idhhrb7h/wcevVN3DxMuae//SLYMaGdnDXwMyZM=; b=SGIGr2XfcVfZeu13SlO6SCv+QwyXtioDgRIT81ifjJWbuCa0friHkdMb92tXdjVd6m aiOQN6O+5R0Awsnl2eT0xOKGaFhFeGrYt7rFO7IIE5D/riH/WHFClEJFF/VZPdvfjhr5 xi56/01DyKGlDDf+mva0T8kqKOc3Crat9YmrQbRwBCSchiQkB4vWKA3qusjLs44EFZHX 9zvI3gjePlLXIyZKMED7lkUzSx1v9jycJnuRobHoA11FOIfO9YafxE6PI2l6+jhLlMlx vQbZJsVbPF/favuqZ4HZ83hGLmiEVrLv3VcxEAiYanXI0MVwHP8XkOB8rp7OuRCk5uHX 22Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wT95Idhhrb7h/wcevVN3DxMuae//SLYMaGdnDXwMyZM=; b=g22n4dlZCPhXa5fyjaBwC5qsJBdVbT7Z+lR1+zrcMZfVqqRJJKOxaOSY5p68EpsltN T4JQuWs2ExVdq00kOLJrsp+OkDQJAMIRfp7quNevN4hTrFqaPrmuqr9OGsyKJQFu0BDy rZEFnmmwAD21yFKJw8oYFbK0q76kP3kIhgm6Ufb+7bmDr/4aqG7qE5KRneInGDBLNcoL WPAQkaKfewtBaAGmdkHmMurYgwhelRb5VS9LmYfXtykrSTI9yfIuLhprBb+j6/hcpt5Z 17jP8NwFkEldGltdXQcFNRfeqyzzluGxXuE2dr647cVueoJANV00qdFhdkGAL9YlfPK2 uMvA== X-Gm-Message-State: AJcUukfbXWm0VfQ0bnhoPWfgPQG1qOwQXbHP/lS6dWMqajyeikv2ZQv0 PnrxVQlyQxxIBht0eyuGiUAazrzEhmSHMkFJXdU= X-Google-Smtp-Source: ALg8bN5DKihq0teWm+d8YZm3G+TEHhcdRY9NwFfVe0F9zj93ggKmZszqxMtDJsLshtcJUeUAzONNIK2R099Fn+H28ec= X-Received: by 2002:a63:4f20:: with SMTP id d32mr12285952pgb.47.1546897664762; Mon, 07 Jan 2019 13:47:44 -0800 (PST) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DF82DC1@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF8360C@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: From: David Schinazi Date: Mon, 7 Jan 2019 13:47:33 -0800 Message-ID: To: Dave Taht Cc: "STARK, BARBARA H" , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000cfe698057ee52dfc" Archived-At: Subject: Re: [babel] minor DTLS comment X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 21:47:46 -0000 --000000000000cfe698057ee52dfc Content-Type: text/plain; charset="UTF-8" On Mon, Jan 7, 2019 at 1:43 PM Dave Taht wrote: > in /etc/services it's: > > http and https > smtpd and smtpds > > etc. > > "s" rather than -dtls? > That implies that there's only one way to secure HTTP and SMTP. We went with babel-dtls because there are multiple security mechanisms for Babel. We might even want babel-quic one day, and that would get its own port. David --000000000000cfe698057ee52dfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Jan 7, 2019 at 1:43 PM Dave Taht <dave.taht@gmail.com> wrote:
in /etc/services it's:

http and https
smtpd and smtpds

etc.

"s" rather than -dtls?

That i= mplies that there's only one way to secure HTTP and SMTP.
We = went with babel-dtls because there are multiple security mechanisms
for Babel. We might even want babel-quic one day, and that would get its= own port.

David
--000000000000cfe698057ee52dfc-- From nobody Mon Jan 7 14:18:20 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900B512DDA3 for ; Mon, 7 Jan 2019 14:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTrtjqSKyFIn for ; Mon, 7 Jan 2019 14:18:16 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2CBD129508 for ; Mon, 7 Jan 2019 14:18:16 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x07MF8ZZ018080; Mon, 7 Jan 2019 17:18:15 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2pveyq8t6s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Jan 2019 17:18:15 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x07MIDZY028444; Mon, 7 Jan 2019 17:18:14 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x07MIBnV028429; Mon, 7 Jan 2019 17:18:11 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 7FF934048C29; Mon, 7 Jan 2019 22:18:11 +0000 (GMT) Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30485.vci.att.com (Service) with ESMTPS id 6D1184048C1E; Mon, 7 Jan 2019 22:18:11 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0415.000; Mon, 7 Jan 2019 17:18:10 -0500 From: "STARK, BARBARA H" To: =?utf-8?B?J1Rva2UgSMO4aWxhbmQtSsO4cmdlbnNlbic=?= , Dave Taht CC: Juliusz Chroboczek , Mahesh Jethanandani , Babel at IETF Thread-Topic: [babel] hmac info model elements Thread-Index: AdSi6E9jJwLKz5kXQlCy2NNONpdJZQA7HaOAAB1GhjAAFlCHAAB9AEdgAA5ybwAAARIuAAAEYQSAAATVnJA= Date: Mon, 7 Jan 2019 22:18:09 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF86FD0@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87tvio2i9l.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF8669E@GAALPA1MSGUSRBF.ITServices.sbc.com> <87k1jgwhlz.fsf@toke.dk> <87ef9owadw.fsf@toke.dk> In-Reply-To: <87ef9owadw.fsf@toke.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.202.237] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-07_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901070182 Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 22:18:18 -0000 PiA+PiA+IFRva2Ugc2FpZDogIkJpcmQgdXNlcyBhbiB1bmVuY29kZWQgc3RyaW5nLi4uIg0KPiA+ PiA+IDxiaHM+IEknbSBub3Qgc3VyZSB3aGF0ICJ1bmVuY29kZWQiIG1lYW5zIGhlcmU/IEJ1dCB0 aGlzIHNvdW5kcw0KPiA+PiA+IGxpa2UgbWF5YmUgdGhlIGVudGVyZWQgc3RyaW5nIGlzIGEgInBh c3NwaHJhc2UiIC8gUFNLLCBsaWtlIHdoYXQncw0KPiA+PiA+IHVzZWQgZm9yIFdpLUZpLCB3aGlj aCBpcyB0aGVuIHVzZWQgdG8gZGVyaXZlIHRoZSBITUFDIGtleSB1c2luZw0KPiA+PiA+IFVuaWNv ZGUgZW5jb2Rpbmc/DQo+ID4+DQo+ID4+IE5vcGUsIG5vIGRlcml2YXRpb24sIGp1c3QgdGhlIHJh dyBBU0NJSSBieXRlcyBmcm9tIHRoZSBzdHJpbmcgdXNlZCBhcw0KPiA+PiBhbiBITUFDIGtleSwg emVyby1wYWRkZWQgdG8gdGhlIGJsb2NrIHNpemUuIFVubGVzcyB0aGUgc3VwcGxpZWQgQVNDSUkN Cj4gPj4gc3RyaW5nIGlzIGxvbmdlciB0aGFuIHRoZSBibG9jayBzaXplLCBpbiB3aGljaCBjYXNl IGl0IGlzIGhhc2hlZA0KPiA+PiBmaXJzdC4NCj4gPg0KPiA+IF5eXl5eXiA/Pz8/IFNvIHlvdSBh cmUgc2F5aW5nIGFuIG92ZXJsb25nIGtleSBpcyB0cmFuc211dGVkIGludG8NCj4gPiBzb21ldGhp bmcgZWxzZSBlbnRpcmVseSwgbm90IHRydW5jYXRlZD8NCj4gDQo+IFl1cCwgdGhhdCB3b3VsZCBh cHBlYXIgdG8gYmUgdGhlIGNhc2U6DQo+IA0KPiBodHRwczovL2dpdGxhYi5sYWJzLm5pYy5jei9s YWJzL2JpcmQvYmxvYi9tYXN0ZXIvbGliL21hYy5jI0wxMDUNCg0KSSBub3RpY2VkIHRoZSByZWZl cmVuY2VkIGNvZGUgbWVudGlvbmVkIGl0IGNvdWxkIGJlIHVzZWQgZm9yIE9TUEYgKFJGQyA1NzA5 KS4gU28gSSB3ZW50IHRvIHNlZSBpZiBSRkMgNTcwOSBoYWQgYW55dGhpbmcgdG8gc2F5IGFib3V0 IHRoaXMuIEFuZCBpdCBkb2VzOg0KICAgKDEpIFBSRVBBUkFUSU9OIE9GIEtFWQ0KICAgICAgIElu IHRoaXMgYXBwbGljYXRpb24sIEtvIGlzIGFsd2F5cyBMIG9jdGV0cyBsb25nLg0KDQogICAgICAg SWYgdGhlIEF1dGhlbnRpY2F0aW9uIEtleSAoSykgaXMgTCBvY3RldHMgbG9uZywgdGhlbiBLbyBp cyBlcXVhbA0KICAgICAgIHRvIEsuICBJZiB0aGUgQXV0aGVudGljYXRpb24gS2V5IChLKSBpcyBt b3JlIHRoYW4gTCBvY3RldHMgbG9uZywNCiAgICAgICB0aGVuIEtvIGlzIHNldCB0byBIKEspLiAg SWYgdGhlIEF1dGhlbnRpY2F0aW9uIEtleSAoSykgaXMgbGVzcw0KICAgICAgIHRoYW4gTCBvY3Rl dHMgbG9uZywgdGhlbiBLbyBpcyBzZXQgdG8gdGhlIEF1dGhlbnRpY2F0aW9uIEtleSAoSykNCiAg ICAgICB3aXRoIHplcm9zIGFwcGVuZGVkIHRvIHRoZSBlbmQgb2YgdGhlIEF1dGhlbnRpY2F0aW9u IEtleSAoSyksDQogICAgICAgc3VjaCB0aGF0IEtvIGlzIEwgb2N0ZXRzIGxvbmcuDQoNCkknZCBi ZSBmaW5lIHdpdGggdGhpcyBzY2hlbWUsIGJ1dCB0aGluayB3ZSBzaG91bGQgcHJvYmFibHkgc3Bl Y2lmeSBpdCBzb21ld2hlcmUsIGxpa2UgT1NQRiBkb2VzLiANCkkgbm90aWNlIE9TUEYgbWFrZXMg bm8gbWVudGlvbiBvZiBhcnJpdmluZyBhdCB0aGUgQXV0aGVudGljYXRpb24gS2V5IGZyb20gYSBz dHJpbmcgKG9yIGhleCkuIEl0IGp1c3QgYXNzdW1lcyBpdHMgZGVhbGluZyB3aXRoIHNvbWV0aGlu ZyB0aGF0IGhhcyBhIGxlbmd0aCBtZWFzdXJlZCBpbiBvY3RldHMuIA0KV1BBMiBsaW1pdHMgaXRz IHBhc3NwaHJhc2Ugc3RyaW5ncyB0byAicHJpbnRhYmxlIEFTQ0lJIiBjaGFyYWN0ZXJzICgzMiAt IDEyNikuIFNpbmNlIE9TUEYgZG9lc24ndCBzZWVtIHRvIGNhcmUgaG93IGl0IGNvbWVzIGJ5IHRo ZSBLZXkgb2N0ZXRzLCBpdCBoYXMgbm8gc3VjaCBsaW1pdCBpbiBpdHMgc3BlYy4gSSB3b25kZXIg aWYgdGhlcmUgYXJlIGFueSBjaGFyYWN0ZXJzIHRoYXQgd291bGQgbWFrZSBvbmUgb2YgdGhlIGJh YmVsIGltcGxlbWVudGF0aW9ucyBjaG9rZTsgaWYgc28gd2UgbWF5IHdhbnQgdG8gbGltaXQgd2hh dCBjaGFyYWN0ZXJzIGNhbiBiZSB1c2VkIGlmIGlucHV0IGFzIEFTQ0lJLiBXUEEyIGRvZXMgYWxz byBhbGxvdyBoZXggUFNLLCB3aGljaCBoYXMgbm8gbGltaXRhdGlvbiBvbiB1c2FibGUgdmFsdWVz Lg0KQmFyYmFyYQ0K From nobody Tue Jan 8 00:33:32 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F192130E3F for ; Tue, 8 Jan 2019 00:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojMTILa2DNQq for ; Tue, 8 Jan 2019 00:33:29 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17E81271FF for ; Tue, 8 Jan 2019 00:33:28 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1546936375; bh=yeSxwP8cy/VEfzU7Du/XZ5Qe4TEzDDgkU0aD7hr0HZg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lksdOCVOH6W4OLasHJLXXmWGsQki8oGJ3kd48TEBQqgohanVc3CFSvwLq+bH4PLiJ 5ELeg2ycOPgFU8jLz7NyPVfvB2Q+qAWSDmcVoz42DCH//oVx4d45GOGGjVGTwDO05G KbCEsJ6KC+X02m+TnfSTqYbvWtCndWnYI1ooPlOBOUaL3DRDF+xcjqvv2NYxWi5iPW zf4Nwb17ebTyOqWQX4PmUdlgQbLLGI2RysPTLTghfkHNwD4L7JD3SA8X22QasojDtI TEa8MyOVcRYV5liDj3vsH126VDDf517MSc6lQ2wQoKCmeRpiKR3XmBZ7jnyeyDrPun a7avjn9Sh6Yig== To: "STARK\, BARBARA H" , Dave Taht Cc: Juliusz Chroboczek , Mahesh Jethanandani , Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF86FD0@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF7EECB@GAALPA1MSGUSRBF.ITServices.sbc.com> <91CABBA9-DFC0-48C5-9A36-E2B12FC376D9@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DF8354B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87tvio2i9l.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF8669E@GAALPA1MSGUSRBF.ITServices.sbc.com> <87k1jgwhlz.fsf@toke.dk> <87ef9owadw.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF86FD0@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Tue, 08 Jan 2019 09:32:53 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <875zuzwnuy.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] hmac info model elements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 08:33:32 -0000 "STARK, BARBARA H" writes: >> >> > Toke said: "Bird uses an unencoded string..." >> >> > I'm not sure what "unencoded" means here? But this sounds >> >> > like maybe the entered string is a "passphrase" / PSK, like what's >> >> > used for Wi-Fi, which is then used to derive the HMAC key using >> >> > Unicode encoding? >> >> >> >> Nope, no derivation, just the raw ASCII bytes from the string used as >> >> an HMAC key, zero-padded to the block size. Unless the supplied ASCII >> >> string is longer than the block size, in which case it is hashed >> >> first. >> > >> > ^^^^^^ ???? So you are saying an overlong key is transmuted into >> > something else entirely, not truncated? >> >> Yup, that would appear to be the case: >> >> https://gitlab.labs.nic.cz/labs/bird/blob/master/lib/mac.c#L105 > > I noticed the referenced code mentioned it could be used for OSPF (RFC 5709). So I went to see if RFC 5709 had anything to say about this. And it does: > (1) PREPARATION OF KEY > In this application, Ko is always L octets long. > > If the Authentication Key (K) is L octets long, then Ko is equal > to K. If the Authentication Key (K) is more than L octets long, > then Ko is set to H(K). If the Authentication Key (K) is less > than L octets long, then Ko is set to the Authentication Key (K) > with zeros appended to the end of the Authentication Key (K), > such that Ko is L octets long. Ah, nice find! This is exactly what Bird does. > I'd be fine with this scheme, but think we should probably specify it > somewhere, like OSPF does. Agreed. This scheme has the advantage of being simple, and not requiring another hashing or key derivation algorithm. At the cost of making it easier to go from the derived key back to the original passphrase. Not sure if that is a problem that warrants a "proper" key derivation function? > I notice OSPF makes no mention of arriving at the Authentication Key > from a string (or hex). It just assumes its dealing with something > that has a length measured in octets. > > WPA2 limits its passphrase strings to "printable ASCII" characters (32 > - 126). Since OSPF doesn't seem to care how it comes by the Key > octets, it has no such limit in its spec. I wonder if there are any > characters that would make one of the babel implementations choke; if > so we may want to limit what characters can be used if input as ASCII. > WPA2 does also allow hex PSK, which has no limitation on usable > values. I think that we should specify *something*, or we end up with incompatibilities again. And, well, much as I hate UTF-8-challenged systems in general, I'm not sure if doing UTF-8 is worth it in this instance? -Toke From nobody Tue Jan 8 14:27:26 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841691311B2; Tue, 8 Jan 2019 14:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHiXkZOdIqEf; Tue, 8 Jan 2019 14:27:22 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADFEA1311B7; Tue, 8 Jan 2019 14:27:22 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id l14so4466273ioj.5; Tue, 08 Jan 2019 14:27:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RjfqBEm1+DkAlEPTYHqkgWpc20ARqxUmcAEgGmmaW8w=; b=ngtHoHFI0sv3FyKLxIAMaG09c24/QpPX/D10iO2aPuYXJrCWMRzHgDW0Olj01ll3bx J3yVMNSnLR9sMQ5e4JQioQix4ISUkvCLQhw6cbmJvoByTOd8ioepRGOYeGmyxFBfZEkJ 9w6YsbEpo33y9SGJBrzTLEEJY/5ZAkSSCWQjK+KKbOY003UrN7Mq7/0uFvymF9pkmZCS 2ReNy8RuuAJlF9kBnBUaiNVwy45N3/GmmSMGgEV6dLJ7N5fuhsLXB1nGa8JdFhCRQctw 2bpzkLvSocfoEWiuYzZFHmjat3I2RcRANCkxTKe57y4K8uAHiROoIvQVOdx7pJs/KqSu ukLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RjfqBEm1+DkAlEPTYHqkgWpc20ARqxUmcAEgGmmaW8w=; b=H66PDmaMKM8PTtgGYSQxqYKogkZaoJO+a/3Sg+s2ifeWgsCIKsHTb5b9hY18yxEbmJ a1TUTy5elYmlcP5SyAbGHAr9xOGMQmXGUI/MGSTbwhBZB0plIpmstZxbIkseBSfG3aRz IPshzVfmydN4wVsv+HgYEpLx9/VNqAk25IEyVAflgUH/Mwj/OG+LW5+63KIWI07L1iM9 VkXi7vTqciT3AjYGwaomK5X7BS/SDu9FWI/YL7IrZ4AliwLMPZhqS9MBv+l3ZZ6M7Y5w mhlYxCr6QS2yVL54YobkQMegocHaEqWnDv4BkjdzRaPDP5sGZ3Kj4OJQks7DjXwVkarP +KTA== X-Gm-Message-State: AJcUukc4kzoupx7GfeSL+lCDloaUw+KCNLxzTgnMYVfIQ0pHycxnmf5b eIIPJfjZcK68ZxoLqVtyjflUSrGnlvxHTOnXIKA= X-Google-Smtp-Source: ALg8bN62eZcrKzPJ2DL/ETunE/z1FvRILvGz7W4P1bf6bSD6S1Q/AsXELVMMa1vXQ5pK0mjuR3OtJQ21cDpySVjdIHI= X-Received: by 2002:a6b:e919:: with SMTP id u25mr2390694iof.132.1546986441802; Tue, 08 Jan 2019 14:27:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Donald Eastlake Date: Tue, 8 Jan 2019 17:27:10 -0500 Message-ID: To: David Schinazi Cc: Babel at IETF , draft-ietf-babel-dtls@ietf.org, babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Shepherd's review of draft-ietf-babel-dtls-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 22:27:25 -0000 Hi, I have taken a look, including doing a diff against version -02, and this candidate -03 of draft-ietf-babel-dtls look good to me. Please post and I'll start a new WGLC. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Mon, Jan 7, 2019 at 4:19 PM David Schinazi wrote: > > Thank you for your comments, Donald. I've addressed them in this commit: > https://github.com/jech/babel-drafts/commit/9214e3fc8947d28c41f9f7cd761f107a185d2771 > > Please let us know what you think. We could publish the git version and restart the WGLC if you think we're ready. > > Thanks, > David > > Detailed responses inline: > > On Sun, Jan 6, 2019 at 9:17 PM Donald Eastlake wrote: >> >> Hi, >> >> Here are some comments on the draft: >> >> Abstract and Introduction: Replace "describes" with "specifies". > > > Done > >> Section 2.1, top of page 4, says "When a node receives a new DTLS >> connection, it MUST verify the source IP address, and reject the >> connection if the address is not an IPv6 link-local address." Would it >> be correct to replace this with "When a node receives a new DTLS >> connection, it MUST verify that the source IP address is an IPv6 >> link-local address; if it is not, it MUST reject the connection." or >> is there some other sort of verification it must do? > > > Done. Your change was correct. > >> >> Last paragraph of Section 2.3: I'm not sure about "unprotected >> implementation of Babel". Maybe "Babel implementation without DTLS >> support". > > > Done. > >> >> Also, the reference to replacing "TLV"s seems odd. Can't >> there be multiple TLVs in a message? Maybe "replacing any multicast >> Babel routing protocol message with unicast transmission of the >> message to each known neighbor except that neighbor discovery Hello >> TLVs MUST still be multicast." or something like that. > > > Not quite, since some TLVs such as IHU wouldn't contain the same contents sent unicast vs multicast. I've clarified the text. > >> >> IANA Considerations: As are probably aware, Section 8.1.1 of RFC 6335 >> is about applying for port numbers (and service names, which would, as >> you say, be "babel-dtls" in this case). A completed application >> template could be included as an appendix, though that is not >> necessary. > > > I was thinking of asking IANA for early codepoint assignment once the document has gone through WGLC. > >> >> Security Considerations, first sentence: Maybe "The interaction" -> >> "Confidential interaction". > > > Done > >> Security Considerations and rfc6126bis seem to say that Babel can run >> over IPv4 but the last paragraph of Section 2.1 seems to be limited to >> IPv6. > > > Good point, removed mention of IPv4 here. > >> >> I'm not sure why Performance Considerations is an Appendix rather than >> a section of the main text. But I guess it's OK either way. > > > I think the idea was that these considerations are not normative so they were placed in an appendix to match the spirit of RFC6126. > >> >> Minor wording suggestions, adopt or ignore as you choose: >> >> Abstract and Introduction: in the first line, insert "base" before >> "Babel Routing Protocol". > > > I personally find "base" odd, I'll let my co-authors comment. > >> >> Section 1.2: Delete "very". > > > Done. From nobody Tue Jan 8 14:54:28 2019 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EDF1311B2; Tue, 8 Jan 2019 14:54:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <154698805873.25571.9074332026737733592@ietfa.amsl.com> Date: Tue, 08 Jan 2019 14:54:18 -0800 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-dtls-03.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 22:54:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : Babel Routing Protocol over Datagram Transport Layer Security Authors : Antonin Decimo David Schinazi Juliusz Chroboczek Filename : draft-ietf-babel-dtls-03.txt Pages : 9 Date : 2019-01-08 Abstract: The Babel Routing Protocol does not contain any means to authenticate neighbours or protect messages sent between them. This documents specifies a mechanism to ensure these properties, using Datagram Transport Layer Security (DTLS). This document updates RFC 6126bis. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-dtls-03 https://datatracker.ietf.org/doc/html/draft-ietf-babel-dtls-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-dtls-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 8 14:58:23 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50F91311D9; Tue, 8 Jan 2019 14:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyrnSEJ-HPsH; Tue, 8 Jan 2019 14:58:07 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BCD712D4F0; Tue, 8 Jan 2019 14:58:07 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id u6so2625556pfh.11; Tue, 08 Jan 2019 14:58:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kGliB6xFpt5Fey9trO3J+7ZiAzu1+4iAj4+TFqafZME=; b=K/ZOqH8o1oEwzjnT/0WspkAWZzSEVRsg3QXGaYvuQVrsm37fsg/7/oeHFm1uSjVsz8 WlfiBqkSIuVylyELtb/Ucci0EcJnCFJEDPr3RhjRL55SvW8cl5zAg2YYoDtm2/WmhSXs fsG6hc3TshQrn5WHK7muIlxMdWLKGSp0NRunEdjRsnffGhFBLnU1uRGee5GHJqhZGSZ0 1W63w9Ze6PZvvt5Wb/5lmmtx5Bl24Fh8rcRZBbGkfI39ikPTmcWlOs/PS6cWGaSWcRC1 CZRsGi6nVNf4zMvpBQRG4txToOgHj6sngOmSsKZ9BpOxEvq8296M16/yUD0SRyZzO+tO qaYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kGliB6xFpt5Fey9trO3J+7ZiAzu1+4iAj4+TFqafZME=; b=JIvfXWwVCkkquJ64yRzo/T5tFpU0doxSQ85DiEBsJE7YWptntut6aqLa5M47JkD8Su SeFhFNhBd+liFJUlX8CwgLvtxPZQGmlYRrrRpfhWo8DKEpfPcWqTiAJCtj99MJTfza54 eB7r2977SQNIcPHrMMuS8zC4WB9hF8Ff6KwIlhpBDPh2CU67R3raeFhfIvQXM1OxbFSq qP5y3uLeB4njYzxjDMEuvaWq3RIXDZavhRuMJibNv5mpCUBsi+My7/Rxw2OhgcoTEoy6 Qy5pakFfgYWX5gdH8ei6HoKhELJqQdySqastysEFBLplvWA+DeUqVxMOCcpbxebb1hq/ yZXQ== X-Gm-Message-State: AJcUukd+a1u1QXl20fzdho2bjhLouqjPSQXTp0U6F0FK377E15FNyzjd pobLrbT4V6gYyg2GGBb+QeUr583V6mj8vKtLniIQAA== X-Google-Smtp-Source: ALg8bN7E41sObA49C7ss/AxkRKD9VBnTGZ1Pwuli8X8/Kz6FQme8fMX1NJJClW85kCfeVbDn7OtarWZimqg+BolAMPA= X-Received: by 2002:a63:7e1a:: with SMTP id z26mr3147813pgc.216.1546988286971; Tue, 08 Jan 2019 14:58:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Tue, 8 Jan 2019 14:57:55 -0800 Message-ID: To: Donald Eastlake Cc: Babel at IETF , draft-ietf-babel-dtls@ietf.org, babel-chairs Content-Type: multipart/alternative; boundary="00000000000051137c057efa472b" Archived-At: Subject: Re: [babel] Shepherd's review of draft-ietf-babel-dtls-02 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 22:58:10 -0000 --00000000000051137c057efa472b Content-Type: text/plain; charset="UTF-8" Thank you Donald, I have submitted draft-ietf-babel-dtls-03 . Diff from -02 available here . David On Tue, Jan 8, 2019 at 2:27 PM Donald Eastlake wrote: > Hi, > > I have taken a look, including doing a diff against version -02, and > this candidate -03 of draft-ietf-babel-dtls look good to me. Please > post and I'll start a new WGLC. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail.com > > On Mon, Jan 7, 2019 at 4:19 PM David Schinazi > wrote: > > > > Thank you for your comments, Donald. I've addressed them in this commit: > > > https://github.com/jech/babel-drafts/commit/9214e3fc8947d28c41f9f7cd761f107a185d2771 > > > > Please let us know what you think. We could publish the git version and > restart the WGLC if you think we're ready. > > > > Thanks, > > David > > > > Detailed responses inline: > > > > On Sun, Jan 6, 2019 at 9:17 PM Donald Eastlake wrote: > >> > >> Hi, > >> > >> Here are some comments on the draft: > >> > >> Abstract and Introduction: Replace "describes" with "specifies". > > > > > > Done > > > >> Section 2.1, top of page 4, says "When a node receives a new DTLS > >> connection, it MUST verify the source IP address, and reject the > >> connection if the address is not an IPv6 link-local address." Would it > >> be correct to replace this with "When a node receives a new DTLS > >> connection, it MUST verify that the source IP address is an IPv6 > >> link-local address; if it is not, it MUST reject the connection." or > >> is there some other sort of verification it must do? > > > > > > Done. Your change was correct. > > > >> > >> Last paragraph of Section 2.3: I'm not sure about "unprotected > >> implementation of Babel". Maybe "Babel implementation without DTLS > >> support". > > > > > > Done. > > > >> > >> Also, the reference to replacing "TLV"s seems odd. Can't > >> there be multiple TLVs in a message? Maybe "replacing any multicast > >> Babel routing protocol message with unicast transmission of the > >> message to each known neighbor except that neighbor discovery Hello > >> TLVs MUST still be multicast." or something like that. > > > > > > Not quite, since some TLVs such as IHU wouldn't contain the same > contents sent unicast vs multicast. I've clarified the text. > > > >> > >> IANA Considerations: As are probably aware, Section 8.1.1 of RFC 6335 > >> is about applying for port numbers (and service names, which would, as > >> you say, be "babel-dtls" in this case). A completed application > >> template could be included as an appendix, though that is not > >> necessary. > > > > > > I was thinking of asking IANA for early codepoint assignment once the > document has gone through WGLC. > > > >> > >> Security Considerations, first sentence: Maybe "The interaction" -> > >> "Confidential interaction". > > > > > > Done > > > >> Security Considerations and rfc6126bis seem to say that Babel can run > >> over IPv4 but the last paragraph of Section 2.1 seems to be limited to > >> IPv6. > > > > > > Good point, removed mention of IPv4 here. > > > >> > >> I'm not sure why Performance Considerations is an Appendix rather than > >> a section of the main text. But I guess it's OK either way. > > > > > > I think the idea was that these considerations are not normative so they > were placed in an appendix to match the spirit of RFC6126. > > > >> > >> Minor wording suggestions, adopt or ignore as you choose: > >> > >> Abstract and Introduction: in the first line, insert "base" before > >> "Babel Routing Protocol". > > > > > > I personally find "base" odd, I'll let my co-authors comment. > > > >> > >> Section 1.2: Delete "very". > > > > > > Done. > --00000000000051137c057efa472b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Donald, I have submitted draft-ietf-babel-dtls-03.
Diff from -02 availab= le here.

David

On Tue, Jan 8, 2019 at 2:27 PM Donald Eastlak= e <d3e3e3@gmail.co= m> wrote:
Hi,

I have taken a look, including doing a diff against version -02, and
this candidate -03 of draft-ietf-babel-dtls look good to me. Please
post and I'll start a new WGLC.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A01424 Pro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.co= m

On Mon, Jan 7, 2019 at 4:19 PM David Schinazi <dschinazi.ietf@gmail.com> wrote= :
>
> Thank you for your comments, Donald. I've addressed them in this c= ommit:
> https://git= hub.com/jech/babel-drafts/commit/9214e3fc8947d28c41f9f7cd761f107a185d2771
>
> Please let us know what you think. We could publish the git version an= d restart the WGLC if you think we're ready.
>
> Thanks,
> David
>
> Detailed responses inline:
>
> On Sun, Jan 6, 2019 at 9:17 PM Donald Eastlake <d3e3e3@gmail.com> wrote:
>>
>> Hi,
>>
>> Here are some comments on the draft:
>>
>> Abstract and Introduction: Replace "describes" with &quo= t;specifies".
>
>
> Done
>
>> Section 2.1, top of page 4, says "When a node receives a new = DTLS
>> connection, it MUST verify the source IP address, and reject the >> connection if the address is not an IPv6 link-local address."= Would it
>> be correct to replace this with "When a node receives a new D= TLS
>> connection, it MUST verify that the source IP address is an IPv6 >> link-local address; if it is not, it MUST reject the connection.&q= uot; or
>> is there some other sort of verification it must do?
>
>
> Done. Your change was correct.
>
>>
>> Last paragraph of Section 2.3: I'm not sure about "unprot= ected
>> implementation of Babel". Maybe "Babel implementation wi= thout DTLS
>> support".
>
>
> Done.
>
>>
>> Also, the reference to replacing "TLV"s seems odd. Can&#= 39;t
>> there be multiple TLVs in a message? Maybe "replacing any mul= ticast
>> Babel routing protocol message with unicast transmission of the >> message to each known neighbor except that neighbor discovery Hell= o
>> TLVs MUST still be multicast." or something like that.
>
>
> Not quite, since some TLVs such as IHU wouldn't contain the same c= ontents sent unicast vs multicast. I've clarified the text.
>
>>
>> IANA Considerations: As are probably aware, Section 8.1.1 of RFC 6= 335
>> is about applying for port numbers (and service names, which would= , as
>> you say, be "babel-dtls" in this case). A completed appl= ication
>> template could be included as an appendix, though that is not
>> necessary.
>
>
> I was thinking of asking IANA for early codepoint assignment once the = document has gone through WGLC.
>
>>
>> Security Considerations, first sentence: Maybe "The interacti= on" ->
>> "Confidential interaction".
>
>
> Done
>
>> Security Considerations and rfc6126bis seem to say that Babel can = run
>> over IPv4 but the last paragraph of Section 2.1 seems to be limite= d to
>> IPv6.
>
>
> Good point, removed mention of IPv4 here.
>
>>
>> I'm not sure why Performance Considerations is an Appendix rat= her than
>> a section of the main text. But I guess it's OK either way. >
>
> I think the idea was that these considerations are not normative so th= ey were placed in an appendix to match the spirit of RFC6126.
>
>>
>> Minor wording suggestions, adopt or ignore as you choose:
>>
>> Abstract and Introduction: in the first line, insert "base&qu= ot; before
>> "Babel Routing Protocol".
>
>
> I personally find "base" odd, I'll let my co-authors com= ment.
>
>>
>> Section 1.2: Delete "very".
>
>
> Done.
--00000000000051137c057efa472b-- From nobody Tue Jan 8 20:44:02 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A0F12F1A2; Tue, 8 Jan 2019 20:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSjP0Gy9lcLM; Tue, 8 Jan 2019 20:43:59 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B59812D4EB; Tue, 8 Jan 2019 20:43:59 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id g76so9840510itg.2; Tue, 08 Jan 2019 20:43:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Wo9gXsHNB6phktVEZEpbEP53Gn6rboGfmehtLkDYZ5w=; b=XpJDur5HWPHnTuZaX1ghRHRZKzOGxjOqBZKJtLcNCAysnAsgh46GtgMB5pVlsf2SCg s/QSUEFDUMFkRp1qUrd9oCdVORrNJxRAp6HXrFCahz7f6iboWyh3qdab9hOhfkJN5J9G ZBdT1u3Y50649Meb6hqAXTpuG5r0GpceHxIimw1yvTAy1lbntZC+YKwNVy/38oT1MtNJ VEs+8KY4H/LR2kNolmXs21lgM51rB8rzBB6THFwWOL+8QESyLp1+6DmG9qXvHPymGUTX Tp+vsygnCJkYcfCO+wnwwhH6BDS/kvqGajpOzRCCRZtZFPvlJjhfpJ79KgcIQdqO/53s ow+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Wo9gXsHNB6phktVEZEpbEP53Gn6rboGfmehtLkDYZ5w=; b=AiMlWvJOVDB6J9uPHeqoh8mzaUXE/QIJMoL6oeX7pGjOtYO4WvHJV7gK2grcaJ9+o1 pJcE2bHYFUJRAmzzFC7I9swi/GBkejZWeeSr+bMKyDBz27KLRsBzH94Wn+L6PFHW1oiY 9kXXpNp+8aAeHR0WGg1sgSzLvmnB09awsTrJDHvJiJmLQvsjrTuieedUBcKU70ZCmPfD 9L3GPaDEP052nFe4C4mjkPDjTdwNA+6QQh2b9nafb8ld6TazDkKzctLPEEkCrLFBHMCb 7mpxELdoRRKOMn5rqwf1//W33IlPT1N69I4jl6jgx56UYXE6QQPzdxE69zRK2d8QMs3Q P1jg== X-Gm-Message-State: AJcUukfNJ+k3pIuS2kHixBJEL+fbbS9Y0ib0Rmpv+DggGZUyK3fRZ0j8 LqsBC3FkD0ChTotn1x/fbtBJb9oBL19FAhmhyCzRrDgN X-Google-Smtp-Source: ALg8bN6TbRXQQHSPh3U5LPMytJvdFKPg/tOH/qMoiYVremKGLIRQ+tfpW2FblrnrMlkAq+/aMSebQCvePGa+wkEqAZs= X-Received: by 2002:a24:36cf:: with SMTP id l198mr3442870itl.102.1547009038069; Tue, 08 Jan 2019 20:43:58 -0800 (PST) MIME-Version: 1.0 From: Donald Eastlake Date: Tue, 8 Jan 2019 23:43:46 -0500 Message-ID: To: Babel at IETF Cc: draft-ietf-babel-dtls@ietf.org, babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] WG Last Call for draft-ietf-babel-dtls-03 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 04:44:00 -0000 Hi, This message begins a Working Group Last Call on draft-ietf-babel-dtls running to January 21st. Please comment on whether or not you think the draft is ready for publication. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com From nobody Wed Jan 9 00:37:29 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFFC130DC1; Wed, 9 Jan 2019 00:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3so2wjEs5cP; Wed, 9 Jan 2019 00:37:25 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29185128766; Wed, 9 Jan 2019 00:37:24 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1547023010; bh=1og08e+fpFIQq0P3kLnsZxRLx9A4sKdb+R2b/8jhAFg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=w14C1I969NNcyB0Duo/MwqSPL5hP3Hd3zT/0aWKA+nG5Gio7WOmRbZsX8hJkb3HvG bLebQvt4BPc9MxKiJqARkR8VesctEUywJC4MqQ1Sb3PkjU2XauLYBah/Lnv6phB8tm ZpUAKt1epzdGfQuzei3waOWH8H+Hrsftadwh6JtwoGEkl7uJ0QLqVNu7OiMnEbmV0r /0uVLfFgDl5mK7WQKqkISb9pXvvKZ5rvqpDcLd/6WedKVmlcBvtgp+ivcLIe4kXv4L Jjk4/pUmtIASZkrb2OyhrHgRVKPyLuGauMGinLUWiNsxjXcHDlfy6RgS7Ej1Ek7zpz u2C5Rr5jvP0Cg== To: Donald Eastlake , Babel at IETF Cc: babel-chairs , draft-ietf-babel-dtls@ietf.org In-Reply-To: References: Date: Wed, 09 Jan 2019 09:36:47 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87sgy2teg0.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-dtls-03 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 08:37:28 -0000 Donald Eastlake writes: > Hi, > > This message begins a Working Group Last Call on draft-ietf-babel-dtls > running to January 21st. Please comment on whether or not you think > the draft is ready for publication. I support publication :) -Toke From nobody Wed Jan 9 05:15:18 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4676F12F19D for ; Wed, 9 Jan 2019 05:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDk8KNoPhuEZ for ; Wed, 9 Jan 2019 05:15:14 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF6A1294FA for ; Wed, 9 Jan 2019 05:15:13 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x09DF2DC022851; Wed, 9 Jan 2019 14:15:02 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C20F580533; Wed, 9 Jan 2019 14:15:07 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id h2rnixWO2cnW; Wed, 9 Jan 2019 14:15:05 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 80B198052F; Wed, 9 Jan 2019 14:15:05 +0100 (CET) Date: Wed, 09 Jan 2019 14:15:05 +0100 Message-ID: <87imyyq8fa.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: Markus Stenberg , Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF82217@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF65C81@GAALPA1MSGUSRBF.ITServices.sbc.com> <87efa9legt.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF7E186@GAALPA1MSGUSRBF.ITServices.sbc.com> <87tviplm17.wl-jch@irif.fr> <5720979F-C0D2-4291-B4D6-653B28E77D4B@kapsi.fi> <87muohlfsj.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF82217@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 09 Jan 2019 14:15:02 +0100 (CET) X-Miltered: at korolev with ID 5C35F3D6.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C35F3D6.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C35F3D6.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] info-model: message log X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 13:15:16 -0000 >> (Note that picking a dump format doesn't mean we can parse it -- there's the >> small matter of the encapsulation used, which could be 802.2, radiotap, raw >> IPv6, or something else. Do we need to specify that?) > Encapsulation is the job of the management protocol. The info model will > allow the file to be exposed... That's not what I meant. Pcap and pcapng contain a sequence of frames -- these frames can be using a number of different encapsulations. Here are the cases I'm familiar with: - pcap can contain a sequence of Ethernet frames; - pcap can contain a sequence of 802.2 SNAP frames; - pcap can contain a sequence of radiotap frames which themselves contain whatever is carried by the 802.11 link (typically 802.2 SNAP). Is it legal for an implementation to expose, say, PPP frames in the pcap file? Do we need to formalise the allowed encapsulations contained within the pcap file, or are we going to assume implementers do something reasonable? (I'd argue in favour of being liberal here -- being restrictive might cause issues if at some point Babel is carried over exotic link layers, and after all one of Babe's strenghts is that it's link-layer-agnostic. But I think it deserves discussion.) -- Juliusz From nobody Wed Jan 9 06:21:12 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C20E12426E for ; Wed, 9 Jan 2019 06:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.299 X-Spam-Level: * X-Spam-Status: No, score=1.299 tagged_above=-999 required=5 tests=[KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zzGWJ79LLU1 for ; Wed, 9 Jan 2019 06:21:09 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C851228B7 for ; Wed, 9 Jan 2019 06:21:09 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x09EEmWI003556; Wed, 9 Jan 2019 09:21:08 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 2pwjee0b92-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Jan 2019 09:21:08 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x09EL7gs029494; Wed, 9 Jan 2019 09:21:07 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x09EL4VZ029444; Wed, 9 Jan 2019 09:21:04 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 18241401404F; Wed, 9 Jan 2019 14:21:04 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30487.vci.att.com (Service) with ESMTPS id 055D64014048; Wed, 9 Jan 2019 14:21:04 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0415.000; Wed, 9 Jan 2019 09:21:03 -0500 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: Markus Stenberg , Babel at IETF Thread-Topic: [babel] info-model: message log Thread-Index: AdSXyYnBQkQrNQ5OTYeO5Bd7aNbDmQCcr+YAAOaIy4ABPlBSwAA3y64AAARvUoAAAEXiAAAD1qlwAR2Ms4AACWxIAA== Date: Wed, 9 Jan 2019 14:21:02 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF895BF@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF65C81@GAALPA1MSGUSRBF.ITServices.sbc.com> <87efa9legt.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF7E186@GAALPA1MSGUSRBF.ITServices.sbc.com> <87tviplm17.wl-jch@irif.fr> <5720979F-C0D2-4291-B4D6-653B28E77D4B@kapsi.fi> <87muohlfsj.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF82217@GAALPA1MSGUSRBF.ITServices.sbc.com> <87imyyq8fa.wl-jch@irif.fr> In-Reply-To: <87imyyq8fa.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.217.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-09_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=557 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901090120 Archived-At: Subject: Re: [babel] info-model: message log X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 14:21:10 -0000 > >> (Note that picking a dump format doesn't mean we can parse it -- > >> there's the small matter of the encapsulation used, which could be > >> 802.2, radiotap, raw IPv6, or something else. Do we need to specify > >> that?) >=20 > > Encapsulation is the job of the management protocol. The info model > > will allow the file to be exposed... >=20 > That's not what I meant. Pcap and pcapng contain a sequence of frames -- > these frames can be using a number of different encapsulations. >=20 > Here are the cases I'm familiar with: >=20 > - pcap can contain a sequence of Ethernet frames; > - pcap can contain a sequence of 802.2 SNAP frames; > - pcap can contain a sequence of radiotap frames which themselves > contain whatever is carried by the 802.11 link (typically 802.2 SNAP)= . >=20 > Is it legal for an implementation to expose, say, PPP frames in the pcap = file? > Do we need to formalise the allowed encapsulations contained within the > pcap file, or are we going to assume implementers do something > reasonable? >=20 > (I'd argue in favour of being liberal here -- being restrictive might cau= se issues > if at some point Babel is carried over exotic link layers, and after all = one of > Babel's strengths is that it's link-layer-agnostic. > But I think it deserves discussion.) Ah. I understand now (I hope). I see no need to be restrictive. The data li= nk type is specified in the file header (using values from http://www.tcpdu= mp.org/linktypes.html). I think it's the responsibility of whatever is rea= ding the file to be able to comprehend the link types of the Babel deployme= nt. If you deploy Babel in an exotic environment, you need to have the tool= s that understand your exotic environment. I'm often accused of being liber= al. From nobody Wed Jan 9 10:30:57 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609B5130FBB; Wed, 9 Jan 2019 10:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuX0uFtwTt4S; Wed, 9 Jan 2019 10:30:53 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E6F13104D; Wed, 9 Jan 2019 10:30:50 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id x6so6807480ioa.9; Wed, 09 Jan 2019 10:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dK62ukzVZuAh4mVVk1ORno/CEK4DUQoSbWUlVlHVfg4=; b=fRZOB7bxhvae3MMwZYyUAGu4lbUlUjzcSc7twJkIO8IsTfYz4f5B4hqoy1Cod3Gw8J pg6AhER6O19sQ2zB3UVasvwENKZc8iov4Fw4W8wUzAPbpQKENiETZTMiIQ3sS2wqhBFM cHQYmaqbxCMOICtMgQzxjmm+WY0So13hMk+pizTqRKPE/vmWJTuF8HTEfj4pjXL7rakA uB7BYGEgr3fxzRutFozchMxa8Hb/8oFbetUeQiOhnTYj/gYDzlHtVcgjbB/JNXyhK18z NY92Y6q17cT/R1VCQ4DUSeC413w7oZdSVu/xPd2ot7w/yHX0gkBDwTTis189018hatAZ L7Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dK62ukzVZuAh4mVVk1ORno/CEK4DUQoSbWUlVlHVfg4=; b=Fw4pCmENz1G3oCPrIzp5pMXu9OzsRrKhBjPjQ0928yy6RiDXD+dw+7FptvXe3XqjC6 1hcOqgiN5fAJhrf4mpwI52OZWFPZsli34NmI1SkADnF2prnkyRkavPKTPT3lSu0ax0n0 /CTb+pL6ombpdthaGmv68SU2gYrsmFSAUVZ610FWfgivPZMiWIksvKb3e2FzoXCC6dkc NatnPpSlI2xNee1oFDdLTt+HJL1gy9A4pkJf4jTTdwccJF5S+TAEX5G+8bKOd3fnwD6N ZahVQCfpfd2pTwNcq80q0uI/C5oFXnzqTpu7nU0nKDrfdxTFdnPof9IwkdNaopNPfK52 wl7w== X-Gm-Message-State: AJcUuke3KJLzMUucH6DCm3UwGRkh+db4mur3Jc8/XU5wplkPZ0TOYvEi jF07Judhyf1RtIB37z4Z7H5nCP2pxwENQfl/fNw= X-Google-Smtp-Source: ALg8bN5wuoiS51aENS8obAs9tVUZHqtC32Lj6xV10bPXBZyVLAHJP7IL4KCMn4U/NOOB9c/NFOeO6P4C6n7qzZkK/tU= X-Received: by 2002:a6b:3c17:: with SMTP id k23mr4299348iob.182.1547058649358; Wed, 09 Jan 2019 10:30:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Date: Wed, 9 Jan 2019 19:30:30 +0100 Message-ID: To: Donald Eastlake Cc: Babel at IETF , draft-ietf-babel-dtls@ietf.org, babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-dtls-03 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 18:30:55 -0000 Hello Donald, I support publication. -- Antonin From nobody Wed Jan 9 11:33:49 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9F7131053; Wed, 9 Jan 2019 11:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ3IUD3OHaqW; Wed, 9 Jan 2019 11:33:47 -0800 (PST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6A7130F6D; Wed, 9 Jan 2019 11:33:47 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id c123so4142220pfb.0; Wed, 09 Jan 2019 11:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=soMTF1maQWXjlNvxhXKp3+UUoAKlryokU/B6IiJuk3k=; b=m0R+zymWov42jBXyCfOUgSnNd5NpgwiyAoaPU6wcsKFLgRY0JZCMeRUfz9Z6XBxhlQ 5BElwV9iHthR9L5eBETTTDjrHq3+fJ5IhR3+gyOHUsJBqUE6YgtmlvJymzxxRTq8wqBj O//CYHsq0wS6RVtijpC4mpcFNY/dnxIyRrnJLL4TyZbYT2ka0FLQ2Y3zwpmov3rdLyqa DwEpYwqbBZ4wO8C9M7qv3pkdsYjQwlRFP+oEKcSMDqNZp1VUcLMJaN0cxuCj5R0Z03b4 QD/+AZkN6dfZx8fGFkA5wrn/B914guvdKIRqTogGmHLiXxoWMPnI/zSgxD5kAtj3Srm1 0Pug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=soMTF1maQWXjlNvxhXKp3+UUoAKlryokU/B6IiJuk3k=; b=Nxx9rZ54YE+E6PtWkYBZ3UUYiTJtLgOyFWPPQrdz1AkVwgbaFfXXgQC60BraIjmR2j DXEWmRflzhejAcWTLibUWLvONy2LtKiB/yuMeurwftmiXiTIseSmtY8hevR95cvN/Ll0 R0RrnGe13RoEiwZQuSsXZaX7EtfZSAR/TfXgEZUGJDrujVGwSegwltxJPRMBD7bNyluD TfYZemJFyiSAwqPRXolh0bdCxnbjsttwob+WSpXt33hy4fQaqQdbU//XXBS59NjjN6GZ d7PuV1HbLLldUkZdUVRalqIQNkaVOEXgOQkXDKK3dgx1olHrbptfwxOx8hK6o3akEGW4 jMkw== X-Gm-Message-State: AJcUukdyaaUhNmDjDInCIvDaMEKZ1bDei034USEI6M2697O+vnmmg29z qlXa9ux6UGtOWMYttnt46W/0pNVPNHV45x3iLHrUKQ== X-Google-Smtp-Source: ALg8bN5qonMsN5RwA6u5ynf7PyGbMx/rIweEo5yiPXdPnBK4xSdIM6gMp2dEvKLaYICatntNI0ikhhhDuiQmsVWs66U= X-Received: by 2002:a63:6c48:: with SMTP id h69mr6317248pgc.139.1547062426913; Wed, 09 Jan 2019 11:33:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Wed, 9 Jan 2019 11:33:35 -0800 Message-ID: To: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Cc: Donald Eastlake , Babel at IETF , draft-ietf-babel-dtls@ietf.org, babel-chairs Content-Type: multipart/alternative; boundary="00000000000066cf8b057f0b8afc" Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-dtls-03 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 19:33:48 -0000 --00000000000066cf8b057f0b8afc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (Stating the obvious, as co-author) I support publication. On Wed, Jan 9, 2019 at 10:30 AM Antonin D=C3=A9cimo wrote: > Hello Donald, > > I support publication. > > -- Antonin > --00000000000066cf8b057f0b8afc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Stating the obvious, as co-author) I support publication.=

On Wed, Jan 9, 2019 a= t 10:30 AM Antonin D=C3=A9cimo <antonin.decimo@gmail.com> wrote:
Hello Donald,

I support publication.

-- Antonin
--00000000000066cf8b057f0b8afc-- From nobody Wed Jan 9 13:40:50 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF45130FD4; Wed, 9 Jan 2019 13:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY_D6fq7m4la; Wed, 9 Jan 2019 13:40:44 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE067130FCB; Wed, 9 Jan 2019 13:40:44 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id l11so10102740qtp.0; Wed, 09 Jan 2019 13:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rORUd+eHGgFNXTuN0tp95K2eilo804fQKUtEjf6QaeY=; b=dVj82Qa61m+AAPJcCtoy98jY7MVNKim66mROMbFkj8HEoJ4Bl+ZQD65p8KaA3ZseRM VnF1NL/HxnQ+WkvJZ+XbXrah4iBBpez54UiO+G/DghGdWo3bxbvitMN1DGwNIh4WX7Ro /DVIO7/dtVXo/5n9NoscL97GBwax0oC3SG5562vq0BXJldqoVvuHTBYThFxB/aMfuDin Ku7RdtqYwjLPUbzyewpeO6fclwlQW2qmWd8pV5gLcm/kJujY3ez5sEbU0e3C/eCJ0+m/ G1YEqYMKykRYbSihx70Yks7dfR3/+1tslQdZvKHVrACBj0TDhC+nbcFBHyGxrNzqdTA7 Lrvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rORUd+eHGgFNXTuN0tp95K2eilo804fQKUtEjf6QaeY=; b=i4qIIgQDJ371wfOFji8jX4dwvAHM4nkIF8wLA2yGwDMYtNaV1DjbMwnTdKgAJSvsuU GEwTfJxeHcZShVpTvteSKjWwmeiV3VfosnrfUsd6aRfJlBbX0ZMD6CBIw2L4CPC85BUB eRqDDDcF33/0SRkMWE0Qk6zrhLZVUj1wUZB0WSLwiIXK/+yNksRF5fae85d5uD49iCeP lEC83LU4S7Flt4Q3kh0+U6XwCUWBpQ9thNHJbRa7cMdjY33NLeEjpJPMuAuvr8mEqVkM OagYYsRInixvJf/3kvQxo7sRCoWI00XFA3Bymrij/1NymWKgh/gdvNLrQSg3tUKWETtp yWaA== X-Gm-Message-State: AJcUukdtAD+fNOJes12H7ySVzqBq1ykmZNrT8KqopLJ2SbV2qH48P1wx p1P1Ob9bUnkQUjYzA9DyFCVzuCY4orBHNQxjv94= X-Google-Smtp-Source: ALg8bN6up4LELSrmIbaXstmxe5/imnAlsXxbTG7y4n8lO351tbHmJnORt6kGGKtIPNzdgxtQJQlM82hUfGH/iyYlyE4= X-Received: by 2002:a0c:a402:: with SMTP id w2mr7501846qvw.129.1547070043747; Wed, 09 Jan 2019 13:40:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Wed, 9 Jan 2019 13:40:30 -0800 Message-ID: To: David Schinazi Cc: =?UTF-8?Q?Antonin_D=C3=A9cimo?= , Donald Eastlake , draft-ietf-babel-dtls@ietf.org, babel-chairs , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-dtls-03 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 21:40:47 -0000 well, I've been playing catchup on these drafts for a while and had barely looked at this before now. * As usual, I like having two interoperable implementations before committing to a draft. To me, this is unclear: " When a Babel node discovers a new neighbor (generally by receiving an unencrypted multicast Babel packet), it compares the neighbour's IPv6 link-local address with its own, using network byte ordering. If a node's address is lower than the recently discovered neighbor's address, it acts as a client and connects to the neighbor. In other words, the node with the lowest address is the DTLS client for this pairwise relationship. As an example, fe80::1:2 is considered lower than fe80::2:1." A DTLS enabled node receiving that unencrypted multicast hello packet (on the main babel port? on the dtls port?), is then supposed to try contacting the other router on the DTLS port? Recieving a hello from a lower numbered fe80 address means you wait for the lower numbered fe80 address to initiate (so you send a hello with or without an ihu?) So a DOS attack is merely lots of hellos and a very slow DTLS exchange? (what are the timeouts associated with a DTLS negotiation?) In the HMAC draft there was a 300ms timeout suggested for some things. On Wed, Jan 9, 2019 at 11:33 AM David Schinazi w= rote: > > (Stating the obvious, as co-author) I support publication. > > On Wed, Jan 9, 2019 at 10:30 AM Antonin D=C3=A9cimo wrote: >> >> Hello Donald, >> >> I support publication. >> >> -- Antonin > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel -- Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Wed Jan 9 13:42:57 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB1B12DD85 for ; Wed, 9 Jan 2019 13:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAPUoA4-YaDh for ; Wed, 9 Jan 2019 13:42:53 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9409B130FCB for ; Wed, 9 Jan 2019 13:42:53 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x09LRWXn014949; Wed, 9 Jan 2019 16:42:52 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2pwqkttxpb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Jan 2019 16:42:52 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x09LgpYx029368; Wed, 9 Jan 2019 16:42:51 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x09LgmbW029337; Wed, 9 Jan 2019 16:42:48 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id E4ED54013D37; Wed, 9 Jan 2019 21:42:48 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30484.vci.att.com (Service) with ESMTPS id 721CE400037E; Wed, 9 Jan 2019 21:42:48 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0415.000; Wed, 9 Jan 2019 16:42:47 -0500 From: "STARK, BARBARA H" To: "'David Schinazi'" CC: Babel at IETF Thread-Topic: babel-dtls: verifying "authentication" Thread-Index: AdSoVYQo0/ay4EhYQw+N2cLNVC6kSA== Date: Wed, 9 Jan 2019 21:42:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF8A154@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.217.171] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-09_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901090171 Archived-At: Subject: [babel] babel-dtls: verifying "authentication" X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 21:42:55 -0000 SSByZWFkIHRoZSBkcmFmdCBhbmQgdGhpbmsgdGhlIGxhc3QgcGFyYWdyYXBoIG9mIDIuMSBjb3Vs ZCBkbyB3aXRoIGEgbGl0dGxlIG1vcmUgdmVyYmlhZ2UgYXMgdG8gd2hhdCAiZmFpbHMgdG8gdmVy aWZ5IHRoZSBwZWVyJ3MgYXV0aGVudGljYXRpb24iIG1lYW5zLCBzaW5jZSBpdCdzIHBhcnQgb2Yg YSAiTVVTVCIgbm9ybWF0aXZlIHN0YXRlbWVudC4gSSBhbHNvIGRvbid0IHRoaW5rIHRoZSB3b3Jk ICJhdXRoZW50aWNhdGlvbiIgaXMgdXNlZCBjb25zaXN0ZW50bHkgb3IgKGluIHNvbWUgY2FzZXMp IGNvcnJlY3RseS4gSSB0aGluayBvZiAiYXV0aGVudGljYXRpb24iIGFzIGEgcHJvY2Vzcy4NCg0K SSBmaW5kICJyZXF1ZXN0IGNsaWVudCBhdXRoZW50aWNhdGlvbiIgYW5kICJ2ZXJpZnkgdGhlIHBl ZXIncyBhdXRoZW50aWNhdGlvbiIgdG8gYmUgb2RkIHVzZXMgb2YgdGhlIHdvcmQgImF1dGhlbnRp Y2F0aW9uIiwgYW5kIG5vdCBjb25zaXN0ZW50IHdpdGggbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUg d29yZC4gSSB3b3VsZCBzdWdnZXN0IHNvbWV0aGluZyBsaWtlICJyZXF1ZXN0IGNsaWVudCBjZXJ0 aWZpY2F0ZSIgKGNvbnNpc3RlbnQgd2l0aCB0aGUgbmFtZSBvZiB0aGUgbWVzc2FnZSB0aGF0IGlz IHNlbnQpIG9yICJyZXF1ZXN0IGNsaWVudCBjcmVkZW50aWFscyIgZm9yIHRoZSBmaXJzdCBwaHJh c2UuIEFuZCBwZXJoYXBzICJ2YWxpZGF0ZSB0aGUgcGVlcidzIGNlcnRpZmljYXRlIiBvciAidmFs aWRhdGUgdGhlIHBlZXIncyBjcmVkZW50aWFscyIgZm9yIHRoZSBzZWNvbmQuIFVubGVzcyB5b3Ug bWVhbiBzb21ldGhpbmcgZGlmZmVyZW50IGJ5ICJ2ZXJpZnkiIHZzLiAidmFsaWRhdGUiIGhlcmUu IA0KDQpXaWxsIG9ubHkgWC41MDkgY2VydGlmaWNhdGUga2V5cyBiZSBhbGxvd2VkLCBvciB3aWxs ICJESF9hbm9uIiBrZXkgZXhjaGFuZ2UgYmUgYWxsb3dlZD8gDQoNCkhlcmUgYXJlIHRoZSBwb3Nz aWJsZSB0aGluZ3MgdGhhdCBhcmUgc29tZXRpbWVzIGRvbmUgYXMgcGFydCBvZiBjZXJ0aWZpY2F0 ZSB2YWxpZGF0aW9uLCB0aGF0IEkgdGhpbmsgdGhpcyBwaHJhc2UgaXMgcG90ZW50aWFsbHkgcmVm ZXJyaW5nIHRvOg0KMS4gRW5zdXJlIHRoZSBjZXJ0aWZpY2F0ZSB2YWxpZERhdGUgaXMgbm90IGlu IHRoZSBwYXN0LiBUaGlzIGNoZWNrIHNob3VsZCBvbmx5IGJlIGRvbmUgaWYgdGhlIGltcGxlbWVu dGF0aW9uIHRoaW5rcyB0aGUgdW5kZXJseWluZyBzeXN0ZW0gaGFzIGFjcXVpcmVkIGEgZ29vZCBj dXJyZW50IHRpbWUgKGkuZS4sIGl0IHJ1bnMgYSBOVFAgY2xpZW50IGFuZCBnZXR0aW5nIHRoZSBj dXJyZW50IGRhdGV0aW1lIHZpYSBOVFAgaGFzIHN1Y2NlZWRlZCwgb3IgdGhlIGN1cnJlbnQgZGF0 ZXRpbWUgaGFzIGJlZW4gY29uZmlndXJlZCkuIA0KMi4gQ2hlY2sgdGhlIGNlcnRpZmljYXRlJ3Mg Y2hhaW4gb2YgdHJ1c3QgZm9yIGEgdHJ1c3RlZCBDQS4gVGhpcyB3b3VsZCBtZWFuIHRoZXJlIGlz IGEgY29uZmlndXJlZCBzZXQgb2YgdHJ1c3RlZCBDQXMuDQozLiBDaGVjayBpZiB0aGUgY2VydGlm aWNhdGUgaGFzIGJlZW4gcmV2b2tlZC4gVGhpcyBpcyBvZnRlbiBub3QgZG9uZSwgYnV0IG1pZ2h0 IG5vdCBiZSBhIGJhZCBpZGVhIHRoZSBmaXJzdCB0aW1lIHRoZSBjZXJ0aWZpY2F0ZSBpcyBzZWVu Lg0KNC4gQ2hlY2sgaWYgdGhpcyBpZGVudGljYWwgY2VydGlmaWNhdGUgaXMgaW5jbHVkZWQgaW4g YSBzdG9yZSBvZiB0cnVzdGVkIGNlcnRpZmljYXRlcyAoZWl0aGVyIGl0IHdhcyBwcmV2aW91c2x5 IHRydXN0ZWQgYW5kIHN0b3JlZCBvciB0aGUgc3RvcmUgaXMgY29uZmlndXJlZCkuDQo1LiBDaGVj ayBzb21lIGFzcGVjdCBvZiAiaWRlbnRpdHkiLiBJcyB0aGVyZSBzb21lIGNoYXJhY3RlcmlzdGlj IG9mIHRoZSBwZWVyIHRoYXQgaXMgZXhwZWN0ZWQgdG8gYmUgc3RhYmxlIHdydCBhIGNlcnRpZmlj YXRlPyBGb3IgZXhhbXBsZSwgd291bGQgdGhlIHNhbWUgY2VydGlmaWNhdGUgYWx3YXlzIG9yaWdp bmF0ZSBmcm9tIHRoZSBzYW1lIE1BQyBhZGRyZXNzIG9yIExMIElQdjYgYWRkcmVzcz8gDQo2LiBJ ZiBhIFRPRlUgKHRydXN0IG9uIGZpcnN0IHVzZSkgcG9saWN5IGlzIHN1cHBvcnRlZCwgd2hhdCBl eGFjdGx5IHNob3VsZCBiZSB0cnVzdGVkIChhbmQgd2hhdCBzaG91bGQgbm90IGJlIHRydXN0ZWQp PyBJIGRvIGxpa2UgYWxsb3dpbmcgZm9yIGEgVE9GVSBwb2xpY3kgKGlmIGFuIGltcGxlbWVudGF0 aW9uIGNob29zZXMgdG8gc3VwcG9ydCBvbmUpLiBJZiBpdCBpcyBhbGxvd2VkLCBJIHdvdWxkIHN1 Z2dlc3Qgc29tZXRoaW5nIGxpa2UgdGhlIGNlcnQgaXMgVE9GVSBpZiB0aGUgSVB2NiBMTCBhZGRy ZXNzIGhhc24ndCBiZWVuIHNlZW4gYmVmb3JlIChuZXcgbmVpZ2hib3IpLiBBZnRlciB0aGF0IGl0 IGFsd2F5cyBoYXMgdG8gdXNlIHRoZSBzYW1lIGNlcnQuIFdoZW4gY2hhbmdpbmcgY2VydHMsIHNl bmQgb2xkIGFuZCBuZXcgY2VydCB0b2dldGhlciBmb3Igc29tZSB0aW1lLCBzbyBuZXcgY2VydCBp cyBhc3NvY2lhdGVkIHdpdGggdHJ1c3RlZCBvbGQgY2VydC4NCg0KUHJlc3VtYWJseSwgYSBkZXZp Y2UgbWlnaHQgYmUgY29uZmlndXJlZCB3aXRoIGEgbmV3IGNlcnRpZmljYXRlIGF0IHNvbWUgcG9p bnQgKGxpa2Ugd2hlbiB0aGUgb2xkIG9uZSBleHBpcmVzKS4gV2lsbCB0aGUgbmV3IGNlcnRpZmlj YXRlIGJlIGNvbnNpZGVyZWQgdGhlIHNhbWUgbmVpZ2hib3IgaWYgdGhlICJpZGVudGl0eSIgbWF0 Y2hlcyAoc2VlIGl0ZW0gNSBmb3IgcXVlc3Rpb24gb24gZGV0ZXJtaW5pbmcgaWRlbnRpdHkpPyBJ ZiB5b3UgZ2V0IGEgcmVxdWVzdCBmb3IgYSBuZXcgRFRMUyBzZXNzaW9uIGFuZCBhbHJlYWR5IGhh dmUgYSBzZXNzaW9uIGZvciB0aGF0ICJpZGVudGl0eSIgKElQdjYgTEwgYWRkcmVzcz8pIHdpdGgg YSBkaWZmZXJlbnQgY2VydGlmaWNhdGUsIHdoYXQgZG8geW91IGRvPw0KDQpJZiB0aGVyZSBpcyBh bHJlYWR5IGEgRFRMUyBjb25uZWN0aW9uIHVzaW5nIGEgcHJvdmlkZWQgY2VydGlmaWNhdGUsIHdo YXQgZG8geW91IGRvIGlmIHlvdSBnZXQgYSByZXF1ZXN0IGZvciBhIG5ldyBEVExTIHNlc3Npb24g dXNpbmcgdGhlIHNhbWUgY2VydGlmaWNhdGU/IFRlYXIgZG93biB0aGUgb2xkIG9uZT8NCg0KV2l0 aCBhbGwgdGhpcyBzYWlkLiBJIHRoaW5rIGl0IG1pZ2h0IGJlIGVub3VnaCBpZiB0aGUgZHJhZnQg aGFkIHN0YXRlbWVudHMgbGlrZToNCiJUaGUga2V5IGV4Y2hhbmdlIG1lY2hhbmlzbSB1c2VkIE1V U1QgcmVxdWlyZSB1c2Ugb2YgWC41MDkgY2VydGlmaWNhdGVzLiIgKGlmIHRoaXMgaXMgdGhlIGlu dGVudCkNCiJDZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uIE1VU1QgYmUgZG9uZSBhY2NvcmRpbmcgdG8g aW50ZXJuYWwgcG9saWN5LiBDaGFyYWN0ZXJpc3RpY3Mgb2YgY2VydGlmaWNhdGVzIHRoYXQgTUFZ IGJlIHVzZWQgZm9yIHZhbGlkYXRpb24gaW5jbHVkZSB0aGUgdmFsaWREYXRlLCB0aGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5IChDQSkgY2hhaW4gb2YgdHJ1c3QsIGluY2x1c2lvbiBpbiBhIHJldm9j YXRpb24gbGlzdCwgcHJpb3IgZGV0ZXJtaW5hdGlvbiBvZiB0cnVzdCwgYW5kIHdoZXRoZXIgdGhl IElQdjYgbGluayBsb2NhbCBhZGRyZXNzIGlzIHRoZSBzYW1lIGFzIGluIHByaW9yIHVzZXMgb2Yg dGhlIGNlcnRpZmljYXRlLiBBIHRydXN0IG9uIGZpcnN0IHVzZSAoVE9GVSkgbW9kZWwgTUFZIGJl IHN1cHBvcnRlZCwgd2l0aCBwb2xpY3kgZGVmaW5lZCBieSB0aGUgaW1wbGVtZW50YXRpb24uIEFu eSBUT0ZVIHBvbGljeSBNVVNULCBhdCBhIG1pbmltdW0sIGVuc3VyZSB0aGF0IGEgZ2l2ZW4gY2Vy dGlmaWNhdGUgaXMgb25seSBldmVyIHVzZWQgZnJvbSBhIHNpbmdsZSBJUHY2IGxpbmsgbG9jYWwg YWRkcmVzcyAobmVpZ2hib3IpIGFuZCBmYWlsIGFuIHVua25vd24gY2VydGlmaWNhdGUgdXNlZCBm b3IgYW4gSVB2NiBsaW5rIGxvY2FsIGFkZHJlc3MgYWxyZWFkeSBhc3NvY2lhdGVkIHdpdGggYSB0 cnVzdGVkIGNlcnRpZmljYXRlLiAiDQoiV2hlbiBuZXcgY2VydGlmaWNhdGVzIGFyZSBpc3N1ZWQs IHRoZXkgU0hPVUxEIGJlIHNlbnQgdG9nZXRoZXIgd2l0aCB0aGUgb2xkIGNlcnRpZmljYXRlIHBy aW9yIHRvIHRoZSBvbGQgY2VydGlmaWNhdGUncyBleHBpcmF0aW9uIG9yIHJldm9jYXRpb24sIHNv IGl0IGlzIHBvc3NpYmxlIGZvciB0aGUgbmV3IGNlcnRpZmljYXRlIHRvIGluaGVyaXQgYW55IHRy dXN0IGFzc29jaWF0ZWQgd2l0aCB0aGUgb2xkIGNlcnRpZmljYXRlLiINCg0KT3IgbWFrZSBjZXJ0 aWZpY2F0ZSB2YWxpZGF0aW9uIGEgU0hPVUxELiDimLkNCkJhcmJhcmENCg== From nobody Wed Jan 9 13:47:07 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A0C12DD85; Wed, 9 Jan 2019 13:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gElS4ycuahyN; Wed, 9 Jan 2019 13:47:03 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB8B130FCB; Wed, 9 Jan 2019 13:47:03 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id g189so3876324pgc.5; Wed, 09 Jan 2019 13:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JEjJ6TSbvz7xf9uCGwxrjAj4/qoRgS0bWkv5NqOWTC8=; b=m6/EEDFFHRtMMs9xqgszCAjgWRJ91zebEmAp+U8TDrpNQ1hPFvgN31wHL8JWha9Pz5 VNQg9+N4zrgs+sodr3U00uZgXBrKAPy/MBqJ/dj2zHLcSe1/OjAAmuqxsjHNiIWFddmW 4pGd4t24iZQzbot2X5eSQzrSXTEhoAf4vaO+Kzcbr1iEjU0dYEjb3y46km7kFYeDCaLH U3o0pEerEq6cMP1R5QdxKiUJI7uF+I4I4tiVdEJW/40cTSUuTjU6vFcH7kMh+AtMXN5b EWMNSVdBeRIGFhCi39asoU53z29DQU/JDp4562u2kYGHZq15i5abAdGZFe3mHF8nQy90 Ao/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JEjJ6TSbvz7xf9uCGwxrjAj4/qoRgS0bWkv5NqOWTC8=; b=s5oB0miqIeNSsogHQQMSHTPbipWuNDXRQwQSwR4M2zide3MJxpTFf8brExzPXqC04x vwJ3aP5hb3pZ7xvsaq5vNKzQya6u6RWzauoDO3Da+E8b/Q3oXwUv1eiNrvsdA8jsSLjj rRPHePPjtTEh+qiqIRq0DjHERR0PP+f+LNF0Mv49bSWJrf11g6Xzhr0VTR5zhZHVuto1 ah4lEdPbvGheXa06CLmMfGEMXxauu3XPxVuA4xtAviIs5xM+efY/LxhkJp++lp5o9kR8 6sSergQv52z9gDGn+V33qmytllp/a/3aHpQYBDZzDtfRhP67x9nxRvMIPY/JEklNNBPV dX/w== X-Gm-Message-State: AJcUukdPRZF8uIetRTvNOQWHzep343tRzN78wv9dQf7buYxRBl+FSWh7 xvy0FaTzHAtOqrYFhvh4Nob5Tnk3mKyzYR3a+ps= X-Google-Smtp-Source: ALg8bN5kG2oxPnOokZiwOQpKoAxkyfHCZYRWnkYPZC+BmafwucUPtdNixvSVANACi3zX3dc58dZxc03NaQdef4QWWTQ= X-Received: by 2002:a63:7e1a:: with SMTP id z26mr6786374pgc.216.1547070422541; Wed, 09 Jan 2019 13:47:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Wed, 9 Jan 2019 13:46:51 -0800 Message-ID: To: Dave Taht Cc: =?UTF-8?Q?Antonin_D=C3=A9cimo?= , Donald Eastlake , draft-ietf-babel-dtls@ietf.org, babel-chairs , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000fa6d27057f0d66db" Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-dtls-03 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 21:47:05 -0000 --000000000000fa6d27057f0d66db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, The questions you ask are answered in different sections of the draft. If you have suggestions on how to clarify the document, please let us know we'd love to make it as clear as possible. David On Wed, Jan 9, 2019 at 1:40 PM Dave Taht wrote: > well, I've been playing catchup on these drafts for a while and had > barely looked at this before now. > > * As usual, I like having two interoperable implementations before > committing to a draft. > > To me, this is unclear: > > " When a Babel node > discovers a new neighbor (generally by receiving an unencrypted > multicast Babel packet), it compares the neighbour's IPv6 link-local > address with its own, using network byte ordering. If a node's > address is lower than the recently discovered neighbor's address, it > acts as a client and connects to the neighbor. In other words, the > node with the lowest address is the DTLS client for this pairwise > relationship. As an example, fe80::1:2 is considered lower than > fe80::2:1." > > A DTLS enabled node receiving that unencrypted multicast hello packet > (on the main babel port? on the dtls port?), is then supposed to try > contacting the other router on the DTLS port? > > Recieving a hello from a lower numbered fe80 address means you wait > for the lower numbered fe80 address to initiate (so you send a hello > with or without an ihu?) > > So a DOS attack is merely lots of hellos and a very slow DTLS > exchange? (what are the timeouts associated with a DTLS negotiation?) > > In the HMAC draft there was a 300ms timeout suggested for some things. > > > On Wed, Jan 9, 2019 at 11:33 AM David Schinazi > wrote: > > > > (Stating the obvious, as co-author) I support publication. > > > > On Wed, Jan 9, 2019 at 10:30 AM Antonin D=C3=A9cimo > wrote: > >> > >> Hello Donald, > >> > >> I support publication. > >> > >> -- Antonin > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://www.ietf.org/mailman/listinfo/babel > > > > -- > > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 > --000000000000fa6d27057f0d66db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,

The questions you ask are answ= ered in different sections of the draft.
If you have suggestions = on how to clarify the document, please let us know
we'd love = to make it as clear as possible.

David
=
On Wed, Jan 9, 2019 at 1:40= PM Dave Taht <dave.taht@gmail.co= m> wrote:
well, I've been playing catchup on these drafts for a while and had barely looked at this before now.

* As usual, I like having two interoperable implementations before
committing to a draft.

To me, this is unclear:

" When a Babel node
=C2=A0 =C2=A0discovers a new neighbor (generally by receiving an unencrypte= d
=C2=A0 =C2=A0multicast Babel packet), it compares the neighbour's IPv6 = link-local
=C2=A0 =C2=A0address with its own, using network byte ordering.=C2=A0 If a = node's
=C2=A0 =C2=A0address is lower than the recently discovered neighbor's a= ddress, it
=C2=A0 =C2=A0acts as a client and connects to the neighbor.=C2=A0 In other = words, the
=C2=A0 =C2=A0node with the lowest address is the DTLS client for this pairw= ise
=C2=A0 =C2=A0relationship.=C2=A0 As an example, fe80::1:2 is considered low= er than
=C2=A0 =C2=A0fe80::2:1."

A DTLS enabled node receiving that unencrypted multicast hello packet
(on the main babel port? on the dtls port?), is then supposed to try
contacting the other router on the DTLS port?

Recieving a hello from a lower numbered fe80 address means you wait
for the lower numbered fe80 address to initiate (so you send a hello
with or without an ihu?)

So a DOS attack is merely lots of hellos and a very slow DTLS
exchange? (what are the timeouts associated with a DTLS negotiation?)

In the HMAC draft there was a 300ms timeout suggested for some things.


On Wed, Jan 9, 2019 at 11:33 AM David Schinazi <dschinazi.ietf@gmail.com> wrot= e:
>
> (Stating the obvious, as co-author) I support publication.
>
> On Wed, Jan 9, 2019 at 10:30 AM Antonin D=C3=A9cimo <antonin.decimo@gmail.com> wrote:
>>
>> Hello Donald,
>>
>> I support publication.
>>
>> -- Antonin
>
> _______________________________________________
> babel mailing list
> babel@ietf.org=
> https://www.ietf.org/mailman/listinfo/babel



--

Dave T=C3=A4ht
CTO, TekLibre, LLC
ht= tp://www.teklibre.com
Tel: 1-831-205-9740
--000000000000fa6d27057f0d66db-- From nobody Wed Jan 9 14:06:56 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E98A126DBF for ; Wed, 9 Jan 2019 14:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPyPSeF56-0S for ; Wed, 9 Jan 2019 14:06:52 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C5312D4F2 for ; Wed, 9 Jan 2019 14:06:51 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id w7so3873809pgp.13 for ; Wed, 09 Jan 2019 14:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/4UPWuuP4CvNBhp4VKYcb1Rn3+fSCZi+FIo6RcLuKf0=; b=WLDk1KEVelOUcOY2hpE4KXc+qgaSJuJYiWEDdyARa8UWYEDryjKz7yKEi5f5kzG5HG 14UUxsNkrgp9o+DyissirQtoH6BebAqraxW9aikI5QGEly+hTXg5QeetJ/xeixQ2x+bY x7ttpusiogBS/YUyAT5O4Ijw+dicJVidNJ4htpukiUWPtKzqFz0admW+ME5tGRLZYR+J i0JiePv6yfIKYsebT3Ylt2Hm5LGIWu7Obpe46zJ5apRas+whkGsLtR+slkqPntnH3NPw qG+U6pq1+SnQ4RrRJQl2/y4PDmp290RwPFxWEIaHQ6fuubBqijoFbuuGER7GTF15W+j0 kX7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/4UPWuuP4CvNBhp4VKYcb1Rn3+fSCZi+FIo6RcLuKf0=; b=HQ/Gu7codrmA+rpL3nhlZpi43x+NJx8BeVdprI20pWDcLr0uqFlKdTnFJ8Ly8xdBi+ 8kDGBYpgzycdCnufZ/MSsawyOoqsvVcO4yBBUfYQOp5M84ZvaFiCETUjzc/55KwFoX+B Quhbho8YUzKA8fviX/+6uJMUTSl48mCAyItZfzYJADF8+YRDDSA4qswAbbJR94VBBQib PrgrIYNuw9BfgYL2kTthAaDtRyKm+f6F+V8nC77QbYN50fow6MJXtcCaqGJSEF5YAd6E 7IIGZ4uuCFM6cRiJSY6262YkoC/5fyX4A9yt4sSHESexjOYcR+tvJT6Ir4ogeVAPQyHu UNqg== X-Gm-Message-State: AJcUukf1Y3b8J+QXJuTl1xjkloC70916zITOJH+i7nbWEvXbd/RgeYMJ 9aYzmje53Jx7AVsNWuTaRyBs87G1ER6N/zNNRdE= X-Google-Smtp-Source: ALg8bN5bR0dXLfrr0fBC1nSnuFSz9pH0GA8nwvQLFB0wUdgfJT67NAsaQCbo31nIGCvXCpHkGGva1qosHtbkmmIT5EQ= X-Received: by 2002:a62:1b83:: with SMTP id b125mr8003818pfb.42.1547071611382; Wed, 09 Jan 2019 14:06:51 -0800 (PST) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DF8A154@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF8A154@GAALPA1MSGUSRBF.ITServices.sbc.com> From: David Schinazi Date: Wed, 9 Jan 2019 14:06:40 -0800 Message-ID: To: "STARK, BARBARA H" Cc: Babel at IETF Content-Type: multipart/alternative; boundary="000000000000d6af0c057f0dad26" Archived-At: Subject: Re: [babel] babel-dtls: verifying "authentication" X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2019 22:06:55 -0000 --000000000000d6af0c057f0dad26 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Barbara, Thanks for your review. Responses inline. On Wed, Jan 9, 2019 at 1:42 PM STARK, BARBARA H wrote: > I read the draft and think the last paragraph of 2.1 could do with a > little more verbiage as to what "fails to verify the peer's authenticatio= n" > means, since it's part of a "MUST" normative statement. I also don't thin= k > the word "authentication" is used consistently or (in some cases) > correctly. I think of "authentication" as a process. > > I find "request client authentication" and "verify the peer's > authentication" to be odd uses of the word "authentication", and not > consistent with my understanding of the word. I would suggest something > like "request client certificate" (consistent with the name of the messag= e > that is sent) or "request client credentials" for the first phrase. And > perhaps "validate the peer's certificate" or "validate the peer's > credentials" for the second. Unless you mean something different by > "verify" vs. "validate" here. > Our intent was to use the terms authenticate and authentication in the same way as the TLS specifications do, in particular see the TLS 1.3 spec introduction . > Will only X.509 certificate keys be allowed, or will "DH_anon" key > exchange be allowed? > babel-dtls does not specify what source of authentication to use, X509 are one allowed option, but they are not mandated DH_anon is prohibited by "Nodes MUST use mutual authentication" (and subsequent clarifying text in section 2.1) > Here are the possible things that are sometimes done as part of > certificate validation, that I think this phrase is potentially referring > to: > 1. Ensure the certificate validDate is not in the past. This check should > only be done if the implementation thinks the underlying system has > acquired a good current time (i.e., it runs a NTP client and getting the > current datetime via NTP has succeeded, or the current datetime has been > configured). > 2. Check the certificate's chain of trust for a trusted CA. This would > mean there is a configured set of trusted CAs. > 3. Check if the certificate has been revoked. This is often not done, but > might not be a bad idea the first time the certificate is seen. > 4. Check if this identical certificate is included in a store of trusted > certificates (either it was previously trusted and stored or the store is > configured). > 5. Check some aspect of "identity". Is there some characteristic of the > peer that is expected to be stable wrt a certificate? For example, would > the same certificate always originate from the same MAC address or LL IPv= 6 > address? > 6. If a TOFU (trust on first use) policy is supported, what exactly shoul= d > be trusted (and what should not be trusted)? I do like allowing for a TOF= U > policy (if an implementation chooses to support one). If it is allowed, I > would suggest something like the cert is TOFU if the IPv6 LL address hasn= 't > been seen before (new neighbor). After that it always has to use the same > cert. When changing certs, send old and new cert together for some time, = so > new cert is associated with trusted old cert. > > Presumably, a device might be configured with a new certificate at some > point (like when the old one expires). Will the new certificate be > considered the same neighbor if the "identity" matches (see item 5 for > question on determining identity)? If you get a request for a new DTLS > session and already have a session for that "identity" (IPv6 LL address?) > with a different certificate, what do you do? > > If there is already a DTLS connection using a provided certificate, what > do you do if you get a request for a new DTLS session using the same > certificate? Tear down the old one? > > With all this said. I think it might be enough if the draft had statement= s > like: > "The key exchange mechanism used MUST require use of X.509 certificates." > (if this is the intent) > "Certificate validation MUST be done according to internal policy. > Characteristics of certificates that MAY be used for validation include t= he > validDate, the Certificate Authority (CA) chain of trust, inclusion in a > revocation list, prior determination of trust, and whether the IPv6 link > local address is the same as in prior uses of the certificate. A trust on > first use (TOFU) model MAY be supported, with policy defined by the > implementation. Any TOFU policy MUST, at a minimum, ensure that a given > certificate is only ever used from a single IPv6 link local address > (neighbor) and fail an unknown certificate used for an IPv6 link local > address already associated with a trusted certificate. " > "When new certificates are issued, they SHOULD be sent together with the > old certificate prior to the old certificate's expiration or revocation, = so > it is possible for the new certificate to inherit any trust associated wi= th > the old certificate." > Certificate validation is out of scope for the babel-dtls draft, in the same manner as it is out of scope for the TLS or DTLS RFCs. I don't think any mention of certificates at all belongs in this draft, as some applications may choose to not use certificates. In the case of babel, the babel-dtls draft specifies how to use DTLS; on the other hand the certificates and PKI you use is left to the users of babel-dtls, for example the homenet mapping document could mandate X509 and how to add new certificates to the trust store, and the other points you mentioned would make sense to me in that document. Or make certificate validation a SHOULD. =E2=98=B9 > Validating identity is a MUST, the fact that that identity maps to a certificate is a MAY. Thanks, David --000000000000d6af0c057f0dad26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Barbara,

Thanks for your review. Responses inline.

On Wed, Jan 9, 2019 at 1:42 PM STARK, BAR= BARA H <bs7652@att.com> wrote:<= br>
I read the draft= and think the last paragraph of 2.1 could do with a little more verbiage a= s to what "fails to verify the peer's authentication" means, = since it's part of a "MUST" normative statement. I also don&#= 39;t think the word "authentication" is used consistently or (in = some cases) correctly. I think of "authentication" as a process.<= br>
I find "request client authentication" and "verify the peer&= #39;s authentication" to be odd uses of the word "authentication&= quot;, and not consistent with my understanding of the word. I would sugges= t something like "request client certificate" (consistent with th= e name of the message that is sent) or "request client credentials&quo= t; for the first phrase. And perhaps "validate the peer's certific= ate" or "validate the peer's credentials" for the second= . Unless you mean something different by "verify" vs. "valid= ate" here.

Our intent was to use = the terms authenticate and authentication in the same way as the TLS specif= ications do, in particular see the TLS 1.3 spec introduction.
=C2=A0
Will only X.509 certificate keys be allowed, or will "DH_anon" ke= y exchange be allowed?

babel-dtls does= not specify what source of authentication to use, X509 are one allowed opt= ion, but they are not mandated
DH_anon is prohibited by "Nod= es MUST use mutual authentication" (and subsequent clarifying text in = section 2.1)
=C2=A0
Here are the possible things that are sometimes done as part of certificate= validation, that I think this phrase is potentially referring to:
1. Ensure the certificate validDate is not in the past. This check should o= nly be done if the implementation thinks the underlying system has acquired= a good current time (i.e., it runs a NTP client and getting the current da= tetime via NTP has succeeded, or the current datetime has been configured).=
2. Check the certificate's chain of trust for a trusted CA. This would = mean there is a configured set of trusted CAs.
3. Check if the certificate has been revoked. This is often not done, but m= ight not be a bad idea the first time the certificate is seen.
4. Check if this identical certificate is included in a store of trusted ce= rtificates (either it was previously trusted and stored or the store is con= figured).
5. Check some aspect of "identity". Is there some characteristic = of the peer that is expected to be stable wrt a certificate? For example, w= ould the same certificate always originate from the same MAC address or LL = IPv6 address?
6. If a TOFU (trust on first use) policy is supported, what exactly should = be trusted (and what should not be trusted)? I do like allowing for a TOFU = policy (if an implementation chooses to support one). If it is allowed, I w= ould suggest something like the cert is TOFU if the IPv6 LL address hasn= 9;t been seen before (new neighbor). After that it always has to use the sa= me cert. When changing certs, send old and new cert together for some time,= so new cert is associated with trusted old cert.

Presumably, a device might be configured with a new certificate at some poi= nt (like when the old one expires). Will the new certificate be considered = the same neighbor if the "identity" matches (see item 5 for quest= ion on determining identity)? If you get a request for a new DTLS session a= nd already have a session for that "identity" (IPv6 LL address?) = with a different certificate, what do you do?

If there is already a DTLS connection using a provided certificate, what do= you do if you get a request for a new DTLS session using the same certific= ate? Tear down the old one?

With all this said. I think it might be enough if the draft had statements = like:
"The key exchange mechanism used MUST require use of X.509 certificate= s." (if this is the intent)
"Certificate validation MUST be done according to internal policy. Cha= racteristics of certificates that MAY be used for validation include the va= lidDate, the Certificate Authority (CA) chain of trust, inclusion in a revo= cation list, prior determination of trust, and whether the IPv6 link local = address is the same as in prior uses of the certificate. A trust on first u= se (TOFU) model MAY be supported, with policy defined by the implementation= . Any TOFU policy MUST, at a minimum, ensure that a given certificate is on= ly ever used from a single IPv6 link local address (neighbor) and fail an u= nknown certificate used for an IPv6 link local address already associated w= ith a trusted certificate. "
"When new certificates are issued, they SHOULD be sent together with t= he old certificate prior to the old certificate's expiration or revocat= ion, so it is possible for the new certificate to inherit any trust associa= ted with the old certificate."

Cer= tificate validation is out of scope for the babel-dtls draft, in the same m= anner as it is out of scope for the TLS or DTLS RFCs. I don't think any= mention of certificates at all belongs in this draft, as some applications= may choose to not use certificates. In the case of babel, the babel-dtls d= raft specifies how to use DTLS; on the other hand the certificates and PKI = you use is left to the users of babel-dtls, for example the homenet mapping= document could mandate X509 and how to add new certificates to the trust s= tore, and the other points you mentioned would make sense to me in that doc= ument.=C2=A0

Or make certificate validation a SHOULD. =E2=98=B9
Validating identity is a MUST, the fact that that identity maps= to a certificate is a MAY.

Thanks,
Davi= d
--000000000000d6af0c057f0dad26-- From nobody Wed Jan 9 19:18:07 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89A41310E8 for ; Wed, 9 Jan 2019 19:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ccOn1haoWgm for ; Wed, 9 Jan 2019 19:18:03 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E16B1310DE for ; Wed, 9 Jan 2019 19:18:03 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x0A3Ekrd023111; Wed, 9 Jan 2019 22:18:01 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2pwv27291q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Jan 2019 22:18:01 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0A3HvZY018201; Wed, 9 Jan 2019 22:17:58 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0A3Hpsc018129; Wed, 9 Jan 2019 22:17:52 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id E9EB1402EFA8; Thu, 10 Jan 2019 03:17:51 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30485.vci.att.com (Service) with ESMTPS id CF53740002DB; Thu, 10 Jan 2019 03:17:51 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0415.000; Wed, 9 Jan 2019 22:17:51 -0500 From: "STARK, BARBARA H" To: "'David Schinazi'" CC: Babel at IETF Thread-Topic: babel-dtls: verifying "authentication" Thread-Index: AdSoVYQo0/ay4EhYQw+N2cLNVC6kSAAO/2EAAAFCPHA= Date: Thu, 10 Jan 2019 03:17:50 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF8A9A3@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF8A154@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.217.171] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114DF8A9A3GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-10_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901100025 Archived-At: Subject: Re: [babel] babel-dtls: verifying "authentication" X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 03:18:06 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114DF8A9A3GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBXZWQsIEphbiA5LCAyMDE5IGF0IDE6NDIgUE0gU1RBUkssIEJBUkJBUkEgSCA8YnM3NjUy QGF0dC5jb208bWFpbHRvOmJzNzY1MkBhdHQuY29tPj4gd3JvdGU6DQpJIHJlYWQgdGhlIGRyYWZ0 IGFuZCB0aGluayB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgMi4xIGNvdWxkIGRvIHdpdGggYSBsaXR0 bGUgbW9yZSB2ZXJiaWFnZSBhcyB0byB3aGF0ICJmYWlscyB0byB2ZXJpZnkgdGhlIHBlZXIncyBh dXRoZW50aWNhdGlvbiIgbWVhbnMsIHNpbmNlIGl0J3MgcGFydCBvZiBhICJNVVNUIiBub3JtYXRp dmUgc3RhdGVtZW50LiBJIGFsc28gZG9uJ3QgdGhpbmsgdGhlIHdvcmQgImF1dGhlbnRpY2F0aW9u IiBpcyB1c2VkIGNvbnNpc3RlbnRseSBvciAoaW4gc29tZSBjYXNlcykgY29ycmVjdGx5LiBJIHRo aW5rIG9mICJhdXRoZW50aWNhdGlvbiIgYXMgYSBwcm9jZXNzLg0KDQpJIGZpbmQgInJlcXVlc3Qg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIiBhbmQgInZlcmlmeSB0aGUgcGVlcidzIGF1dGhlbnRpY2F0 aW9uIiB0byBiZSBvZGQgdXNlcyBvZiB0aGUgd29yZCAiYXV0aGVudGljYXRpb24iLCBhbmQgbm90 IGNvbnNpc3RlbnQgd2l0aCBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSB3b3JkLiBJIHdvdWxkIHN1 Z2dlc3Qgc29tZXRoaW5nIGxpa2UgInJlcXVlc3QgY2xpZW50IGNlcnRpZmljYXRlIiAoY29uc2lz dGVudCB3aXRoIHRoZSBuYW1lIG9mIHRoZSBtZXNzYWdlIHRoYXQgaXMgc2VudCkgb3IgInJlcXVl c3QgY2xpZW50IGNyZWRlbnRpYWxzIiBmb3IgdGhlIGZpcnN0IHBocmFzZS4gQW5kIHBlcmhhcHMg InZhbGlkYXRlIHRoZSBwZWVyJ3MgY2VydGlmaWNhdGUiIG9yICJ2YWxpZGF0ZSB0aGUgcGVlcidz IGNyZWRlbnRpYWxzIiBmb3IgdGhlIHNlY29uZC4gVW5sZXNzIHlvdSBtZWFuIHNvbWV0aGluZyBk aWZmZXJlbnQgYnkgInZlcmlmeSIgdnMuICJ2YWxpZGF0ZSIgaGVyZS4NCg0KT3VyIGludGVudCB3 YXMgdG8gdXNlIHRoZSB0ZXJtcyBhdXRoZW50aWNhdGUgYW5kIGF1dGhlbnRpY2F0aW9uIGluIHRo ZSBzYW1lIHdheSBhcyB0aGUgVExTIHNwZWNpZmljYXRpb25zIGRvLCBpbiBwYXJ0aWN1bGFyIHNl ZSB0aGUgVExTIDEuMyBzcGVjIGludHJvZHVjdGlvbjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjODQ0Ni0y M3NlY3Rpb24tMkQxJmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy04 c2M4U1k4VHE0dnJmb2cmbT1ZQzcyUGpmbFJYbl9HZ2lGNU1ldEJjRFpsTG5lekNDQ2NHeUtJQm51 ZzBnJnM9b0JGOTZzakNETDVRSTVHcFBrYk5TX0thdldwZ3Y5a2ZXNVFvMU4weWUyMCZlPT4uDQoN CjxiaHM+IEkgbG9va2VkIGF0IHRoZSBUTFMgMS4zIHNwZWMsIGFuZCB0aGUgdXNlIG9mIOKAnGF1 dGhlbnRpY2F0aW9u4oCdIHRoZXJlIGlzIHZlcnkgY29uc2lzdGVudCB3aXRoIG15IHVuZGVyc3Rh bmRpbmcgb2YgYXV0aGVudGljYXRpb24gYXMgYSBwcm9jZXNzLiBUaGUgMiBwaHJhc2VzIEkgbm90 ZWQgc2VlbSB0byB1c2Ug4oCcYXV0aGVudGljYXRpb27igJ0gYXMgaWYgaXQgbWVhbnQg4oCcYXV0 aGVudGljYXRpb24ga2V54oCdIOKAkyB3aGljaCBpdCBkb2VzIG5vdC4gVGhlIENlcnRpZmljYXRl UmVxdWVzdCBtZXNzYWdlIGlzIG5vdCB1c2VkIHRvIHJlcXVlc3QgY2xpZW50IGF1dGhlbnRpY2F0 aW9uIChpLmUuLCByZXF1ZXN0IHRoZSBjbGllbnQgcGVyZm9ybSB0aGUgYXV0aGVudGljYXRpb24g cHJvY2VzcykuIEl0IGlzIHVzZWQgdG8gcmVxdWVzdCBhIGNsaWVudCBhdXRoZW50aWNhdGlvbiBr ZXkuIFlvdSBjYW5ub3QgdmVyaWZ5IGFuIGF1dGhlbnRpY2F0aW9uLiBCdXQgeW91IGNhbiB2ZXJp ZnkgYW4gYXV0aGVudGljYXRpb24ga2V5Lg0KDQpXaWxsIG9ubHkgWC41MDkgY2VydGlmaWNhdGUg a2V5cyBiZSBhbGxvd2VkLCBvciB3aWxsICJESF9hbm9uIiBrZXkgZXhjaGFuZ2UgYmUgYWxsb3dl ZD8NCg0KYmFiZWwtZHRscyBkb2VzIG5vdCBzcGVjaWZ5IHdoYXQgc291cmNlIG9mIGF1dGhlbnRp Y2F0aW9uIHRvIHVzZSwgWDUwOSBhcmUgb25lIGFsbG93ZWQgb3B0aW9uLCBidXQgdGhleSBhcmUg bm90IG1hbmRhdGVkDQpESF9hbm9uIGlzIHByb2hpYml0ZWQgYnkgIk5vZGVzIE1VU1QgdXNlIG11 dHVhbCBhdXRoZW50aWNhdGlvbiIgKGFuZCBzdWJzZXF1ZW50IGNsYXJpZnlpbmcgdGV4dCBpbiBz ZWN0aW9uIDIuMSkNCg0KPGJocz4gVExTIDEuMiAoUkZDIDUyNDYpIHNheXMg4oCcVGhlIGZvbGxv d2luZyBydWxlcyBhcHBseSB0byB0aGUgY2VydGlmaWNhdGVzIHNlbnQgYnkgdGhlIHNlcnZlcjoN CiAgIC0gIFRoZSBjZXJ0aWZpY2F0ZSB0eXBlIE1VU1QgYmUgWC41MDl2MywgdW5sZXNzIGV4cGxp Y2l0bHkgbmVnb3RpYXRlZCBvdGhlcndpc2UgKGUuZy4sIFtUTFNQR1BdKS7igJ0NCkRUTFMgKFJG QyA2MzQ3KSBkb2VzbuKAmXQgbW9kaWZ5IHRoaXMgcmVxdWlyZW1lbnQgYW5kIG5laXRoZXIgRFRM UyBub3IgYmFiZWwtRFRMUyByZXF1aXJlcyBzdXBwb3J0IGZvciBjZXJ0aWZpY2F0ZSBmb3JtYXQg bmVnb3RpYXRpb24uIEV2ZXJ5IGJhYmVsLWR0bHMgaW1wbGVtZW50YXRpb24gaGFzIHRvIGJlIHBy ZXBhcmVkIHRvIGFjdCBhcyB0aGUgRFRMUyBzZXJ2ZXIuIFByYWN0aWNhbGx5IHNwZWFraW5nIGRv ZXNu4oCZdCB0aGlzIG1lYW4gZXZlcnkgYmFiZWwtZHRscyBpbXBsZW1lbnRhdGlvbiB0aGF0IGV4 cGVjdHMgdG8gaW50ZXJvcGVyYXRlIGluIGFuIG9wZW4gZW52aXJvbm1lbnQgaGFzIHRvIGVpdGhl ciBoYXZlIG9yIGJlIGFibGUgdG8gZ2VuZXJhdGUgYW4gWC41MDkgY2VydGlmaWNhdGU/IEFueXRo aW5nIGxlc3MgYW5kIHRoZXJlIGNhbiBiZSBubyBleHBlY3RhdGlvbiBvZiBpbnRlcm9wZXJhYmls aXR5LiBDbGVhcmx5LCBhIGNsb3NlZCBlbnZpcm9ubWVudCBjYW4gdXNlIHdoYXRldmVyIGl0IHdh bnRzLiBCdXQgSSBkb27igJl0IGZpbmQgY2xvc2VkIGVudmlyb25tZW50cyB2ZXJ5IGludGVyZXN0 aW5nLg0KDQpIZXJlIGFyZSB0aGUgcG9zc2libGUgdGhpbmdzIHRoYXQgYXJlIHNvbWV0aW1lcyBk b25lIGFzIHBhcnQgb2YgY2VydGlmaWNhdGUgdmFsaWRhdGlvbiwgdGhhdCBJIHRoaW5rIHRoaXMg cGhyYXNlIGlzIHBvdGVudGlhbGx5IHJlZmVycmluZyB0bzoNCjEuIEVuc3VyZSB0aGUgY2VydGlm aWNhdGUgdmFsaWREYXRlIGlzIG5vdCBpbiB0aGUgcGFzdC4gVGhpcyBjaGVjayBzaG91bGQgb25s eSBiZSBkb25lIGlmIHRoZSBpbXBsZW1lbnRhdGlvbiB0aGlua3MgdGhlIHVuZGVybHlpbmcgc3lz dGVtIGhhcyBhY3F1aXJlZCBhIGdvb2QgY3VycmVudCB0aW1lIChpLmUuLCBpdCBydW5zIGEgTlRQ IGNsaWVudCBhbmQgZ2V0dGluZyB0aGUgY3VycmVudCBkYXRldGltZSB2aWEgTlRQIGhhcyBzdWNj ZWVkZWQsIG9yIHRoZSBjdXJyZW50IGRhdGV0aW1lIGhhcyBiZWVuIGNvbmZpZ3VyZWQpLg0KMi4g Q2hlY2sgdGhlIGNlcnRpZmljYXRlJ3MgY2hhaW4gb2YgdHJ1c3QgZm9yIGEgdHJ1c3RlZCBDQS4g VGhpcyB3b3VsZCBtZWFuIHRoZXJlIGlzIGEgY29uZmlndXJlZCBzZXQgb2YgdHJ1c3RlZCBDQXMu DQozLiBDaGVjayBpZiB0aGUgY2VydGlmaWNhdGUgaGFzIGJlZW4gcmV2b2tlZC4gVGhpcyBpcyBv ZnRlbiBub3QgZG9uZSwgYnV0IG1pZ2h0IG5vdCBiZSBhIGJhZCBpZGVhIHRoZSBmaXJzdCB0aW1l IHRoZSBjZXJ0aWZpY2F0ZSBpcyBzZWVuLg0KNC4gQ2hlY2sgaWYgdGhpcyBpZGVudGljYWwgY2Vy dGlmaWNhdGUgaXMgaW5jbHVkZWQgaW4gYSBzdG9yZSBvZiB0cnVzdGVkIGNlcnRpZmljYXRlcyAo ZWl0aGVyIGl0IHdhcyBwcmV2aW91c2x5IHRydXN0ZWQgYW5kIHN0b3JlZCBvciB0aGUgc3RvcmUg aXMgY29uZmlndXJlZCkuDQo1LiBDaGVjayBzb21lIGFzcGVjdCBvZiAiaWRlbnRpdHkiLiBJcyB0 aGVyZSBzb21lIGNoYXJhY3RlcmlzdGljIG9mIHRoZSBwZWVyIHRoYXQgaXMgZXhwZWN0ZWQgdG8g YmUgc3RhYmxlIHdydCBhIGNlcnRpZmljYXRlPyBGb3IgZXhhbXBsZSwgd291bGQgdGhlIHNhbWUg Y2VydGlmaWNhdGUgYWx3YXlzIG9yaWdpbmF0ZSBmcm9tIHRoZSBzYW1lIE1BQyBhZGRyZXNzIG9y IExMIElQdjYgYWRkcmVzcz8NCjYuIElmIGEgVE9GVSAodHJ1c3Qgb24gZmlyc3QgdXNlKSBwb2xp Y3kgaXMgc3VwcG9ydGVkLCB3aGF0IGV4YWN0bHkgc2hvdWxkIGJlIHRydXN0ZWQgKGFuZCB3aGF0 IHNob3VsZCBub3QgYmUgdHJ1c3RlZCk/IEkgZG8gbGlrZSBhbGxvd2luZyBmb3IgYSBUT0ZVIHBv bGljeSAoaWYgYW4gaW1wbGVtZW50YXRpb24gY2hvb3NlcyB0byBzdXBwb3J0IG9uZSkuIElmIGl0 IGlzIGFsbG93ZWQsIEkgd291bGQgc3VnZ2VzdCBzb21ldGhpbmcgbGlrZSB0aGUgY2VydCBpcyBU T0ZVIGlmIHRoZSBJUHY2IExMIGFkZHJlc3MgaGFzbid0IGJlZW4gc2VlbiBiZWZvcmUgKG5ldyBu ZWlnaGJvcikuIEFmdGVyIHRoYXQgaXQgYWx3YXlzIGhhcyB0byB1c2UgdGhlIHNhbWUgY2VydC4g V2hlbiBjaGFuZ2luZyBjZXJ0cywgc2VuZCBvbGQgYW5kIG5ldyBjZXJ0IHRvZ2V0aGVyIGZvciBz b21lIHRpbWUsIHNvIG5ldyBjZXJ0IGlzIGFzc29jaWF0ZWQgd2l0aCB0cnVzdGVkIG9sZCBjZXJ0 Lg0KDQpQcmVzdW1hYmx5LCBhIGRldmljZSBtaWdodCBiZSBjb25maWd1cmVkIHdpdGggYSBuZXcg Y2VydGlmaWNhdGUgYXQgc29tZSBwb2ludCAobGlrZSB3aGVuIHRoZSBvbGQgb25lIGV4cGlyZXMp LiBXaWxsIHRoZSBuZXcgY2VydGlmaWNhdGUgYmUgY29uc2lkZXJlZCB0aGUgc2FtZSBuZWlnaGJv ciBpZiB0aGUgImlkZW50aXR5IiBtYXRjaGVzIChzZWUgaXRlbSA1IGZvciBxdWVzdGlvbiBvbiBk ZXRlcm1pbmluZyBpZGVudGl0eSk/IElmIHlvdSBnZXQgYSByZXF1ZXN0IGZvciBhIG5ldyBEVExT IHNlc3Npb24gYW5kIGFscmVhZHkgaGF2ZSBhIHNlc3Npb24gZm9yIHRoYXQgImlkZW50aXR5IiAo SVB2NiBMTCBhZGRyZXNzPykgd2l0aCBhIGRpZmZlcmVudCBjZXJ0aWZpY2F0ZSwgd2hhdCBkbyB5 b3UgZG8/DQoNCklmIHRoZXJlIGlzIGFscmVhZHkgYSBEVExTIGNvbm5lY3Rpb24gdXNpbmcgYSBw cm92aWRlZCBjZXJ0aWZpY2F0ZSwgd2hhdCBkbyB5b3UgZG8gaWYgeW91IGdldCBhIHJlcXVlc3Qg Zm9yIGEgbmV3IERUTFMgc2Vzc2lvbiB1c2luZyB0aGUgc2FtZSBjZXJ0aWZpY2F0ZT8gVGVhciBk b3duIHRoZSBvbGQgb25lPw0KDQpXaXRoIGFsbCB0aGlzIHNhaWQuIEkgdGhpbmsgaXQgbWlnaHQg YmUgZW5vdWdoIGlmIHRoZSBkcmFmdCBoYWQgc3RhdGVtZW50cyBsaWtlOg0KIlRoZSBrZXkgZXhj aGFuZ2UgbWVjaGFuaXNtIHVzZWQgTVVTVCByZXF1aXJlIHVzZSBvZiBYLjUwOSBjZXJ0aWZpY2F0 ZXMuIiAoaWYgdGhpcyBpcyB0aGUgaW50ZW50KQ0KIkNlcnRpZmljYXRlIHZhbGlkYXRpb24gTVVT VCBiZSBkb25lIGFjY29yZGluZyB0byBpbnRlcm5hbCBwb2xpY3kuIENoYXJhY3RlcmlzdGljcyBv ZiBjZXJ0aWZpY2F0ZXMgdGhhdCBNQVkgYmUgdXNlZCBmb3IgdmFsaWRhdGlvbiBpbmNsdWRlIHRo ZSB2YWxpZERhdGUsIHRoZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkgKENBKSBjaGFpbiBvZiB0cnVz dCwgaW5jbHVzaW9uIGluIGEgcmV2b2NhdGlvbiBsaXN0LCBwcmlvciBkZXRlcm1pbmF0aW9uIG9m IHRydXN0LCBhbmQgd2hldGhlciB0aGUgSVB2NiBsaW5rIGxvY2FsIGFkZHJlc3MgaXMgdGhlIHNh bWUgYXMgaW4gcHJpb3IgdXNlcyBvZiB0aGUgY2VydGlmaWNhdGUuIEEgdHJ1c3Qgb24gZmlyc3Qg dXNlIChUT0ZVKSBtb2RlbCBNQVkgYmUgc3VwcG9ydGVkLCB3aXRoIHBvbGljeSBkZWZpbmVkIGJ5 IHRoZSBpbXBsZW1lbnRhdGlvbi4gQW55IFRPRlUgcG9saWN5IE1VU1QsIGF0IGEgbWluaW11bSwg ZW5zdXJlIHRoYXQgYSBnaXZlbiBjZXJ0aWZpY2F0ZSBpcyBvbmx5IGV2ZXIgdXNlZCBmcm9tIGEg c2luZ2xlIElQdjYgbGluayBsb2NhbCBhZGRyZXNzIChuZWlnaGJvcikgYW5kIGZhaWwgYW4gdW5r bm93biBjZXJ0aWZpY2F0ZSB1c2VkIGZvciBhbiBJUHY2IGxpbmsgbG9jYWwgYWRkcmVzcyBhbHJl YWR5IGFzc29jaWF0ZWQgd2l0aCBhIHRydXN0ZWQgY2VydGlmaWNhdGUuICINCiJXaGVuIG5ldyBj ZXJ0aWZpY2F0ZXMgYXJlIGlzc3VlZCwgdGhleSBTSE9VTEQgYmUgc2VudCB0b2dldGhlciB3aXRo IHRoZSBvbGQgY2VydGlmaWNhdGUgcHJpb3IgdG8gdGhlIG9sZCBjZXJ0aWZpY2F0ZSdzIGV4cGly YXRpb24gb3IgcmV2b2NhdGlvbiwgc28gaXQgaXMgcG9zc2libGUgZm9yIHRoZSBuZXcgY2VydGlm aWNhdGUgdG8gaW5oZXJpdCBhbnkgdHJ1c3QgYXNzb2NpYXRlZCB3aXRoIHRoZSBvbGQgY2VydGlm aWNhdGUuIg0KDQpDZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uIGlzIG91dCBvZiBzY29wZSBmb3IgdGhl IGJhYmVsLWR0bHMgZHJhZnQsIGluIHRoZSBzYW1lIG1hbm5lciBhcyBpdCBpcyBvdXQgb2Ygc2Nv cGUgZm9yIHRoZSBUTFMgb3IgRFRMUyBSRkNzLiBJIGRvbid0IHRoaW5rIGFueSBtZW50aW9uIG9m IGNlcnRpZmljYXRlcyBhdCBhbGwgYmVsb25ncyBpbiB0aGlzIGRyYWZ0LCBhcyBzb21lIGFwcGxp Y2F0aW9ucyBtYXkgY2hvb3NlIHRvIG5vdCB1c2UgY2VydGlmaWNhdGVzLiBJbiB0aGUgY2FzZSBv ZiBiYWJlbCwgdGhlIGJhYmVsLWR0bHMgZHJhZnQgc3BlY2lmaWVzIGhvdyB0byB1c2UgRFRMUzsg b24gdGhlIG90aGVyIGhhbmQgdGhlIGNlcnRpZmljYXRlcyBhbmQgUEtJIHlvdSB1c2UgaXMgbGVm dCB0byB0aGUgdXNlcnMgb2YgYmFiZWwtZHRscywgZm9yIGV4YW1wbGUgdGhlIGhvbWVuZXQgbWFw cGluZyBkb2N1bWVudCBjb3VsZCBtYW5kYXRlIFg1MDkgYW5kIGhvdyB0byBhZGQgbmV3IGNlcnRp ZmljYXRlcyB0byB0aGUgdHJ1c3Qgc3RvcmUsIGFuZCB0aGUgb3RoZXIgcG9pbnRzIHlvdSBtZW50 aW9uZWQgd291bGQgbWFrZSBzZW5zZSB0byBtZSBpbiB0aGF0IGRvY3VtZW50Lg0KDQpPciBtYWtl IGNlcnRpZmljYXRlIHZhbGlkYXRpb24gYSBTSE9VTEQuIOKYuQ0KDQpWYWxpZGF0aW5nIGlkZW50 aXR5IGlzIGEgTVVTVCwgdGhlIGZhY3QgdGhhdCB0aGF0IGlkZW50aXR5IG1hcHMgdG8gYSBjZXJ0 aWZpY2F0ZSBpcyBhIE1BWS4NCg0KPGJocz4gVmFsaWRhdGluZyB3aGF0IGlkZW50aXR5PyBZb3Ug aGF2ZW7igJl0IHNwZWNpZmllZCBhbnkgaWRlbnRpdHkgdG8gbWFwIGFueXRoaW5nIHRvLiBZb3Ug Y2Fu4oCZdCBtYWtlIHZhbGlkYXRpb24gYSBNVVNUIGlmIHlvdSBnaXZlIG5vIGNsdWUgYXMgdG8g aG93IG9yIHdoYXQgdG8gdmFsaWRhdGUuDQoNCkJhcmJhcmENCg0KVGhhbmtzLA0KRGF2aWQNCg== --_000_2D09D61DDFA73D4C884805CC7865E6114DF8A9A3GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgRW1vamkiO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwg SmFuIDksIDIwMTkgYXQgMTo0MiBQTSBTVEFSSywgQkFSQkFSQSBIICZsdDs8YSBocmVmPSJtYWls dG86YnM3NjUyQGF0dC5jb20iPmJzNzY1MkBhdHQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHJlYWQg dGhlIGRyYWZ0IGFuZCB0aGluayB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgMi4xIGNvdWxkIGRvIHdp dGggYSBsaXR0bGUgbW9yZSB2ZXJiaWFnZSBhcyB0byB3aGF0ICZxdW90O2ZhaWxzIHRvIHZlcmlm eSB0aGUgcGVlcidzIGF1dGhlbnRpY2F0aW9uJnF1b3Q7IG1lYW5zLCBzaW5jZSBpdCdzIHBhcnQg b2YgYSAmcXVvdDtNVVNUJnF1b3Q7IG5vcm1hdGl2ZSBzdGF0ZW1lbnQuIEkgYWxzbyBkb24ndCB0 aGluayB0aGUgd29yZCAmcXVvdDthdXRoZW50aWNhdGlvbiZxdW90Ow0KIGlzIHVzZWQgY29uc2lz dGVudGx5IG9yIChpbiBzb21lIGNhc2VzKSBjb3JyZWN0bHkuIEkgdGhpbmsgb2YgJnF1b3Q7YXV0 aGVudGljYXRpb24mcXVvdDsgYXMgYSBwcm9jZXNzLjxicj4NCjxicj4NCkkgZmluZCAmcXVvdDty ZXF1ZXN0IGNsaWVudCBhdXRoZW50aWNhdGlvbiZxdW90OyBhbmQgJnF1b3Q7dmVyaWZ5IHRoZSBw ZWVyJ3MgYXV0aGVudGljYXRpb24mcXVvdDsgdG8gYmUgb2RkIHVzZXMgb2YgdGhlIHdvcmQgJnF1 b3Q7YXV0aGVudGljYXRpb24mcXVvdDssIGFuZCBub3QgY29uc2lzdGVudCB3aXRoIG15IHVuZGVy c3RhbmRpbmcgb2YgdGhlIHdvcmQuIEkgd291bGQgc3VnZ2VzdCBzb21ldGhpbmcgbGlrZSAmcXVv dDtyZXF1ZXN0IGNsaWVudCBjZXJ0aWZpY2F0ZSZxdW90OyAoY29uc2lzdGVudCB3aXRoIHRoZQ0K IG5hbWUgb2YgdGhlIG1lc3NhZ2UgdGhhdCBpcyBzZW50KSBvciAmcXVvdDtyZXF1ZXN0IGNsaWVu dCBjcmVkZW50aWFscyZxdW90OyBmb3IgdGhlIGZpcnN0IHBocmFzZS4gQW5kIHBlcmhhcHMgJnF1 b3Q7dmFsaWRhdGUgdGhlIHBlZXIncyBjZXJ0aWZpY2F0ZSZxdW90OyBvciAmcXVvdDt2YWxpZGF0 ZSB0aGUgcGVlcidzIGNyZWRlbnRpYWxzJnF1b3Q7IGZvciB0aGUgc2Vjb25kLiBVbmxlc3MgeW91 IG1lYW4gc29tZXRoaW5nIGRpZmZlcmVudCBieSAmcXVvdDt2ZXJpZnkmcXVvdDsgdnMuICZxdW90 O3ZhbGlkYXRlJnF1b3Q7IGhlcmUuDQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk91ciBpbnRlbnQgd2FzIHRvIHVzZSB0aGUgdGVy bXMgYXV0aGVudGljYXRlIGFuZCBhdXRoZW50aWNhdGlvbiBpbiB0aGUgc2FtZSB3YXkgYXMgdGhl IFRMUyBzcGVjaWZpY2F0aW9ucyBkbywgaW4gcGFydGljdWxhciBzZWUNCjxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0 Zi5vcmdfaHRtbF9yZmM4NDQ2LTIzc2VjdGlvbi0yRDEmYW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVot bzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9TG9HemhDLThzYzhTWThUcTR2cmZvZyZhbXA7bT1ZQzcy UGpmbFJYbl9HZ2lGNU1ldEJjRFpsTG5lekNDQ2NHeUtJQm51ZzBnJmFtcDtzPW9CRjk2c2pDREw1 UUk1R3BQa2JOU19LYXZXcGd2OWtmVzVRbzFOMHllMjAmYW1wO2U9Ij4NCnRoZSBUTFMgMS4zIHNw ZWMgaW50cm9kdWN0aW9uPC9hPi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O2JocyZndDsg SSBsb29rZWQgYXQgdGhlIFRMUyAxLjMgc3BlYywgYW5kIHRoZSB1c2Ugb2Yg4oCcYXV0aGVudGlj YXRpb27igJ0gdGhlcmUgaXMgdmVyeSBjb25zaXN0ZW50IHdpdGggbXkgdW5kZXJzdGFuZGluZyBv ZiBhdXRoZW50aWNhdGlvbiBhcyBhIHByb2Nlc3MuIFRoZSAyIHBocmFzZXMgSSBub3RlZCBzZWVt IHRvIHVzZSDigJxhdXRoZW50aWNhdGlvbuKAnSBhcyBpZiBpdCBtZWFudCDigJxhdXRoZW50aWNh dGlvbiBrZXnigJ0g4oCTDQogd2hpY2ggaXQgZG9lcyBub3QuIFRoZSBDZXJ0aWZpY2F0ZVJlcXVl c3QgbWVzc2FnZSBpcyBub3QgdXNlZCB0byByZXF1ZXN0IGNsaWVudCBhdXRoZW50aWNhdGlvbiAo aS5lLiwgcmVxdWVzdCB0aGUgY2xpZW50IHBlcmZvcm0gdGhlIGF1dGhlbnRpY2F0aW9uIHByb2Nl c3MpLiBJdCBpcyB1c2VkIHRvIHJlcXVlc3QgYSBjbGllbnQgYXV0aGVudGljYXRpb24ga2V5LiBZ b3UgY2Fubm90IHZlcmlmeSBhbiBhdXRoZW50aWNhdGlvbi4gQnV0IHlvdSBjYW4NCiB2ZXJpZnkg YW4gYXV0aGVudGljYXRpb24ga2V5LiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2lsbCBvbmx5IFguNTA5IGNlcnRpZmljYXRlIGtl eXMgYmUgYWxsb3dlZCwgb3Igd2lsbCAmcXVvdDtESF9hbm9uJnF1b3Q7IGtleSBleGNoYW5nZSBi ZSBhbGxvd2VkPw0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5iYWJlbC1kdGxzIGRvZXMgbm90IHNwZWNpZnkgd2hhdCBzb3VyY2Ug b2YgYXV0aGVudGljYXRpb24gdG8gdXNlLCBYNTA5IGFyZSBvbmUgYWxsb3dlZCBvcHRpb24sIGJ1 dCB0aGV5IGFyZSBub3QgbWFuZGF0ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkRIX2Fub24gaXMgcHJvaGliaXRlZCBieSAmcXVvdDtOb2RlcyBN VVNUIHVzZSBtdXR1YWwgYXV0aGVudGljYXRpb24mcXVvdDsgKGFuZCBzdWJzZXF1ZW50IGNsYXJp ZnlpbmcgdGV4dCBpbiBzZWN0aW9uIDIuMSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O2Jo cyZndDsgVExTIDEuMiAoUkZDIDUyNDYpIHNheXMg4oCcVGhlIGZvbGxvd2luZyBydWxlcyBhcHBs eSB0byB0aGUgY2VydGlmaWNhdGVzIHNlbnQgYnkgdGhlIHNlcnZlcjo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAtJm5ic3A7IFRoZSBjZXJ0aWZpY2F0 ZSB0eXBlIE1VU1QgYmUgWC41MDl2MywgdW5sZXNzIGV4cGxpY2l0bHkgbmVnb3RpYXRlZCBvdGhl cndpc2UgKGUuZy4sIFtUTFNQR1BdKS7igJ0NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RFRMUyAoUkZDIDYzNDcpIGRvZXNu4oCZdCBtb2RpZnkgdGhpcyByZXF1aXJlbWVu dCBhbmQgbmVpdGhlciBEVExTIG5vciBiYWJlbC1EVExTIHJlcXVpcmVzIHN1cHBvcnQgZm9yIGNl cnRpZmljYXRlIGZvcm1hdCBuZWdvdGlhdGlvbi4gRXZlcnkgYmFiZWwtZHRscyBpbXBsZW1lbnRh dGlvbiBoYXMgdG8gYmUgcHJlcGFyZWQgdG8gYWN0IGFzIHRoZSBEVExTIHNlcnZlci4gUHJhY3Rp Y2FsbHkgc3BlYWtpbmcgZG9lc27igJl0DQogdGhpcyBtZWFuIGV2ZXJ5IGJhYmVsLWR0bHMgaW1w bGVtZW50YXRpb24gdGhhdCBleHBlY3RzIHRvIGludGVyb3BlcmF0ZSBpbiBhbiBvcGVuIGVudmly b25tZW50IGhhcyB0byBlaXRoZXIgaGF2ZSBvciBiZSBhYmxlIHRvIGdlbmVyYXRlIGFuIFguNTA5 IGNlcnRpZmljYXRlPyBBbnl0aGluZyBsZXNzIGFuZCB0aGVyZSBjYW4gYmUgbm8gZXhwZWN0YXRp b24gb2YgaW50ZXJvcGVyYWJpbGl0eS4gQ2xlYXJseSwgYSBjbG9zZWQgZW52aXJvbm1lbnQgY2Fu DQogdXNlIHdoYXRldmVyIGl0IHdhbnRzLiBCdXQgSSBkb27igJl0IGZpbmQgY2xvc2VkIGVudmly b25tZW50cyB2ZXJ5IGludGVyZXN0aW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlIGFyZSB0aGUgcG9zc2libGUgdGhpbmdz IHRoYXQgYXJlIHNvbWV0aW1lcyBkb25lIGFzIHBhcnQgb2YgY2VydGlmaWNhdGUgdmFsaWRhdGlv biwgdGhhdCBJIHRoaW5rIHRoaXMgcGhyYXNlIGlzIHBvdGVudGlhbGx5IHJlZmVycmluZyB0bzo8 YnI+DQoxLiBFbnN1cmUgdGhlIGNlcnRpZmljYXRlIHZhbGlkRGF0ZSBpcyBub3QgaW4gdGhlIHBh c3QuIFRoaXMgY2hlY2sgc2hvdWxkIG9ubHkgYmUgZG9uZSBpZiB0aGUgaW1wbGVtZW50YXRpb24g dGhpbmtzIHRoZSB1bmRlcmx5aW5nIHN5c3RlbSBoYXMgYWNxdWlyZWQgYSBnb29kIGN1cnJlbnQg dGltZSAoaS5lLiwgaXQgcnVucyBhIE5UUCBjbGllbnQgYW5kIGdldHRpbmcgdGhlIGN1cnJlbnQg ZGF0ZXRpbWUgdmlhIE5UUCBoYXMgc3VjY2VlZGVkLCBvcg0KIHRoZSBjdXJyZW50IGRhdGV0aW1l IGhhcyBiZWVuIGNvbmZpZ3VyZWQpLiA8YnI+DQoyLiBDaGVjayB0aGUgY2VydGlmaWNhdGUncyBj aGFpbiBvZiB0cnVzdCBmb3IgYSB0cnVzdGVkIENBLiBUaGlzIHdvdWxkIG1lYW4gdGhlcmUgaXMg YSBjb25maWd1cmVkIHNldCBvZiB0cnVzdGVkIENBcy48YnI+DQozLiBDaGVjayBpZiB0aGUgY2Vy dGlmaWNhdGUgaGFzIGJlZW4gcmV2b2tlZC4gVGhpcyBpcyBvZnRlbiBub3QgZG9uZSwgYnV0IG1p Z2h0IG5vdCBiZSBhIGJhZCBpZGVhIHRoZSBmaXJzdCB0aW1lIHRoZSBjZXJ0aWZpY2F0ZSBpcyBz ZWVuLjxicj4NCjQuIENoZWNrIGlmIHRoaXMgaWRlbnRpY2FsIGNlcnRpZmljYXRlIGlzIGluY2x1 ZGVkIGluIGEgc3RvcmUgb2YgdHJ1c3RlZCBjZXJ0aWZpY2F0ZXMgKGVpdGhlciBpdCB3YXMgcHJl dmlvdXNseSB0cnVzdGVkIGFuZCBzdG9yZWQgb3IgdGhlIHN0b3JlIGlzIGNvbmZpZ3VyZWQpLjxi cj4NCjUuIENoZWNrIHNvbWUgYXNwZWN0IG9mICZxdW90O2lkZW50aXR5JnF1b3Q7LiBJcyB0aGVy ZSBzb21lIGNoYXJhY3RlcmlzdGljIG9mIHRoZSBwZWVyIHRoYXQgaXMgZXhwZWN0ZWQgdG8gYmUg c3RhYmxlIHdydCBhIGNlcnRpZmljYXRlPyBGb3IgZXhhbXBsZSwgd291bGQgdGhlIHNhbWUgY2Vy dGlmaWNhdGUgYWx3YXlzIG9yaWdpbmF0ZSBmcm9tIHRoZSBzYW1lIE1BQyBhZGRyZXNzIG9yIExM IElQdjYgYWRkcmVzcz8NCjxicj4NCjYuIElmIGEgVE9GVSAodHJ1c3Qgb24gZmlyc3QgdXNlKSBw b2xpY3kgaXMgc3VwcG9ydGVkLCB3aGF0IGV4YWN0bHkgc2hvdWxkIGJlIHRydXN0ZWQgKGFuZCB3 aGF0IHNob3VsZCBub3QgYmUgdHJ1c3RlZCk/IEkgZG8gbGlrZSBhbGxvd2luZyBmb3IgYSBUT0ZV IHBvbGljeSAoaWYgYW4gaW1wbGVtZW50YXRpb24gY2hvb3NlcyB0byBzdXBwb3J0IG9uZSkuIElm IGl0IGlzIGFsbG93ZWQsIEkgd291bGQgc3VnZ2VzdCBzb21ldGhpbmcgbGlrZSB0aGUNCiBjZXJ0 IGlzIFRPRlUgaWYgdGhlIElQdjYgTEwgYWRkcmVzcyBoYXNuJ3QgYmVlbiBzZWVuIGJlZm9yZSAo bmV3IG5laWdoYm9yKS4gQWZ0ZXIgdGhhdCBpdCBhbHdheXMgaGFzIHRvIHVzZSB0aGUgc2FtZSBj ZXJ0LiBXaGVuIGNoYW5naW5nIGNlcnRzLCBzZW5kIG9sZCBhbmQgbmV3IGNlcnQgdG9nZXRoZXIg Zm9yIHNvbWUgdGltZSwgc28gbmV3IGNlcnQgaXMgYXNzb2NpYXRlZCB3aXRoIHRydXN0ZWQgb2xk IGNlcnQuPGJyPg0KPGJyPg0KUHJlc3VtYWJseSwgYSBkZXZpY2UgbWlnaHQgYmUgY29uZmlndXJl ZCB3aXRoIGEgbmV3IGNlcnRpZmljYXRlIGF0IHNvbWUgcG9pbnQgKGxpa2Ugd2hlbiB0aGUgb2xk IG9uZSBleHBpcmVzKS4gV2lsbCB0aGUgbmV3IGNlcnRpZmljYXRlIGJlIGNvbnNpZGVyZWQgdGhl IHNhbWUgbmVpZ2hib3IgaWYgdGhlICZxdW90O2lkZW50aXR5JnF1b3Q7IG1hdGNoZXMgKHNlZSBp dGVtIDUgZm9yIHF1ZXN0aW9uIG9uIGRldGVybWluaW5nIGlkZW50aXR5KT8gSWYgeW91IGdldCBh DQogcmVxdWVzdCBmb3IgYSBuZXcgRFRMUyBzZXNzaW9uIGFuZCBhbHJlYWR5IGhhdmUgYSBzZXNz aW9uIGZvciB0aGF0ICZxdW90O2lkZW50aXR5JnF1b3Q7IChJUHY2IExMIGFkZHJlc3M/KSB3aXRo IGEgZGlmZmVyZW50IGNlcnRpZmljYXRlLCB3aGF0IGRvIHlvdSBkbz88YnI+DQo8YnI+DQpJZiB0 aGVyZSBpcyBhbHJlYWR5IGEgRFRMUyBjb25uZWN0aW9uIHVzaW5nIGEgcHJvdmlkZWQgY2VydGlm aWNhdGUsIHdoYXQgZG8geW91IGRvIGlmIHlvdSBnZXQgYSByZXF1ZXN0IGZvciBhIG5ldyBEVExT IHNlc3Npb24gdXNpbmcgdGhlIHNhbWUgY2VydGlmaWNhdGU/IFRlYXIgZG93biB0aGUgb2xkIG9u ZT88YnI+DQo8YnI+DQpXaXRoIGFsbCB0aGlzIHNhaWQuIEkgdGhpbmsgaXQgbWlnaHQgYmUgZW5v dWdoIGlmIHRoZSBkcmFmdCBoYWQgc3RhdGVtZW50cyBsaWtlOjxicj4NCiZxdW90O1RoZSBrZXkg ZXhjaGFuZ2UgbWVjaGFuaXNtIHVzZWQgTVVTVCByZXF1aXJlIHVzZSBvZiBYLjUwOSBjZXJ0aWZp Y2F0ZXMuJnF1b3Q7IChpZiB0aGlzIGlzIHRoZSBpbnRlbnQpPGJyPg0KJnF1b3Q7Q2VydGlmaWNh dGUgdmFsaWRhdGlvbiBNVVNUIGJlIGRvbmUgYWNjb3JkaW5nIHRvIGludGVybmFsIHBvbGljeS4g Q2hhcmFjdGVyaXN0aWNzIG9mIGNlcnRpZmljYXRlcyB0aGF0IE1BWSBiZSB1c2VkIGZvciB2YWxp ZGF0aW9uIGluY2x1ZGUgdGhlIHZhbGlkRGF0ZSwgdGhlIENlcnRpZmljYXRlIEF1dGhvcml0eSAo Q0EpIGNoYWluIG9mIHRydXN0LCBpbmNsdXNpb24gaW4gYSByZXZvY2F0aW9uIGxpc3QsIHByaW9y IGRldGVybWluYXRpb24gb2YgdHJ1c3QsDQogYW5kIHdoZXRoZXIgdGhlIElQdjYgbGluayBsb2Nh bCBhZGRyZXNzIGlzIHRoZSBzYW1lIGFzIGluIHByaW9yIHVzZXMgb2YgdGhlIGNlcnRpZmljYXRl LiBBIHRydXN0IG9uIGZpcnN0IHVzZSAoVE9GVSkgbW9kZWwgTUFZIGJlIHN1cHBvcnRlZCwgd2l0 aCBwb2xpY3kgZGVmaW5lZCBieSB0aGUgaW1wbGVtZW50YXRpb24uIEFueSBUT0ZVIHBvbGljeSBN VVNULCBhdCBhIG1pbmltdW0sIGVuc3VyZSB0aGF0IGEgZ2l2ZW4gY2VydGlmaWNhdGUgaXMgb25s eQ0KIGV2ZXIgdXNlZCBmcm9tIGEgc2luZ2xlIElQdjYgbGluayBsb2NhbCBhZGRyZXNzIChuZWln aGJvcikgYW5kIGZhaWwgYW4gdW5rbm93biBjZXJ0aWZpY2F0ZSB1c2VkIGZvciBhbiBJUHY2IGxp bmsgbG9jYWwgYWRkcmVzcyBhbHJlYWR5IGFzc29jaWF0ZWQgd2l0aCBhIHRydXN0ZWQgY2VydGlm aWNhdGUuICZxdW90Ozxicj4NCiZxdW90O1doZW4gbmV3IGNlcnRpZmljYXRlcyBhcmUgaXNzdWVk LCB0aGV5IFNIT1VMRCBiZSBzZW50IHRvZ2V0aGVyIHdpdGggdGhlIG9sZCBjZXJ0aWZpY2F0ZSBw cmlvciB0byB0aGUgb2xkIGNlcnRpZmljYXRlJ3MgZXhwaXJhdGlvbiBvciByZXZvY2F0aW9uLCBz byBpdCBpcyBwb3NzaWJsZSBmb3IgdGhlIG5ldyBjZXJ0aWZpY2F0ZSB0byBpbmhlcml0IGFueSB0 cnVzdCBhc3NvY2lhdGVkIHdpdGggdGhlIG9sZCBjZXJ0aWZpY2F0ZS4mcXVvdDs8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNlcnRp ZmljYXRlIHZhbGlkYXRpb24gaXMgb3V0IG9mIHNjb3BlIGZvciB0aGUgYmFiZWwtZHRscyBkcmFm dCwgaW4gdGhlIHNhbWUgbWFubmVyIGFzIGl0IGlzIG91dCBvZiBzY29wZSBmb3IgdGhlIFRMUyBv ciBEVExTIFJGQ3MuIEkgZG9uJ3QgdGhpbmsgYW55IG1lbnRpb24gb2YgY2VydGlmaWNhdGVzIGF0 IGFsbCBiZWxvbmdzIGluIHRoaXMgZHJhZnQsIGFzIHNvbWUgYXBwbGljYXRpb25zIG1heSBjaG9v c2UNCiB0byBub3QgdXNlIGNlcnRpZmljYXRlcy4gSW4gdGhlIGNhc2Ugb2YgYmFiZWwsIHRoZSBi YWJlbC1kdGxzIGRyYWZ0IHNwZWNpZmllcyBob3cgdG8gdXNlIERUTFM7IG9uIHRoZSBvdGhlciBo YW5kIHRoZSBjZXJ0aWZpY2F0ZXMgYW5kIFBLSSB5b3UgdXNlIGlzIGxlZnQgdG8gdGhlIHVzZXJz IG9mIGJhYmVsLWR0bHMsIGZvciBleGFtcGxlIHRoZSBob21lbmV0IG1hcHBpbmcgZG9jdW1lbnQg Y291bGQgbWFuZGF0ZSBYNTA5IGFuZCBob3cgdG8gYWRkDQogbmV3IGNlcnRpZmljYXRlcyB0byB0 aGUgdHJ1c3Qgc3RvcmUsIGFuZCB0aGUgb3RoZXIgcG9pbnRzIHlvdSBtZW50aW9uZWQgd291bGQg bWFrZSBzZW5zZSB0byBtZSBpbiB0aGF0IGRvY3VtZW50LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PciBtYWtlIGNlcnRp ZmljYXRlIHZhbGlkYXRpb24gYSBTSE9VTEQuIDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj4NCuKYuTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlZhbGlk YXRpbmcgaWRlbnRpdHkgaXMgYSBNVVNULCB0aGUgZmFjdCB0aGF0IHRoYXQgaWRlbnRpdHkgbWFw cyB0byBhIGNlcnRpZmljYXRlIGlzIGEgTUFZLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7 YmhzJmd0OyBWYWxpZGF0aW5nIHdoYXQgaWRlbnRpdHk/IFlvdSBoYXZlbuKAmXQgc3BlY2lmaWVk IGFueSBpZGVudGl0eSB0byBtYXAgYW55dGhpbmcgdG8uIFlvdSBjYW7igJl0IG1ha2UgdmFsaWRh dGlvbiBhIE1VU1QgaWYgeW91IGdpdmUgbm8gY2x1ZSBhcyB0byBob3cgb3Igd2hhdCB0byB2YWxp ZGF0ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFyYmFyYTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZpZDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_2D09D61DDFA73D4C884805CC7865E6114DF8A9A3GAALPA1MSGUSRBF_-- From nobody Thu Jan 10 00:22:21 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF3213118F; Thu, 10 Jan 2019 00:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9g3deGc47Tha; Thu, 10 Jan 2019 00:22:17 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A3713118E; Thu, 10 Jan 2019 00:22:16 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0A8M9FO020550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 Jan 2019 09:22:09 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x0A8MA2k030095; Thu, 10 Jan 2019 09:22:10 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id EB78D5272C; Thu, 10 Jan 2019 09:22:13 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id GsDBNge7wgMH; Thu, 10 Jan 2019 09:22:12 +0100 (CET) Received: from [192.168.0.167] (aaubervilliers-652-1-58-123.w90-61.abo.wanadoo.fr [90.61.25.123]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id ABC6E5271C; Thu, 10 Jan 2019 09:22:09 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Matthieu Boutier In-Reply-To: Date: Thu, 10 Jan 2019 09:22:08 +0100 Cc: Babel at IETF , babel-chairs , draft-ietf-babel-dtls@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <7C3D31F2-CA77-4505-9978-06272DFB2424@irif.fr> References: To: Donald Eastlake X-Mailer: Apple Mail (2.3445.9.1) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 10 Jan 2019 09:22:09 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 10 Jan 2019 09:22:11 +0100 (CET) X-Miltered: at korolev with ID 5C3700B1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5C3700B2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C3700B1.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5C3700B2.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C3700B1.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5C3700B2.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-dtls-03 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 08:22:20 -0000 I support publication. Matthieu From nobody Thu Jan 10 12:44:51 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B563131249; Thu, 10 Jan 2019 12:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-FNN5dJ1ds6; Thu, 10 Jan 2019 12:44:47 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7BB413123C; Thu, 10 Jan 2019 12:44:47 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1547153084; bh=voN++mkhpczZ9DB6QGjZjfIJeiAkfMDGAZKKq078/rc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=b6CI59jNPteB7acgXYxKQhzNwlRj8Lk+prLj5fz+eOq6sJYN2U6R9yUXmjkAyOxna 3144IbAX0d3MY1h0b/PBorpef4uakwvIjwRiQHOXVSKD6ut4rQZEJDnD5jQW8e3DDE k8mmJf3uzKOpoV0ixN31/HuRx7wEb4obliegC41LZGThRSFchZGL2yT1xQVweQb7DI VXbMFGfZduQTVASru39i87NecTjNgfFDDXziFFpke0cBEQr00vZk5DsafA62IwQaax lsVN2ECBUOqH26KAgxsURkFp4zrBFKtecEXdYE5XHMNXUFgPRS3hDdaLnhQPhVkbDl Yg2UcbQiCaBdQ== To: Donald Eastlake , Babel at IETF Cc: babel-chairs In-Reply-To: References: Date: Thu, 10 Jan 2019 21:44:42 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87bm4otf7p.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] WG Last Call on draft-ietf-babel-hmac X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 20:44:51 -0000 Donald Eastlake writes: > Hi, > > At the Bangkok IETF meeting we said we would start a WG Last Call on > draft-ietf-babel-hmac. So, this message starts such a Last Call. Due > to the holidays, this will run through January 13th. Do you think this > draft is ready for publication? It is fine to provide suggestions for > improvement with your response. So, apart from the nits we've already been over, I support publication of the draft, in case that wasn't clear... -Toke From nobody Thu Jan 10 13:05:49 2019 Return-Path: <7riw77@gmail.com> X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C596312896A; Thu, 10 Jan 2019 13:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLeE7JSSuWqe; Thu, 10 Jan 2019 13:05:47 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D601F130F3F; Thu, 10 Jan 2019 13:05:46 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id s5so11229931oth.7; Thu, 10 Jan 2019 13:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=xl7v6eTJJI32FUQV9yMhsSeS9lU05Y//HnPxDfYZozg=; b=Gb2EP9m3yP00388hd7M0qFOcXErEBRSpvgQyrvIYI4ZT8hTVWNy0usMT2yN3GdgIuC EAV2Pg+dk3LVIwlsxyAv24Ibv0Ar5eflR0Kvirs4/Efp/VyTjUefoQ6501YjEv7jXg2c G27eO0H5zbUN/KwXMDCk1bE+2nNipWHFKs1qPb4wWHh+Sq5unV1Ib9ZEjV224l/LYyId ivkzh/THoJSDW8RjIlriIbrEMBgsQm/OLpR3P+Do8ezrWAkgWK9X6/HsX3IYlQtsycg6 KzHUnmoglIeD7TbbF9I1kF45pvAhkUU/PwVm2fe4s2K230ifCUAMm6J3Gzb+s7nYz2Bh oYoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=xl7v6eTJJI32FUQV9yMhsSeS9lU05Y//HnPxDfYZozg=; b=ZOuzTGO9VHDR4tnVgWzjmKBM6Pq2wm/8BkMw6x2tmB3SO3E58By7D4if67niKm7ipv rUI5vZ3iazbIHBFlqXckZM/xixJ4eye5rispOPrd0ViN9c9zqThhhSu7vZi6btI6dQdk FZgjNGK6xfpj9yIL64EyTkLsOXUICEdbP/9U6qIxDfK2pSyrk5MDyf9fWeqn6F3KUv+M hHe7ImgUaTU6btOBirVopqpAJspmoGP1MIVmdgeisVSoEhyJmmL5LXpkJrxd632wEdII YnBp/5wVcnTDx0Y35/FSDb0oXTSRBjcx5Vky3LqNJZio7QUxAOXmldM5K/V7OBUz1d1C bG0A== X-Gm-Message-State: AJcUukerwx98XkGQ9AuZ1aG0pcusfy4ABLESOz5ZLowVmm8SO3nzHPKd hkw6aqaTY9U8XsT6oFMwovzTEBub X-Google-Smtp-Source: ALg8bN70axCxlr/LyxgsFEi5gwZQqI/mY9hHvaa6a1HEAOL0eIX5LQgEpsn2yokzsfiwfK4684sxBg== X-Received: by 2002:a05:6830:1408:: with SMTP id v8mr7533284otp.211.1547154346002; Thu, 10 Jan 2019 13:05:46 -0800 (PST) Received: from RussPC (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id b18sm41912585oii.51.2019.01.10.13.05.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Jan 2019 13:05:45 -0800 (PST) From: <7riw77@gmail.com> To: =?utf-8?Q?'Toke_H=C3=B8iland-J=C3=B8rgensen'?= , "'Donald Eastlake'" , "'Babel at IETF'" Cc: "'babel-chairs'" References: <87bm4otf7p.fsf@toke.dk> In-Reply-To: <87bm4otf7p.fsf@toke.dk> Date: Thu, 10 Jan 2019 16:05:44 -0500 Message-ID: <01ea01d4a928$40dba730$c292f590$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIeZZboUSC43Or12SKnh3JicGuvkQJjKxYLpQJr6xA= Content-Language: en-us Archived-At: Subject: Re: [babel] WG Last Call on draft-ietf-babel-hmac X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 21:05:48 -0000 I support, as well. =F0=9F=98=8A /r > -----Original Message----- > From: Toke H=C3=B8iland-J=C3=B8rgensen > Sent: Thursday, January 10, 2019 3:45 PM > To: Donald Eastlake ; Babel at IETF > Cc: babel-chairs > Subject: Re: [babel] WG Last Call on draft-ietf-babel-hmac >=20 > Donald Eastlake writes: >=20 > > Hi, > > > > At the Bangkok IETF meeting we said we would start a WG Last Call on > > draft-ietf-babel-hmac. So, this message starts such a Last Call. Due > > to the holidays, this will run through January 13th. Do you think = this > > draft is ready for publication? It is fine to provide suggestions = for > > improvement with your response. >=20 > So, apart from the nits we've already been over, I support publication = of the > draft, in case that wasn't clear... >=20 > -Toke From nobody Thu Jan 10 15:14:37 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5861312B8 for ; Thu, 10 Jan 2019 15:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSj-aNHzDWdn for ; Thu, 10 Jan 2019 15:14:35 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F22C1311EA for ; Thu, 10 Jan 2019 15:14:35 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x0AN71R8040354 for ; Thu, 10 Jan 2019 18:14:34 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2pxcksmdeb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 10 Jan 2019 18:14:34 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0ANEWpo003961 for ; Thu, 10 Jan 2019 18:14:33 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0ANERqF003851 for ; Thu, 10 Jan 2019 18:14:28 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 500854048C20 for ; Thu, 10 Jan 2019 23:14:27 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30488.vci.att.com (Service) with ESMTPS id 3773940002A2 for ; Thu, 10 Jan 2019 23:14:27 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.203]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0415.000; Thu, 10 Jan 2019 18:14:26 -0500 From: "STARK, BARBARA H" To: Babel at IETF Thread-Topic: babel-hmac: key requirements Thread-Index: AdSpKuuhWh3uIPf3TSyfFq2fmw6nrA== Date: Thu, 10 Jan 2019 23:14:25 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.196.192] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-10_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901100176 Archived-At: Subject: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 23:14:36 -0000 VGhlIHJlY2VudCBkaXNjdXNzaW9uIGFyb3VuZCB0aGUgSE1BQyBrZXkgc3VnZ2VzdHMgdG8gbWUg dGhhdCB3ZSBuZWVkIHRvIGhhdmUgc29tZSB0ZXh0IHNvbWV3aGVyZSB0aGF0IGRpc2N1c3NlcyBl eHBlY3RhdGlvbnMgZm9yIHRoZSBhdXRoZW50aWNhdGlvbiBrZXkuIE9yIGVsc2Ugd2UncmUgYWxt b3N0IGd1YXJhbnRlZWQgdG8gYWNoaWV2ZSBub24taW50ZXJvcGVyYWJpbGl0eSBhY3Jvc3MgaW1w bGVtZW50YXRpb25zLg0KDQpBcyBhIHJlbWluZGVyIChmcm9tIHRoYXQgZGlzY3Vzc2lvbiksIE9T UEYgKFJGQyA1NzA5KSBoYXMgdGhpczoNCiAgICgxKSBQUkVQQVJBVElPTiBPRiBLRVkNCiAgICAg ICBJbiB0aGlzIGFwcGxpY2F0aW9uLCBLbyBpcyBhbHdheXMgTCBvY3RldHMgbG9uZy4NCiAgICAg ICBJZiB0aGUgQXV0aGVudGljYXRpb24gS2V5IChLKSBpcyBMIG9jdGV0cyBsb25nLCB0aGVuIEtv IGlzIGVxdWFsDQogICAgICAgdG8gSy4gIElmIHRoZSBBdXRoZW50aWNhdGlvbiBLZXkgKEspIGlz IG1vcmUgdGhhbiBMIG9jdGV0cyBsb25nLA0KICAgICAgIHRoZW4gS28gaXMgc2V0IHRvIEgoSyku ICBJZiB0aGUgQXV0aGVudGljYXRpb24gS2V5IChLKSBpcyBsZXNzDQogICAgICAgdGhhbiBMIG9j dGV0cyBsb25nLCB0aGVuIEtvIGlzIHNldCB0byB0aGUgQXV0aGVudGljYXRpb24gS2V5IChLKQ0K ICAgICAgIHdpdGggemVyb3MgYXBwZW5kZWQgdG8gdGhlIGVuZCBvZiB0aGUgQXV0aGVudGljYXRp b24gS2V5IChLKSwNCiAgICAgICBzdWNoIHRoYXQgS28gaXMgTCBvY3RldHMgbG9uZy4NCndoZXJl DQogICAgICBIICAgIGlzIHRoZSBzcGVjaWZpYyBoYXNoaW5nIGFsZ29yaXRobSAoZS5nLiwgU0hB LTI1NikuDQogICAgICBLbyAgIGlzIHRoZSBjcnlwdG9ncmFwaGljIGtleSB1c2VkIHdpdGggdGhl IGhhc2ggYWxnb3JpdGhtLg0KICAgICAgQiAgICBpcyB0aGUgYmxvY2sgc2l6ZSBvZiBILCBtZWFz dXJlZCBpbiBvY3RldHMNCiAgICAgICAgICAgcmF0aGVyIHRoYW4gYml0cy4gIE5vdGUgd2VsbCB0 aGF0IEIgaXMgdGhlDQogICAgICAgICAgIGludGVybmFsIGJsb2NrIHNpemUsIG5vdCB0aGUgaGFz aCBzaXplLg0KICAgICAgICAgICAgICBGb3IgU0hBLTEgYW5kIFNIQS0yNTY6IEIgPT0gNjQNCiAg ICAgICAgICAgICAgRm9yIFNIQS0zODQgYW5kIFNIQS01MTI6IEIgPT0gMTI4ICAgICANCiAgICAg IEwgICAgaXMgdGhlIGxlbmd0aCBvZiB0aGUgaGFzaCwgbWVhc3VyZWQgaW4gb2N0ZXRzDQogICAg ICAgICAgIHJhdGhlciB0aGFuIGJpdHMuDQoNCkkndmUgYWxzbyBkaXNjb3ZlcmVkIHRoYXQgdGhl IEhNQUMgUkZDIChSRkMgMjEwNCkgc2F5czoNCiAgIFRoZSBkZWZpbml0aW9uIG9mIEhNQUMgcmVx dWlyZXMgYSBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rpb24sIHdoaWNoDQogICB3ZSBkZW5vdGUg YnkgSCwgYW5kIGEgc2VjcmV0IGtleSBLLiBXZSBhc3N1bWUgSCB0byBiZSBhIGNyeXB0b2dyYXBo aWMNCiAgIGhhc2ggZnVuY3Rpb24gd2hlcmUgZGF0YSBpcyBoYXNoZWQgYnkgaXRlcmF0aW5nIGEg YmFzaWMgY29tcHJlc3Npb24NCiAgIGZ1bmN0aW9uIG9uIGJsb2NrcyBvZiBkYXRhLiAgIFdlIGRl bm90ZSBieSBCIHRoZSBieXRlLWxlbmd0aCBvZiBzdWNoDQogICBibG9ja3MgKEI9NjQgZm9yIGFs bCB0aGUgYWJvdmUgbWVudGlvbmVkIGV4YW1wbGVzIG9mIGhhc2ggZnVuY3Rpb25zKSwNCiAgIGFu ZCBieSBMIHRoZSBieXRlLWxlbmd0aCBvZiBoYXNoIG91dHB1dHMgKEw9MTYgZm9yIE1ENSwgTD0y MCBmb3INCiAgIFNIQS0xKS4gIFRoZSBhdXRoZW50aWNhdGlvbiBrZXkgSyBjYW4gYmUgb2YgYW55 IGxlbmd0aCB1cCB0byBCLCB0aGUNCiAgIGJsb2NrIGxlbmd0aCBvZiB0aGUgaGFzaCBmdW5jdGlv bi4gIEFwcGxpY2F0aW9ucyB0aGF0IHVzZSBrZXlzIGxvbmdlcg0KICAgdGhhbiBCIGJ5dGVzIHdp bGwgZmlyc3QgaGFzaCB0aGUga2V5IHVzaW5nIEggYW5kIHRoZW4gdXNlIHRoZQ0KICAgcmVzdWx0 YW50IEwgYnl0ZSBzdHJpbmcgYXMgdGhlIGFjdHVhbCBrZXkgdG8gSE1BQy4gSW4gYW55IGNhc2Ug dGhlDQogICBtaW5pbWFsIHJlY29tbWVuZGVkIGxlbmd0aCBmb3IgSyBpcyBMIGJ5dGVzIChhcyB0 aGUgaGFzaCBvdXRwdXQNCiAgIGxlbmd0aCkuIFNlZSBzZWN0aW9uIDMgZm9yIG1vcmUgaW5mb3Jt YXRpb24gb24ga2V5cy4NCmFuZCBlbHNld2hlcmUgaXQgc2F5cw0KICAgVGhlIGtleSBmb3IgSE1B QyBjYW4gYmUgb2YgYW55IGxlbmd0aCAoa2V5cyBsb25nZXIgdGhhbiBCIGJ5dGVzIGFyZQ0KICAg Zmlyc3QgaGFzaGVkIHVzaW5nIEgpLiAgSG93ZXZlciwgbGVzcyB0aGFuIEwgYnl0ZXMgaXMgc3Ry b25nbHkNCiAgIGRpc2NvdXJhZ2VkIGFzIGl0IHdvdWxkIGRlY3JlYXNlIHRoZSBzZWN1cml0eSBz dHJlbmd0aCBvZiB0aGUNCiAgIGZ1bmN0aW9uLiAgS2V5cyBsb25nZXIgdGhhbiBMIGJ5dGVzIGFy ZSBhY2NlcHRhYmxlIGJ1dCB0aGUgZXh0cmENCiAgIGxlbmd0aCB3b3VsZCBub3Qgc2lnbmlmaWNh bnRseSBpbmNyZWFzZSB0aGUgZnVuY3Rpb24gc3RyZW5ndGguIChBDQogICBsb25nZXIga2V5IG1h eSBiZSBhZHZpc2FibGUgaWYgdGhlIHJhbmRvbW5lc3Mgb2YgdGhlIGtleSBpcw0KICAgY29uc2lk ZXJlZCB3ZWFrLikNCg0KTm90ZSB0aGF0IE9TUEYgZG9lc24ndCBxdWl0ZSBmb2xsb3cgdGhlIEhN QUMgUkZDIC0tIGl0IGhhc2hlcyB0aGUgaW5wdXQga2V5IHdoZW4gdGhhdCBrZXkgbGVuZ3RoIGlz ID4gTCAod2hlcmUgSE1BQyBzYXlzIHRoaXMgaXMgZG9uZSB3aGVuIGtleSBsZW5ndGggaXMgPCBC KS4gDQpXZSBhbHNvIG5vdGVkIHRoYXQgdGhlIEJpcmQgY29kZSBhcHBsaWVzIEFTQ0lJICh3aGlj aCBpcyB0aGUgc2FtZSBhcyBVVEYtOCkgZW5jb2RpbmcgdG8gYW4gaW5wdXQgYXV0aGVudGljYXRp b24ga2V5IHN0cmluZyAoYW5kIG5vdCAgaGV4LCBiYXNlNjQsIG9yIFVURi0xNikuIA0KDQpNeSBw cmVmZXJlbmNlIGlzIHRoYXQgd2UgaGF2ZSBzb21ldGhpbmcgaW4gdGhlIEhNQUMgZHJhZnQsIG5v dCB0b28gbXVjaCB1bmxpa2UgdGhlIE9TUEYgdGV4dC4NCkkgdGhpbmssIGJhc2VkIG9uIHRoZSBI TUFDIFJGQyBzdGF0ZW1lbnQgdGhhdCBjcnlwdG9ncmFwaGljIGtleXMgd2l0aCBsZW5ndGggPiBM IGRvbid0IGFkZCB2YWx1ZSwgaXQgbWFrZXMgc2Vuc2UgdG8gcmVzdHJpY3QgdGhlIGxlbmd0aCB0 byBMIChpbnN0ZWFkIG9mIEIpLiBMaWtlIE9TUEYgZG9lcy4NCkkgbGlrZSBVVEYtOC4gSXQncyB3 b3JrZWQgdmVyeSB3ZWxsIGZvciBXaS1GaSBXUEExIGFuZCBXUEEyIHBhc3NwaHJhc2VzLiBCdXQg SSBhbHNvIHJlY29nbml6ZSB0aGF0IHRoaXMgcHJldmVudHMgZnVsbCB1c2Ugb2YgdGhlIGF2YWls YWJsZSBiaXRzLiBXaGljaCBpcyB3aHkgc29tZSBXaS1GaSBpbXBsZW1lbnRhdGlvbnMgYWxzbyBz dXBwb3J0IGRpcmVjdCBpbnB1dCBvZiB0aGUgY3J5cHRvZ3JhcGhpYyBrZXkgaW4gaGV4IGZvcm1h dC4gTm90ZSB0aGF0IHBhc3NwaHJhc2VzIGFyZSB1c2VkIHRvIGdlbmVyYXRlIHRoZSBjcnlwdG9n cmFwaGljIGtleSB1c2luZyBQQktERjIgKGZyb20gUkZDIDI4OTgpIHdpdGggdGhlIFNTSUQgYXMg dGhlIHNhbHQuIEluIG9yZGVyIHRvIHByZXZlbnQgY29uZnVzaW9uIHdoZW4gYSBXaS1GaSBpbXBs ZW1lbnRhdGlvbiBpcyBwcm92aWRlZCB3aXRoIGEgImtleSIsIHBhc3NwaHJhc2VzIGFyZSByZXF1 aXJlZCB0byBiZSBiZXR3ZWVuIDggYW5kIDYzIGNoYXJhY3RlcnMuIEEgc3RyaW5nIHRoYXQgaXMg ZXhhY3RseSA2NCBjaGFyYWN0ZXJzIGlzIHRoZSBoZXggY3J5cHRvZ3JhcGhpYyBrZXkgKHdoaWNo IG1lYW5zIGl0IGhhcyB0byBiZSByZXN0cmljdGVkIHRvIGhleCBjaGFyYWN0ZXJzLCBhbmQgaXQg cmVxdWlyZXMgbm8gUEJLREYyIG1hbmlwdWxhdGlvbikuIFRoaXMgbWVhbnMgV2ktRmkgV1BBMSBh bmQgV1BBMiBkb24ndCBzdXBwb3J0IGFueSBsZW5ndGggb2Yga2V5IG90aGVyIHRoYW4gMjU2IGJp dC4gV2hpY2ggaXMgc29ydCBvZiBsaW1pdGluZyBmb3IgYW55dGhpbmcgdGhhdCB3YW50cyB0byBi ZSBhYmxlIHRvIGVhc2lseSBhZGQgc3VwcG9ydCBmb3IgbmV3IGZ1dHVyZSBoYXNoIGFsZ29yaXRo bXMuIFdpLUZpIGRlYWxzIHdpdGggc3VwcG9ydCBvZiBuZXcgaGFzaGluZyBhbGdvcml0aG1zIGJ5 IGNyZWF0aW5nIGEgbmV3IFdQQSAoV1BBMyBjb21pbmcgc29vbiB0byBzdG9yZXMgbmVhciB5b3Ug YW5kIG9ubGluZSkuIE11Y2ggb2YgdGhpcyBXaS1GaSBzdHVmZiBzZWVtcyB1bm5lY2Vzc2FyaWx5 IGNvbXBsZXggZm9yIHdoYXQgd2UgbmVlZCwgYW5kIEkgdGhpbmsgd2Ugc2hvdWxkIGxlYW4gdG93 YXJkcyB0aGUgSE1BQyBhcHByb2FjaC4NCg0KSGVyZSBpcyBteSBzdWdnZXN0aW9uOg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkFkZCBuZXcgc2VjdGlvbiwg c29tZXdoZXJlIGJldHdlZW4gdGhlIGVuZCBvZiB0aGUgQ29uY2VwdHVhbCBPdmVydmlldyAoc2Vj dGlvbiAyKSBhbmQgYmVmb3JlIFRoZSBJbnRlcmZhY2UgVGFibGUgKHNlY3Rpb24gMy4xKS4NCg0K IyBQcmVwYXJhdGlvbiBvZiB0aGUgSE1BQyBLZXkNCg0KQWxsIEhNQUMgYWxnb3JpdGhtcyByZXF1 aXJlIGEgY3J5cHRvZ3JhcGhpYyBrZXkuIFNvbWUgDQptYW5pcHVsYXRpb24gb2YgYW4gaW5wdXQg c3RyaW5nIG1heSBiZSByZXF1aXJlZCwgdG8gcHJlcGFyZQ0KaXQgZm9yIHVzZSBhcyB0aGUgY3J5 cHRvZ3JhcGhpYyBITUFDIEtleS4gVG8gYWxsb3cgdGhlDQpzYW1lIHN0cmluZyB0byBiZSBpbnB1 dCB0byBkaWZmZXJlbnQgQmFiZWwgbm9kZXMsIA0KYWxsIEJhYmVsIG5vZGVzIHdpbGwgbmVlZCB0 byBkbyB0aGUgc2FtZSBzdHJpbmcgbWFuaXB1bGF0aW9uLg0KDQpJbiB0aGUgZGVzY3JpcHRpb24g YmVsb3csIHRoZSBmb2xsb3dpbmcgbm9tZW5jbGF0dXJlLCB3aGljaA0KaXMgY29uc2lzdGVudCB3 aXRoIFtSRkMyMTA0XSwgaXMgdXNlZDoNCg0KICAgICAgSCAgICBpcyB0aGUgc3BlY2lmaWMgaGFz aGluZyBhbGdvcml0aG0gKGUuZy4sIFNIQS0yNTYpLg0KICAgICAgSyAgICBpcyB0aGUgZW50ZXJl ZCBBdXRoZW50aWNhdGlvbiBLZXkgKGlucHV0IHN0cmluZykuDQogICAgICBLbyAgIGlzIHRoZSBj cnlwdG9ncmFwaGljIGtleSB1c2VkIHdpdGggdGhlIGhhc2ggYWxnb3JpdGhtDQogICAgICAgICAg ICAocmVmZXJyZWQgdG8gYXMgdGhlIEhNQUMgS2V5IGluIHRoaXMgZG9jdW1lbnQpLg0KICAgICAg QiAgICBpcyB0aGUgYmxvY2sgc2l6ZSBvZiBILCBtZWFzdXJlZCBpbiBvY3RldHMgcmF0aGVyIHRo YW4gYml0cy4gIA0KICAgICAgTCAgICBpcyB0aGUgbGVuZ3RoIG9mIHRoZSBoYXNoLCBtZWFzdXJl ZCBpbiBvY3RldHMgcmF0aGVyIHRoYW4gYml0cy4NCg0KVGhlIEhNQUMgS2V5IChLbykgd2lsbCBh bHdheXMgYmUgTCBvY3RldHMgbG9uZy4NCg0KSWYgdGhlIGVudGVyZWQgQXV0aGVudGljYXRpb24g S2V5IChLKSBsZW5ndGggaXMgZXhhY3RseSAyTCBhbmQNCnVzZXMgb25seSB0aGUgY2hhcmFjdGVy cyAwLTkgYW5kIGEtZiBvciBBLUYsIGl0IE1VU1QgYmUgdXNlZCBhcw0KYSBoZXgtZW5jb2RlZCBz dHJpbmcsIGFuZCBLbyBpcyBlcXVhbCB0byBLLg0KDQpPdGhlcndpc2UsIHRoZSBBdXRoZW50aWNh dGlvbiBLZXkgTVVTVCBiZSB1c2VkIGFzIGEgVVRGLTgNCmVuY29kZWQgc3RyaW5nLiBJZiB0aGUg QXV0aGVudGljYXRpb24gS2V5IChLKSBpcyBMIG9jdGV0cyBsb25nLA0KdGhlbiBLbyBpcyBlcXVh bCB0byBLLiAgSWYgdGhlIEF1dGhlbnRpY2F0aW9uIEtleSAoSykgaXMgbW9yZSB0aGFuDQpMIG9j dGV0cyBsb25nLCB0aGVuIEtvIGlzIHNldCB0byBIKEspLiAgSWYgdGhlIEF1dGhlbnRpY2F0aW9u IEtleSAoSykgaXMgbGVzcw0KdGhhbiBMIG9jdGV0cyBsb25nLCB0aGVuIEtvIGlzIHNldCB0byB0 aGUgQXV0aGVudGljYXRpb24gS2V5IChLKQ0Kd2l0aCB6ZXJvcyAoYml0cykgYXBwZW5kZWQgdG8g dGhlIGVuZCBvZiB0aGUgQXV0aGVudGljYXRpb24gS2V5IChLKSwNCnN1Y2ggdGhhdCBLbyBpcyBM IG9jdGV0cyBsb25nLg0KDQpCYXJiYXJhDQo= From nobody Fri Jan 11 11:43:36 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C434128766 for ; Fri, 11 Jan 2019 11:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdnUiTnBUJM3 for ; Fri, 11 Jan 2019 11:43:32 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD091286E7 for ; Fri, 11 Jan 2019 11:43:32 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id t13so6704758pgr.11 for ; Fri, 11 Jan 2019 11:43:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DMHKWadR2mj31tmaHewWA6jISb0jendSyilZTQvjJNI=; b=Vqwq5QmwNeQjceN2ylLe9QZ6/wCLTZ+4VF1RYsy3aQ4b15jdPfTxLHPUq9FEOppxQY cAQ2No3YjIOam/sCQTJFMUic8v1bwwOArVkXN0T5wBa2/SQbD6k8WtnBtd6PMlMqrT8G HeCj8Iue8eX0haq3xtkHzwYZ2sBbFLQgVRaKcRW4wlBIxXxH20XVy71+knTLRoij7VRr xFncB5E1RbBxh6DpMnrNezuX27fJC1pefWm7xgTSTOp7JZ1+RYXnO+1iIX8D/i+dUw+G V1FWtdHor6EIAaIoenGZf1O1wL8Hv+FjmRSZ8kCRadnZ5yBvdhY97qNwgIMygSBC3ui7 vRPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DMHKWadR2mj31tmaHewWA6jISb0jendSyilZTQvjJNI=; b=WbF+ousEfTEkq7/D4FxvS/SVtW5v0dnXhcUipWG1WElA7a52fNvzhUCBqJVfBJYAM/ tk6K1HQvTj5vO2/edsKO888iJB38UEN/GvA5qUA2dDku6u5soeQ2U0WMidScqVncguvW ATRjpemxDLAOhS/Dz3xEr1PpF/MfkbOqwdsS8BMNDLhXcMewR5xFFDA1VdS4uANUbcF6 plLLtC3I/hR2Jtfb6vVY4cEmv0ZzxFj/PNkbDjwuUBUkiys9Lan+7w1GAZu6UcUi0rBl DaEDdwHHAEEdSDTfNrFBVK+ct2XTHogjrWst0GMN/SvQrZbxfJe+oMS59/ng4Q/kbYfl dYAQ== X-Gm-Message-State: AJcUukeDLh4mwVawEWfWX1LT4Fv0j6DKFvqqHRYz6DHuDp+/bB3IXGAh UftYoRedv4unQDKi9Ci7lQxAR4vpU4yZtBdRXRU= X-Google-Smtp-Source: ALg8bN5LWzjEEIfljFtWjhWHhkcoSli6LXYgxosGRIxEFebImU0bsR2S6Up6dQgsigwMvrErbMmrj6JduEUArKHTleA= X-Received: by 2002:a62:5658:: with SMTP id k85mr15685947pfb.231.1547235811519; Fri, 11 Jan 2019 11:43:31 -0800 (PST) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DF8A154@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF8A9A3@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF8A9A3@GAALPA1MSGUSRBF.ITServices.sbc.com> From: David Schinazi Date: Fri, 11 Jan 2019 11:43:20 -0800 Message-ID: To: "STARK, BARBARA H" Cc: Babel at IETF Content-Type: multipart/alternative; boundary="000000000000edf0ee057f33e860" Archived-At: Subject: Re: [babel] babel-dtls: verifying "authentication" X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 19:43:35 -0000 --000000000000edf0ee057f33e860 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Barbara, I think we're using terminology differently, but I'm not sure how to resolve that best. Would you consider proposing text that would address the issues you point out? A pull request to our repository would be ideal :) Perhaps one way to resolve your issue would be to remove the MUST validate identity, because I see your point that it is unclear. I still believe that we shouldn't over-specify this and instead let usage profiles (like the homenet profile) specify what kind of identity and keys to use for a given use-case. David On Wed, Jan 9, 2019 at 7:18 PM STARK, BARBARA H wrote: > > > On Wed, Jan 9, 2019 at 1:42 PM STARK, BARBARA H wrote: > > I read the draft and think the last paragraph of 2.1 could do with a > little more verbiage as to what "fails to verify the peer's authenticatio= n" > means, since it's part of a "MUST" normative statement. I also don't thin= k > the word "authentication" is used consistently or (in some cases) > correctly. I think of "authentication" as a process. > > I find "request client authentication" and "verify the peer's > authentication" to be odd uses of the word "authentication", and not > consistent with my understanding of the word. I would suggest something > like "request client certificate" (consistent with the name of the messag= e > that is sent) or "request client credentials" for the first phrase. And > perhaps "validate the peer's certificate" or "validate the peer's > credentials" for the second. Unless you mean something different by > "verify" vs. "validate" here. > > > > Our intent was to use the terms authenticate and authentication in the > same way as the TLS specifications do, in particular see the TLS 1.3 spec > introduction > > . > > > > I looked at the TLS 1.3 spec, and the use of =E2=80=9Cauthenticatio= n=E2=80=9D there > is very consistent with my understanding of authentication as a process. > The 2 phrases I noted seem to use =E2=80=9Cauthentication=E2=80=9D as if = it meant > =E2=80=9Cauthentication key=E2=80=9D =E2=80=93 which it does not. The Cer= tificateRequest message is > not used to request client authentication (i.e., request the client perfo= rm > the authentication process). It is used to request a client authenticatio= n > key. You cannot verify an authentication. But you can verify an > authentication key. > > > > Will only X.509 certificate keys be allowed, or will "DH_anon" key > exchange be allowed? > > > > babel-dtls does not specify what source of authentication to use, X509 ar= e > one allowed option, but they are not mandated > > DH_anon is prohibited by "Nodes MUST use mutual authentication" (and > subsequent clarifying text in section 2.1) > > > > TLS 1.2 (RFC 5246) says =E2=80=9CThe following rules apply to the > certificates sent by the server: > > - The certificate type MUST be X.509v3, unless explicitly negotiated > otherwise (e.g., [TLSPGP]).=E2=80=9D > > DTLS (RFC 6347) doesn=E2=80=99t modify this requirement and neither DTLS = nor > babel-DTLS requires support for certificate format negotiation. Every > babel-dtls implementation has to be prepared to act as the DTLS server. > Practically speaking doesn=E2=80=99t this mean every babel-dtls implement= ation that > expects to interoperate in an open environment has to either have or be > able to generate an X.509 certificate? Anything less and there can be no > expectation of interoperability. Clearly, a closed environment can use > whatever it wants. But I don=E2=80=99t find closed environments very inte= resting. > > > > Here are the possible things that are sometimes done as part of > certificate validation, that I think this phrase is potentially referring > to: > 1. Ensure the certificate validDate is not in the past. This check should > only be done if the implementation thinks the underlying system has > acquired a good current time (i.e., it runs a NTP client and getting the > current datetime via NTP has succeeded, or the current datetime has been > configured). > 2. Check the certificate's chain of trust for a trusted CA. This would > mean there is a configured set of trusted CAs. > 3. Check if the certificate has been revoked. This is often not done, but > might not be a bad idea the first time the certificate is seen. > 4. Check if this identical certificate is included in a store of trusted > certificates (either it was previously trusted and stored or the store is > configured). > 5. Check some aspect of "identity". Is there some characteristic of the > peer that is expected to be stable wrt a certificate? For example, would > the same certificate always originate from the same MAC address or LL IPv= 6 > address? > 6. If a TOFU (trust on first use) policy is supported, what exactly shoul= d > be trusted (and what should not be trusted)? I do like allowing for a TOF= U > policy (if an implementation chooses to support one). If it is allowed, I > would suggest something like the cert is TOFU if the IPv6 LL address hasn= 't > been seen before (new neighbor). After that it always has to use the same > cert. When changing certs, send old and new cert together for some time, = so > new cert is associated with trusted old cert. > > Presumably, a device might be configured with a new certificate at some > point (like when the old one expires). Will the new certificate be > considered the same neighbor if the "identity" matches (see item 5 for > question on determining identity)? If you get a request for a new DTLS > session and already have a session for that "identity" (IPv6 LL address?) > with a different certificate, what do you do? > > If there is already a DTLS connection using a provided certificate, what > do you do if you get a request for a new DTLS session using the same > certificate? Tear down the old one? > > With all this said. I think it might be enough if the draft had statement= s > like: > "The key exchange mechanism used MUST require use of X.509 certificates." > (if this is the intent) > "Certificate validation MUST be done according to internal policy. > Characteristics of certificates that MAY be used for validation include t= he > validDate, the Certificate Authority (CA) chain of trust, inclusion in a > revocation list, prior determination of trust, and whether the IPv6 link > local address is the same as in prior uses of the certificate. A trust on > first use (TOFU) model MAY be supported, with policy defined by the > implementation. Any TOFU policy MUST, at a minimum, ensure that a given > certificate is only ever used from a single IPv6 link local address > (neighbor) and fail an unknown certificate used for an IPv6 link local > address already associated with a trusted certificate. " > "When new certificates are issued, they SHOULD be sent together with the > old certificate prior to the old certificate's expiration or revocation, = so > it is possible for the new certificate to inherit any trust associated wi= th > the old certificate." > > > > Certificate validation is out of scope for the babel-dtls draft, in the > same manner as it is out of scope for the TLS or DTLS RFCs. I don't think > any mention of certificates at all belongs in this draft, as some > applications may choose to not use certificates. In the case of babel, th= e > babel-dtls draft specifies how to use DTLS; on the other hand the > certificates and PKI you use is left to the users of babel-dtls, for > example the homenet mapping document could mandate X509 and how to add ne= w > certificates to the trust store, and the other points you mentioned would > make sense to me in that document. > > > > Or make certificate validation a SHOULD. =E2=98=B9 > > > > Validating identity is a MUST, the fact that that identity maps to a > certificate is a MAY. > > > > Validating what identity? You haven=E2=80=99t specified any identit= y to map > anything to. You can=E2=80=99t make validation a MUST if you give no clue= as to how > or what to validate. > > > > Barbara > > > > Thanks, > > David > --000000000000edf0ee057f33e860 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Barbara,

I think we're using ter= minology differently, but I'm not sure how to resolve that best. Would = you consider proposing text that would address the issues you point out? A = pull request to our reposi= tory would be ideal :)

Perhaps one way to reso= lve your issue would be to remove the MUST validate identity, because I see= your point that it is unclear. I still believe that we shouldn't over-= specify this and instead let usage profiles (like the homenet profile) spec= ify what kind of identity and keys to use for a given use-case.
<= br>
David

On Wed, Jan 9, 2019 at 7:18 PM STARK, BARBARA H <bs7652@att.com> wrote:

=C2=A0

On Wed, Jan 9, 2019 at 1:42 PM STARK, BARBARA H <= bs7652@att.com> = wrote:

I read the draft and think the last paragraph of 2.1= could do with a little more verbiage as to what "fails to verify the = peer's authentication" means, since it's part of a "MUST&= quot; normative statement. I also don't think the word "authentica= tion" is used consistently or (in some cases) correctly. I think of "authen= tication" as a process.

I find "request client authentication" and "verify the peer&= #39;s authentication" to be odd uses of the word "authentication&= quot;, and not consistent with my understanding of the word. I would sugges= t something like "request client certificate" (consistent with th= e name of the message that is sent) or "request client credentials"= ; for the first phrase. And perhaps "validate the peer's certifica= te" or "validate the peer's credentials" for the second.= Unless you mean something different by "verify" vs. "valida= te" here.

=C2=A0

Our intent was to use the terms authenticate and aut= hentication in the same way as the TLS specifications do, in particular see the TLS 1.3 spec introduction.

=C2=A0

<bhs> I looked at the TLS 1.3 spec, and the us= e of =E2=80=9Cauthentication=E2=80=9D there is very consistent with my unde= rstanding of authentication as a process. The 2 phrases I noted seem to use= =E2=80=9Cauthentication=E2=80=9D as if it meant =E2=80=9Cauthentication ke= y=E2=80=9D =E2=80=93 which it does not. The CertificateRequest message is not used to request c= lient authentication (i.e., request the client perform the authentication p= rocess). It is used to request a client authentication key. You cannot veri= fy an authentication. But you can verify an authentication key.

=C2=A0

Will only X.509 certificate keys be allowed, or will= "DH_anon" key exchange be allowed?

=C2=A0

babel-dtls does not specify what source of authentic= ation to use, X509 are one allowed option, but they are not mandated=

DH_anon is prohibited by "Nodes MUST use mutual= authentication" (and subsequent clarifying text in section 2.1)

=C2=A0

<bhs> TLS 1.2 (RFC 5246) says =E2=80=9CThe fol= lowing rules apply to the certificates sent by the server:

=C2=A0=C2=A0 -=C2=A0 The certificate type MUST be X.= 509v3, unless explicitly negotiated otherwise (e.g., [TLSPGP]).=E2=80=9D

DTLS (RFC 6347) doesn=E2=80=99t modify this requirem= ent and neither DTLS nor babel-DTLS requires support for certificate format= negotiation. Every babel-dtls implementation has to be prepared to act as = the DTLS server. Practically speaking doesn=E2=80=99t this mean every babel-dtls implementation that expects to interoperate in = an open environment has to either have or be able to generate an X.509 cert= ificate? Anything less and there can be no expectation of interoperability.= Clearly, a closed environment can use whatever it wants. But I don=E2=80=99t find closed environments very i= nteresting.

=C2=A0

Here are the possible things that are sometimes done= as part of certificate validation, that I think this phrase is potentially= referring to:
1. Ensure the certificate validDate is not in the past. This check should o= nly be done if the implementation thinks the underlying system has acquired= a good current time (i.e., it runs a NTP client and getting the current da= tetime via NTP has succeeded, or the current datetime has been configured).
2. Check the certificate's chain of trust for a trusted CA. This would = mean there is a configured set of trusted CAs.
3. Check if the certificate has been revoked. This is often not done, but m= ight not be a bad idea the first time the certificate is seen.
4. Check if this identical certificate is included in a store of trusted ce= rtificates (either it was previously trusted and stored or the store is con= figured).
5. Check some aspect of "identity". Is there some characteristic = of the peer that is expected to be stable wrt a certificate? For example, w= ould the same certificate always originate from the same MAC address or LL = IPv6 address?
6. If a TOFU (trust on first use) policy is supported, what exactly should = be trusted (and what should not be trusted)? I do like allowing for a TOFU = policy (if an implementation chooses to support one). If it is allowed, I w= ould suggest something like the cert is TOFU if the IPv6 LL address hasn't been seen before (new neigh= bor). After that it always has to use the same cert. When changing certs, s= end old and new cert together for some time, so new cert is associated with= trusted old cert.

Presumably, a device might be configured with a new certificate at some poi= nt (like when the old one expires). Will the new certificate be considered = the same neighbor if the "identity" matches (see item 5 for quest= ion on determining identity)? If you get a request for a new DTLS session and already have a session for that "i= dentity" (IPv6 LL address?) with a different certificate, what do you = do?

If there is already a DTLS connection using a provided certificate, what do= you do if you get a request for a new DTLS session using the same certific= ate? Tear down the old one?

With all this said. I think it might be enough if the draft had statements = like:
"The key exchange mechanism used MUST require use of X.509 certificate= s." (if this is the intent)
"Certificate validation MUST be done according to internal policy. Cha= racteristics of certificates that MAY be used for validation include the va= lidDate, the Certificate Authority (CA) chain of trust, inclusion in a revo= cation list, prior determination of trust, and whether the IPv6 link local address is the same as in prior uses of th= e certificate. A trust on first use (TOFU) model MAY be supported, with pol= icy defined by the implementation. Any TOFU policy MUST, at a minimum, ensu= re that a given certificate is only ever used from a single IPv6 link local address (neighbor) and fail an unk= nown certificate used for an IPv6 link local address already associated wit= h a trusted certificate. "
"When new certificates are issued, they SHOULD be sent together with t= he old certificate prior to the old certificate's expiration or revocat= ion, so it is possible for the new certificate to inherit any trust associa= ted with the old certificate."

=C2=A0

Certificate validation is out of scope for the babel= -dtls draft, in the same manner as it is out of scope for the TLS or DTLS R= FCs. I don't think any mention of certificates at all belongs in this d= raft, as some applications may choose to not use certificates. In the case of babel, the babel-dtls draft specif= ies how to use DTLS; on the other hand the certificates and PKI you use is = left to the users of babel-dtls, for example the homenet mapping document c= ould mandate X509 and how to add new certificates to the trust store, and the other points you mentioned wo= uld make sense to me in that document.=C2=A0

=C2=A0

Or make certificate validation a SHOULD. =E2=98=B9

=C2=A0

Validating identity is a MUST, the fact that that id= entity maps to a certificate is a MAY.

=C2=A0

<bhs> Validating what identity? You haven=E2= =80=99t specified any identity to map anything to. You can=E2=80=99t make v= alidation a MUST if you give no clue as to how or what to validate.<= u>

=C2=A0

Barbara

=C2=A0

Thanks,

David

--000000000000edf0ee057f33e860-- From nobody Sat Jan 12 03:49:01 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018B512DD85 for ; Sat, 12 Jan 2019 03:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_nJX3y3y2wm for ; Sat, 12 Jan 2019 03:48:56 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57251129A87 for ; Sat, 12 Jan 2019 03:48:56 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0CBmk6l000978; Sat, 12 Jan 2019 12:48:46 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id CA3DB746E9; Sat, 12 Jan 2019 12:48:51 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id pBYOQZLjEj0Q; Sat, 12 Jan 2019 12:48:49 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 4ECAD746E7; Sat, 12 Jan 2019 12:48:47 +0100 (CET) Date: Sat, 12 Jan 2019 12:48:47 +0100 Message-ID: <875zuuw0yo.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'David Schinazi'" , Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF8A9A3@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF8A154@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF8A9A3@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 12 Jan 2019 12:48:46 +0100 (CET) X-Miltered: at korolev with ID 5C39D41E.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C39D41E.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C39D41E.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] babel-dtls: verifying "authentication" X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2019 11:48:59 -0000 > TLS 1.2 (RFC 5246) says “The following rules apply to the certificates > sent by the server: > - The certificate type MUST be X.509v3, unless explicitly negotiated > otherwise (e.g., [TLSPGP]).” My reading is that this doesn't preclude negotiating a different certificate type (either in-band or out-of-band, e.g. through static configuration) or using a PSK (symmetric key). I agree with David that this is out of scope for the Babel-DTLS draft. > Validating identity is a MUST, the fact that that identity maps to a > certificate is a MAY. > Validating what identity? David should not have spoken about identity -- what we're speaking here is authentication. TLS has a notion of server and client authentication. Server authentication is hardwired into the protocol, client authentication is optional. What the draft says is that the Babel-DTLS protocol requires client authentication in addition to server authentication. > You haven’t specified any identity to map anything to. You can’t make > validation a MUST if you give no clue as to how or what to validate. I'm not a specialist, but this looks like it's consistent with the nature of TLS. -- Juliusz From nobody Sat Jan 12 04:32:32 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2D6129B88 for ; Sat, 12 Jan 2019 04:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F55yqnF3kV5d for ; Sat, 12 Jan 2019 04:32:29 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7A53128CF3 for ; Sat, 12 Jan 2019 04:32:28 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0CCWGDF019258; Sat, 12 Jan 2019 13:32:16 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 4503474C06; Sat, 12 Jan 2019 13:32:22 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id EZS47vOYE_QL; Sat, 12 Jan 2019 13:32:20 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C2AB274C04; Sat, 12 Jan 2019 13:32:19 +0100 (CET) Date: Sat, 12 Jan 2019 13:32:19 +0100 Message-ID: <874laevyy4.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 12 Jan 2019 13:32:17 +0100 (CET) X-Miltered: at korolev with ID 5C39DE50.004 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C39DE50.004 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C39DE50.004 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2019 12:32:31 -0000 Barbara, I think we must carefully distinguish between: - the key K being used by HMAC; - how the key is computed; - the user interface (e.g. the config file), which allows the user (or the managing software, e.g. HNCP) to express the key computation. The key K is well defined in all cases -- it's a string of octets the length of the HMAC bloc size. Computation of the key should not happen on the router -- the router should be given the computed key, and any secrets used to compute the key should not be distributed on the routers. For example, if the key is obtained by hashing a passphrase, then the original passphrase should not be stored on the router. Similarly, if the key is drawn randomly (e.g. by an automated key distribution protocol), then the PRNG state should not be exposed to the routers. > As a reminder (from that discussion), OSPF (RFC 5709) has this: [...] > I've also discovered that the HMAC RFC (RFC 2104) says: Both of these look extremely naive to my untrained eyes (and 2104 is confusing). Better approaches include: - drawing the key randomly before distribution (RFC 4086); - using a proper KDF to derive a key from a passphrase (see e.g. RFC 5869). As mentioned above, the key generation should happen offline, and is therefore out of scope for this draft. > We also noted that the Bird code applies ASCII (which is the same as > UTF-8) encoding to an input authentication key string (and not hex, > base64, or UTF-16). Internally, BIRD uses the raw binary string. The user interface allows entering the key as a quoted string. BIRD doesn't interpret the octets entered in the string, so they could be encoded as UTF-8, ISO 8859-15, Shift-JIS, whatever, depending on your terminal configuration. (See the terminal TEXT in cf-lex.l in the BIRD sources.) > My preference is that we have something in the HMAC draft, not too much > unlike the OSPF text. I disagree. RFC 5709 is very naive, if a key is generated from user input, that should be done offline, and using a proper KDF, not the naive procedure described in 5709. > I like UTF-8. So do I -- but this is all out of scope for this draft, since key generation should happen offline. If you believe that the key derivation procedure should be described, then this should happen in a separate draft (that can be used with both Babel-HMAC and OSPF static keying), or perhaps in an informative appendix to this draft. In that case, we'd need to consult a cryptographer in order to select a safe KDF. -- Juliusz From nobody Sat Jan 12 06:05:12 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511201274D0 for ; Sat, 12 Jan 2019 06:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kapsi.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMQBQE5mtW2I for ; Sat, 12 Jan 2019 06:05:08 -0800 (PST) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A986C124BAA for ; Sat, 12 Jan 2019 06:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=JeMSACFu77HBmCH+hkUh+2NPznOxxy3InySsp5w1sAc=; b=vDkkTjn7uRCG3W7PTksun4yNPN 8XK8O3R1b+j/jGqYuz86w+s13E0t+vdI4KL8XvhJpKuHte0ebSajrZsmtPpvPHARXCx8pCbUC/g// kK6PK7351RJuHDtHcGeadGWbbkdNNwZJltpGdUxuAxaQ8j19QxThYfG+ziqSqLSlhRzBH8wwab9kQ jMCXZfTr5/8qOr2vt4mr98A1W9936RCry1uU5kCbdC/AKomHnK2A/v5MgMv9leW17njizccWpCzCx kWB83GwxcXYm92xdbvNH2UtYOzTb86J/bP+HxAhK6sOhS69lMM8g/mds3Q96THWa5j9M6AgLC5oqp +8JOeiwg==; Received: from 91-155-69-202.elisa-laajakaista.fi ([91.155.69.202] helo=himawari.lan) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1giJuK-0007ic-HL; Sat, 12 Jan 2019 16:05:04 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Markus Stenberg In-Reply-To: <874laevyy4.wl-jch@irif.fr> Date: Sat, 12 Jan 2019 16:05:04 +0200 Cc: BARBARA H STARK , Babel at IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> <874laevyy4.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.102.3) X-SA-Exim-Connect-IP: 91.155.69.202 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2019 14:05:11 -0000 On 12.01.2019, at 14.32, Juliusz Chroboczek wrote: >> I've also discovered that the HMAC RFC (RFC 2104) says: >=20 > Both of these look extremely naive to my untrained eyes (and 2104 is > confusing). Better approaches include: >=20 > - drawing the key randomly before distribution (RFC 4086); > - using a proper KDF to derive a key from a passphrase (see e.g. RFC = 5869). >=20 > As mentioned above, the key generation should happen offline, and is > therefore out of scope for this draft. +1. If one really cares about security, few bytes of ASCII is not really = what you want to use as key; ideally, very close to random bits, and = plenty of them. One way of sourcing them is by deriving them from passphrase using some = computation which is hard to brute-force though, so even if I use = password 'Markus rul3s', someone is unlikely to bother trying to = bruteforce it and the clever 3 is sufficient as a security mechanism if = it takes (say) minute per attempt on modern CPU. e.g. RFC5869 is a good starting point (or its SHA-2 application in = RFC6234). >> My preference is that we have something in the HMAC draft, not too = much >> unlike the OSPF text. > I disagree. RFC 5709 is very naive, if a key is generated from user > input, that should be done offline, and using a proper KDF, not the = naive > procedure described in 5709. +1. All the classic 'let's HMAC and call it done' mechanisms are completely = obsolete as security mechanisms, unless the input to HMAC is in and of = itself pseudorandom garbage of sufficient length and not passphrase in = the first place. Disclaimer: These are 'old school' recommendations, current KDF state of = the art is bit different IIRC but even these are much better than the = good old IETF standard (toss MD5 in), or 'modern-ish' IETF standard = (toss HMAC-SHA in) way. Draft should possibly state that if passphrases are used, KDF of SOME = SORT should be used, but the actual KDF is IMHO implementation matter = and as long as all implementations can be configured with same bytes = that come out of KDF they would interoperate. Cheers, -Markus= From nobody Sat Jan 12 06:27:24 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B20130E96 for ; Sat, 12 Jan 2019 06:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epwF8RTsNLn8 for ; Sat, 12 Jan 2019 06:27:22 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28514130E66 for ; Sat, 12 Jan 2019 06:27:21 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0CERE7e027933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 12 Jan 2019 15:27:14 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x0CEREve003204; Sat, 12 Jan 2019 15:27:15 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 463F175B48; Sat, 12 Jan 2019 15:27:18 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id L1VVjjSzUD9J; Sat, 12 Jan 2019 15:27:16 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2EE0075B46; Sat, 12 Jan 2019 15:27:16 +0100 (CET) Date: Sat, 12 Jan 2019 15:27:16 +0100 Message-ID: <87wonauf23.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: Babel at IETF In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> <874laevyy4.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 12 Jan 2019 15:27:14 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 12 Jan 2019 15:27:16 +0100 (CET) X-Miltered: at korolev with ID 5C39F942.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5C39F942.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C39F942.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5C39F942.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C39F942.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5C39F942.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2019 14:27:23 -0000 > Disclaimer: These are 'old school' recommendations, current KDF state of > the art is bit different IIRC I'd be interested in a pointer, if you have one handy. Thanks, -- Juliusz From nobody Sat Jan 12 06:30:53 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257A4130F9A for ; Sat, 12 Jan 2019 06:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kapsi.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWkqUAL25twz for ; Sat, 12 Jan 2019 06:30:45 -0800 (PST) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322A3130FB5 for ; Sat, 12 Jan 2019 06:30:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=9pNFdBGwuDspGfIO5jg0UY/qIV/80shRg2OGf1AUOyM=; b=lvu2kNOAMmTN+4H+2K0r2xmjEr CMx37YiOGtncpbXdmwfsh6x0plW8aZGAJbV7vRpL9kvp8VD+U8CZQy5qXXAiW0DVWcz2SNQcI6Fzg 0kvFwjpjLw/fT7NqiXFH7bA/IpYk4HJRUZx1h7ZZ/CcIRQvnfvqjQODCnm0o76jofD3Pg3FYS4gTL ktQFea4KWGiXdioqJnhqN23aXX+eb8zL2TIK+OwEIBhbx97LfW4+9yKj8ACnmCWoUoADm3ZqtKWJ+ IFg4U7yZMzYgmKIEHHGlz+vtD4/Kh91qNCksC8UpFOmx3ZyAzfCezMIjTVpJf06Jsmbi3F1s0LAox 1oPO/6/w==; Received: from 91-155-69-202.elisa-laajakaista.fi ([91.155.69.202] helo=himawari.lan) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1giKJ8-0007q5-M4; Sat, 12 Jan 2019 16:30:42 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Markus Stenberg In-Reply-To: <87wonauf23.wl-jch@irif.fr> Date: Sat, 12 Jan 2019 16:30:42 +0200 Cc: Babel at IETF Content-Transfer-Encoding: 7bit Message-Id: <4C3B7EE9-36F8-4E3A-8F2F-1DD4A29B2790@iki.fi> References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> <874laevyy4.wl-jch@irif.fr> <87wonauf23.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.102.3) X-SA-Exim-Connect-IP: 91.155.69.202 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2019 14:30:52 -0000 On 12.01.2019, at 16.27, Juliusz Chroboczek wrote: >> Disclaimer: These are 'old school' recommendations, current KDF state of >> the art is bit different IIRC > I'd be interested in a pointer, if you have one handy. https://password-hashing.net -Markus From nobody Sat Jan 12 06:42:41 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344F1124BAA for ; Sat, 12 Jan 2019 06:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P05VZzPRkZYp for ; Sat, 12 Jan 2019 06:42:37 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76AC5126C7E for ; Sat, 12 Jan 2019 06:42:37 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0CEgRJJ000608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 12 Jan 2019 15:42:27 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x0CEgTQv007165; Sat, 12 Jan 2019 15:42:29 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3FE6375D4C; Sat, 12 Jan 2019 15:42:33 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id VNUxIf4tMW00; Sat, 12 Jan 2019 15:42:31 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1BF4F75D45; Sat, 12 Jan 2019 15:42:31 +0100 (CET) Date: Sat, 12 Jan 2019 15:42:31 +0100 Message-ID: <87tvieueco.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: BARBARA H STARK , Babel at IETF In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> <874laevyy4.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 12 Jan 2019 15:42:27 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 12 Jan 2019 15:42:29 +0100 (CET) X-Miltered: at korolev with ID 5C39FCD3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5C39FCD5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C39FCD3.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5C39FCD5.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C39FCD3.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5C39FCD5.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2019 14:42:39 -0000 > Draft should possibly state that if passphrases are used, KDF of SOME > SORT should be used, but the actual KDF is IMHO implementation matter > and as long as all implementations can be configured with same bytes > that come out of KDF they would interoperate. So it looks like I should add something to the Security Considerations section. What about In addition to the above, the mechanism described in this draft relies on an attacker being unable to guess the HMAC key, whether by brute force or by other means. Ideally, the HMAC key SHOULD be generated randomly using a strong random number generator [RFC4086] and distributed to the routers using some sufficiently secure mechanism (e.g., ssh [RFC4251]). If the HMAC key is generated from user input (a "passphrase"), then the passphrase SHOULD NOT be stored on the individual routers: the key SHOULD be generated on a secure host using a sufficiently strong Key Derivation Function (KDF) RFC5869] [RFC6234] and, again, the resulting distributed to the routers using some sufficiently secure mechanism. In order to make offline key generation practical, implementations SHOULD use the key provided by the user with no transformation of any kind. From nobody Sat Jan 12 07:30:33 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A44130E25 for ; Sat, 12 Jan 2019 07:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIhhG5pbsW4H for ; Sat, 12 Jan 2019 07:30:30 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DF84129B88 for ; Sat, 12 Jan 2019 07:30:30 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0CFUMP5016645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 12 Jan 2019 16:30:22 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x0CFUOsZ019086; Sat, 12 Jan 2019 16:30:24 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 10A7C762E1; Sat, 12 Jan 2019 16:30:28 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id CYZOnw-n1ZDl; Sat, 12 Jan 2019 16:30:26 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 98625762DD; Sat, 12 Jan 2019 16:30:23 +0100 (CET) Date: Sat, 12 Jan 2019 16:30:23 +0100 Message-ID: <87o98lvqpc.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: Babel at IETF In-Reply-To: <4C3B7EE9-36F8-4E3A-8F2F-1DD4A29B2790@iki.fi> References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> <874laevyy4.wl-jch@irif.fr> <87wonauf23.wl-jch@irif.fr> <4C3B7EE9-36F8-4E3A-8F2F-1DD4A29B2790@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 12 Jan 2019 16:30:22 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 12 Jan 2019 16:30:24 +0100 (CET) X-Miltered: at korolev with ID 5C3A080E.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5C3A0810.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C3A080E.003 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5C3A0810.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C3A080E.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5C3A0810.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2019 15:30:33 -0000 >>> Disclaimer: These are 'old school' recommendations, current KDF state of >>> the art is bit different IIRC >> I'd be interested in a pointer, if you have one handy. > https://password-hashing.net Interesting, thanks. Roughly speaking, they're concerned about ASIC and FPGA implementations of brute-force cracking, so they design hashing algorithms that require absolute shitloads of RAM. -- Juliusz From nobody Mon Jan 14 09:02:33 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D9E1311B7 for ; Mon, 14 Jan 2019 09:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivIeOW57Lzha for ; Mon, 14 Jan 2019 09:02:29 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868141311B6 for ; Mon, 14 Jan 2019 09:02:29 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x0EGvBDA018916; Mon, 14 Jan 2019 12:02:28 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2q0wnt1epc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Jan 2019 12:02:28 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0EH2Rmf012611; Mon, 14 Jan 2019 12:02:28 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0EH2OBJ012517; Mon, 14 Jan 2019 12:02:24 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 26B784013D3B; Mon, 14 Jan 2019 17:02:24 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30484.vci.att.com (Service) with ESMTPS id 13C1D4013D3A; Mon, 14 Jan 2019 17:02:24 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.203]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0415.000; Mon, 14 Jan 2019 12:02:23 -0500 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: Babel at IETF Thread-Topic: [babel] babel-hmac: key requirements Thread-Index: AdSpKuuhWh3uIPf3TSyfFq2fmw6nrABcdjuAAFt168A= Date: Mon, 14 Jan 2019 17:02:22 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF9BFAF@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> <874laevyy4.wl-jch@irif.fr> In-Reply-To: <874laevyy4.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.250.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-14_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901140139 Archived-At: Subject: Re: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 17:02:31 -0000 My goal in this discussion is: 1. Getting rid of ambiguity in HMAC key format that is accepted as an input= to a babel-hmac implementation on a device. 2. Understand how human beings are expected to interact with getting keys i= nto an implementation, and making sure these expectations are reasonable. .... > Computation of the key should not happen on the router -- the router > should be given the computed key, and any secrets used to compute the key > should not be distributed on the routers. For example, if the key is obt= ained > by hashing a passphrase, then the original passphrase should not be store= d > on the router. Similarly, if the key is drawn randomly (e.g. by an autom= ated > key distribution protocol), then the PRNG state should not be exposed to = the > routers. I'm fine with this, if this is the approach everyone agrees on. But the cur= rent draft makes no mention of this expectation, which has resulted in Toke= 's implementation accepting direct entry of a string it interprets as ASCII= and will subsequently hash if the string is longer than the length of the = hash (which is inconsistent with the above expectation). I don't blame Toke= for doing this -- it seems perfectly reasonable given the lack of specific= ation in the draft and the available tools. I'd like the expectations on th= e HMAC Key to be easily found by someone scanning the table of contents. Here is a suggestion: Insert new 2nd level header below 3 (Data Structures) ## The HMAC Key The HMAC Key is the exact cryptographic key used with the hash algorithm. H= ow the HMAC Key is provided (e.g., a configuration protocol, a user interfa= ce, a separate application that includes a computation algorithm, etc.) is= outside the scope of this specification. The provided HMAC Key MUST NOT be= modified in any way prior to use with the hash algorithm.=20 =20 ... > If you believe that the key derivation procedure should be described, the= n > this should happen in a separate draft (that can be used with both Babel- > HMAC and OSPF static keying), or perhaps in an informative appendix to th= is > draft. In that case, we'd need to consult a cryptographer in order to se= lect a > safe KDF. No, I don't think that's needed, and I don't think we have anything to say = about OSPF static keying. What I do think is needed is a lack of ambiguity = around what the "HMAC Key" is and a statement that no modification of the p= rovided HMAC Key is permitted. If that's the approach being taken. Barbara From nobody Mon Jan 14 09:12:57 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D7E1311C3; Mon, 14 Jan 2019 09:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiN2W_Z0O2Fl; Mon, 14 Jan 2019 09:12:54 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA211311BE; Mon, 14 Jan 2019 09:12:53 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id c14so23894103wrr.0; Mon, 14 Jan 2019 09:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OoRRtPfmuB5LQkjV4F68Sb7m9giJSrXIqivMs3QnNz0=; b=JJM7FlGZUwqWDLiGZs7dyRj3apWZxOqzD0wqUVr8kSyLtHWhH/mupkQBYoqaoO+IDq TMq8ryWaiOB3/y7UJ+v2/kXDKhIFqjXmx42V1k5b1STRHZQkyiSfTu2BEhC+T+4n6y3S hB5Jox7uIiG+C5Z3225JUGE9F2JYRGTPXk3RMM8aiUOZcoK+HMmC2ISTrqcBm4zOvvjW IAWGwcWZJRIiUkoSI5prj8CyKGKXdQmp7uGeBjGlzNT7j1eF6mp6ScgzTb6tGnIVOInt sCE3s3traoGB+rZx1YmpTRNEKRU82Nrg/7h1EYWe0PFpqtloke406xQtzts9cInvvvmh VAKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OoRRtPfmuB5LQkjV4F68Sb7m9giJSrXIqivMs3QnNz0=; b=k4hMj5OCeBapbYjPrdxFF0eqdxTNPPt5JaEZnkrvdFfK+1XJDEpwWipIGKGZAV8Qgl TABXMljdG/QepkV6ZSchsGcsSW58IMSCsEzkyTMhTibYB2+1lfMMlAdQAtam+fFvY8Sw nj4HdemF5IEs/hp9Df0n58nFVtJyz9J3fpBWYfYqQw2dq9bWYOkqDX42FVcODj0kFDKc d/c3SmpJzi8jDb9qP7VkBJbrTk2ekwqQbysEctqHet8k4Tdx4b8dnAoeuyjuLbbJE0lm VQZCPhMY+pSZyVGrfnYoDfYtTsjvZ08tY31dQfMGky4A0EmLA7PgoKCerPqszLj+prr9 OAyQ== X-Gm-Message-State: AJcUukc/VXLqKi+ik/hA3UbJLPu3a2qtNcPMRPEubrclXmZURj81Yjzn 4D2rRBQDweVK2Qb607fxicw2PoYAQzMiSfN8aJA= X-Google-Smtp-Source: ALg8bN5aajWgtCNoG4EvqoC5cuKHZrJjFRaX2OfeYw9wq7sjCe3tfk2ORnclf05AohKGCNMwemNDOyF3v/9hBPFpaBI= X-Received: by 2002:adf:dbcb:: with SMTP id e11mr26162365wrj.58.1547485972094; Mon, 14 Jan 2019 09:12:52 -0800 (PST) MIME-Version: 1.0 Received: by 2002:adf:e4c1:0:0:0:0:0 with HTTP; Mon, 14 Jan 2019 09:12:51 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Weronika_Ko=C5=82odziejak?= Date: Mon, 14 Jan 2019 18:12:51 +0100 Message-ID: To: Donald Eastlake Cc: Babel at IETF , babel-chairs , "draft-ietf-babel-dtls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a964bf057f6e27d4" Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-dtls-03 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 17:12:56 -0000 --000000000000a964bf057f6e27d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Donald, I support publication. Weronika W dniu =C5=9Broda, 9 stycznia 2019 Donald Eastlake napis= a=C5=82(a): > Hi, > > This message begins a Working Group Last Call on draft-ietf-babel-dtls > running to January 21st. Please comment on whether or not you think > the draft is ready for publication. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail.com > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000a964bf057f6e27d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Donald,

I support publication.

Weronika

W dniu =C5=9Broda, 9 stycznia 2019 Donald Eastlake &l= t;d3e3e3@gmail.com> napisa=C5=82= (a):
Hi,

This message begins a Working Group Last Call on draft-ietf-babel-dtls
running to January 21st. Please comment on whether or not you think
the draft is ready for publication.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A01424 Pro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.com

_______________________________________________
babel mailing list
babel@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/babel
--000000000000a964bf057f6e27d4-- From nobody Mon Jan 14 09:14:05 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85C11311CA; Mon, 14 Jan 2019 09:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbsVOJdDMlZN; Mon, 14 Jan 2019 09:14:02 -0800 (PST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41BB91311BF; Mon, 14 Jan 2019 09:14:02 -0800 (PST) Received: by mail-wm1-x333.google.com with SMTP id t200so352857wmt.0; Mon, 14 Jan 2019 09:14:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z2exBupNlUy+cZ+jKL4mc6vldNJUl5pyIuE6k3eGWPY=; b=KF7mADoOc/NgcelXe643Q7VYwMTFbVx3jSm+4QDFnh6goYsZin4YX/SNb58tewE0rB DlfOaZW0dlzoY2A8bMjlcz3HpL/mJbSxS53yxlPfH+ANssLfzvhdpTTiqkk/Efco5cAZ N78nmwTELNI/dA0nibysPNUunpWFQLufm88Im4cdmg2PC/YPfHiSN7qbAYLy80ooJiAQ idI15pi3zoMg5u/km2tJ54QYU0bSBwyfpPhZy8/HG89WVvivR6J/L3S54IyUU2YTHf9A ui8Pv2kxs8xS4+h9xYNwLJ0BBsmWyLaBbEqLVTaGMr7/s7euWVrxSHIb9JUBSs8Z/rB6 0ULg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z2exBupNlUy+cZ+jKL4mc6vldNJUl5pyIuE6k3eGWPY=; b=d7gf+Bo5YctY6e9s5hyv2QgnJ/2LTr9Es5Esj+p1T0pnGqY5V6BUw/G/e1nurtB/8m /IB2U8CzBXiHrH4RKZdOdg2w0ABM9FRfoOkjn87zxqCIgvsldojWyQiH6FIftgj/IctU XoIdVZUXA9F1/72DsOqvpODysl1VjQi77m1yUyI2DgyouAJW8PF3NhvRDEOH3zRaDD+r ZPqlUymKFAiOIOeGLPFmUQcB0+YuH2FlT3/Xx3BNUX2u7LM3kRGDi3nkK8GCjk6IDanE p/QlQg2wSqgSBIpcWyN0WaKlffdA+OYcMSmdDfDlj1t3d2CCdu8Pl9sCrS+3RNF1VIba XWDQ== X-Gm-Message-State: AJcUukdHaj81iuVWlBTq454ikYVbPze0CKdItSr0/vB2nAD11hFYqJvx Rq/hm3U8xNQpas9027y9yWvNHrxXCehWV3WTmK0= X-Google-Smtp-Source: ALg8bN47d7Ckl/2DrHfTLgDrRixMDfHhj2rBtYu7aMCH6Qv3wJwent9qGTBQgQDs8keAxVLSjcTt5qB1EWQIG4grmS0= X-Received: by 2002:a1c:63d5:: with SMTP id x204mr81048wmb.137.1547486040633; Mon, 14 Jan 2019 09:14:00 -0800 (PST) MIME-Version: 1.0 Received: by 2002:adf:e4c1:0:0:0:0:0 with HTTP; Mon, 14 Jan 2019 09:14:00 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Weronika_Ko=C5=82odziejak?= Date: Mon, 14 Jan 2019 18:14:00 +0100 Message-ID: To: Donald Eastlake Cc: Babel at IETF , babel-chairs Content-Type: multipart/alternative; boundary="000000000000bf3b2d057f6e2b74" Archived-At: Subject: Re: [babel] WG Last Call on draft-ietf-babel-hmac X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 17:14:04 -0000 --000000000000bf3b2d057f6e2b74 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Donald, I support publication. Weronika W dniu pi=C4=85tek, 21 grudnia 2018 Donald Eastlake napisa=C5=82(a): > Hi, > > At the Bangkok IETF meeting we said we would start a WG Last Call on > draft-ietf-babel-hmac. So, this message starts such a Last Call. Due > to the holidays, this will run through January 13th. Do you think this > draft is ready for publication? It is fine to provide suggestions for > improvement with your response. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail.com > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000bf3b2d057f6e2b74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Donald,

I support publication.

Weronika=C2=A0

W dniu pi=C4=85tek, 21 grudnia 2018 Donald East= lake <d3e3e3@gmail.com> napis= a=C5=82(a):
Hi,

At the Bangkok IETF meeting we said we would start a WG Last Call on
draft-ietf-babel-hmac. So, this message starts such a Last Call. Due
to the holidays, this will run through January 13th. Do you think this
draft is ready for publication? It is fine to provide suggestions for
improvement with your response.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A01424 Pro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.com

_______________________________________________
babel mailing list
babel@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/babel
--000000000000bf3b2d057f6e2b74-- From nobody Mon Jan 14 09:25:31 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C6A130FB4; Mon, 14 Jan 2019 09:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgV35Nqna2vJ; Mon, 14 Jan 2019 09:25:27 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0BED1311BF; Mon, 14 Jan 2019 09:25:24 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id y78so10970411qka.12; Mon, 14 Jan 2019 09:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tjQST5WTRc74w4vkbFrzt9vVSzKckHoxBTycmIdBQLU=; b=DKWBFoaGevUq0hrPtf4gABXoZtvAKBMmBx03qCLonOcTWZlHvh4837wEvAQIkBcjWd Bg76BsLTVU8IQJRaW8SUsB9Yl+9DA2i/LlTlV6PByIqXldbt7xLDK5mSEgfECWk9KDfw ULbLpnlS84+JzkRjAg/tPgLA+KtgMdS5L2yyW3SNKIf9V/MnrSQfPopTB8P5cjCs/rFP JEVhJLn0Yl2qu/OIUL6WO0N5EFJY7FozZFwu7/jfBPEsJ2fosiFOAXnJ9GwdxEMzXwOc rHfF8U3VvkdxEwVA3XyfVFSIvhrLiet7QA8ODcvV7i+L3clleHHfv3Bv72mfASXm2vnD a9qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tjQST5WTRc74w4vkbFrzt9vVSzKckHoxBTycmIdBQLU=; b=EvCH6yy4uxGDl/aO1zlTYtfhlcyWHKGyZPTAsSSo/5gN3c+ZTRl9IDi6ojwQhkkum7 XnoiZoUHvCz9SvSgUhxh7UrJd66tVVLJlsZYFHaQu2LxcGPgYdJSF7CsPxvD8zukxtfR NUdCJISlu8SkHL8wqhN+n+2a051YhXeG7JFKyyrEHN+Dnwh5D19+/tTIEJN+I2sZdOtz aOkiSUS1LMVXCthho8y3ZbpG9WrjPYfIq5CzSDZTWDFrioahwdcnDoGm8lMNSw2QlNWu YzRGFrMxFCTyBldKC0aQHb7vswIoZIi3cDYkrxWg/Khe4D42lvDtGPVGvAAq4fDKYEFu Ix3g== X-Gm-Message-State: AJcUukfDfi0002lUgbqwcSbQ3P0vswtf1H+DMM2Y/I6CU2DTWSjaRwfX YsoQZULWHiTeJk+q5sBf61mKG6+2mOhFj1BzgjE= X-Google-Smtp-Source: ALg8bN75YTeEIzETWWpoG2YGkpUqV6gLRhsQaZpQ2dcQd6w5iupuML4WQKgI/a2XuIAj2dMl5FmTUA0gD5n8B/fG/YI= X-Received: by 2002:ae9:ee02:: with SMTP id i2mr22818375qkg.179.1547486724015; Mon, 14 Jan 2019 09:25:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Mon, 14 Jan 2019 09:25:12 -0800 Message-ID: To: =?UTF-8?Q?Weronika_Ko=C5=82odziejak?= Cc: Donald Eastlake , babel-chairs , Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] WG Last Call on draft-ietf-babel-hmac X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 17:25:30 -0000 I've raised all my issues and am glad the key format one is attracting attention. Otherwise... I support publication of this draft. From nobody Mon Jan 14 09:27:22 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D23130FE1; Mon, 14 Jan 2019 09:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuJOVNtLhiLY; Mon, 14 Jan 2019 09:27:20 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E0E130FB4; Mon, 14 Jan 2019 09:27:20 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id y20so27386632qtm.13; Mon, 14 Jan 2019 09:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=n9WSMamVkCoih5eJOfHCKXe3zAvpONjgwO5Bp2Ylnl4=; b=gVJDoboehzt8CkpNCtZ7tApRTuXOSo/m/8v+U6o1NHNnIe4hD3EmQ2/1JbiOQTm0Mz 6qxJgMT2IVRUrKpSMpdWnyFTiy++9Ny2wb18VpPJmUVl8g9Dk0pySC2FBZUzNH8lskAE VEjor78kKeEuHboUK4BrI4MdPOxCEEydGSO3BTAJg5i/cOtAMml688pPADZZETbVZL9q MJ+ZeT9KXTiIXKRwElVWgYc8Y34/YoNfuAxamCZsQmKRedutLF4GKRFHvwZ4zzuNW4IN tufnw2fvPAktIijHgO9gYf7ejRDjhpQNXzw6xHw/x033jtgYuCHppM4l4CeCrj9BpJOs k5yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=n9WSMamVkCoih5eJOfHCKXe3zAvpONjgwO5Bp2Ylnl4=; b=poBFFRgt3ioi69b9FCohyMstjoNxFJLSk4yZX9an5yt5jxXDvPbsMaQ+UULYAsakOY XXELv6FKo358+NHgcfy488kGc61t9Jld8Pb9HDn3EnWqCAvKlWkvL6fEAYOMTUDaxoum tfGkSAMw//BvIS0XAVqpxKgb/fVzjflVOE0Mm+CAQRbwceVxxYzNb51oqW+9ZjvwEEUS 1sF3EysNSLhN1bTqH+/wizKsWbJvqyzVcZb1cUHLvp78yzDJxrvcKGA5Hjhd0GP27vWQ ixtdusykQmHVZxhsPJM6t7aDZUrTaXZzBSmYTKiPwtmbZs5cnft2wnckLBq8A5yv1W/R VyBQ== X-Gm-Message-State: AJcUukf1UyOzvqSVG/E8Imi96/4DWpXGRkphs0vqI10w4Op1zt7tKEcZ n50h8AOICuynuvR6pynj900z6l517PrB8DdJRF8= X-Google-Smtp-Source: ALg8bN6ZrAJBPlGaPwhGTm11oyvnbEG4cJidN8fknKdGTH9ELCdutfpGiIWT0Z6pAw3OXk8l8AYqR0VLDMz8GU44EUY= X-Received: by 2002:ac8:3065:: with SMTP id g34mr25192302qte.136.1547486839126; Mon, 14 Jan 2019 09:27:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Mon, 14 Jan 2019 09:27:07 -0800 Message-ID: To: =?UTF-8?Q?Weronika_Ko=C5=82odziejak?= Cc: Donald Eastlake , babel-chairs , "draft-ietf-babel-dtls@ietf.org" , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-dtls-03 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 17:27:22 -0000 Lacking two workable interoperating implementations, and some deployment experience, I cannot support this draft. I think it is presently too vague and fuzzy to lead to working implementations. On Mon, Jan 14, 2019 at 9:13 AM Weronika Ko=C5=82odziejak wrote: > > Hello Donald, > > I support publication. > > Weronika > > W dniu =C5=9Broda, 9 stycznia 2019 Donald Eastlake nap= isa=C5=82(a): >> >> Hi, >> >> This message begins a Working Group Last Call on draft-ietf-babel-dtls >> running to January 21st. Please comment on whether or not you think >> the draft is ready for publication. >> >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 1424 Pro Shop Court, Davenport, FL 33896 USA >> d3e3e3@gmail.com >> >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Mon Jan 14 11:35:09 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39172131268 for ; Mon, 14 Jan 2019 11:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgxtKzCLUc1f for ; Mon, 14 Jan 2019 11:35:05 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD704131263 for ; Mon, 14 Jan 2019 11:35:05 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x0EJPgSN044152; Mon, 14 Jan 2019 14:35:04 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2q10j708aa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Jan 2019 14:35:04 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0EJZ2Bc017845; Mon, 14 Jan 2019 14:35:03 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0EJYuvg017637; Mon, 14 Jan 2019 14:34:56 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 7CABF4048C31; Mon, 14 Jan 2019 19:34:56 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30485.vci.att.com (Service) with ESMTPS id 660764048C25; Mon, 14 Jan 2019 19:34:56 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.203]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0415.000; Mon, 14 Jan 2019 14:34:56 -0500 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'David Schinazi'" , Babel at IETF Thread-Topic: [babel] babel-dtls: verifying "authentication" Thread-Index: AdSoVYQo0/ay4EhYQw+N2cLNVC6kSAAO/2EAAAFCPHAAgAlFgABc58dw Date: Mon, 14 Jan 2019 19:34:55 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF9C5D7@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF8A154@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF8A9A3@GAALPA1MSGUSRBF.ITServices.sbc.com> <875zuuw0yo.wl-jch@irif.fr> In-Reply-To: <875zuuw0yo.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.250.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-14_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901140150 Archived-At: Subject: Re: [babel] babel-dtls: verifying "authentication" X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 19:35:07 -0000 PiA+IDxiaHM+IFRMUyAxLjIgKFJGQyA1MjQ2KSBzYXlzIOKAnFRoZSBmb2xsb3dpbmcgcnVsZXMg YXBwbHkgdG8gdGhlDQo+ID4gY2VydGlmaWNhdGVzIHNlbnQgYnkgdGhlIHNlcnZlcjoNCj4gDQo+ ID4gICAgLSAgVGhlIGNlcnRpZmljYXRlIHR5cGUgTVVTVCBiZSBYLjUwOXYzLCB1bmxlc3MgZXhw bGljaXRseQ0KPiA+IG5lZ290aWF0ZWQgb3RoZXJ3aXNlIChlLmcuLCBbVExTUEdQXSku4oCdDQo+ IA0KPiBNeSByZWFkaW5nIGlzIHRoYXQgdGhpcyBkb2Vzbid0IHByZWNsdWRlIG5lZ290aWF0aW5n IGEgZGlmZmVyZW50IGNlcnRpZmljYXRlDQo+IHR5cGUgKGVpdGhlciBpbi1iYW5kIG9yIG91dC1v Zi1iYW5kLCBlLmcuIHRocm91Z2ggc3RhdGljDQo+IGNvbmZpZ3VyYXRpb24pIG9yIHVzaW5nIGEg UFNLIChzeW1tZXRyaWMga2V5KS4NCj4gDQo+IEkgYWdyZWUgd2l0aCBEYXZpZCB0aGF0IHRoaXMg aXMgb3V0IG9mIHNjb3BlIGZvciB0aGUgQmFiZWwtRFRMUyBkcmFmdC4NCg0KSSBhbHNvIGFncmVl IGl0J3Mgb3V0LW9mLXNjb3BlIHRvIHNheSBhbnl0aGluZyBhYm91dCB0aGlzIGluIHRoZSBiYWJl bC1kdGxzIGRyYWZ0LiBCdXQgaXQncyBub3Qgb3V0LW9mLXNjb3BlIGZvciBpbmZvcm1hdGlvbi1t b2RlbC4gSSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGUgaW5mbyBtb2RlbCBwcm92aWRlcyB0aGUgYWJp bGl0eSB0byBlYXNpbHkgbWFuaXB1bGF0ZSAoYWRkL2RlbGV0ZSkgdGhlIHR5cGVzIG9mIGNlcnRp ZmljYXRlcyB3ZSB0aGluayB3aWxsIGNvbW1vbmx5IGJlIHVzZWQuIExlYXZpbmcgdGhlIGluZm8t bW9kZWwgb3BlbiB0byBzdXBwb3J0aW5nIGFsbCBwb3NzaWJsZSBjZXJ0aWZpY2F0ZSB0eXBlcyBp c24ndCBzb21ldGhpbmcgSSdtIGluIGZhdm9yIG9mLiBJdCdzIGFsc28gdXNlZnVsIHRvIHVuZGVy c3RhbmQgd2hhdCBzb3J0IG9mIGNlcnRpZmljYXRlIG1pZ2h0IGJlIHVzZWQgd2hlbiB0cnlpbmcg dG8gZmlndXJlIG91dCB3aGF0IGl0IG1lYW5zIHRvICJhdXRoZW50aWNhdGUiIChvciAidmFsaWRh dGUiIG9yICJ2ZXJpZnkiKSBzdWNoIGEgY2VydGlmaWNhdGUuIA0KDQo+ID4gVmFsaWRhdGluZyBp ZGVudGl0eSBpcyBhIE1VU1QsIHRoZSBmYWN0IHRoYXQgdGhhdCBpZGVudGl0eSBtYXBzIHRvIGEN Cj4gPiBjZXJ0aWZpY2F0ZSBpcyBhIE1BWS4NCj4gDQo+ID4gPGJocz4gVmFsaWRhdGluZyB3aGF0 IGlkZW50aXR5Pw0KPiANCj4gRGF2aWQgc2hvdWxkIG5vdCBoYXZlIHNwb2tlbiBhYm91dCBpZGVu dGl0eSAtLSB3aGF0IHdlJ3JlIHNwZWFraW5nIGhlcmUgaXMNCj4gYXV0aGVudGljYXRpb24uDQo+ IA0KPiBUTFMgaGFzIGEgbm90aW9uIG9mIHNlcnZlciBhbmQgY2xpZW50IGF1dGhlbnRpY2F0aW9u LiAgU2VydmVyIGF1dGhlbnRpY2F0aW9uIGlzDQo+IGhhcmR3aXJlZCBpbnRvIHRoZSBwcm90b2Nv bCwgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIG9wdGlvbmFsLiAgV2hhdCB0aGUgZHJhZnQNCj4g c2F5cyBpcyB0aGF0IHRoZSBCYWJlbC1EVExTIHByb3RvY29sIHJlcXVpcmVzIGNsaWVudCBhdXRo ZW50aWNhdGlvbiBpbiBhZGRpdGlvbg0KPiB0byBzZXJ2ZXIgYXV0aGVudGljYXRpb24uDQo+IA0K PiA+IFlvdSBoYXZlbuKAmXQgc3BlY2lmaWVkIGFueSBpZGVudGl0eSB0byBtYXAgYW55dGhpbmcg dG8uIFlvdSBjYW7igJl0IG1ha2UNCj4gPiB2YWxpZGF0aW9uIGEgTVVTVCBpZiB5b3UgZ2l2ZSBu byBjbHVlIGFzIHRvIGhvdyBvciB3aGF0IHRvIHZhbGlkYXRlLg0KPiANCj4gSSdtIG5vdCBhIHNw ZWNpYWxpc3QsIGJ1dCB0aGlzIGxvb2tzIGxpa2UgaXQncyBjb25zaXN0ZW50IHdpdGggdGhlIG5h dHVyZSBvZiBUTFMuDQoNCk5vLiAoRClUTFMgZWNvc3lzdGVtcyBoYXZlIHRvIHNwZWNpZnkgd2hh dCAiYXV0aGVudGljYXRpb24iIG1lYW5zIHdpdGhpbiB0aGF0IGVjb3N5c3RlbS4gU2VydmVyIGF1 dGhlbnRpY2F0aW9uIGlzICpub3QqIGhhcmR3aXJlZCBpbnRvIHRoZSBUTFMgcHJvdG9jb2wuIE9u bHkgdGhlIGV4Y2hhbmdlIG9mIGNlcnRpZmljYXRlcywgYW5kIHRoZWlyIHVzZSBpbiBuZWdvdGlh dGluZyBhIHNoYXJlZCBzZWNyZXQgYW5kIGVzdGFibGlzaGluZyBlbmNyeXB0aW9uLCBpcyBzcGVj aWZpZWQgYnkgKEQpVExTLiBBcyBmYXIgYXMgKEQpVExTIGlzIGNvbmNlcm5lZCwgcmVjZWl2ZWQg Y2VydGlmaWNhdGVzIGNhbiBiZSBhdXRvbWF0aWNhbGx5IGFjY2VwdGVkIHdpdGhvdXQgcXVlc3Rp b24gKGkuZS4sIHdpdGhvdXQgYXV0aGVudGljYXRpb24pLCBhbmQgKEQpVExTIHdpbGwgd29yayBq dXN0IGZpbmUuIE11dHVhbGx5IGV4Y2hhbmdpbmcgY3JlZGVudGlhbHMgIT0gbXV0dWFsIGF1dGhl bnRpY2F0aW9uLiBTZW5kaW5nIGEgQ2VydGlmaWNhdGVSZXF1ZXN0IG1lc3NhZ2Ugc2ltcGx5IHJl cXVlc3RzIHRoZSBjbGllbnQgdG8gc2VuZCBhIGNlcnQuIEl0IGRvZXMgKm5vdCogInJlcXVlc3Qg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIi4gSXQgKmFsbG93cyogdGhlIHNlcnZlciB0byBwZXJmb3Jt IGNsaWVudCBhdXRoZW50aWNhdGlvbiBvbiB0aGUgY2VydCBzdWJzZXF1ZW50bHkgc2VudCBieSB0 aGUgY2xpZW50LiBIb3cgb3Igd2hldGhlciB0byBhdXRoZW50aWNhdGUgYSByZWNlaXZlZCBjZXJ0 aWZpY2F0ZSBpcyBzcGVjaWZpZWQgYnkgYXBwbGljYXRpb24gbGF5ZXIgcG9saWN5LiANCg0KUXVv dGUgZnJvbSB0aGUgVExTIFJGQzogDQoiLi4uIHRoZSBkZWNpc2lvbnMgb24gLi4uIGhvdyB0byBp bnRlcnByZXQgdGhlIGF1dGhlbnRpY2F0aW9uIGNlcnRpZmljYXRlcyBleGNoYW5nZWQgYXJlIGxl ZnQgdG8gdGhlIGp1ZGdtZW50IG9mIHRoZSBkZXNpZ25lcnMgYW5kIGltcGxlbWVudG9ycyBvZiBw cm90b2NvbHMgdGhhdCBydW4gb24gdG9wIG9mIFRMUy4iIA0KW05vdGUgYXV0aGVudGljYXRpb24g Y2VydGlmaWNhdGUgPSBhdXRoZW50aWNhdGlvbiBrZXkgPSBjZXJ0aWZpY2F0ZTsgYXV0aGVudGlj YXRpb24gY2VydGlmaWNhdGUgIT0gYXV0aGVudGljYXRpb24uXQ0KDQpFeGFtcGxlcyBvZiBlY29z eXN0ZW0tc3BlY2lmaWMgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnRzOg0KIC0gV2hlbiBUTFMg aXMgdXNlZCB3aXRoIEludGVybmV0IHNlcnZlcnMsIGF1dGhlbnRpY2F0aW9uIGNvbnNpc3RzIG9m IGNoZWNraW5nIHRoZSB2YWxpZGF0ZSwgY2hlY2tpbmcgdGhhdCBpdCdzIHNpZ25lZCBieSBhIENB IHdob3NlIGNlcnQgaXMgaW4gYW4gaW50ZXJuYWwgY2VydCBzdG9yZSBvZiB0cnVzdGVkIGNyZWRl bnRpYWxzLCBjaGVja2luZyB0aGF0IHNpdGUgZG9tYWluIG5hbWUgPSBzdWJqZWN0QWx0TmFtZSBm aWVsZCwgYW5kIG9wdGlvbmFsbHkgY2hlY2tpbmcgb3RoZXIgdGhpbmdzIGxpa2Ugd2hldGhlciB0 aGUgY2VydCBoYXMgYmVlbiByZXZva2VkLiBEaWZmZXJlbnQgd2ViIGJyb3dzZXJzIChhbmQgb3Ro ZXIgSFRUUCBhcHBsaWNhdGlvbnMpIGhhdmUgZGlmZmVyZW50IGNlcnQgc3RvcmVzIGZvciB3aGF0 IENBcyB0aGV5IHRydXN0IGFuZCBkaWZmZXJlbnQgc3BlY2lmaWMgYXV0aGVudGljYXRpb24gYWxn b3JpdGhtcy4gDQogLSBDaGVja2luZyB0aGF0IHByb3ZpZGVkIGNyZWRlbnRpYWxzIGFyZSBpbiBh biBpbnRlcm5hbCBzdG9yZSBvZiB0cnVzdGVkIGNyZWRlbnRpYWxzIA0KIC0gQ2hlY2tpbmcgdGhh dCBwcm92aWRlZCBjcmVkZW50aWFscyBhcmUgaW4gYW4gaW50ZXJuYWwgc3RvcmUgb2YgdHJ1c3Rl ZCBjcmVkZW50aWFscyBhbmQgYWx3YXlzIHNlbnQgZnJvbSBhIHBhcnRpY3VsYXIgSVAgYWRkcmVz cw0KIC0gQ2hlY2tpbmcgdGhhdCBwcm92aWRlZCBjZXJ0aWZpY2F0ZSBpcyBpbiBhbiBpbnRlcm5h bCBjZXJ0IHN0b3JlIGFuZCBzdWJqZWN0QWx0TmFtZSBtYXRjaGVzIGFuIGlkZW50aXR5IGluY2x1 ZGVkIGluIHRoZSBhcHBsaWNhdGlvbi1sYXllciBwcm90b2NvbC4NCg0KSGVyZSBhcmUgc29tZSBw b3NzaWJsZSBhdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudHMgdGhhdCBtaWdodCBiZSByZWFzb25h YmxlIGZvciBiYWJlbC1kdGxzLiBJJ20gc3Ryb25nbHkgaW4gZmF2b3Igb2YgdGhlIGZpcnN0IG9m IHRoZXNlLiBJIGFsc28gdGhpbmsgdGhlIENBIHJlcXVpcmVtZW50IGlzIGEgZ29vZCBpZGVhLiBU aGUgb3RoZXJzIEknbSBwcmVzZW50aW5nIHRvIHByb3ZpZGUgYW4gaWRlYSBvZiB3aGF0IGVsc2Ug d2UgbWlnaHQgc2F5LCBidXQgSSBkbyB0aGluayBpdCdzIGdvb2QgdG8gcHJvdmlkZSBhdCBsZWFz dCBvbmUgKG9wdGlvbmFsKSBtZXRob2QgZm9yIGFzc29jaWF0aW5nIGNyZWRlbnRpYWxzIHdpdGgg YSBzcGVjaWZpYyByb3V0ZXItaWQgb3IgSVAgYWRkcmVzcy4NCk1VU1QgYXV0aGVudGljYXRlIHJl Y2VpdmVkIGNyZWRlbnRpYWxzIGFnYWluc3QgYW4gaW50ZXJuYWwgc3RvcmUgb2YgY3JlZGVudGlh bHMuDQpTSE9VTEQgYXNzb2NpYXRlIHJvdXRlci1pZCB3aXRoIGNyZWRlbnRpYWxzIGFuZCBlbnN1 cmUgY3JlZGVudGlhbHMgYXJlIG9ubHkgdXNlZCBmb3IgdGhhdCByb3V0ZXIgKHRoaXMgd291bGQg cmVxdWlyZSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBmb3IgaG93IHRvIGV4cHJlc3Mgcm91dGVy LWlkIGluIGNlcnRhaW4gdHlwZXMgb2YgY3JlZGVudGlhbHMgLS0gbGlrZSBYLjUwOSBzdWJqZWN0 QWx0TmFtZSkuDQpNQVkgZW5zdXJlIHNhbWUgSVAgYWRkcmVzcyBpcyB1c2VkIHRvIHNlbmQgYSBw YXJ0aWN1bGFyIGNlcnQsIGFmdGVyIGZpcnN0IHVzZSBvZiBjZXJ0DQpNQVkgc3VwcG9ydCB2YWxp ZGF0aW9uIGJ5IGNlcnRpZmljYXRlIGF1dGhvcml0eSAoQ0EpIGNyZWRlbnRpYWxzIChyZXF1aXJl cyBhbiBpbnRlcm5hbCBzdG9yZSBvZiBDQSBjcmVkZW50aWFscykgdXNlZCB0byBzaWduIHJlY2Vp dmVkIGNyZWRlbnRpYWxzLg0KTUFZIHN1cHBvcnQgdHJ1c3Qtb24tZmlyc3QtdXNlIGZvciBmaXJz dCB0aW1lIGFuIElQIGFkZHJlc3MgaXMgc2Vlbg0KDQpCYXJiYXJhDQoNCg0K From nobody Mon Jan 14 13:39:33 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1320B13102C for ; Mon, 14 Jan 2019 13:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Oa3mP1s8wfU for ; Mon, 14 Jan 2019 13:39:30 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D48131008 for ; Mon, 14 Jan 2019 13:39:29 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0ELdI6A023385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Jan 2019 22:39:19 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x0ELdJhK008575; Mon, 14 Jan 2019 22:39:19 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5E64B9A29C; Mon, 14 Jan 2019 22:39:23 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id JFTdKLso-Tsn; Mon, 14 Jan 2019 22:39:21 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3CA2F9A298; Mon, 14 Jan 2019 22:39:19 +0100 (CET) Date: Mon, 14 Jan 2019 22:39:19 +0100 Message-ID: <87imyqgbqw.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'David Schinazi'" , Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF9C5D7@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF8A154@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF8A9A3@GAALPA1MSGUSRBF.ITServices.sbc.com> <875zuuw0yo.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9C5D7@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Mon, 14 Jan 2019 22:39:19 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 14 Jan 2019 22:39:19 +0100 (CET) X-Miltered: at korolev with ID 5C3D0186.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5C3D0187.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C3D0186.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5C3D0187.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C3D0186.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5C3D0187.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] babel-dtls: verifying "authentication" X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 21:39:32 -0000 > No. (D)TLS ecosystems have to specify what "authentication" means within > that ecosystem. [...] > As far as (D)TLS is concerned, received certificates can be > automatically accepted without question (i.e., without authentication), > and (D)TLS will work just fine. Right. Thanks for the explanation. From nobody Mon Jan 14 14:04:01 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CF11313A4 for ; Mon, 14 Jan 2019 14:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nd-t_P5LRgO3 for ; Mon, 14 Jan 2019 14:03:57 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A511313AC for ; Mon, 14 Jan 2019 14:03:57 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id y4so234374pgc.12 for ; Mon, 14 Jan 2019 14:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jmi+UG7A6XL9XMoH/bvo10jH4W3UN1m/eaNsd1FYiZ4=; b=ePnRlPJ4t0tQtzDYve+zIW7O/M0gB0lr9lDKt859cXEkwlIKNIBuSckaZn1PWGXOIL sC8fyfY/fTE+CNlMVKdo7TD70WV2RzkTbd7ZG2Gob7/Jy288u8gttFM569YtPZ4Kec1w d+IOsNNZP8bEhn7Z1BFPCnpEYjmz+KJKlFhWAnGOALmbsLa/GWcfJ4SDxv8pdcmYlpcE wI0HfZ7nhRa63Vxl2KWAGLlqZdKm4V6NcmndTzlCw+gnLuNXBccTz/6roN3eZ32Y6r8b f8fWFl/ZtNBYCkqyxNcdCGTHlchl7ieUBIPa7U2SG4gOqrDdXwimaCwNEHcVziU+fVeb ZxBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jmi+UG7A6XL9XMoH/bvo10jH4W3UN1m/eaNsd1FYiZ4=; b=m9/Y0UFxNbsKN7/S3H/r6DlQCjtgWJuo7pZIBO9PbVc1jw188Fg1ULCTsg5owz56sP CppLn+GkbRarJADfDYDT5UdI1lgSFGC4gJ9TvC+w4MVeJ8iW4Zmva65lPIm32K8HhtBn Ted7Hb/eCNB9CrIPY8SCA/9nOG7HlbKL6BtMN9gjDQrG5K0apDCv3aDEVlWuqO/3y5jJ gkE66Six6A7pnBWeLUW2RrPyvzOjVXwuFjBJnL8FLPUJiS3RVqmVTqQ0HgZ9Lu5/S+qM 1+ligXHpnFRbGiJOorkCaYxAC+PQBUR3ppjViJVWE9YNzZhM5FgqGuaW59lmeJs6sSkN cjjQ== X-Gm-Message-State: AJcUukemUMxHSGT9yu+c9DZ2E61/obdGZMz6lHjmSXNVV+zBAMy0RaX0 tAgXCeDhsMR8cacA2W4KcDaSsG0Ecq4sB2JPm7s= X-Google-Smtp-Source: ALg8bN6SNhIeKZrHs3ePSnWZeBuh8G55os/RaqIQ4UmyC8CFHz8a2DU1Q+XEX24DDj37sP71INcumHTYXoNKhoGFhxQ= X-Received: by 2002:a63:7e1a:: with SMTP id z26mr639262pgc.216.1547503437241; Mon, 14 Jan 2019 14:03:57 -0800 (PST) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DF8A154@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF8A9A3@GAALPA1MSGUSRBF.ITServices.sbc.com> <875zuuw0yo.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9C5D7@GAALPA1MSGUSRBF.ITServices.sbc.com> <87imyqgbqw.wl-jch@irif.fr> In-Reply-To: <87imyqgbqw.wl-jch@irif.fr> From: David Schinazi Date: Mon, 14 Jan 2019 14:03:46 -0800 Message-ID: To: Juliusz Chroboczek Cc: "STARK, BARBARA H" , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000aa645a057f7238a1" Archived-At: Subject: Re: [babel] babel-dtls: verifying "authentication" X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 22:04:00 -0000 --000000000000aa645a057f7238a1 Content-Type: text/plain; charset="UTF-8" Hi Barbara, I think we might be interpreting the TLS document differently from one another, but I'm sure we'll find agreement on what to change in Babel-DTLS. Regarding the type of credentials, I'm fine with the information model restricting configuration to X509 certificates, but I do not think that should belong in Babel-DTLS as there might be non-certificate based use-cases for Babel-DTLS. Responding inline to your text proposals: On Mon, Jan 14, 2019 at 11:35 AM STARK, BARBARA H wrote: > Here are some possible authentication requirements that might be > reasonable for babel-dtls. I'm strongly in favor of the first of these. I > also think the CA requirement is a good idea. The others I'm presenting to > provide an idea of what else we might say, but I do think it's good to > provide at least one (optional) method for associating credentials with a > specific router-id or IP address. > Requiring a CA would break the homenet use-case for example. In my opinion, if I buy a bunch of homenet routers I should be able to setup my network even if I don't currently have Internet access to get a CA to sign my certificates. > MUST authenticate received credentials against an internal store of > credentials. > I'm not sure how this differs from the current text "Nodes MUST use mutual authentication" - authenticating a peer implies it is done against a store of credentials, but perhaps adding a line of clarification is worthwhile. > SHOULD associate router-id with credentials and ensure credentials are > only used for that router (this would require additional requirements for > how to express router-id in certain types of credentials -- like X.509 > subjectAltName). > I don't think we should necessarily bind ourselves to the router-ID, as that could inhibit future innovation - I could run a router that uses two router IDs to do . Having a way to tie router-IDs to X509 certificates makes sense to me, but I see that as a separate document (similar to how subjectAltName is not defined or mentioned in the TLS spec). > MAY ensure same IP address is used to send a particular cert, after first > use of cert > There are devices out there rotating MAC addresses and IP addresses periodically to improve user privacy, I don't want Babel-DTLS to get in the way of that. > MAY support validation by certificate authority (CA) credentials (requires > an internal store of CA credentials) used to sign received credentials. > MAY support trust-on-first-use for first time an IP address is seen > I'm not sure how these MAYs improve the document. These mechanisms will be defined by the profiles that use Babel-DTLS. If you feel strongly about this we could add an appendix providing options for what credentials would make sense, but I would remove the normative language. All this said, it might be simplest to have a phone call / video chat of some kind to discuss this in real time. Thanks, David On Mon, Jan 14, 2019 at 1:39 PM Juliusz Chroboczek wrote: > > No. (D)TLS ecosystems have to specify what "authentication" means within > > that ecosystem. > > [...] > > > As far as (D)TLS is concerned, received certificates can be > > automatically accepted without question (i.e., without authentication), > > and (D)TLS will work just fine. > > Right. Thanks for the explanation. > --000000000000aa645a057f7238a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi= Barbara,

I think we might be interpreting the TLS= document differently from one another, but I'm sure we'll find agr= eement on what to change in Babel-DTLS.

Regarding = the type of credentials, I'm fine with the information model restrictin= g configuration to X509 certificates, but I do not think that should belong= in Babel-DTLS as there might be non-certificate based use-cases for Babel-= DTLS.

Responding inline to your text proposals:

On Mon, Jan 14, 2019 at 11:3= 5 AM STARK, BARBARA H <bs7652@att.com<= /a>> wrote:
Here = are some possible authentication requirements that might be reasonable for = babel-dtls. I'm strongly in favor of the first of these. I also think t= he CA requirement is a good idea. The others I'm presenting to provide = an idea of what else we might say, but I do think it's good to provide = at least one (optional) method for associating credentials with a specific = router-id or IP address.

Requiring a CA= would break the homenet use-case for example. In my opinion, if I buy a bu= nch of homenet routers I should be able to setup my network even if I don&#= 39;t currently have Internet access to get a CA to sign my certificates.
=C2=A0
MUST = authenticate received credentials against an internal store of credentials.=

I'm not sure how this differs from= the current text "Nodes MUST use mutual authentication" - authen= ticating a peer implies it is done against a store of credentials, but perh= aps adding a line of clarification is worthwhile.
=C2=A0
SHOULD associate router-id w= ith credentials and ensure credentials are only used for that router (this = would require additional requirements for how to express router-id in certa= in types of credentials -- like X.509 subjectAltName).

I don't think we should necessarily bind ourselves to t= he router-ID, as that could inhibit future innovation - I could run a route= r that uses two router IDs to do <insert magic new feature here>.
Having a way to tie router-IDs to X509 certificates makes sense to m= e, but I see that as a separate document (similar to how subjectAltName is = not defined or mentioned in the TLS spec).
=C2=A0
MAY ensure same IP address is used = to send a particular cert, after first use of cert
There are devices out there rotating MAC addresses and IP addre= sses periodically to improve user privacy, I don't want Babel-DTLS to g= et in the way of that.
=C2=A0
MAY support validation by certificate authority (CA) cr= edentials (requires an internal store of CA credentials) used to sign recei= ved credentials.
MAY support trust-on-first-use for first time an IP add= ress is seen

I'm not sure how these= MAYs improve the document. These mechanisms will be defined by the profile= s that use Babel-DTLS. If you feel strongly about this we could add an appe= ndix providing options for what credentials would make sense, but I would r= emove the normative language.

All this said, it mi= ght be simplest to have a phone call / video chat of some kind to discuss t= his in real time.

Thanks,
David


> No. (D)TLS ecosystems have to specify what "authenti= cation" means within
> that ecosystem.

[...]

> As far as (D)TLS is concerned, received certificates can be
> automatically accepted without question (i.e., without authentication)= ,
> and (D)TLS will work just fine.

Right.=C2=A0 Thanks for the explanation.
--000000000000aa645a057f7238a1-- From nobody Mon Jan 14 14:24:47 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65861313EB for ; Mon, 14 Jan 2019 14:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMPv_T7hSq_P for ; Mon, 14 Jan 2019 14:24:44 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E5A1313EA for ; Mon, 14 Jan 2019 14:24:43 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0EMOXPA009410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Jan 2019 23:24:33 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x0EMOZ0C023745; Mon, 14 Jan 2019 23:24:35 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D38AE9A6C6; Mon, 14 Jan 2019 23:24:38 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id EoL1kLrspM53; Mon, 14 Jan 2019 23:24:36 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8FD0F9A6C3; Mon, 14 Jan 2019 23:24:36 +0100 (CET) Date: Mon, 14 Jan 2019 23:24:36 +0100 Message-ID: <87bm4ig9nf.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'David Schinazi'" , Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF9C5D7@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF8A154@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF8A9A3@GAALPA1MSGUSRBF.ITServices.sbc.com> <875zuuw0yo.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9C5D7@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Mon, 14 Jan 2019 23:24:33 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 14 Jan 2019 23:24:35 +0100 (CET) X-Miltered: at korolev with ID 5C3D0C21.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5C3D0C23.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C3D0C21.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5C3D0C23.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C3D0C21.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5C3D0C23.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] babel-dtls: verifying "authentication" X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 22:24:46 -0000 > MUST authenticate received credentials against an internal store of > credentials. Sounds good to me. Say that a router is configured with a number of credentials, and that what authentication means depends on the exact kind of the credential. Give three examples -- public key, CA, pre-shared symmetric key. Be very clear that this list is not exhaustive, and implementations MAY use other strategies. > SHOULD associate router-id with credentials No, that's too restrictive. While 6126bis associates a router-id with a router, router-ids are only carried by routes, so a router that doesn't redistribute any routes does not need to carry a router-id. Furthermore, router-ids need not be persistent -- a router can pick a new router-id whenever it reboots. > MAY ensure same IP address is used to send a particular cert, after > first use of cert That won't work -- Babel supports having multiple interfaces on the same link (and that actually happens quite often in radio networks, either due to misconfiguration or for increased reliability). IPs identify interfaces, not routers. > MAY support validation by certificate authority (CA) credentials > (requires an internal store of CA credentials) used to sign received > credentials. Yep. That's the second example in my list above. > MAY support trust-on-first-use for first time an IP address is seen That would work -- as long as we allow the same cert to be originated by multiple IPs. -- Juliusz From nobody Tue Jan 15 10:12:52 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE239130F0D for ; Tue, 15 Jan 2019 10:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4GsVRxvxz8i for ; Tue, 15 Jan 2019 10:12:35 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B538130F11 for ; Tue, 15 Jan 2019 10:12:35 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id y1so1643989plp.9 for ; Tue, 15 Jan 2019 10:12:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c6VND/lCyLTCUI9eqcchudICFhXr517HegKXVrSHnIM=; b=PbmyQVJq83cs/odJF6k2Cj1nlAnIyWiXbS9Nj0ps25D/UtteMQa8CQcTlAcac2diSO xWvXPKLcxDiRcDfD0bUiy9dgecMwYGlptaSdwdEGcM698D78Y/7ekZZ4NBnIoO4GRwCD wtzO0HI2eadLt4xVOVLr8Ct/lHtslrVfpVWi+0gnfU6idguqvjw7mHoiJOVvM1JOagiP dtHckNC7A6aa/U2GmWCLEveHLPO0o+jxdv5pZf4cBEV2IOOBSsaDWLBWTpIz0q/+6+vs W8ivTubgbuXMOwovAXj0q4KrsL6x813Cbwgzg8SG/Jtwyo8Oyrt1WvpUWq3wC+rh+E8q RgVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c6VND/lCyLTCUI9eqcchudICFhXr517HegKXVrSHnIM=; b=mv+Q1UVoOtx4KpV+QcR64X9r3NnO+ylIj363eLv5ckc64hq3aZ7xWKKr+7usKVqWUK pTP8Y0+njN3AwA9iU+fuMlEu090rx3xYjHxse+5KChenX8fSO2t00BzBFiqpJFjWuoJU 4P6dXG0rWwldz7Q0v5Ysh6x+LbB80nhegm3C0UGMpVw+1OMlEM8V3L6unTNZ8B2dFuin EaY2YxXf0viFw5RaGPQFlTNO4Vzs6nIoLQ9qTj7dnckAeZEIUJIdXow0fv7oZ2motmaZ 7iEnyFPacrAcphjpas0jVm5J6/HbwjNKf1tsqOESlx23ISA6yQW5rffuA4yE6Vv+uVAP 9/aw== X-Gm-Message-State: AJcUukfW1g2qsBiAjUSdICLNHyddQmv0fskgBwjxQk2bv88WKt9gi0Ks H0lWixTTqJRYaH70GNdP4AK4SImGzwjnZohqutw= X-Google-Smtp-Source: ALg8bN6Qg9dO9Fgl8HGYhoqVFnCUwrtj3PmpOrUbcruJDoaotBC2C+npdtSOooIGL36AKlkQ2EAyaqrKkMOgK4zNmRc= X-Received: by 2002:a17:902:aa0a:: with SMTP id be10mr5329120plb.266.1547575954625; Tue, 15 Jan 2019 10:12:34 -0800 (PST) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DF8A154@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF8A9A3@GAALPA1MSGUSRBF.ITServices.sbc.com> <875zuuw0yo.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9C5D7@GAALPA1MSGUSRBF.ITServices.sbc.com> <87bm4ig9nf.wl-jch@irif.fr> In-Reply-To: <87bm4ig9nf.wl-jch@irif.fr> From: David Schinazi Date: Tue, 15 Jan 2019 10:12:23 -0800 Message-ID: To: Juliusz Chroboczek Cc: "STARK, BARBARA H" , Babel at IETF Content-Type: multipart/alternative; boundary="00000000000009da12057f831bf9" Archived-At: Subject: Re: [babel] babel-dtls: verifying "authentication" X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 18:12:49 -0000 --00000000000009da12057f831bf9 Content-Type: text/plain; charset="UTF-8" I just had a quick phone call with Barbara and we clarified our differences in terminology. I have slightly tweaked the authentication text to hopefully address these: https://github.com/jech/babel-drafts/commit/0d1fbc98e5a8a0b86e6cbe6d6757c1fbe7d6fc2d Barbara, thanks for taking the time, and please let us know if you like the new text. Thanks! David On Mon, Jan 14, 2019 at 2:24 PM Juliusz Chroboczek wrote: > > MUST authenticate received credentials against an internal store of > > credentials. > > Sounds good to me. Say that a router is configured with a number of > credentials, and that what authentication means depends on the exact kind > of the credential. Give three examples -- public key, CA, pre-shared > symmetric key. Be very clear that this list is not exhaustive, and > implementations MAY use other strategies. > > > SHOULD associate router-id with credentials > > No, that's too restrictive. While 6126bis associates a router-id with > a router, router-ids are only carried by routes, so a router that doesn't > redistribute any routes does not need to carry a router-id. Furthermore, > router-ids need not be persistent -- a router can pick a new router-id > whenever it reboots. > > > MAY ensure same IP address is used to send a particular cert, after > > first use of cert > > That won't work -- Babel supports having multiple interfaces on the same > link (and that actually happens quite often in radio networks, either due > to misconfiguration or for increased reliability). IPs identify > interfaces, not routers. > > > MAY support validation by certificate authority (CA) credentials > > (requires an internal store of CA credentials) used to sign received > > credentials. > > Yep. That's the second example in my list above. > > > MAY support trust-on-first-use for first time an IP address is seen > > That would work -- as long as we allow the same cert to be originated by > multiple IPs. > > -- Juliusz > --00000000000009da12057f831bf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just had a quick phone call with Barbar= a and we clarified our differences in terminology.
I have slightly twea= ked the authentication text to hopefully address these:

Barbara, thanks f= or taking the time, and please let us know if you like the new text.
<= div>
Thanks!
David

On Mon, Jan 14, 2019 at 2:24 PM Juliusz C= hroboczek <jch@irif.fr> wrote:
=
> MUST authentic= ate received credentials against an internal store of
> credentials.

Sounds good to me.=C2=A0 Say that a router is configured with a number of credentials, and that what authentication means depends on the exact kind of the credential.=C2=A0 Give three examples -- public key, CA, pre-shared<= br> symmetric key.=C2=A0 Be very clear that this list is not exhaustive, and implementations MAY use other strategies.

> SHOULD associate router-id with credentials

No, that's too restrictive.=C2=A0 While 6126bis associates a router-id = with
a router, router-ids are only carried by routes, so a router that doesn'= ;t
redistribute any routes does not need to carry a router-id.=C2=A0 Furthermo= re,
router-ids need not be persistent -- a router can pick a new router-id
whenever it reboots.

> MAY ensure same IP address is used to send a particular cert, after > first use of cert

That won't work -- Babel supports having multiple interfaces on the sam= e
link (and that actually happens quite often in radio networks, either due to misconfiguration or for increased reliability).=C2=A0 IPs identify
interfaces, not routers.

> MAY support validation by certificate authority (CA) credentials
> (requires an internal store of CA credentials) used to sign received > credentials.

Yep.=C2=A0 That's the second example in my list above.

> MAY support trust-on-first-use for first time an IP address is seen
That would work -- as long as we allow the same cert to be originated by multiple IPs.

-- Juliusz
--00000000000009da12057f831bf9-- From nobody Tue Jan 15 11:44:39 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93587130F12 for ; Tue, 15 Jan 2019 11:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ICP7jTRjkgx for ; Tue, 15 Jan 2019 11:44:35 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467B612872C for ; Tue, 15 Jan 2019 11:44:35 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0FJiNM3024240; Tue, 15 Jan 2019 20:44:25 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E697E27E82; Tue, 15 Jan 2019 20:44:28 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id fsiDQoRYQm9b; Tue, 15 Jan 2019 20:44:27 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C3A2D27E7C; Tue, 15 Jan 2019 20:44:24 +0100 (CET) Date: Tue, 15 Jan 2019 20:44:24 +0100 Message-ID: <87o98hbt9j.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF9BFAF@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> <874laevyy4.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9BFAF@GAALPA1MSGUSRBF.ITServices.sbc.com> otUser-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 15 Jan 2019 20:44:25 +0100 (CET) X-Miltered: at korolev with ID 5C3E3817.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C3E3817.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C3E3817.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 19:44:38 -0000 > The provided HMAC Key MUST NOT be modified in any way prior to use with > the hash algorithm. Which draft are we speaking about? The management draft or the HMAC draft? -- Juliusz From nobody Tue Jan 15 13:17:50 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79AA9130F13 for ; Tue, 15 Jan 2019 13:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGCncuvysPRy for ; Tue, 15 Jan 2019 13:17:47 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF97129AA0 for ; Tue, 15 Jan 2019 13:17:47 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x0FLH4H0033950; Tue, 15 Jan 2019 16:17:46 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2q1pqnj27r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Jan 2019 16:17:45 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0FLHi9w024640; Tue, 15 Jan 2019 16:17:44 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0FLHbum024416; Tue, 15 Jan 2019 16:17:37 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 6FC2C4048C37; Tue, 15 Jan 2019 21:17:37 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30488.vci.att.com (Service) with ESMTPS id 5DE43405C9AB; Tue, 15 Jan 2019 21:17:37 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.203]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0415.000; Tue, 15 Jan 2019 16:17:36 -0500 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: Babel at IETF Thread-Topic: [babel] babel-hmac: key requirements Thread-Index: AdSpKuuhWh3uIPf3TSyfFq2fmw6nrABcdjuAAFt168AASoEFAAAIqZ0A Date: Tue, 15 Jan 2019 21:17:36 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF9E3B4@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> <874laevyy4.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9BFAF@GAALPA1MSGUSRBF.ITServices.sbc.com> <87o98hbt9j.wl-jch@irif.fr> In-Reply-To: <87o98hbt9j.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.215.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-15_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901150169 Archived-At: Subject: Re: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 21:17:49 -0000 > > The provided HMAC Key MUST NOT be modified in any way prior to use > > with the hash algorithm. >=20 > Which draft are we speaking about? The management draft or the HMAC > draft? The HMAC draft.=20 >From your comments, it seems that the "HMAC Key" referenced throughout babe= l-hmac is the exact set of bits used to compute the HMAC. If this is true, = then this is an important fact that is not currently obvious from reading t= he draft. So the HMAC Key that is an input to an implementation of this spe= c must not be modified by the implementation prior to use. An implementation of babel-hmac that hashes a provided HMAC Key value longe= r than the length of the hash must be considered in violation of the babel-= hmac spec. Any user interface that accepts input of ASCII characters to gen= erate an HMAC Key must be separate from the babel-hmac implementation. The = existence of OSPF key "preparation" rules and the base HMAC RFC rules key p= reparation rules means the babel-hmac text needs to unambiguously state tha= t such preparation is *not* done to an "HMAC Key" prior to its use in babel= -hmac. This will impose a requirement on the info-model to treat the HMAC Key as a= binary field (like the router-id). BTW, I'm fine with the text you proposed for the security section. But it d= oesn't solve the problem of ensuring there is no ambiguity regarding non-"p= reparation" of the key. Barbara From nobody Tue Jan 15 13:36:06 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73521130F18 for ; Tue, 15 Jan 2019 13:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mogZ0wK3laCF for ; Tue, 15 Jan 2019 13:36:02 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2a00:7660:6da:2001::664]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C62130F13 for ; Tue, 15 Jan 2019 13:36:01 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1547588157; bh=4VvHZ0UL9oWz9RKwtF/YEQj8Sl+LSVZQ/kjprTJWIf8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mm3lpaTth7ExM1iMrBPuxwcg4rzelCK1hkRwu2OiJeb8GucmGLl0dxva8YHgJkX5c AzfzGteYr7RV1KMOq5xJYnglJbXbZB37zDoRmgOM/txZ0EdR8vjO/R4pJydZIQ/GfC 3HFgsxP+Ldi7IapjjzNrX8gBWehdkmtV05m6kxbp+jkn7/lTKF1wAYmkTp33X3OTp6 3XrNDGFp66yItcfjCPsIpu0G9a6fFpFrxOUAfWOeEoFq2hgyFTlqjm5AHOEsuedkJY AbGhiMN4x4sG8UTrt+NHe4woIFWsTkUUkDdaH26F5WrMjPcchpD5ItwNO1p5jbH+PW OIXjICx3oz9Aw== To: "STARK\, BARBARA H" , 'Juliusz Chroboczek' Cc: Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF9E3B4@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> <874laevyy4.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9BFAF@GAALPA1MSGUSRBF.ITServices.sbc.com> <87o98hbt9j.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9E3B4@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Tue, 15 Jan 2019 22:35:53 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k1j5ob7q.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 21:36:05 -0000 "STARK, BARBARA H" writes: >> > The provided HMAC Key MUST NOT be modified in any way prior to use >> > with the hash algorithm. >> >> Which draft are we speaking about? The management draft or the HMAC >> draft? > > The HMAC draft. > >>From your comments, it seems that the "HMAC Key" referenced throughout >>babel-hmac is the exact set of bits used to compute the HMAC. If this >>is true, then this is an important fact that is not currently obvious >>from reading the draft. So the HMAC Key that is an input to an >>implementation of this spec must not be modified by the implementation >>prior to use. > > An implementation of babel-hmac that hashes a provided HMAC Key value > longer than the length of the hash must be considered in violation of > the babel-hmac spec. So this means you want to specify that a key MUST be exactly (or at most?) $blocksize bytes long? > Any user interface that accepts input of ASCII characters to generate > an HMAC Key must be separate from the babel-hmac implementation. How do you define "separate from"? -Toke From nobody Tue Jan 15 14:02:33 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B87F130F13 for ; Tue, 15 Jan 2019 14:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_SUBJECT=1.799, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAouMdWprDZ3 for ; Tue, 15 Jan 2019 14:02:30 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B1C130F1F for ; Tue, 15 Jan 2019 14:02:29 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0FM2Jxd011558; Tue, 15 Jan 2019 23:02:20 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 813AD2965D; Tue, 15 Jan 2019 23:02:25 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id r4zaxHFGDjhZ; Tue, 15 Jan 2019 23:02:24 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 032502965A; Tue, 15 Jan 2019 23:02:24 +0100 (CET) Date: Tue, 15 Jan 2019 23:02:23 +0100 Message-ID: <87lg3lbmvk.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: Babel at IETF nSubject: Re: [babel] babel-hmac: key requirements In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF9E3B4@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> <874laevyy4.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9BFAF@GAALPA1MSGUSRBF.ITServices.sbc.com> <87o98hbt9j.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9E3B4@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 15 Jan 2019 23:02:20 +0100 (CET) X-Miltered: at korolev with ID 5C3E586B.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C3E586B.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C3E586B.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] (no subject) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 22:02:31 -0000 >>> The provided HMAC Key MUST NOT be modified in any way prior to use >>> with the hash algorithm. >> Which draft are we speaking about? The management draft or the HMAC draft? > The HMAC draft. Please consider me utterly confused. The HMAC draft was carefully written to be agnostic about key distribution policies. It assumes that one or more HMAC keys are associated to each interface (Section 3.1), and takes no stand about how these keys got into the interface data strcture. For example, a key might come from a config file, it might come from a configuration protocol, or it might be the result of a Diffie-Hellman key exchange. Babel-HMAC doesn't care, it just consults the interface data structure and grabs the keys that are there. So what do you mean by "provided" in the sentence you suggest? Who's the mysterious entity doing the providing, and who is she providing the keys to? (The point I'm making is that you obviously have a particular management interface in mind -- probably a config file, or perhaps some kind of XML over HTTP thing --, and that management interfaces are out of scope for this draft.) -- Juliusz From nobody Tue Jan 15 14:27:24 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512FD127598 for ; Tue, 15 Jan 2019 14:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyImQUt5Ns0w for ; Tue, 15 Jan 2019 14:27:21 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5D7128B01 for ; Tue, 15 Jan 2019 14:27:21 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0FMQavS019511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Jan 2019 23:26:37 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x0FMQcW7004533; Tue, 15 Jan 2019 23:26:38 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id BF68B29986; Tue, 15 Jan 2019 23:26:41 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id t5r0cs3bCSDD; Tue, 15 Jan 2019 23:26:40 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2454629981; Tue, 15 Jan 2019 23:26:40 +0100 (CET) Date: Tue, 15 Jan 2019 23:26:40 +0100 Message-ID: <87k1j5blr3.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: "STARK, BARBARA H" , Babel at IETF In-Reply-To: <87k1j5ob7q.fsf@toke.dk> References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> <874laevyy4.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9BFAF@GAALPA1MSGUSRBF.ITServices.sbc.com> <87o98hbt9j.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9E3B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <87k1j5ob7q.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 15 Jan 2019 23:26:37 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 15 Jan 2019 23:26:38 +0100 (CET) X-Miltered: at korolev with ID 5C3E5E1C.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5C3E5E1E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C3E5E1C.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5C3E5E1E.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C3E5E1C.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5C3E5E1E.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 22:27:23 -0000 Let's be pedantic here -- let's distinguish the objects we manipulate from the concrete syntax that we use in our config files. > So this means you want to specify that a key MUST be exactly (or at > most?) $blocksize bytes long? An HMAC key is a string of bytes the length of which is exactly the block size. (RFC 2104 confuses matters by distinguishing the "key" and the "actual key". Please ignore this nonsense.) The actual concrete representation that you put in your config file is a sequence of characters (which happens to be serialised as a sequence of bytes using some character encoding, but that's irrelevant). How this sequence of characters is parsed into a sequence of bytes is outside the scope of the Babel-HMAC draft. Babeld requires a hex string in the config file, which to me is the obviously right thing to do, but makes Dave angry. Bird does something different, which I happen to believe is silly. >> Any user interface that accepts input of ASCII characters to generate >> an HMAC Key must be separate from the babel-hmac implementation. > How do you define "separate from"? The algorithm defined in the Babel-HMAC draft assumes that at any time your interface data structure contains one or more HMAC keys (Section 3.1). Describing how these bytes got into the interface structure is not the job of the Babel-HMAC draft, it's the job of the management draft, and of the documentation of your config file format. (Although, the be fair, we could add an informative appendix that explains that hex is the right thing to do, that no post-processing should happen, and that if you do anything else you need your head examined.) (The other day, I was implementing in Go an undocumented protocol that has only been implemented in Javascript before. They take an SHA-1 hash, interpret it as a sequence of twenty 8-bit Unicode codepoints, and then encode the result in UTF-16. I simply cannot conceive the kind of intellectual sloppiness that yielded this brain-damage.) -- Juliusz, feeling grumpy From nobody Tue Jan 15 16:12:26 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729D612D4F2 for ; Tue, 15 Jan 2019 16:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6P_tQZAYbiLj for ; Tue, 15 Jan 2019 16:12:22 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5CF126C01 for ; Tue, 15 Jan 2019 16:12:21 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0G0CE25019894 for ; Wed, 16 Jan 2019 01:12:14 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3B2742A7CC for ; Wed, 16 Jan 2019 01:12:20 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id YSQgUEDLRHNN for ; Wed, 16 Jan 2019 01:12:18 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 087722A7CA for ; Wed, 16 Jan 2019 01:12:16 +0100 (CET) Date: Wed, 16 Jan 2019 01:12:16 +0100 Message-ID: <87h8e9bgv3.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 16 Jan 2019 01:12:14 +0100 (CET) X-Miltered: at korolev with ID 5C3E76DE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C3E76DE.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C3E76DE.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Proposed appendix to Babel-HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 00:12:24 -0000 Key representation ================== The protocol described in this document assumes the presence of one or more keys in entries of the interface table (Section 3.1) that have been securely provisioned by means outside of the protocol. In this appendix, we describe how this provisioning might happen. Static configuration file ------------------------- In the simplest case, the keys are taken from a static configuration file. When that is the case, the keys should either be drawn randomly using a good source of entropy, or generated from a user-provided passphrase using a good Key Derivation Function (KDF). In either case, the keys should be distributed to all routers using a some secure channel (e.g., ssh login or human slaves carrying USB flashkeys). The user-provided passphrase, if any, should not be distributed to the routers, but rather kept on a secure central host where key generation happens. In the interest of interoperability, it is recommended that all Babel implementations support a configuration syntax where the key is expressed as a string of hexadecimal digits (both uppercase or lowercase should be accepted) of exactly the right size to yield an HMAC key (e.g., 64 hexadecimal digits for a SHA-256 key). It is recommended that keys of the wrong size should be rejected rather than extended or hashed. Static provisioning through a management protocol ------------------------------------------------- In a slightly more advanced implementation, HMAC keys are provisioned using a management protocol, either a standard XML over HTTP horror [NETCONF, TR-69], or an elegant ad-hoc protocol. In that case, the keys should be expressed in whatever format the management protocol uses for representing raw binary data, and keys should be rejected unless they have exactly the right size for a given HMAC algorithm (e.g., 32 octets for a SHA-256 key). If the management protocol has no usual syntax for binary blobs, hexadecimal is recommended. Key distribution protocol ------------------------- The recommended approach is to use a centralised key distribution server that periodically generates a new key. In that approach, the central server generates a new key every 20 minutes or so and installs it on all the secure interfaces of all the routers in a given routing domain; after all routers have been updated, the central server performs a second pass to remove the now-obsolete keys. The on-the-wire protocol involved could be something as simple as connecting over ssh to every router and editing the relevan configuration files, something as complex as a an XML over HTTP monster, or something as elegant as a secure hop-to-hop flooding algorithm. It is important that the key distribution algorithm should be able to recover from failed key installation, which may happen if a router was not reachable at the time a new key was being installed. In the case of a protocol that uses global unicast, this can be ensured either by using a separate management network, or by designing the network so that there is a connected backbone that is not secured by HMAC. The elegant solution to the problem is to use a key distribution protocol that only relies on link-local IPv6 communication. From nobody Wed Jan 16 05:59:07 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483D1130ED1 for ; Wed, 16 Jan 2019 05:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.39 X-Spam-Level: * X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Qs7wygSxiEO for ; Wed, 16 Jan 2019 05:59:02 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1B0130E5F for ; Wed, 16 Jan 2019 05:59:02 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x0GDuUDB045027; Wed, 16 Jan 2019 08:59:01 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2q25vs03sg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Jan 2019 08:59:01 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0GDwxxK024992; Wed, 16 Jan 2019 08:59:00 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0GDwtkn024913; Wed, 16 Jan 2019 08:58:55 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 89D0440006FD; Wed, 16 Jan 2019 13:58:55 +0000 (GMT) Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30484.vci.att.com (Service) with ESMTPS id 74E314013D3D; Wed, 16 Jan 2019 13:58:55 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.203]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0415.000; Wed, 16 Jan 2019 08:58:54 -0500 From: "STARK, BARBARA H" To: "'David Schinazi'" , Juliusz Chroboczek CC: Babel at IETF Thread-Topic: [babel] babel-dtls: verifying "authentication" Thread-Index: AdSoVYQo0/ay4EhYQw+N2cLNVC6kSAAO/2EAAAFCPHAAgAlFgABc58dwAB3iEgAAKXudgAAe5RQA Date: Wed, 16 Jan 2019 13:58:54 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF9F064@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF8A154@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DF8A9A3@GAALPA1MSGUSRBF.ITServices.sbc.com> <875zuuw0yo.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9C5D7@GAALPA1MSGUSRBF.ITServices.sbc.com> <87bm4ig9nf.wl-jch@irif.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.220.117] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114DF9F064GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-16_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901160116 Archived-At: Subject: Re: [babel] babel-dtls: verifying "authentication" X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 13:59:05 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114DF9F064GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIHJlYWQgdGhlIHByb3Bvc2VkIHRleHQuIEl0IHJlc29sdmVzIG15IGNvbW1lbnRzLg0K SSBoYXZlIG5vIG90aGVyIGNvbW1lbnRzIGFuZCBzdXBwb3J0IHB1YmxpY2F0aW9uIG9mIHRoZSBk cmFmdC4NCkJhcmJhcmENCg0KRnJvbTogRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6aS5pZXRmQGdt YWlsLmNvbT4NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTUsIDIwMTkgMToxMiBQTQ0KVG86IEp1 bGl1c3ogQ2hyb2JvY3playA8amNoQGlyaWYuZnI+DQpDYzogU1RBUkssIEJBUkJBUkEgSCA8YnM3 NjUyQGF0dC5jb20+OyBCYWJlbCBhdCBJRVRGIDxiYWJlbEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbYmFiZWxdIGJhYmVsLWR0bHM6IHZlcmlmeWluZyAiYXV0aGVudGljYXRpb24iDQoNCkkganVz dCBoYWQgYSBxdWljayBwaG9uZSBjYWxsIHdpdGggQmFyYmFyYSBhbmQgd2UgY2xhcmlmaWVkIG91 ciBkaWZmZXJlbmNlcyBpbiB0ZXJtaW5vbG9neS4NCkkgaGF2ZSBzbGlnaHRseSB0d2Vha2VkIHRo ZSBhdXRoZW50aWNhdGlvbiB0ZXh0IHRvIGhvcGVmdWxseSBhZGRyZXNzIHRoZXNlOg0KaHR0cHM6 Ly9naXRodWIuY29tL2plY2gvYmFiZWwtZHJhZnRzL2NvbW1pdC8wZDFmYmM5OGU1YThhMGI4NmU2 Y2JlNmQ2NzU3YzFmYmU3ZDZmYzJkPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9qZWNoX2JhYmVsLTJEZHJhZnRzX2NvbW1pdF8w ZDFmYmM5OGU1YThhMGI4NmU2Y2JlNmQ2NzU3YzFmYmU3ZDZmYzJkJmQ9RHdNRmFRJmM9TEZZWi1v OV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmbT1RT011Q3NlUV9McFBQ cVc2dVlJcThUVFZPd2ZnWVJjcld6MG5tSjF4YlZNJnM9a1VoSDh3cERIQ3lBU1V4d3lHUUZhdHk0 TVpFWFN6bDYtVlQxaFZpbWhIVSZlPT4NCg0KQmFyYmFyYSwgdGhhbmtzIGZvciB0YWtpbmcgdGhl IHRpbWUsIGFuZCBwbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IGxpa2UgdGhlIG5ldyB0ZXh0Lg0K DQpUaGFua3MhDQpEYXZpZA0KDQpPbiBNb24sIEphbiAxNCwgMjAxOSBhdCAyOjI0IFBNIEp1bGl1 c3ogQ2hyb2JvY3playA8amNoQGlyaWYuZnI8bWFpbHRvOmpjaEBpcmlmLmZyPj4gd3JvdGU6DQo+ IE1VU1QgYXV0aGVudGljYXRlIHJlY2VpdmVkIGNyZWRlbnRpYWxzIGFnYWluc3QgYW4gaW50ZXJu YWwgc3RvcmUgb2YNCj4gY3JlZGVudGlhbHMuDQoNClNvdW5kcyBnb29kIHRvIG1lLiAgU2F5IHRo YXQgYSByb3V0ZXIgaXMgY29uZmlndXJlZCB3aXRoIGEgbnVtYmVyIG9mDQpjcmVkZW50aWFscywg YW5kIHRoYXQgd2hhdCBhdXRoZW50aWNhdGlvbiBtZWFucyBkZXBlbmRzIG9uIHRoZSBleGFjdCBr aW5kDQpvZiB0aGUgY3JlZGVudGlhbC4gIEdpdmUgdGhyZWUgZXhhbXBsZXMgLS0gcHVibGljIGtl eSwgQ0EsIHByZS1zaGFyZWQNCnN5bW1ldHJpYyBrZXkuICBCZSB2ZXJ5IGNsZWFyIHRoYXQgdGhp cyBsaXN0IGlzIG5vdCBleGhhdXN0aXZlLCBhbmQNCmltcGxlbWVudGF0aW9ucyBNQVkgdXNlIG90 aGVyIHN0cmF0ZWdpZXMuDQoNCj4gU0hPVUxEIGFzc29jaWF0ZSByb3V0ZXItaWQgd2l0aCBjcmVk ZW50aWFscw0KDQpObywgdGhhdCdzIHRvbyByZXN0cmljdGl2ZS4gIFdoaWxlIDYxMjZiaXMgYXNz b2NpYXRlcyBhIHJvdXRlci1pZCB3aXRoDQphIHJvdXRlciwgcm91dGVyLWlkcyBhcmUgb25seSBj YXJyaWVkIGJ5IHJvdXRlcywgc28gYSByb3V0ZXIgdGhhdCBkb2Vzbid0DQpyZWRpc3RyaWJ1dGUg YW55IHJvdXRlcyBkb2VzIG5vdCBuZWVkIHRvIGNhcnJ5IGEgcm91dGVyLWlkLiAgRnVydGhlcm1v cmUsDQpyb3V0ZXItaWRzIG5lZWQgbm90IGJlIHBlcnNpc3RlbnQgLS0gYSByb3V0ZXIgY2FuIHBp Y2sgYSBuZXcgcm91dGVyLWlkDQp3aGVuZXZlciBpdCByZWJvb3RzLg0KDQo+IE1BWSBlbnN1cmUg c2FtZSBJUCBhZGRyZXNzIGlzIHVzZWQgdG8gc2VuZCBhIHBhcnRpY3VsYXIgY2VydCwgYWZ0ZXIN Cj4gZmlyc3QgdXNlIG9mIGNlcnQNCg0KVGhhdCB3b24ndCB3b3JrIC0tIEJhYmVsIHN1cHBvcnRz IGhhdmluZyBtdWx0aXBsZSBpbnRlcmZhY2VzIG9uIHRoZSBzYW1lDQpsaW5rIChhbmQgdGhhdCBh Y3R1YWxseSBoYXBwZW5zIHF1aXRlIG9mdGVuIGluIHJhZGlvIG5ldHdvcmtzLCBlaXRoZXIgZHVl DQp0byBtaXNjb25maWd1cmF0aW9uIG9yIGZvciBpbmNyZWFzZWQgcmVsaWFiaWxpdHkpLiAgSVBz IGlkZW50aWZ5DQppbnRlcmZhY2VzLCBub3Qgcm91dGVycy4NCg0KPiBNQVkgc3VwcG9ydCB2YWxp ZGF0aW9uIGJ5IGNlcnRpZmljYXRlIGF1dGhvcml0eSAoQ0EpIGNyZWRlbnRpYWxzDQo+IChyZXF1 aXJlcyBhbiBpbnRlcm5hbCBzdG9yZSBvZiBDQSBjcmVkZW50aWFscykgdXNlZCB0byBzaWduIHJl Y2VpdmVkDQo+IGNyZWRlbnRpYWxzLg0KDQpZZXAuICBUaGF0J3MgdGhlIHNlY29uZCBleGFtcGxl IGluIG15IGxpc3QgYWJvdmUuDQoNCj4gTUFZIHN1cHBvcnQgdHJ1c3Qtb24tZmlyc3QtdXNlIGZv ciBmaXJzdCB0aW1lIGFuIElQIGFkZHJlc3MgaXMgc2Vlbg0KDQpUaGF0IHdvdWxkIHdvcmsgLS0g YXMgbG9uZyBhcyB3ZSBhbGxvdyB0aGUgc2FtZSBjZXJ0IHRvIGJlIG9yaWdpbmF0ZWQgYnkNCm11 bHRpcGxlIElQcy4NCg0KLS0gSnVsaXVzeg0K --_000_2D09D61DDFA73D4C884805CC7865E6114DF9F064GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J 4oCZdmUgcmVhZCB0aGUgcHJvcG9zZWQgdGV4dC4gSXQgcmVzb2x2ZXMgbXkgY29tbWVudHMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgbm8gb3RoZXIgY29tbWVu dHMgYW5kIHN1cHBvcnQgcHVibGljYXRpb24gb2YgdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFyYmFyYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PkZyb206PC9iPiBEYXZpZCBTY2hpbmF6aSAmbHQ7ZHNjaGluYXppLmlldGZAZ21haWwuY29tJmd0 OyA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAxNSwgMjAxOSAxOjEyIFBNPGJy Pg0KPGI+VG86PC9iPiBKdWxpdXN6IENocm9ib2N6ZWsgJmx0O2pjaEBpcmlmLmZyJmd0Ozxicj4N CjxiPkNjOjwvYj4gU1RBUkssIEJBUkJBUkEgSCAmbHQ7YnM3NjUyQGF0dC5jb20mZ3Q7OyBCYWJl bCBhdCBJRVRGICZsdDtiYWJlbEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtiYWJlbF0gYmFiZWwtZHRsczogdmVyaWZ5aW5nICZxdW90O2F1dGhlbnRpY2F0aW9uJnF1b3Q7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg anVzdCBoYWQgYSBxdWljayBwaG9uZSBjYWxsIHdpdGggQmFyYmFyYSBhbmQgd2UgY2xhcmlmaWVk IG91ciBkaWZmZXJlbmNlcyBpbiB0ZXJtaW5vbG9neS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgc2xpZ2h0bHkgdHdlYWtlZCB0aGUgYXV0aGVudGlj YXRpb24gdGV4dCB0byBob3BlZnVsbHkgYWRkcmVzcyB0aGVzZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9qZWNoX2Jh YmVsLTJEZHJhZnRzX2NvbW1pdF8wZDFmYmM5OGU1YThhMGI4NmU2Y2JlNmQ2NzU3YzFmYmU3ZDZm YzJkJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPUxvR3po Qy04c2M4U1k4VHE0dnJmb2cmYW1wO209UU9NdUNzZVFfTHBQUHFXNnVZSXE4VFRWT3dmZ1lSY3JX ejBubUoxeGJWTSZhbXA7cz1rVWhIOHdwREhDeUFTVXh3eUdRRmF0eTRNWkVYU3psNi1WVDFoVmlt aEhVJmFtcDtlPSI+aHR0cHM6Ly9naXRodWIuY29tL2plY2gvYmFiZWwtZHJhZnRzL2NvbW1pdC8w ZDFmYmM5OGU1YThhMGI4NmU2Y2JlNmQ2NzU3YzFmYmU3ZDZmYzJkPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYXJiYXJhLCB0aGFua3Mg Zm9yIHRha2luZyB0aGUgdGltZSwgYW5kIHBsZWFzZSBsZXQgdXMga25vdyBpZiB5b3UgbGlrZSB0 aGUgbmV3IHRleHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkRhdmlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKYW4gMTQsIDIwMTkgYXQgMjoyNCBQTSBK dWxpdXN6IENocm9ib2N6ZWsgJmx0OzxhIGhyZWY9Im1haWx0bzpqY2hAaXJpZi5mciI+amNoQGly aWYuZnI8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgTVVTVCBhdXRoZW50aWNhdGUgcmVjZWl2ZWQgY3Jl ZGVudGlhbHMgYWdhaW5zdCBhbiBpbnRlcm5hbCBzdG9yZSBvZjxicj4NCiZndDsgY3JlZGVudGlh bHMuPGJyPg0KPGJyPg0KU291bmRzIGdvb2QgdG8gbWUuJm5ic3A7IFNheSB0aGF0IGEgcm91dGVy IGlzIGNvbmZpZ3VyZWQgd2l0aCBhIG51bWJlciBvZjxicj4NCmNyZWRlbnRpYWxzLCBhbmQgdGhh dCB3aGF0IGF1dGhlbnRpY2F0aW9uIG1lYW5zIGRlcGVuZHMgb24gdGhlIGV4YWN0IGtpbmQ8YnI+ DQpvZiB0aGUgY3JlZGVudGlhbC4mbmJzcDsgR2l2ZSB0aHJlZSBleGFtcGxlcyAtLSBwdWJsaWMg a2V5LCBDQSwgcHJlLXNoYXJlZDxicj4NCnN5bW1ldHJpYyBrZXkuJm5ic3A7IEJlIHZlcnkgY2xl YXIgdGhhdCB0aGlzIGxpc3QgaXMgbm90IGV4aGF1c3RpdmUsIGFuZDxicj4NCmltcGxlbWVudGF0 aW9ucyBNQVkgdXNlIG90aGVyIHN0cmF0ZWdpZXMuPGJyPg0KPGJyPg0KJmd0OyBTSE9VTEQgYXNz b2NpYXRlIHJvdXRlci1pZCB3aXRoIGNyZWRlbnRpYWxzPGJyPg0KPGJyPg0KTm8sIHRoYXQncyB0 b28gcmVzdHJpY3RpdmUuJm5ic3A7IFdoaWxlIDYxMjZiaXMgYXNzb2NpYXRlcyBhIHJvdXRlci1p ZCB3aXRoPGJyPg0KYSByb3V0ZXIsIHJvdXRlci1pZHMgYXJlIG9ubHkgY2FycmllZCBieSByb3V0 ZXMsIHNvIGEgcm91dGVyIHRoYXQgZG9lc24ndDxicj4NCnJlZGlzdHJpYnV0ZSBhbnkgcm91dGVz IGRvZXMgbm90IG5lZWQgdG8gY2FycnkgYSByb3V0ZXItaWQuJm5ic3A7IEZ1cnRoZXJtb3JlLDxi cj4NCnJvdXRlci1pZHMgbmVlZCBub3QgYmUgcGVyc2lzdGVudCAtLSBhIHJvdXRlciBjYW4gcGlj ayBhIG5ldyByb3V0ZXItaWQ8YnI+DQp3aGVuZXZlciBpdCByZWJvb3RzLjxicj4NCjxicj4NCiZn dDsgTUFZIGVuc3VyZSBzYW1lIElQIGFkZHJlc3MgaXMgdXNlZCB0byBzZW5kIGEgcGFydGljdWxh ciBjZXJ0LCBhZnRlcjxicj4NCiZndDsgZmlyc3QgdXNlIG9mIGNlcnQ8YnI+DQo8YnI+DQpUaGF0 IHdvbid0IHdvcmsgLS0gQmFiZWwgc3VwcG9ydHMgaGF2aW5nIG11bHRpcGxlIGludGVyZmFjZXMg b24gdGhlIHNhbWU8YnI+DQpsaW5rIChhbmQgdGhhdCBhY3R1YWxseSBoYXBwZW5zIHF1aXRlIG9m dGVuIGluIHJhZGlvIG5ldHdvcmtzLCBlaXRoZXIgZHVlPGJyPg0KdG8gbWlzY29uZmlndXJhdGlv biBvciBmb3IgaW5jcmVhc2VkIHJlbGlhYmlsaXR5KS4mbmJzcDsgSVBzIGlkZW50aWZ5PGJyPg0K aW50ZXJmYWNlcywgbm90IHJvdXRlcnMuPGJyPg0KPGJyPg0KJmd0OyBNQVkgc3VwcG9ydCB2YWxp ZGF0aW9uIGJ5IGNlcnRpZmljYXRlIGF1dGhvcml0eSAoQ0EpIGNyZWRlbnRpYWxzPGJyPg0KJmd0 OyAocmVxdWlyZXMgYW4gaW50ZXJuYWwgc3RvcmUgb2YgQ0EgY3JlZGVudGlhbHMpIHVzZWQgdG8g c2lnbiByZWNlaXZlZDxicj4NCiZndDsgY3JlZGVudGlhbHMuPGJyPg0KPGJyPg0KWWVwLiZuYnNw OyBUaGF0J3MgdGhlIHNlY29uZCBleGFtcGxlIGluIG15IGxpc3QgYWJvdmUuPGJyPg0KPGJyPg0K Jmd0OyBNQVkgc3VwcG9ydCB0cnVzdC1vbi1maXJzdC11c2UgZm9yIGZpcnN0IHRpbWUgYW4gSVAg YWRkcmVzcyBpcyBzZWVuPGJyPg0KPGJyPg0KVGhhdCB3b3VsZCB3b3JrIC0tIGFzIGxvbmcgYXMg d2UgYWxsb3cgdGhlIHNhbWUgY2VydCB0byBiZSBvcmlnaW5hdGVkIGJ5PGJyPg0KbXVsdGlwbGUg SVBzLjxicj4NCjxicj4NCi0tIEp1bGl1c3o8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2D09D61DDFA73D4C884805CC7865E6114DF9F064GAALPA1MSGUSRBF_-- From nobody Wed Jan 16 07:46:10 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC30130E74 for ; Wed, 16 Jan 2019 07:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHL9m9mE1-3B for ; Wed, 16 Jan 2019 07:46:08 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B0E130DE4 for ; Wed, 16 Jan 2019 07:46:08 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x0GFj4kb016873; Wed, 16 Jan 2019 10:46:07 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2q248g4v76-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Jan 2019 10:46:06 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0GFk58t011515; Wed, 16 Jan 2019 10:46:06 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0GFk0R3011261; Wed, 16 Jan 2019 10:46:02 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 492CB402FFC6; Wed, 16 Jan 2019 15:46:00 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30485.vci.att.com (Service) with ESMTPS id 36B28402FFC5; Wed, 16 Jan 2019 15:46:00 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.203]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0415.000; Wed, 16 Jan 2019 10:45:59 -0500 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" , =?iso-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= CC: Babel at IETF Thread-Topic: [babel] babel-hmac: key requirements Thread-Index: AdSpKuuhWh3uIPf3TSyfFq2fmw6nrABcdjuAAFt168AASoEFAAAIqZ0A///Z2YCAAA4wAP//SZFg Date: Wed, 16 Jan 2019 15:45:59 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF9F26C@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> <874laevyy4.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9BFAF@GAALPA1MSGUSRBF.ITServices.sbc.com> <87o98hbt9j.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9E3B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <87k1j5ob7q.fsf@toke.dk> <87k1j5blr3.wl-jch@irif.fr> In-Reply-To: <87k1j5blr3.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.220.117] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-16_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=964 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901160128 Archived-At: Subject: Re: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 15:46:09 -0000 I don't seem to be communicating well what I'm looking for. An informative = appendix doesn't solve my problem. The advice is nice, but it's not what I'= m needing. Let me try saying this differently. If it weren't for OSPF defining 2 different keys (the entered key and the c= ryptographic key) and the HMAC RFC 2104 defining the jey as something of va= riable length that gets hashed when it's longer than the block size, I/we w= ouldn't have a problem. But because of those specs (and RFC 2104 is normati= vely referenced), the term "HMAC key" is ambiguous. A careful reader might = not see it as ambiguous and understand what's implied by the text; but all = readers aren't careful. Therefore, I would like for babel-hmac to resolve this ambiguity by providi= ng a prominent (hard to miss) definition of "HMAC key". Here's another suggestion for how this might be achieved. Insert a section under Data Structures of: ## The HMAC Key The HMAC key is a string of bytes the length of which is exactly the block = size of the HMAC algorithm being used. Note this is different from the [RF= C2104] definition. ---------------------------- A second problem I have (which doesn't need to be resolved by text in babel= -hmac, but can be dealt with in information-model) is the format to use for= supplying an input that becomes an HMAC key. I think we're somewhere betwe= en binary and hex at this point. I don't care which, but I need to choose o= ne or the other. Barbara From nobody Wed Jan 16 08:53:27 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2BF12894E for ; Wed, 16 Jan 2019 08:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NHZNfK-9tVk for ; Wed, 16 Jan 2019 08:53:24 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57EB1276D0 for ; Wed, 16 Jan 2019 08:53:23 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0GGrD9h021135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Jan 2019 17:53:13 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x0GGrFHN021531; Wed, 16 Jan 2019 17:53:15 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 15A6A36E60; Wed, 16 Jan 2019 17:53:19 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id uviD41u4Q9AC; Wed, 16 Jan 2019 17:53:17 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id F27E536E59; Wed, 16 Jan 2019 17:53:16 +0100 (CET) Date: Wed, 16 Jan 2019 17:53:16 +0100 Message-ID: <871s5cbl37.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF9F26C@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> <874laevyy4.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9BFAF@GAALPA1MSGUSRBF.ITServices.sbc.com> <87o98hbt9j.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9E3B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <87k1j5ob7q.fsf@toke.dk> <87k1j5blr3.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9F26C@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 16 Jan 2019 17:53:13 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 16 Jan 2019 17:53:15 +0100 (CET) X-Miltered: at korolev with ID 5C3F6179.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5C3F617B.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C3F6179.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5C3F617B.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C3F6179.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5C3F617B.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 16:53:26 -0000 > Here's another suggestion for how this might be achieved. > Insert a section under Data Structures of: > ## The HMAC Key > The HMAC key is a string of bytes the length of which is exactly the > block size of the HMAC algorithm being used. Note this is different > from the [RFC2104] definition. Good idea. I'll do that. -- Juliusz From nobody Wed Jan 16 09:06:56 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6A31276D0 for ; Wed, 16 Jan 2019 09:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v09aVyMT8QbF for ; Wed, 16 Jan 2019 09:06:53 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998F3124C04 for ; Wed, 16 Jan 2019 09:06:53 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x0GH6fAT038345; Wed, 16 Jan 2019 12:06:53 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2q26k9kvbq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Jan 2019 12:06:52 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0GH6nwT014092; Wed, 16 Jan 2019 12:06:51 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0GH6kaK013960; Wed, 16 Jan 2019 12:06:46 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id D1A4B401467C; Wed, 16 Jan 2019 17:06:46 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30483.vci.att.com (Service) with ESMTPS id C0DD9401466C; Wed, 16 Jan 2019 17:06:46 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.203]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0415.000; Wed, 16 Jan 2019 12:06:46 -0500 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: =?iso-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= , Babel at IETF Thread-Topic: [babel] babel-hmac: key requirements Thread-Index: AdSpKuuhWh3uIPf3TSyfFq2fmw6nrABcdjuAAFt168AASoEFAAAIqZ0A///Z2YCAAA4wAP//SZFggAHrnQCAAFB6MA== Date: Wed, 16 Jan 2019 17:06:45 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF9F4DF@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF96321@GAALPA1MSGUSRBF.ITServices.sbc.com> <874laevyy4.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9BFAF@GAALPA1MSGUSRBF.ITServices.sbc.com> <87o98hbt9j.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9E3B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <87k1j5ob7q.fsf@toke.dk> <87k1j5blr3.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DF9F26C@GAALPA1MSGUSRBF.ITServices.sbc.com> <871s5cbl37.wl-jch@irif.fr> In-Reply-To: <871s5cbl37.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.220.117] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=681 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901160138 Archived-At: Subject: Re: [babel] babel-hmac: key requirements X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 17:06:55 -0000 > > Insert a section under Data Structures of: >=20 > > ## The HMAC Key >=20 > > The HMAC key is a string of bytes the length of which is exactly the > > block size of the HMAC algorithm being used. Note this is different > > from the [RFC2104] definition. >=20 > Good idea. I'll do that. Thx. That will resolve my comment. With this, I'm fine with publication of = the draft. I'll start a separate thread to handle my question about the information-mo= del datatype. Barbara From nobody Wed Jan 16 09:16:39 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CF3124C04 for ; Wed, 16 Jan 2019 09:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRrbOr-vu81U for ; Wed, 16 Jan 2019 09:16:37 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB95124BE5 for ; Wed, 16 Jan 2019 09:16:37 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x0GH6a6W048681 for ; Wed, 16 Jan 2019 12:16:37 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2q25vs5879-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 16 Jan 2019 12:16:36 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0GHGZ0C000944 for ; Wed, 16 Jan 2019 12:16:35 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0GHGUh2000822 for ; Wed, 16 Jan 2019 12:16:30 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id CCB70402FFC6 for ; Wed, 16 Jan 2019 17:16:30 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30485.vci.att.com (Service) with ESMTPS id B7D3F402FFC4 for ; Wed, 16 Jan 2019 17:16:30 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.203]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0415.000; Wed, 16 Jan 2019 12:16:30 -0500 From: "STARK, BARBARA H" To: Babel at IETF Thread-Topic: information-model: hmac-key datatype Thread-Index: AdStvfi9ajIjBKd+R+6calcuWZ5UqA== Date: Wed, 16 Jan 2019 17:16:29 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF9F556@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.220.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=614 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901160138 Archived-At: Subject: [babel] information-model: hmac-key datatype X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 17:16:38 -0000 What datatype should we use for the hmac-key parameter? Choices are binary or hex (I think we've already agreed on not "string"). My preference is "binary", because we aren't using hex for anything else, s= o I'd have to add a definition for it. Of course, when I do a TR-181 data m= odel, I'll be using the TR-181 "hexBinary" datatype that's defined as "hex = encoded binary". Barbara From nobody Fri Jan 18 12:42:06 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E27130FD6 for ; Fri, 18 Jan 2019 12:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxS2bqLB2el0 for ; Fri, 18 Jan 2019 12:42:03 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1ED11313C2 for ; Fri, 18 Jan 2019 12:42:03 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x0IHjWsM029068 for ; Fri, 18 Jan 2019 12:52:06 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2q3k1ugx21-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 18 Jan 2019 12:52:06 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0IHq5Ob010733 for ; Fri, 18 Jan 2019 12:52:05 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0IHq3jY010706 for ; Fri, 18 Jan 2019 12:52:03 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 7E3404048B41 for ; Fri, 18 Jan 2019 17:52:03 +0000 (GMT) Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (unknown [130.8.218.153]) by zlp30486.vci.att.com (Service) with ESMTPS id 6E19540002D7 for ; Fri, 18 Jan 2019 17:52:03 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.203]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0415.000; Fri, 18 Jan 2019 12:52:02 -0500 From: "STARK, BARBARA H" To: "'Babel at IETF'" Thread-Topic: information-model: hmac-key datatype Thread-Index: AdStvfi9ajIjBKd+R+6calcuWZ5UqABmDmtA Date: Fri, 18 Jan 2019 17:52:02 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DFA15E0@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DF9F556@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DF9F556@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.187.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-18_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=819 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901180128 Archived-At: Subject: Re: [babel] information-model: hmac-key datatype X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 20:42:05 -0000 > What datatype should we use for the hmac-key parameter? > Choices are binary or hex (I think we've already agreed on not "string"). >=20 > My preference is "binary", because we aren't using hex for anything else,= so > I'd have to add a definition for it. Of course, when I do a TR-181 data m= odel, > I'll be using the TR-181 "hexBinary" datatype that's defined as "hex enco= ded > binary". Having heard no other preferences expressed, I declare my preference of "bi= nary" to be the winner. Barbara From nobody Sat Jan 19 06:10:36 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A7F124C04 for ; Sat, 19 Jan 2019 06:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2i-fNRcHGBma for ; Sat, 19 Jan 2019 06:10:32 -0800 (PST) Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E8012426E for ; Sat, 19 Jan 2019 06:10:32 -0800 (PST) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 3A75C21425; Sat, 19 Jan 2019 14:10:29 +0000 (UTC) From: Dave Taht To: Juliusz Chroboczek Cc: babel@ietf.org References: <87h8e9bgv3.wl-jch@irif.fr> Date: Sat, 19 Jan 2019 06:09:49 -0800 In-Reply-To: <87h8e9bgv3.wl-jch@irif.fr> (Juliusz Chroboczek's message of "Wed, 16 Jan 2019 01:12:16 +0100") Message-ID: <877ef0pwlu.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Proposed appendix to Babel-HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 14:10:34 -0000 Juliusz Chroboczek writes: > Key representation > ================== > > The protocol described in this document assumes the presence of one or > more keys in entries of the interface table (Section 3.1) that have been > securely provisioned by means outside of the protocol. In this appendix, > we describe how this provisioning might happen. > > Static configuration file > ------------------------- > > In the simplest case, the keys are taken from a static configuration file. > When that is the case, the keys should either be drawn randomly using > a good source of entropy, or generated from a user-provided passphrase > using a good Key Derivation Function (KDF). > > In either case, the keys should be distributed to all routers using a some > secure channel (e.g., ssh login or human slaves carrying USB flashkeys). human slavery is usually not in the domain of the ietf, and is usually only in the domain of corporations and oppressive governments. yes, I laughed, but there is a huge movement to rid the language of the master/slave analogy across all of tech. > The user-provided passphrase, if any, should not be distributed to the > routers, but rather kept on a secure central host where key generation > happens. > > In the interest of interoperability, it is recommended that all Babel > implementations support a configuration syntax where the key is expressed > as a string of hexadecimal digits (both uppercase or lowercase should be > accepted) of exactly the right size to yield an HMAC key (e.g., 64 > hexadecimal digits for a SHA-256 key). It is recommended that keys of the > wrong size should be rejected rather than extended or hashed. I figure I've lost on the BASE64 idea. Still I felt 0xthekey for hex was a good idea rather than just thekey > Static provisioning through a management protocol > ------------------------------------------------- > > In a slightly more advanced implementation, HMAC keys are provisioned > using a management protocol, either a standard XML over HTTP horror > [NETCONF, TR-69], or an elegant ad-hoc protocol. In that case, the keys > should be expressed in whatever format the management protocol uses for > representing raw binary data, and keys should be rejected unless they have > exactly the right size for a given HMAC algorithm (e.g., 32 octets for > a SHA-256 key). If the management protocol has no usual syntax for binary > blobs, hexadecimal is recommended. > > Key distribution protocol > ------------------------- > > The recommended approach is to use a centralised key distribution server > that periodically generates a new key. In that approach, the central > server generates a new key every 20 minutes or so and installs it on all > the secure interfaces of all the routers in a given routing domain; after > all routers have been updated, the central server performs a second pass > to remove the now-obsolete keys. The on-the-wire protocol involved could > be something as simple as connecting over ssh to every router and editing > the relevan configuration files, something as complex as a an XML over spelling:relevant. > HTTP monster, or something as elegant as a secure hop-to-hop flooding > algorithm. It is obvious that some frustration and perhaps, vodka, were leaking through this proposed appendix. ", something as complex as XML over HTTP, or a secure hop-to-hop" > It is important that the key distribution algorithm should be able to > recover from failed key installation, which may happen if a router was not > reachable at the time a new key was being installed. In the case of > a protocol that uses global unicast, this can be ensured either by using > a separate management network, or by designing the network so that there > is a connected backbone that is not secured by HMAC. The elegant solution > to the problem is to use a key distribution protocol that only relies on > link-local IPv6 communication. Feel free to reference hnet here... > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Mon Jan 21 13:40:11 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD34812950A for ; Mon, 21 Jan 2019 13:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pEKdgCUYSnO for ; Mon, 21 Jan 2019 13:40:07 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474E31200B3 for ; Mon, 21 Jan 2019 13:40:07 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x0LLa3mA023102; Mon, 21 Jan 2019 16:40:06 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2q5ks8uqk6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Jan 2019 16:39:59 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0LLdpTt016786; Mon, 21 Jan 2019 16:39:51 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0LLdlIP016740; Mon, 21 Jan 2019 16:39:47 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 8597C40002C2; Mon, 21 Jan 2019 21:39:47 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30488.vci.att.com (Service) with ESMTPS id 6E56E4048C31; Mon, 21 Jan 2019 21:39:47 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.203]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0415.000; Mon, 21 Jan 2019 16:39:46 -0500 From: "STARK, BARBARA H" To: "'Dave Taht'" , Juliusz Chroboczek CC: "babel@ietf.org" Thread-Topic: [babel] Proposed appendix to Babel-HMAC Thread-Index: AQHUrTAuG985DzKsXkaxl3m9pr67o6W2pyewgAOeNDA= Date: Mon, 21 Jan 2019 21:39:46 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DFA4C1E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87h8e9bgv3.wl-jch@irif.fr> <877ef0pwlu.fsf@taht.net> In-Reply-To: <877ef0pwlu.fsf@taht.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.193.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-21_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901210168 Archived-At: Subject: Re: [babel] Proposed appendix to Babel-HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 21:40:09 -0000 Hi Dave, I'm not sure this proposed appendix is still being considered? In mine and = Juliusz' last exchange re the babel-hmac draft, I said I would be satisfied= with an easy-to-fine (i.e., in the Table of Contents) definition for the t= erm "HMAC Key" in the draft. Which we agreed was=20 ## The HMAC Key The HMAC key is a string of bytes the length of which is exactly the=20 block size of the HMAC algorithm being used. Note this is different=20 from the [RFC2104] definition. This doesn't specify base64 or hex format. But in the information model, I proposed the parameter be binary datatype (= noting that I would be using a hexBinary datatype with the TR-181 data mode= l). No-one disagreed with me, so I declared the decision made.=20 If we think there is value in an appendix on configuration of the HMAC key,= I'm fine with that. But I sense an anxiousness to proceed with declaring W= GLC triumphant and sending babel-hmac on to IESG. Alternately, I could see = such an appendix potentially belonging in the information-model -- where it= wouldn't clutter up hmac-babel, and where we could also discuss (more gene= rically) distribution of credentials. Barbara > -----Original Message----- > From: Dave Taht >=20 > Juliusz Chroboczek writes: >=20 > > Key representation > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > The protocol described in this document assumes the presence of one or > > more keys in entries of the interface table (Section 3.1) that have > > been securely provisioned by means outside of the protocol. In this > > appendix, we describe how this provisioning might happen. > > > > Static configuration file > > ------------------------- > > > > In the simplest case, the keys are taken from a static configuration fi= le. > > When that is the case, the keys should either be drawn randomly using > > a good source of entropy, or generated from a user-provided passphrase > > using a good Key Derivation Function (KDF). > > > > In either case, the keys should be distributed to all routers using a > > some secure channel (e.g., ssh login or human slaves carrying USB > flashkeys). >=20 > human slavery is usually not in the domain of the ietf, and is usually on= ly in > the domain of corporations and oppressive governments. >=20 > yes, I laughed, but there is a huge movement to rid the language of the > master/slave analogy across all of tech. >=20 > > The user-provided passphrase, if any, should not be distributed to the > > routers, but rather kept on a secure central host where key generation > > happens. > > > > In the interest of interoperability, it is recommended that all Babel > > implementations support a configuration syntax where the key is > > expressed as a string of hexadecimal digits (both uppercase or > > lowercase should be > > accepted) of exactly the right size to yield an HMAC key (e.g., 64 > > hexadecimal digits for a SHA-256 key). It is recommended that keys of > > the wrong size should be rejected rather than extended or hashed. >=20 > I figure I've lost on the BASE64 idea. Still I felt 0xthekey for hex was = a good > idea rather than just thekey >=20 > > Static provisioning through a management protocol > > ------------------------------------------------- > > > > In a slightly more advanced implementation, HMAC keys are provisioned > > using a management protocol, either a standard XML over HTTP horror > > [NETCONF, TR-69], or an elegant ad-hoc protocol. In that case, the > > keys should be expressed in whatever format the management protocol > > uses for representing raw binary data, and keys should be rejected > > unless they have exactly the right size for a given HMAC algorithm > > (e.g., 32 octets for a SHA-256 key). If the management protocol has > > no usual syntax for binary blobs, hexadecimal is recommended. > > > > Key distribution protocol > > ------------------------- > > > > The recommended approach is to use a centralised key distribution > > server that periodically generates a new key. In that approach, the > > central server generates a new key every 20 minutes or so and installs > > it on all the secure interfaces of all the routers in a given routing > > domain; after all routers have been updated, the central server > > performs a second pass to remove the now-obsolete keys. The > > on-the-wire protocol involved could be something as simple as > > connecting over ssh to every router and editing the relevan > > configuration files, something as complex as a an XML over >=20 > spelling:relevant. >=20 > > HTTP monster, or something as elegant as a secure hop-to-hop flooding > > algorithm. >=20 > It is obvious that some frustration and perhaps, vodka, were leaking thro= ugh > this proposed appendix. >=20 > ", something as complex as XML over HTTP, or a secure hop-to-hop" >=20 > > It is important that the key distribution algorithm should be able to > > recover from failed key installation, which may happen if a router was > > not reachable at the time a new key was being installed. In the case > > of a protocol that uses global unicast, this can be ensured either by > > using a separate management network, or by designing the network so > > that there is a connected backbone that is not secured by HMAC. The > > elegant solution to the problem is to use a key distribution protocol > > that only relies on link-local IPv6 communication. >=20 > Feel free to reference hnet here... >=20 > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mail > > man_listinfo_babel&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8T > > > q4vrfog&m=3DrVTf2a9q1YuL5raIl0tB7LvZBM3KmepN__mx0Jhtx88&s=3DuSNNUw > MZqU_Co5 > > Dltj5FVWGdMLHE4m1R1Jc9CfFlha0&e=3D >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DrVTf2a9q1YuL5raIl0tB7LvZBM3KmepN__mx0Jhtx88&s=3D > uSNNUwMZqU_Co5Dltj5FVWGdMLHE4m1R1Jc9CfFlha0&e=3D From nobody Mon Jan 21 13:47:31 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81901129BBF for ; Mon, 21 Jan 2019 13:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci_qOy7fqUit for ; Mon, 21 Jan 2019 13:47:27 -0800 (PST) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35524129B88 for ; Mon, 21 Jan 2019 13:47:27 -0800 (PST) Received: by mail-qt1-x842.google.com with SMTP id t13so25260925qtn.3 for ; Mon, 21 Jan 2019 13:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lN0CzcOJwMN716WmG6MHt3l0WfCVu8e93LKvEWv4E/o=; b=MX3L9YOoiu8anyco7fl7C+qA7SxGsSZSaRML56zSowEWtWcnGTazFNl4h1j/ekkKVt TDws0H1+7a8s7nvScuo4xKc/OIl/ojcRehe6FunDiWDJ1DfOWRmjpGibeY1wEs0Mjfjg aXVBP7pVHAfLCnq0c7nscGlQMdRpCIXk3UhQ7TBOLqi+CeLKW+zUOONNZjr6gp+iy4U0 QLWjZ9dTNEndfx5xpiAWVQ//B2ZRWKjDcd8gekC83PM2B716jtP0QQYqQ5M4ysVfymJj ri/+fWc5l+tEa3hAMrI1vv4ouy5RRgwR3ds4O2YqfvYQiYWDG2tMNMycGNuEDcCAtijo ouog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lN0CzcOJwMN716WmG6MHt3l0WfCVu8e93LKvEWv4E/o=; b=lloECleXIkgXNfgTmKUaCiuhvBWYwwonK7RapgCMNXOR+J2uJuapTmHpAco08xeMoq CrRV+BIKrrU/QAzjphA29Za9a2yFxQAosIOw4gRUl20vcPXvtgiVm8afd9kiPcoWAZQY 5XHptK0DVRPjTkaYj0h8+kO00fqaHbBnwqZ3fauisvAPEAR7c0Dg67F0JiSgNMykGF/n 2e76pifpG2ZWQgYBtHAIKz0ozuJOtdEVD68xcfipoXmyOJI/N1aKJ3uOWfpyLQegHvo9 Pzu+HMtQm2qxNomfd2sevkLjuhYrLXsv+Dy4oFsignr1So7+mArplJUyXOUpzBZyHkEs FPeA== X-Gm-Message-State: AJcUukfv8nPBzEyr06Idp6UJ8kqJFxxjxYYIdjkzbhG3DqYnLmIArElA MKuw0qzvOtSyyrfJ5DT69Pv+lANh1jSMeta1YW/7Ow== X-Google-Smtp-Source: ALg8bN7VTQEPZkcYLCHNzcSM8OWy+xEhgIoJ+hypl93hZE1EXN7OXz28/FTQlFkIfBVdkQmTvkhDk4yd8/hCTAzM6p8= X-Received: by 2002:a0c:8a5a:: with SMTP id 26mr26875375qvu.94.1548107246020; Mon, 21 Jan 2019 13:47:26 -0800 (PST) MIME-Version: 1.0 References: <87h8e9bgv3.wl-jch@irif.fr> <877ef0pwlu.fsf@taht.net> <2D09D61DDFA73D4C884805CC7865E6114DFA4C1E@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DFA4C1E@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Dave Taht Date: Mon, 21 Jan 2019 13:46:46 -0800 Message-ID: To: "STARK, BARBARA H" Cc: Dave Taht , Juliusz Chroboczek , "babel@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Proposed appendix to Babel-HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 21:47:31 -0000 On Mon, Jan 21, 2019 at 1:40 PM STARK, BARBARA H wrote: > > Hi Dave, > I'm not sure this proposed appendix is still being considered? In mine an= d Juliusz' last exchange re the babel-hmac draft, I said I would be satisfi= ed with an easy-to-fine (i.e., in the Table of Contents) definition for the= term "HMAC Key" in the draft. Which we agreed was > ## The HMAC Key > The HMAC key is a string of bytes the length of which is exactly the > block size of the HMAC algorithm being used. Note this is different > from the [RFC2104] definition. > > This doesn't specify base64 or hex format. > > But in the information model, I proposed the parameter be binary datatype= (noting that I would be using a hexBinary datatype with the TR-181 data mo= del). No-one disagreed with me, so I declared the decision made. > > If we think there is value in an appendix on configuration of the HMAC ke= y, I'm fine with that. But I sense an anxiousness to proceed with declaring= WGLC triumphant and sending babel-hmac on to IESG. Alternately, I could se= e such an appendix potentially belonging in the information-model -- where = it wouldn't clutter up hmac-babel, and where we could also discuss (more ge= nerically) distribution of credentials. I can live with this approach. If the appendix is considered necessary anywhere I would substitute "human minions" for "human slaves" as being more PC. > Barbara > > > -----Original Message----- > > From: Dave Taht > > > > Juliusz Chroboczek writes: > > > > > Key representation > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > The protocol described in this document assumes the presence of one o= r > > > more keys in entries of the interface table (Section 3.1) that have > > > been securely provisioned by means outside of the protocol. In this > > > appendix, we describe how this provisioning might happen. > > > > > > Static configuration file > > > ------------------------- > > > > > > In the simplest case, the keys are taken from a static configuration = file. > > > When that is the case, the keys should either be drawn randomly using > > > a good source of entropy, or generated from a user-provided passphras= e > > > using a good Key Derivation Function (KDF). > > > > > > In either case, the keys should be distributed to all routers using a > > > some secure channel (e.g., ssh login or human slaves carrying USB > > flashkeys). > > > > human slavery is usually not in the domain of the ietf, and is usually = only in > > the domain of corporations and oppressive governments. > > > > yes, I laughed, but there is a huge movement to rid the language of the > > master/slave analogy across all of tech. > > > > > The user-provided passphrase, if any, should not be distributed to th= e > > > routers, but rather kept on a secure central host where key generatio= n > > > happens. > > > > > > In the interest of interoperability, it is recommended that all Babel > > > implementations support a configuration syntax where the key is > > > expressed as a string of hexadecimal digits (both uppercase or > > > lowercase should be > > > accepted) of exactly the right size to yield an HMAC key (e.g., 64 > > > hexadecimal digits for a SHA-256 key). It is recommended that keys o= f > > > the wrong size should be rejected rather than extended or hashed. > > > > I figure I've lost on the BASE64 idea. Still I felt 0xthekey for hex wa= s a good > > idea rather than just thekey > > > > > Static provisioning through a management protocol > > > ------------------------------------------------- > > > > > > In a slightly more advanced implementation, HMAC keys are provisioned > > > using a management protocol, either a standard XML over HTTP horror > > > [NETCONF, TR-69], or an elegant ad-hoc protocol. In that case, the > > > keys should be expressed in whatever format the management protocol > > > uses for representing raw binary data, and keys should be rejected > > > unless they have exactly the right size for a given HMAC algorithm > > > (e.g., 32 octets for a SHA-256 key). If the management protocol has > > > no usual syntax for binary blobs, hexadecimal is recommended. > > > > > > Key distribution protocol > > > ------------------------- > > > > > > The recommended approach is to use a centralised key distribution > > > server that periodically generates a new key. In that approach, the > > > central server generates a new key every 20 minutes or so and install= s > > > it on all the secure interfaces of all the routers in a given routing > > > domain; after all routers have been updated, the central server > > > performs a second pass to remove the now-obsolete keys. The > > > on-the-wire protocol involved could be something as simple as > > > connecting over ssh to every router and editing the relevan > > > configuration files, something as complex as a an XML over > > > > spelling:relevant. > > > > > HTTP monster, or something as elegant as a secure hop-to-hop flooding > > > algorithm. > > > > It is obvious that some frustration and perhaps, vodka, were leaking th= rough > > this proposed appendix. > > > > ", something as complex as XML over HTTP, or a secure hop-to-hop" > > > > > It is important that the key distribution algorithm should be able to > > > recover from failed key installation, which may happen if a router wa= s > > > not reachable at the time a new key was being installed. In the case > > > of a protocol that uses global unicast, this can be ensured either by > > > using a separate management network, or by designing the network so > > > that there is a connected backbone that is not secured by HMAC. The > > > elegant solution to the problem is to use a key distribution protocol > > > that only relies on link-local IPv6 communication. > > > > Feel free to reference hnet here... > > > > > > > > _______________________________________________ > > > babel mailing list > > > babel@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mail > > > man_listinfo_babel&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > > 8sc8SY8T > > > > > q4vrfog&m=3DrVTf2a9q1YuL5raIl0tB7LvZBM3KmepN__mx0Jhtx88&s=3DuSNNUw > > MZqU_Co5 > > > Dltj5FVWGdMLHE4m1R1Jc9CfFlha0&e=3D > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > > 8sc8SY8Tq4vrfog&m=3DrVTf2a9q1YuL5raIl0tB7LvZBM3KmepN__mx0Jhtx88&s=3D > > uSNNUwMZqU_Co5Dltj5FVWGdMLHE4m1R1Jc9CfFlha0&e=3D > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 From nobody Mon Jan 21 17:31:13 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7F4130E7F; Mon, 21 Jan 2019 17:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6SG3r9dJ1rz; Mon, 21 Jan 2019 17:31:11 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72321130E84; Mon, 21 Jan 2019 17:31:11 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id o125so13406039qkf.3; Mon, 21 Jan 2019 17:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oc6ukMBYlbRN1DZ7cdmzPXB1wkj9UAZgCfYaBMU4Q8M=; b=r6w5hDaPHj5/KYvx5WLwd2i/ToYb5xDBDu59z2QoTIqqmT4o2dVEULvRusrQY0BJ5S yA2+n53OSq7tD0k1/+zrnFUoDfoFe5UgMa0JGaomsipDm7leCEjvH870s0NmOdyi34Lk qr569H3dof7VyzEfmKqO73U4J+snX7HNDBzW+lMlhwMNobMPuOhBY3KunDhI1JGowZuw Jh2Xd3GTBVlRlCITGrHTrQ6UqgqzpyzgFCczatG+Ikm9IbcT4tit8LBnV6MUF7ej2UwI r35Y3JzY0r4LA84slH7HSxttKVGij9Bc7ZAep3+GAf5DPQarF9kHtkpaqHIr3aO/y8B2 6QXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oc6ukMBYlbRN1DZ7cdmzPXB1wkj9UAZgCfYaBMU4Q8M=; b=PNbew13Q/t9brCCPebwLiKfMDnKcvj2063JZDwBVdsH2zMKSviHjT4AO1hSCM9BxEI K6HFOZnndCwaZEZSrhOTuu9QiVhXGB4g2xInw2lP0hx39HVnxjyCz+scb/I2NvCnlTVl iu/JaC1w/NgQcl50bIkI1tTuODrHE3F6XRaReajJpLAeVqY8krDwLohPqz04I17epIi5 h/0bUyj6qXusaFYCI3jkPazohPuPlYrgok99M9tk66wFBEcmwzBTLvmNWHr7YuSwVwcR CkpkywCdbTWxhY1zMAlcgwg8tWIq0EP79Hu2CUnLVrj64BWX78KW+hCMwNknNDCSATwS TF3Q== X-Gm-Message-State: AJcUukdDV70VJ6B05iJgs0GSoidRvj+avUnhpGb/3Gb7tvJFPznOZGjj u9tJ5zrtN+DPfMwOAPCoYwuyGSP+dOZW5FGv7fo= X-Google-Smtp-Source: ALg8bN7g+y64POO5Vno09PiQdm9dXdSz5x6js11yacv6oP/iRBgPsdsuIa2JbVss4lOPkB+MAr5ElrhUoKoLX8wK1C0= X-Received: by 2002:a37:a904:: with SMTP id s4mr27304316qke.237.1548120670347; Mon, 21 Jan 2019 17:31:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Mon, 21 Jan 2019 17:30:30 -0800 Message-ID: To: David Schinazi Cc: =?UTF-8?Q?Antonin_D=C3=A9cimo?= , Donald Eastlake , draft-ietf-babel-dtls@ietf.org, babel-chairs , Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-dtls-03 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 01:31:13 -0000 As I have been the only objector to this draft, I hereby lift my objection and support publication. From nobody Tue Jan 22 08:34:41 2019 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D50130F3A for ; Tue, 22 Jan 2019 08:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boLUR_JPosjp for ; Tue, 22 Jan 2019 08:34:38 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C5212E043 for ; Tue, 22 Jan 2019 08:34:37 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x0MGWVvB013549; Tue, 22 Jan 2019 17:32:31 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 41D9B4B2E2; Tue, 22 Jan 2019 17:32:37 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id A6KNa2-sh0om; Tue, 22 Jan 2019 17:32:35 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 4CA444B2DD; Tue, 22 Jan 2019 17:32:32 +0100 (CET) Date: Tue, 22 Jan 2019 17:32:32 +0100 Message-ID: <875zugk5zz.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'Dave Taht'" , "babel@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DFA4C1E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87h8e9bgv3.wl-jch@irif.fr> <877ef0pwlu.fsf@taht.net> <2D09D61DDFA73D4C884805CC7865E6114DFA4C1E@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 22 Jan 2019 17:32:32 +0100 (CET) X-Miltered: at korolev with ID 5C47459F.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C47459F.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C47459F.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Proposed appendix to Babel-HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 16:34:41 -0000 Barbara said: > I'm not sure this proposed appendix is still being considered? My understanding is the same as Barbara's, we're no longer doing an appendix. > But in the information model, I proposed the parameter be binary > datatype (noting that I would be using a hexBinary datatype with the > TR-181 data model). Perhaps you might mention that hex is the preferred human-readable format for this particular piece of data? > If we think there is value in an appendix on configuration of the HMAC > key, I'm fine with that. It makes me a little uncomfortable -- I'd rather we didn't give any implementation advice until we've got more implementation experience. (How many times have you looked at an RFC, started to implement the advice in their informative appendix, just to find out that it cannot reasonably be implemented, or at least not without a lot more work than the appendix implies?) Dave said: > If the appendix is considered necessary anywhere I would substitute > "human minions" for "human slaves" as being more PC. Heh. You do realise that the word has sexual undertones in French? -- Juliusz From nobody Tue Jan 29 18:03:35 2019 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FF71310D4; Tue, 29 Jan 2019 18:03:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner To: Cc: draft-ietf-babel-dtls.all@ietf.org, ietf@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154881379920.7794.15439486195773911279@ietfa.amsl.com> Date: Tue, 29 Jan 2019 18:03:19 -0800 Archived-At: Subject: [babel] Secdir early review of draft-ietf-babel-dtls-03 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 02:03:19 -0000 Reviewer: Sean Turner Review result: Has Nits Hi, David wanted to make it really easy on me and get as much early input as he could get by sending a msg to the TLS list asking for comments [0]. Version -02 addressed those comments. I'm no babel expert, but I did take the time to read/skim the base protocol document to get more familiar with it as well as re-read the babel-tls draft. The tl;dr here is that babel is multicast but DTLS is not so changes to babel are needed. Here are my comments in no particular order. No show stoppers here. 0) Since DTLS is in the RFC Editor's Abbreviations List - I think you can get away with: Babel Routing Protocol over DTLS But, that's up to you. 1) (IEGS food fight alert) I see that the updates header updates 6126bis. Not sure how this will fly in the face of the draft IESG Statement [1]. 2) (This might just be document organization) The applicability section kind of jumped out at me because there's also an applicability draft. Further, it and 6126bis says the HMAC mechanism is preferred. I'd just drop the entire section ;) 3) s2.1 - maybe add a pointer to the IANA considerations section. 4) s2.1 - Because you're doing client authentication do you need say anything about the type of cert, whether certificate_authorities, signature_algorithms_cert, signature_algorithms should be sent (for 1.3 connections)? 5) s4 - add that IANA is requested to point to this specification for the reference. 6) AppA - I think you might need to tweak the last sentence in light 1.3? Cheers, spt [0] https://mailarchive.ietf.org/arch/msg/tls/tIaK0rgm5zCVuYmLm5qsCIvKXKw [1] https://mailarchive.ietf.org/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE