Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-information-model-11: (with DISCUSS and COMMENT)

"STARK, BARBARA H" <bs7652@att.com> Wed, 03 February 2021 22:31 UTC

Return-Path: <bs7652@att.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 B90673A085E; Wed, 3 Feb 2021 14:31:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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=att.onmicrosoft.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 KlJpHsSVfcnI; Wed, 3 Feb 2021 14:31:40 -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 00A093A0853; Wed, 3 Feb 2021 14:31:39 -0800 (PST)
Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 113MOBG3041139; Wed, 3 Feb 2021 17:31:39 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 36feudwcxw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Feb 2021 17:31:38 -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 113MVaaO006973; Wed, 3 Feb 2021 17:31:37 -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 113MVS5w006758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Feb 2021 17:31:28 -0500
Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 617014005C1F; Wed, 3 Feb 2021 22:31:28 +0000 (GMT)
Received: from GAALPA1MSGED2DB.ITServices.sbc.com (unknown [135.50.89.139]) by zlp30486.vci.att.com (Service) with ESMTP id EF6FF4005C22; Wed, 3 Feb 2021 22:31:27 +0000 (GMT)
Received: from GAALPA1MSGEX1AF.ITServices.sbc.com (135.50.89.101) by GAALPA1MSGED2DB.ITServices.sbc.com (135.50.89.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 3 Feb 2021 17:31:25 -0500
Received: from GAALPA1MSGETA01.tmg.ad.att.com (144.160.249.126) by GAALPA1MSGEX1AF.ITServices.sbc.com (135.50.89.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2 via Frontend Transport; Wed, 3 Feb 2021 17:31:25 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.174) by edgeal1.exch.att.com (144.160.249.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2176.2; Wed, 3 Feb 2021 17:31:14 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gzaHYKSUTiqaEzE0sdVjkKUtpLMe6HsYWY1zTUE5S26F9/PYuJsJcK5AmzSzgSuxANK2Z9xgcu09oJMlTAKITHYgSdSWsexzWXJNseaSLlTznBq7FEPjzh4imb0Wmdaq+17udCD4Lw8oKoRcSHwhCGNdXyxAd3PUdwQ2Z9UyfJjpBsNEtnh0rgNpSMcfzLFexafVvxVX02p5wwJOqG2CyCRJW4MiFCBzAG+GcEaLiAG6ZVy4n+iCukdXsHPFXekqhmR72HnF5UoAJnje2uxVWT1uUFKBYqrBdngP2Z0VIj58fYGrrZinVxpYJS4IRLLqX0ESJhYLTw2R03pHC2MaFA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VKDuPJzNMr7lPFlOHZXCaGwpHtl9lJBnDe3VEaJbkyA=; b=IBmSf08V3Saw9jW9JHp/z8gBnMnhjs91Tz5Lo7Ek3nOlB+NdQt1ECA3J6v5iHiT9sJ8CBDlJXcV/3iF4oLXQUnaZl+tasD9d4ns40+Jq1kDIYrYTT9H2cq1PwswO5CJRFmKbdpYxTYU4yEcr3rWVXHPs8Lk81lM5fT+YcjeT5M5lREHWBm6eKcAJSxQAdbx2HS/kBvC30LFyv8zxgpMKVDkFAnmkVUFbYQ4zJ+htf2H+pt8jJ/K8CvnWjDCld8mf/fSBl+rCCdbkAGjYPTMSfMTuTnUZ8LLSU5xX2aR+0AaYAka516Cjym6c3qZW+Z00wdHtvNRVghq8oXIoG3llKQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VKDuPJzNMr7lPFlOHZXCaGwpHtl9lJBnDe3VEaJbkyA=; b=e5rXCfkfNC9IEGeQbYdXfOtBpiz8KYPQ6Y+YV3RimrwPpXnTwFVqzZFgMkQDiz9NJ8+FEPMoW+J5naDVQdkorcsykyWk5p0p3F0ncqrWl6Vt85UmYvcMwUY2cDx8u/YH8eHInRAoWSQ08c2hEl14C/tHZpUeq89IEDKk9mLryMk=
Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB6011.namprd02.prod.outlook.com (2603:10b6:5:156::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.17; Wed, 3 Feb 2021 22:31:13 +0000
Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::c515:1a0e:1ac1:d809]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::c515:1a0e:1ac1:d809%6]) with mapi id 15.20.3805.028; Wed, 3 Feb 2021 22:31:13 +0000
From: "STARK, BARBARA H" <bs7652@att.com>
To: "'Benjamin Kaduk'" <kaduk@mit.edu>, "'The IESG'" <iesg@ietf.org>
CC: "'babel-chairs@ietf.org'" <babel-chairs@ietf.org>, "'d3e3e3@gmail.com'" <d3e3e3@gmail.com>, "'babel@ietf.org'" <babel@ietf.org>, "'draft-ietf-babel-information-model@ietf.org'" <draft-ietf-babel-information-model@ietf.org>
Thread-Topic: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-information-model-11: (with DISCUSS and COMMENT)
Thread-Index: AQHWsXWjpHz8bjw21kuCQu2IvFzP6am4p/pggI6+9zA=
Date: Wed, 3 Feb 2021 22:31:12 +0000
Message-ID: <DM6PR02MB6924227133396A388EECD9D0C3B49@DM6PR02MB6924.namprd02.prod.outlook.com>
References: <160436211925.31069.7931310164710901437@ietfa.amsl.com> <SN6PR02MB4512CEC73FF751E20D7A64F1C3CC0@SN6PR02MB4512.namprd02.prod.outlook.com>
In-Reply-To: <SN6PR02MB4512CEC73FF751E20D7A64F1C3CC0@SN6PR02MB4512.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=att.com;
x-originating-ip: [45.18.123.63]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d6524626-db78-4701-a328-08d8c893699e
x-ms-traffictypediagnostic: DM6PR02MB6011:
x-microsoft-antispam-prvs: <DM6PR02MB6011006F578003B7CE2AAE56C3B49@DM6PR02MB6011.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: inly4+G5Ve6CwnofY20H3u+EAFkPQkFs7TT+WGZW+qoRhELhK2InLpDDnzGTqudaP7QBmq+i1CXTLx8e9g6hVyRQ+dfCdWmTmoHqJFXYDtk2Bzmnm5L44jTiQzaVuVVHTmK9vHhmUIB2+mbgDejXipwiYa0SkgDl4xz5Oz+vPK5eA+2XYbMAgIvc8hCb4D2Zhdk88bEQVMBnzV9B7W182IGfuB7n2qeRUutRYlDo3zyl8VtbwuOtIp2HDC7Uj/R/JS2IzmUUcq9huBoeVspgP3hnrt1dU0qBvssDSbZJuT2nsDFc/MBuLeIHZTPO1VpO4+wwErRPrPOzkSSWohyT3JYPYxB/1oBUZA+dxm6UwSIkvUx236WlLmDi5fesdtf7K8I6MFVPpbF3NxsS43ilGCMbMp8UAT0nsIPZ95wd6B5j3VWySqJI6O/ICcXU3K2n4QhaBEecm604cLmv491r21qvSNUnggrIS+R9229bT6fS/81RazTHwHW7oP9pj9ebCQ033K+ly9yMDi3SlO8hsUFWzOjOrquMuclpeBzAHFQ32tOmvWbvS+vKHQr9+Qsxqi7COjk+/4JzI93CnVH92/EgBSDyzwNv4xxi0FRSeJc=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(396003)(136003)(346002)(39860400002)(76116006)(55016002)(9686003)(66574015)(86362001)(71200400001)(8676002)(2906002)(83380400001)(110136005)(66946007)(66476007)(316002)(54906003)(478600001)(66446008)(64756008)(966005)(6506007)(4326008)(30864003)(52536014)(66556008)(5660300002)(82202003)(186003)(7696005)(26005)(33656002)(8936002)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?ZllOV3hXRmhSUkluU1U5RnUwaE5yMG9EWnFrZVNkM01JaHZ4VHlITCtqLzBu?= =?utf-8?B?SElaQTA5VW42T0ZyWFhmMzJpMG5VZXRLY21WTWxkTnQyVWthRGhLYjZzZlVG?= =?utf-8?B?RFNodEZwTk1tYmlURCtYMDF5c1ROV0pQMy9kOTJBdlZBV1J1OTVuV1k2SEdQ?= =?utf-8?B?WnZQdmdNRkJrOUl1SEVyNnBpUjk5QmJxNk9sS2ZCUFhscFRqdjRiQkJlSi8x?= =?utf-8?B?eTRmbTJlbFFYcnZ4TGF2bmJDcUFMUGs0dnVhaTk1blBMVGlBMjYycTBqR2Nr?= =?utf-8?B?b0YxRHVzb2lwR3pWbjZxcE1iZE5CTlpvNmcxUTBSZUtCMnBzbk1qV2VkZjZw?= =?utf-8?B?M3piYm14dlNzR25TS3FSaDVWd3ZmM1FRRXJ2RktDdjR1bGl6ZkwrNlhXcmVN?= =?utf-8?B?SVpoOEcyY1dtenRYclFvRkdRMmRtSXlTbVZuSXNWb1lwRnJRV3QzZU9URkJP?= =?utf-8?B?QUQxWjRTbVZhYjk4enRCa0ZSNlNjM2NoaXNwaTFucWxlKy80OEJJempjOSsv?= =?utf-8?B?THU1Q2ZpZVFKTW1ha1FCdTdFczhPYWRlcUNhVnJxQ013SGNHQUljWXRYaU5w?= =?utf-8?B?MnRabStmcEd2K1BpWDJPWm1Edjc3TFhTNy84QVJSanZQTnpzYkdIMGtRWFdJ?= =?utf-8?B?eURCNzEwUE5oNU9rTTArMzlPY2tyNTdFdUpyd2MrSUNZTmE4b2tGZXA1UzhW?= =?utf-8?B?MmdFL0ZhMVFOMTVuQWFwdFBUdllIQWoxUjB5QSsxYzhnRGY2UnlMTHN4Yy9m?= =?utf-8?B?QVJ2NHBvRGxiV3JyTGl1OTV5dWxjNVRFeWNUVGpLSXFYdU52dkJwNDdBYlpj?= =?utf-8?B?TXg2Z1U5NnFCZ0NTdUtFY2VhdGM2Y0ZPa2x0M1VRQWROSllWUWxFbFNGYnlq?= =?utf-8?B?ZFZVTmJXenBTSEtVNVdUME5mRWNJWHRaMmFRSW9rcEUwU1lPa3FEU0dGSTFR?= =?utf-8?B?THdsZDVBbGVpYmZhYktHWWFjN0poYm02eTBoU1lNNDRHQnFLcXh2U1hDVWZP?= =?utf-8?B?bDNpcWFoYVMwdURVdTFmajN6aUs1UUFuQ2lGUDZoZDc3dGRnc2RqWkN5ZDdv?= =?utf-8?B?dTE5VmtyWDBFeXZOVUJDZ2Rka0wrU0x5VTNubFRQd1lZQ3dGYUZ3RVRlWFdT?= =?utf-8?B?czRBb1AwQmJmNGtKaFFCL2M2RWNBM3hCN1J1UHBZTVFwZm16NXRXcFpkNU1n?= =?utf-8?B?Y2xaeWNYcFB5NFpoYUNiSjN1MkllbVVTejFWbXF2OGE4dXg5OVpBMG5JQjMy?= =?utf-8?B?bnpwZlo1aFpuc2h4QjhkbFNPa1U3cUFTcXlBR1dZTXdta2FMQWdZbitaUnY5?= =?utf-8?B?YjdvU2txTkFUTWRvS3BCOEM3SDR1Umljclp5QnpWS3ZWY29CR2Rzc3RZRnc1?= =?utf-8?B?dU1kbmFRY210SXVPMjR6TktHYkoxMTZkRGZLOTBMb2JrejBEMStBZklvME5t?= =?utf-8?Q?P82PlLGS?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d6524626-db78-4701-a328-08d8c893699e
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2021 22:31:12.9611 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: M/vcBuwY/lKrjkmPkL6dxUkSnmnJxIpd79dS+jy5fm/CVmarRoyWLZ1DkVz63QW3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6011
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: 95A72D600F7903CDF9DAFFAA994E70741E7926E327F87180A55345AD6D7B3A0E2
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-03_09:2021-02-03, 2021-02-03 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 mlxlogscore=999 clxscore=1011 suspectscore=0 bulkscore=0 impostorscore=0 adultscore=0 spamscore=0 lowpriorityscore=0 mlxscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102030136
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/slV-ftIoARBH_0hbTFOy7Lvyp3M>
Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-information-model-11: (with DISCUSS and 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." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2021 22:31:45 -0000

Hi Ben (and IESG),
I just wanted to mention that I did publish a -12 draft that I think resolves all comments (in the manner I said I would in my various responses). 
https://tools.ietf.org/html/draft-ietf-babel-information-model-12
Looking forward to getting these Discusses cleared... 😊
Thx,
Barbara

> Hi Ben,
> Thanks a bunch for your comments. I'm sorry it's taken me a few weeks to
> provide a response. But, well, NomCom... 😊
> And I wanted to give these comments the full attention they deserved.
> Barbara
> 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Section 2 says that the "DTLS certificate values" are required to return
> > no value when read, but this property seems to be intended for private
> > data such as DTLS private key values, not the certificates themselves
> > (which are public).
> 
> Thanks. I agree and suggest in Section 2, changing "DTLS certificate values" to
> "DTLS private keys" (which are required to return no value when read).
> 
> > While I appreciate that IPv6 is the current version of the internet
> > protocol, I do see that 6126bis allows for Babel to run over both IPv6
> > and IPv4, yet this document in multiple places implicitly assumes that
> > Babel runs over IPv6, to the exclusion of IPv4.  Such a restriction from
> > the core protocol spec should only be undertaken by an information model
> > with clear reasoning and loud disclaimer.
> 
> The WG did discuss this and expressed the view that they were only interested
> in defining configuration for Babel over IPv6. Note that use of Babel to
> configure
> IPv4 routing tables can be done over IPv6.
> 
> Perhaps if we added to the Abstract <Juliusz: please look at this and provide
> suggested changes>:
> "This information model only includes parameters and parameter values
> useful for managing Babel over IPv6.
> This model has no parameters or values specific to operating Babel
> over IPv4, although Babel can be operated over IPv4.
> Note that Babel over IPv6 can be used for configuration of both
> IPv4 and IPv6 routes."
> 
> and then expand on this in the Introduction with
> "This information model only includes parameters and parameter values
> useful for managing Babel over IPv6.
> This model has no parameters or values specific to operating Babel
> over IPv4, even though [ID.ietf-babel-rfc6126bis] does define a multicast
> group for sending and listening to multicast announcements on IPv4.
> There is less likelihood of breakage due to
> inconsistent configuration and increased implementation simplicity
> if Babel is operated always and only over IPv6. Running Babel over IPv6
> requires IPv6 at the link layer and does not need advertised prefixes, router
> advertisements or DHCPv6 to be present in the network. Link-local IPv6 is widely
> supported among devices where Babel is expected to be used.
> Note that Babel over IPv6 can be used for configuration of both
> IPv4 and IPv6 routes."
> 
> > Similarly (as Roman notes), we are putting requirements on the key
> > length for MAC keys (relative to the block size of the underlying hash
> > function) that have were once present in draft-ietf-babel-hmac but have
> > been removed as of draft-ietf-babel-hmac-10.  I assume that the intent
> > is not to impose additional restrictions compared to the protocol spec,
> > thus we need to catch up to those changes.
> 
> How humans interact with configuration parameters presented through
> a data model instantiation of this information model is a concern. Having
> experienced the horrors of the days of configuring WEP keys (which were
> either ASCII or hex and caused most people not to use WEP with Wi-Fi)
> and witnessed (and been party to) the discussions in
> Babel where we wanted to ensure that whatever string was inputted for
> the key would yield consistent MAC computation across all implementations
> (i.e.,
> would yield consistent "actual key"), I believe
> it is imperative for the information model to constrain the input. As I explained
> in my response to Roman and Valery, we saw considerable variability in
> how existing libraries for allowing users to supply a key value treated
> values that could not be directly used as what RFC 2104 calls "the actual key".
> To ensure human users are successful in supplying the same "actual key" value
> to various
> implementations, it's necessary for user interfaces to restrict what is
> supplied to be "the actual key" so no extraneous hashing and processing
> is needed to generate "the actual key" (other than adding zeroes if the input
> key is shorter than an "actual key").
> 
> The restrictions provided for the length of an input key are consistent with
> what the HMAC and BLAKE RFCs indicate for "actual key" length.
> 
> This allows implementations of draft-ietf-babel-hmac to use existing HMAC
> and BLAKE2s libraries without worrying about what inconsistent manipulations
> the libraries or associated libraries for inputting keys do to strings that are
> too long to be directly used as "actual keys".
> 
> > The description of the babel-mac-key-test and babel-cert-test operations
> > need to be tightened up, as the secdir reviewer noted.  (See COMMENT.)
> 
> I think the secdir comments from Valery have been resolved.
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/secdir/V_SK
> LuCuLdwvCDhABW-
> G2kkgRHM/__;!!BhdT!zVTbztfx1uQdw1QWaVSRoJpTOpw1XfAP7LOUxbeJ9rcLXe
> V-GmWLYZzG81V3Sb0x$
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/secdir/_FX7
> GJpGDhMxBN1Ps0_opo2mn68/__;!!BhdT!zVTbztfx1uQdw1QWaVSRoJpTOpw1X
> fAP7LOUxbeJ9rcLXeV-GmWLYZzG84l2CSUL$
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/secdir/eSC-
> 7ApMvv0CulyawvA0AILB59w/__;!!BhdT!zVTbztfx1uQdw1QWaVSRoJpTOpw1XfA
> P7LOUxbeJ9rcLXeV-GmWLYZzG8y_rmrGw$
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/secdir/90Yc
> yVcS90Ya449tT0Zibc6Fb9o/__;!!BhdT!zVTbztfx1uQdw1QWaVSRoJpTOpw1XfAP7
> LOUxbeJ9rcLXeV-GmWLYZzG8-863vKO$
> 
> Summary: Remove babel-cert-test; use "MAC" instead of "hash" in
> babel-mac-key-test description.
> Please let me know if you disagree with this resolution.
> 
> > We seem to be using terminology from the Network Management Datastore
> > Architecture without reference or otherwise introducing the concepts.
> > This is a Discuss point because the only candidate reference I know of,
> > RFC 8342, is specific to YANG and data models, so it's applicability for
> > use in an information model may be subject to discussion.  (Hopefully
> > this only reflects my ignorance and not a fundamental lack of datastore
> > architecture for information models.)
> 
> I'm still a YANG novice. My experience is with BBF TR-181 data models.
> I do have a TR-181 data model of this info model that will be published
> after the info model is published. I also considered the UIs created by the
> Babel protocol implementers to effectively be implementations of the info
> model. But of these, YANG does appear to be unique in maintaining distinct
> representation of operational and running configuration datastores.
> In researching the terminology
> (see
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/babel/Ze2E
> tZEidcE7t2WMF2EqblBJN7I/__;!!BhdT!zVTbztfx1uQdw1QWaVSRoJpTOpw1XfAP
> 7LOUxbeJ9rcLXeV-GmWLYZzG89hknV3y$
> reply to Robert Wilton),
> it appears to me that "operational datastore" and "datastore" are terms of art
> defined
> in techopedia.com without reference to YANG. The dates on those definitions is
> 2013,
> which predates RFC8342. "Running datastore" was used in RFC6241, which also
> predates RFC8342. As I mentioned in my reply to Robert Wilton,
> I don't think a normative reference to RFC 8342 is appropriate for what appear
> to be
> terms of art. There is no terminology section in the babel-information-model
> draft, and I'm not keen on adding a terminology
> section to the draft just for these 2 terms of art.
> But I would do that (and maybe find a few other terms of art to include
> so they don't seem out of place), if people really felt it necessary to define
> these.
> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 1.1
> >
> > Please use the specific RFC 8174 boilerplate (in particular, it includes
> > "NOT RECOMMENDED").
> 
> Thanks. I'll make that change. (This was also a comment from Barry.)
> 
> > Section 2
> >
> > We have separate MAC/DTLS-enablement nodes at a per-interface
> > level, so not having them at the global level is perhaps suprising.
> 
> This was discussed, IIRC, and the WG wanted it at the per-interface
> level only. In addition to the YANG and TR-181 data models, I
> considered the implementation user interfaces to also be instantiations
> of this information model. So many decisions were made based on what
> they found reasonable when implementing their UIs.
> 
> > I'm happy to see babel-dtls-cert-types, given that the babel/DTLS spec
> > leaves much open as to how to authenticate peers.  Even more specificity
> > could be useful.
> >
> >    Most parameters are read-only.  Following is a descriptive list of
> >    the parameters that are not required to be read-only:
> >
> > It's suprising to not see router-id on this list; 6126bis says only that
> > "every Babel speaker is assigned a router-id" without saying how.  In
> > the absence of a "how", it seems reasonable to assume "assigned by the
> > administrator" as a valid option.
> 
> The WG discussed this. There are two points here. First is that the self-router-id
> is useful as a unique key in YANG. But in that case, the value needs to exist and
> be
> immutable when the Babel object is created in the system. Second is that
> Babel users do not care about the value of the router-id; therefore it's
> easiest simply to auto-generate it.
> 
> > How do I configure which prefixes to advertise as originated from this
> > router?  Do I just add something to the babel-routes list with NULL
> > received metric?  But if that's how I do it, then the babel-route-obj
> > can't be 'ro'...
> 
> Section 3.7 of draft-ietf-babel-rfc6126bis indicates that a Babel
> implementation has the ability to advertise and provide updates
> for routes injected into the Babel domain by the local node. I
> believe the Babel implementation interacts with the device's
> "real" routing table to identify these routes (and to update
> that routing table). Since this is all handled by the implementation
> without user interaction, perhaps Juliusz could better explain,
> if necessary.
> 
> >    o  Interface: Metric algorithm
> >
> >    o  Interface: Split horizon
> >
> >    o  Interface: enable/disable Babel on this interface
> >    [...]
> >
> > It might be useful to list these in the same order as they appear in the
> > tree diagram.
> 
> Thanks. I will put them in the same order as in the object definition
> (which is the same as the tree diagram, but the object definition is
> normative if there were to be a difference).
> 
> >    o  Interface: MAC algorithm
> >
> > What node in the tree does this correspond to?
> 
> Thanks. I'll delete "  o  Interface: MAC algorithm".
> It's an unfortunate vestige of earlier revisions.
> 
> > Section 3.1
> >
> >    babel-enable:  When written, it configures whether the protocol
> >       should be enabled (true) or disabled (false).  A read from the
> >       running or intended datastore indicates the configured
> >       administrative value of whether the protocol is enabled (true) or
> >       not (false).  A read from the operational datastore indicates
> >
> > Perhaps it's just me, but running/intended/operational datastores feels
> > like a YANG/NMDA thing and is surprising to see in a nominally generic
> > information model, absent further reference.
> > (Similarly for subsequent usage of the terms.)
> 
> This was language we added as a comment from Mahesh to make his
> creation of the YANG model straightforward. It's not inconsistent with TR-181
> concepts. But this is an area where TR-181 and YANG do things a little
> differently. Language compromise was necessary. I will rely on Mahesh
> to take a first stab at proposing any changes, and will simply make sure
> what I need for TR-181 is still there. I do recommend against a NMDA
> reference, since my research suggests these are terms of art.
> 
> >    babel-self-router-id:  The router-id used by this instance of the
> >       Babel protocol to identify itself.  [I-D.ietf-babel-rfc6126bis]
> >       describes this as an arbitrary string of 8 octets.  The router-id
> >       value MUST NOT consist of all zeroes or all ones.
> >
> > Why is the MUST NOT a requirement of the information model rather than
> > the protocol?
> 
> Because it isn't an issue for a Babel implementation that doesn't implement
> this information model. It only became an issue when the YANG model
> needed to use this as a unique key and needed the object to exist whether
> or not Babel was enabled. In the absence of YANG, a disabled implementation
> is happy for its router-id to be all zeroes.
> 
> >    babel-metric-comp-algorithms:  List of supported cost computation
> >       algorithms.  Possible values include "2-out-of-3", and "ETX". "2-
> >       out-of-3" is described in [I-D.ietf-babel-rfc6126bis], section
> >       A.2.1.  "ETX" is described in [I-D.ietf-babel-rfc6126bis], section
> >       A.2.2.
> >
> > Perhaps this is just me, but the way this is written implies that the
> > specific string values are to be used, which may be overly prescriptive
> > for an information model.  Also, is there a registry for these
> > algorithms that could be referenced?
> 
> There is not a registry. The algorithms an implementation supports
> do not impact interoperability of Babel. Therefore, there is no need
> for a Babel implementation to only use algorithms from some registered
> list. Which makes a registry unnecessary. If an implementation supports
> these algorithms loosely described in
> ietf-babel-rfc6126bis, then using these strings to identify them
> will make that clear to a user (which is good for usability). It's not
> required for a data model to use these exact strings (a human is unlikely
> to be confused by an implementation that uses "2 out of 3" instead of
> "2-out-of-3", but, not surprisingly,
> both the YANG and TR-181 data models are using these exact strings.
> 
> >    babel-security-supported:  List of supported security mechanisms.
> >       Possible values include "MAC" and "DTLS".
> >
> >    babel-mac-algorithms:  List of supported MAC computation algorithms.
> >       Possible values include "HMAC-SHA256", "BLAKE2s".
> >
> >    babel-dtls-cert-types:  List of supported DTLS certificate types.
> >       Possible values include "X.509" and "RawPublicKey".
> >
> > Likewise, are there registries for these?  (D)TLS does have an existing
> > certificate types registry
> > (<url munged by email system>
> > is the one to use), but for the MAC algorithms that's pretty inherently
> > a very flexible extension point so it's easy to add a new algorithm with
> > no or a very minimal written spec.
> 
> Per other commenters, I will be adding references to these to
> draft-ietf-babel-hmac and draft-ietf-babel-dtls.
> The babel hmac draft has normative language for the two mentioned.
> The babel-dtls draft inherits from DTLS, which inherits from TLS
> "The certificate type MUST be X.509v3 [RFC5280], unless explicitly negotiated
> otherwise"
> -- so there's an expectation that X.509(v3) certs will be commonly supported.
> babel-dtls also explicitly mentions that raw public keys "can" be supported.
> The MAC algorithms and types of certificates supported are determined by
> by the implementations of babel-hmac and babel-dtls. Those implementations
> will need to expose to the data model (by some sort of API, most likely) which
> are supported. The values used may be the values exposed, or they may be
> mapped
> from exposed values to values used by the data model. The information model
> cannot constrain values exposed to it by APIs.
> The problem with using the TLS Certificate Types registry names is several of the
> names
> have spaces, which makes them unusable in TR-181. It's not required for
> an instantiation of this info model to use these "possible" values; but, again,
> both the
> YANG and TR-181 do. By listing them this way (as possible values, not using
> normative language), we achieve consistency where
> it makes sense and is useful without preventing deviation in some case where
> it may not be useful or make sense.
> 
> > Section 3.2
> >
> >    babel-mcast-group:  Multicast group for sending and listening to
> >       multicast announcements on IPv6.  Default is ff02::1:6.  An
> >
> > IIRC the core protocol only has it as RECOMMENDED for control traffic to
> > be over IPv6; the "on IPv6" here seems unnecessarily limiting.
> 
> This was what the WG wanted but is related to your 2nd DISCUSS item (and
> my proposed resolution to that).
> 
> > Section 3.3
> >
> >    babel-interface-reference:  Reference to an interface object that can
> >       be used to send and receive IPv6 packets, as defined by the data
> >
> > [again the implicit IPv6 requirement]
> >
> >    babel-mcast-hello-interval:  The current interval in use for
> >       multicast Hellos sent on this interface.  Units are centiseconds.
> >       This is a 16-bit unsigned integer.
> >
> > Perhaps it is better to discuss that the units need to have sufficient
> > precision to represent centisecond granularity rather than to enforce a
> > specific unit and constrain data models/implementations.
> > (Similarly for other mentions of units.)
> 
> This value is the exact value sent via the protocol. The centisecond unit
> of the sent value is specified in draft-ietf-babel-rfc6126bis. I believe it
> would be a bad idea to manipulate the sent value so it is presented to users
> with a unit different from the unit of the sent value. Having the info
> model provide flexibility that does not exist in the Babel protocol would
> add unnecessary complexity and cause potential confusion.
> 
> >    babel-dtls-cached-info:  Indicates whether the cached_info extension
> >       is included in ClientHello and ServerHello packets.  The extension
> >
> > Please reference RFC 7924 here.
> 
> I would prefer to reference draft-ietf-babel-dtls, which in turn references
> RFC7924, because draft-ietf-babel-dtls describes allowed use of this extension.
> 
> >       is included if the value is "true".  An implementation MAY choose
> >       to expose this parameter as read-only ("ro").
> >
> > I wonder if we can/should give a bit more guidance on what to include in
> > the extension, as currently it would be compliant with this spec (but
> > not very useful) to emit a cached_information extension that is highly
> > unlikely to result in any packet size savings.
> 
> Possible use of this extension is described in draft-ietf-babel-dtls Appendix A.
> I don't think the information model is the appropriate place to provide
> implementation guidance for this extension. draft-ietf-babel-dtls would
> be the correct place for any additional implementation guidance. I think
> draft-ietf-babel-dtls is currently in the RFC Editor's queue.
> 
> >    babel-dtls-cert-prefer:  List of supported certificate types, in
> >       order of preference.  The values MUST be among those listed in the
> >       babel-dtls-cert-types parameter.  This list is used to populate
> >       the server_certificate_type extension in a Client Hello.  Values
> >
> > An RFC 7250 reference is probably in order.
> 
> I would prefer to have a reference to draft-ietf-babel-dtls. That is
> where the certificate types for a Babel DTLS implementation are
> discussed. draft-ietf-babel-dtls does reference RFC7250. An
> understanding of RFC7250 is not necessary for implementing
> this information model or any data model derived from it.
> 
> >    babel-packet-log:  A reference or url link to a file that contains a
> >       timestamped log of packets received and sent on babel-udp-port on
> >       this interface.  The [libpcap] file format with .pcap file
> >       extension SHOULD be supported for packet log files.  Logging is
> >
> > Does there need to be a mechanism for content-type
> > negotiation/indication?
> 
> The format for this optional log was discussed by the WG. After
> considering a variety of ways to proceed, this was the agreed outcome.
> Adding content type negotiation would add unnecessary complexity,
> since it's unlikely that an implementation would support more than one
> content type.
> 
> > Section 3.4
> >
> > Shouldn't these all be 'counter's, not 'uint's?
> 
> Hmm. Interesting.
> It looks like I introduced "counter" as a (potential) base type in the -01
> draft (when I was sole author and there were no statistics yet defined). I
> just took all the data types in RFC8193 that looked like they might prove
> useful at some point.
> It appears to be a vestige of that early draft stage that never got used.
> uint is perfectly suitable from an info model perspective. Of course,
> a data model can use a more specific datatype derived from uint, that
> is specially designed for counted statistics.
> I suggest deleting the "counter" data type, but will check with Mahesh
> just to be safe.
> 
> > Section 3.5
> >
> >    babel-hello-mcast-history:  The multicast Hello history of whether or
> >       not the multicast Hello packets prior to babel-exp-mcast-hello-
> >       seqno were received.  A binary sequence where the most recently
> >       received Hello is expressed as a "1" placed in the left-most bit,
> >
> > This seems to indicate that the leftmost bit is always '1', and thus
> > that we cannot be in a situation where we missed one expected multicast
> > hello and are already expecting "the one after it".  Is that correct?
> 
> Yes. An implementation won't know it has missed one until it receives a Hello
> with a non-sequential sequence number. The number of missed packets
> is derived from the difference between the sequence numbers of 2 received
> packets. One of the implementations provided the history in this manner and
> found it to be a very simple way to present this information. It proved useful
> as a diagnostics tool. So the WG agreed to put it in the info model as an
> optional element.
> 
> > Also, should we say anything about truncating the bitstring at some
> > arbitrary point?
> >
> > (Similarly for the unicast case, on both counts.)
> 
> This was discussed by the WG. The implementation that provided the
> history in this manner used 16 bits. But it was decided not to constrain
> a data model or implementation that might want to allow more bits to be
> stored. So the maximum number of history bits stored is left up to the
> data model and the implementation.
> 
> >    babel-exp-ucast-hello-seqno:  Expected unicast Hello sequence number
> >       of next Hello to be received from this neighbor.  If unicast Hello
> >       packets are not expected, or processing of unicast packets is not
> >       enabled, this MUST be NULL.  This is a 16-bit unsigned integer; if
> >
> > (We haven't defined "NULL" semantics yet.)
> 
> I'm unclear as to what sort of semantics are needed? In discussing this
> verbiage in the context of terminology that would work for TR-181 and
> YANG, we figured out we needed to ensure there was a distinction between
> seqno of all zeroes (an allowed value) and no reception/expectation of
> unicast packets. How this is done in YANG and TR-181 is very different.
> So it's important not to over-define the semantics of "NULL".
> 
> > Section 3.6
> >
> >    babel-route-neighbor:  Reference to the babel-neighbors entry for the
> >       neighbor that advertised this route.
> >
> > Wouldn't that make this a "reference" type rather than "string"?
> 
> Yes. I'll make that change. Thx.
> 
> >    babel-route-seqno:  The sequence number with which this route was
> >       advertised.  This is a 16-bit unsigned integer.
> >
> > Is this text correct for locally originated routes?
> 
> Yes. The babel-route-obj allows read-only access to useful parts of the Babel
> "Routing Table" described in draft-ietf-babel-rfc6126bis. Parameters that an
> implementation includes in the Babel "Routing Table" are defined there. This
> Babel "Routing Table" must not be confused with a device's routing table
> that would be maintained external to a Babel implementation.
> 
> > Section 3.7
> >
> > I don't wish to revisit the decision, but it might have been interesting
> > to record some of the reasoning for having an additional abstraction for
> > "key set" and having a list of key-sets, vs just having a list of keys
> > directly.  (Similarly for the DTLS cert sets.)
> 
> There were requirements that it be possible to use different keys for
> different interfaces, the same keys for a set of interfaces, the same
> keys for all interfaces, and have a default set of keys in case a new
> interface were instantiated (e.g., a tunneled interface). Also, there
> was a requirement that it be easy to change the current key by first
> adding the new key and then removing the old key. By having key sets,
> it was easy to do a key change without explicitly adding the new
> key to and deleting the old key from each impacted interface. Only
> the key set needed to be updated. Ditto for certs. If this explanation is
> useful, I could add a paragraph explaining the sets as useful in making
> it easy to change keys/certs to Security Considerations. Ensuring usability
> of key/cert change is, I think, a valid security consideration.
> 
> > Section 3.8
> >
> >    babel-mac-key-use-sign:  Indicates whether this key value is used to
> >       sign sent Babel packets.  Sent packets are signed using this key
> >       if the value is "true".  If the value is "false", this key is not
> >
> > I agree with the secdir reviewer that the "sign" terminology is
> > problematic here, and would prefer something like
> > "babel-mac-key-use-generate" and a similar wording in the prose.
> 
> In email exchange with Valery, it was agreed to rename this to
> babel-mac-key-use-send.
> 
> >    babel-mac-key-value:  The value of the MAC key.  An implementation
> >       MUST NOT allow this parameter to be read.  This can be done by
> >       always providing an empty string when read, or through
> >       permissions, or other means.  This value MUST be provided when
> >       this instance is created, and is not subsequently writable.  This
> >       value is of a length suitable for the associated babel-mac-key-
> >       algorithm.  If the algorithm is based on the HMAC construction
> >       [RFC2104], the length MUST be between 0 and the block size of the
> >       underlying hash inclusive (where "HMAC-SHA256" block size is 64
> >       bytes as described in [RFC4868]).  If the algorithm is "BLAKE2s",
> >       the length MUST be between 0 and 32 bytes inclusive, as described
> >       in [RFC7693].
> >
> > [Per the Discuss, this key-length guidance is not aligned with
> > draft-ietf-babel-hmac.]
> 
> I defer to my explanation above (under the DISCUSS).
> 
> >    babel-mac-key-test:  An operation that allows the MAC key and hash
> >       algorithm to be tested to see if they produce an expected outcome.
> >       Input to this operation is a binary string.  The implementation is
> >       expected to create a hash of this string using the babel-mac-key-
> >       value and the babel-mac-key-algorithm.  The output of this
> >       operation is the resulting hash, as a binary string.
> >
> > s/create a hash of/create a MAC over/
> > s/resulting hash/resulting MAC value/
> 
> Thx. Will do.
> 
> > Given that the intent is to test the MAC operation, it seems like we
> > might want to say that the input string is treated as a babel packet,
> > getting the pseudo-header added per draft-ietf-babel-hmac §4.1, etc.
> > It would be in keeping with cryptographic best practice to continue to
> > use the same pseudo-header (and possibly even include a disambiguating
> > context string) to avoid the risk of being an oracle for generating the
> > MAC of arbitrary text that could then be used to forge other packets
> > elsewhere.
> 
> Since the entity that can use the test can also directly set the key, I'm not
> sure of the use case for an entity with management permissions to
> perform such an attack. But I agree that the test could easily be made
> more secure, so it's a good idea to do so. I've thought about your suggestion
> of treating the input string as a babel packet; but I think that gets very
> complicated because of the behaviors around packet counters and index and
> generation of pseudo headers (the management interface IP addresses and
> ports may be unknown to a Babel implementation and including IP headers in
> this test string makes it even more complicated). So the same code couldn't
> really be used).
> What if we had 2 inputs: the binary string and the expected MAC?
> Then the output would just be success (input expected
> MAC = calculated MAC) or failure. Would something like this be better?
> Alternately (though I would prefer it less), we could have the input string
> just be the expected MAC, where the binary string to generate a MAC for
> would be defined here. The string could be something simple like
> the concatenation of the registered Babel multicast group (ff02::1:6)
> and UDP port (6696).
> 
> > As the secdir review noted, the MAC output length is not necessarily
> > fixed by the algorithm, so some indicatino of the output length is also
> > in order.
> 
> The WG has discussed making 128 bits recommended for BLAKE2s
> (change will be made in AUTH48 to draft-ietf-babel-hmac) and
> the corresponding possible configuration value in this model will be
> "BLAKE2s-128".
> 
> > Section 3.10
> >
> >    babel-cert-name:  A unique name for this DTLS certificate that can be
> >       used to identify the certificate in this object instance, since
> >       the value is too long to be useful for identification.  This value
> >
> > Some guidance on whether or not it is expected to be useful to draw
> > naming information from the certificate's Subject information, vs an
> > arbitrary or fingerprint-based naming scheme, might be in order.
> 
> All constraints from an info model perspective are provided in the
> description: unique and not empty. An implementation that supports
> auto-generation of the name can use whatever rules it wants.
> My TR-181 data model will allow the user to provide any unique and
> non-empty string they want. If the user provides none, the
> auto-generation scheme is implementation-specific and common
> across the entire TR-181 data model (and not just Babel). I think it
> would be odd to explicitly call out the absence of additional requirements
> or expectations. Unless pressed, I will make no change here.
> 
> > Also, it's somewhat unusual to talk about "(D)TLS certificates" as
> > opposed to X.509 certificate, raw public key, etc..
> 
> The TLS RFCs refer to these things as "certificates" in all cases, and
> the IANA registry that lists defined types of these things is titled
> "TLS Certificate Types". This info model table is defined so it should be
> possible for other certificate types to be supported (if desired or
> implemented) with no change to this table structure -- so long as
> the certificate can be expressed in PEM format. If "DTLS certificate"
> is not acceptable, I could change to just "certificate". I don't want
> to constrain what type of certificate this table can support, beyond
> PEM format and for use with an implementation of draft-ietf-babel-dtls.
> 
> >    babel-cert-test:  An operation that allows a hash of the provided
> >       input string to be created using the certificate public key and
> >       the SHA-256 hash algorithm.  Input to this operation is a binary
> >       string.  The output of this operation is the resulting hash, as a
> >       binary string.
> >
> > This is problematic in several ways, as noted by the secdir reviewer.
> > For one, if we want to test a certificate, we usually would do that by
> > producing a signature, not a hash over the public key and some other
> > input.  Furthermore, not all the signatures produced by X.509 certificates
> > compatible with DTLS require a hash at all or are allowed to use SHA-256
> > within the signature operation.  It may be possible to require SHA-256
> > always by having the input to the signature operation be the SHA-256
> > output, which would then be hashed again during the process of computing
> > an (e.g., RSA) signature, but that is also a bit weird.
> > The purpose of the operation needs to be made more clear (is it to
> > verify the public key?  The private key?) as well as how the input is
> > structured; if the certificate private key is used to generate a
> > signature we must take care to avoid producing a signing oracle that can
> > be used to produce signatures valid in other contexts.
> 
> It was agreed (with Valery) to delete this operation.
> 
> > Section 5
> >
> > We do expose an operation to get a packet dump, but it's not clear that
> > there are particularly noteworthy security considerations regarding that
> > -- the dump would appear to be the ciphertext based on the language
> > used, so it would not be a way to bypass DTLS encryption, for example.
> >
> >    This information model defines objects that can allow credentials
> >    (for this device, for trusted devices, and for trusted certificate
> >    authorities) to be added and deleted.  Public keys may be exposed
> >    through this model.  This model requires that private keys never be
> >
> > It might be worth another sentence indicating the scale of the
> > consequences of erroneously/maliciously setting such credentials.
> 
> I'm not quite sure what to say? "Incorrect configuration of credentials
> (whether in error or in malice) will cause the Babel packets between
> the incorrectly configured router(s) and other routers in the network
> not to be trusted by each other. It will not be possible to effectively
> use Babel to determine and react to routing changes in the network,
> in this case."
> 
> >    exposed.  The Babel security mechanisms that make use of these
> >    credentials (e.g., [I-D.ietf-babel-dtls], [I-D.ietf-babel-hmac])
> >    identify what credentials can be used with those mechanisms.
> >
> > The DTLS one really doesn't, though -- it says only something like
> > "details of identity management are left to deployment profiles", and
> > there's a wide variety of DTLS credentials that are possible.
> > The MAC mechanism has a much clearer picture about what is allowed by
> > virtue of using the raw crypto primitive (though the allowed MAC
> > algorithms are negotiated out-of-band there as well).
> 
> Perhaps: "The keys used by a [ID:ietf-babel-hmac] implementation are
> modeled as private keys. Certificates used by a [I-D.ietf-babel-dtls]
> implementations use separate parameters to model the public parts
> (including the public key) and the private key."
> 
> >    algorithm associated with the key.  Short (and zero-length) keys and
> >    keys that make use of only alphanumeric characters are highly
> >    susceptible to brute force attacks.
> >
> > I don't think it's true to say that "keys that make use of only
> > alphanumeric characters are highly susceptible to brute force attacks".
> > Even if I stick to a 32-byte key, `dd if=/dev/random bs=1
> > count=24|openssl base64` is giving me 192 bits of randomness, which is
> > plenty for a modern security protocol.  I think you mean to say that
> > short keys are especially susceptible to brute-force when they only use
> > alphanumeric characters.
> 
> Perhaps simplify this to: "Short (and zero-length) keys are highly
>    susceptible to brute force attacks."
> 
> > Section 8.2
> >
> > Per
> >
> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/stateme
> nts/normative-informative-
> references/__;!!BhdT!zVTbztfx1uQdw1QWaVSRoJpTOpw1XfAP7LOUxbeJ9rcLXe
> V-GmWLYZzG80lrR5aI$  even
> > optional features like DTLS, MAC, RFC 3339 timestasmps, etc., should be
> > listed as normative references.
> 
> Thx. I'll be moving the following references from informative to normative:
> [I-D.ietf-babel-dtls]
> [I-D.ietf-babel-hmac]
> [ISO.10646] (Unicode character definition)
> [RFC2104] (HMAC)
> [RFC3339] (Timestamps)
> [RFC4868] (HMAC-SHA-256)
> [RFC7693] (BLAKE2s)
>