Thank you for the comments Éric. Edits have been added to: https://github.com/anima-wg/brski-cloud/pull/247/commits/9ff70cac6552dac5f0b2eba3b18f2446bcc8e203
> ## DISCUSS (blocking) > > As noted in > https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, > a DISCUSS ballot is a request to have a discussion on the points below; I > really think that the document would be improved with a change here, but > can be > convinced otherwise. > ### Abstract > > As this I-D updates RFC 8995, the abstract must mention this update (with a > one > line describing the update if possibe). Already added in https://github.com/anima-wg/brski-cloud/pull/246/files for Wicinski review. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > ## COMMENTS (non-blocking) > ### Missing privacy / operational considerations ? > As the Cloud and Owner are different organisation, I was expected to > read some privacy considerations: - the Cloud Registrar will see the > addresses (i.e., location) and devices count per Owner - the Owner > relies on the Cloud Registrar availability, i.e., it is a single point > of failure (the draft discusses briefly about bankruptcy but this could > be censorship as well) You raise two unrelated points here, and I want to tease them apart. 1. Privacy. 2. Availability. *Privacy* The Cloud Register(s), yes, will be potentially be operated by multiple organizations. Let me put some concrete names here, and let's say it's a Cisco IP Phone. Owen is still doing phones, I think, and co-author Rifaat was at Avaya when we started this. (I still have a 2003-era unit on my desk...) So the OEM is Cisco. They operate the first Cloud Registrar. a. They know, from Supply Chain information that they shipped the unit to AlphaTelecomCa.example's Canadian warehouse, so they 307 redirect to them. b. registrar.alphatelecomca.example (a VAR/partner) sees the request, and knowing they shipped that unit from the warehouse directly to an ip4bca.example customer, they redirect to registrar.ip4bca.example. c. registrar.ip4bca.example (a VAR/operator) recognizes that this unit was shipped to the bigblueshoesstore.example in Winipeg, looks for the deployment information, recognizes that it should be part of asterisk4325.ip4bca.example so it creates a voucher, and does an estdomain: asterisk4325.ip4bca.example The phone does EST with that server. So, yes, Cisco, AlphaTelecomCA and IP4BCA all know that the phone is at bigblueshoesstore's IP. They see the voucher request (inside HTTPS) so they know the serial number. No eavesdroppers will know the serial number, but they could probably do traffic analysis, especially if they are closer to bigblueshoestore to see all the transactions. Each step does learn about the intended destination of the phone. {I was the network architect at a ip4bca, ~15 years ago, and I built systems to try to cope with drop-shipments, and we couldn't do it, so all stock went to Anjou, QC, was onboarded and then sent to the customer. } In my experience, we would actively tell each layer of the supply chain where the phone was deployed for warantee reasons. Only, half the time, the information would get lost, ignored or entered wrong by some intermediate layer. I know sales channel people were annoyed when we tried to get it fixed. It mattered which province, because warantees/consumer protections are a provincial thing. So, in this case, I'm at a loss to say what further privacy concerns there are. The supply chain already knows, and if anything, the information provided is more reliable. Would it be useful for me to include something like the above. *Availability* It's true that failure of the *first* Cloud Registrar represents an availability concern. Section 5 _LifeCycle Considerations_ captures some of this vulnerability. If AlphaTelecomCa.example's Cloud Registrar dies then phones will not be able to bootstrap; however the OEM could redirect to another Cloud Registrar if they had further saleschannel information. If this VAR goes out of business, there will no further shipments from their warehouse, and if someone else acquires the stock, they will presumably have to communicate with the OEM around warantee and other things. If the HTTPS connection is censorsed, then nothing that uses HTTPS is going to work for onboarding. The owner will have to move to one-touch confirmation in a lab, and/or DHCP options that were used before. > ### Section 1.1 > The OEM definition is not really the usual one, but this is OK I guess > in this I-D even if the word 'created' looks weird in this context (why > not 'manufactured'). What is the usual definition? We can write "manufactured", but we have existing confusion/feedback that the "manufacturer" in MASA (RFC8995) is already poorly translated into *factory*, with the belief that a BRSKI MASA has to be operated by the Factory (in China) where the device was *manufactured*. > Missing "owner", does it mean the guy buying the phone (or...) or the > company operating it ? It is really an ambiguous and overloaded term. We now have: Owner: : The owner is the organization that has purchased the new device (the pledge). The device might be deployed in a network that the owner does not control. Owner Delegate: : The owner delegate is an entity distinct from the Owner that has been contracted to operate/manage the devices in question. For instance, an IT maintenance and support-desk company. > The word 'domain' is also under-specified as it can means several > things. RFC8995 defines Domain. I will list it as a term to import. > ### Section 1.2 > s/target use cases/use cases/ ? Changed to: if the Pledge is deployed in a network that does not include a local Registrar. > More important, as we are in 2025, why using DHCPv4 and no DHCPv6 ? One > author is even a RFC 8415 author... Please update the draft with DHCPv6 > reference. It is informational use of DHCPv4 as an example, therefore > this point is sadly not DISCUSS worthy. 1. sadly, nobody uses DHCPv6 to boot/configure phones :-) 2. I don't see a place where we say DHCPv4. Did you assume v4, when it said DHCP? :-) > Add an informative reference to `LDevID`. > ### Section 2 > Please expand `MASA` and provide a reference. It is mentioned in terminology, but I've expanded on first use. > ### Section 2.1 > Please add "Pledge operator" to the terminology as it is a little > unclear. > It is not enough to state `The Pledge must have an IP address so that > it is able to make DNS queries` suggest "The Pledge must have an IP > address and be capable to reach a recursive DNS server". Changed. > ### Section 2.2 > Suggest expanding `CSR` at first use. Done. > Should a reference be added to `IDevID` ? Done. > ### Section 3 > I find the flow of steps then ventilate by use case somehow difficult > to read. Probably too late to change but a flow by use case then steps > would have been easier to read. I think that there might be some subtly here around your use of the word "ventilate" that I don't understand. The pledge doesn't know which use case it is in, so the goal is to describe the process from the Pledge's point of view only. So a flow by use case would not help author a pledge, I think. > ### Section 3.1.1 > `which are typically` or "which MUST be" ? They don't have to be https:// or well-known, if we had something better. We don't have a scheme for starting with QUIC (and maybe never will). It's essentially a private matter within the manufacturer. > ## NITS (non-blocking / cosmetic) > ### Section 3.1.2 > s/link local IPv6 address/link-local IPv6 address/ done. > ### Section 3.2 > Add a reference to RFC 7231 for "Retry-After". done. > ### Section 3.2.3 > Like in section 1.2, we are still in 2025, so how does the proposed > solution compare to DHCPv6 ? Again, not seeing "DHCPv4" here, I see "DHCP" :-) > ### Section 3.3.1 > Should there be a bound to the number of redirects ? We already write: The Pledge MUST also have a limit on the total number of redirects it will a follow, as the cycle detection requires that it keep track of the places it has been. That limit MUST be in the dozens or more redirects such that no reasonable delegation path would be affected. since the Pledge has to keep track of all the places it has visited, to avoid loops, the limit might be about memory use. "dozen" is a number. VoIP phones likely have a few megabytes of ram so a dozen URLs shouldn't be a problem, but this could be used in class 2 (50KiB) or class 3 (100KiB) devices. How many redirects are needed would depend a bit upon the depth of the supply chain: manufacturers therefore would have some natural feedback mechanism if their limit was too low. > ### Section 4.2 > Is it a little unclear whether global/routable IP addresses are > included in `It MAY also be a local address that includes an IP address > literal including both IPv4 [RFC1918] and IPv6 Unique Local Addresses > [RFC4193]. `. Hmm. Yes. I've reworked that section slightly. > ### Section 8.1 > Isn't it a little scary/unsafe if a pledge upgrades its firmware > (potentially in a non secure way) and its trust anchors ? If the device has a way for firmware updates to occur in an unsecured way (TFTP of unsigned image or something like that), then I think the device is junk, and this document does not change this. OTH, getting to the latest (signed) firmware, before dealing with the Internet, is probably good. } For instance, the device could be } without a default route or NAT44, but able to make HTTP requests via } an HTTP proxy configured via DHCP.) I have removed this sentence, as there actually are no standard DHCP options (v4 or v6) to configure either HTTP proxies or SOCKS proxies. I discovered this while writing another document, and I was actually surprised.
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
