I'm afraid if we use "SHOULD", CPE vendors will follow the path so far followed, which is not building that option into their product.
I'd rather see a "MUST" to the automatic update functionality, but a "SHOULD" in regards whether it's turned on by default or not. Frank -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Fred Baker Sent: Tuesday, October 19, 2010 1:40 PM To: Operations; IESG IESG Cc: [email protected] Subject: Re: [v6ops] Fwd: I-D Action:draft-ietf-v6ops-cpe-simple-security-15.txt On Oct 15, 2010, at 3:40 PM, Brian E Carpenter wrote: >> I'd think that recommending having an option that disables unattended automatic update would address this concern. Managed service providers, since they'd be controlling the CPE, could go in and disable unattended automatic updates (if they so desire). > > I think the discussion has shown that we (the IETF) don't have consensus > and that legal and commercial requirements will vary enormously in the > real world. To me there's only one possible conclusion: the IETF can't > "legislate" on this. So again here is my suggestion: > > REC-13: > Residential Internet Gateways SHOULD provide a convenient means to > securely update their firmware, for the installation of security patches > and other manufacturer-recommended changes. I have been following this discussion with a view to figuring out what recommendations SHOULD be made :-) A key concern I have here, as I said last week, is the difference between a residential gateway and a laptop; A laptop's owner at least knows whether an irritating icon is jumping up and down or has the opportunity to see a dialog box; I don't see that happening with the router in my equipment closet under the stairs. It seems that we agree that there are at least two options that need support: - automated software update - manually initiated software update One could go into other mechanisms such as having the user download the new image to a laptop and then TFTP it to a router. Some things are best left unsuggested, for fear that the vendor might say "hey, that's a great idea!". In both cases, the update has to be initiated by the residential CPE, for scale and reliability, and if automated should be randomized in time for reasons discussed in RFC 3439. Having the ISP or the vendor manage a list of the IP addresses of deployed routers is (ahem) problematic. In both cases, we need a way to specify the URL and certificate of the download site. I should imagine the vendor would preconfigure them, and an ISP running managed services could configure a different URL+certificate in routers it deploys. There is of course the question of what happens should the parameter memory get zapped; I would leave that to the vendor. There is also the question of how the device knows whether it has already downloaded the image; I for one would do that by having the URL change itself, so that the client system ca always get access to an older image as a recovery path and so it can tell whether the image it is requesting is in fact new. In preceding recommendations, the format of the document is to state a recommendation and follow it with an explanatory note. Which brings me to this suggestion: /* * suggestion */ REC-13: Residential Internet Gateways SHOULD provide a convenient means to securely update their firmware, for the installation of security patches and other manufacturer-recommended changes. Vendors can expect users and operators to have differing viewpoints on the maintenance of patches, with some preferring automated update and some preferring manual initiation, and those preferring automated update wanting to download from a vendor site or one managed by the network operator. To handle the disparity, vendors are well advised if they provide manual and automated options. In the automated case, they would do well to facilitate pre-configuration of the download URL and a means of validating the software image such as a certificate. /* * end of suggestion */ Opinions? _______________________________________________ v6ops mailing list [email protected] https://www.ietf.org/mailman/listinfo/v6ops -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
