Hi Brian, I got your double comment, but I had made a response it on 8th Aug. I attached my response below in case.
Regards, Shoichi Sakane ________________________________________ From: Sakane, Shouichi ([email protected]) Sent: Saturday, August 08, 2009 10:50 PM To: Brian E Carpenter; [email protected]; General Area Review Team Cc: [email protected]; Tim Polk Subject: RE: Gen-ART LC review of draft-ietf-krb-wg-cross-problem-statement-04.txt Hi Brian, First of all, thank you for your taking time to review our document. We really appreciate your help. > 1) About 5.5. Client's performance > > > It > > takes 195 milliseconds to perform a TGS exchange with the on-board > > H/W crypto engine. Indeed, this result seems reasonable to the > > requirement of the response time for the control network. > ... > > Also, the delays > > can grow to unacceptable delays when the number of intermediary > > realms increases. > > This analysis seems incomplete. How do we know that 195 ms is OK and > that an unspecified time using intermediary KDCs is too big? There are > certainly some SCADA environments where 195 ms is like infinity, > and others where 20 seconds would be just fine. We explained DCS of the petro-chemical plant, not general SCADA. The real time performance of DCS is more severe than SCADA in general. Typical DCS in the petro-chemical plant requires that: The travel time of data from the device to the other device is demanded within 1 second at least. which is described in section 3. It relates to R-6. The explosion proof is very severe in some area of the petro-chemical plant. It means that total energy of the system is limited. We described: Because there is a requirement of the explosion-proof. The requirement restricts the amount of total energy in the device. It relates both R-6 and R-7. However, we don't intend to eliminate the SCADA system. In general, we think that it is better for requirements to be suite to the severe system. In SCADA system, latency of 195 (ms) may or may not be enough. We can say that 195 (ms) is enough for DCS. An issue here is that the latency would take 195 x n (ms) before the node begin to communicate with the peer node. when there are 4 realms between the local and the remote, the latency will take more than 1 (s). > In fact, shouldn't timing constraints be defined in Section 4 > as external requirements? The existing requirements R-6 (device > performance) and R-7 (link capacity) are rather imprecise, > and do not mention network latency. As we described in section 3: Furthermore, to suppress power consumption, these CPU may be lowered the number of clocks. Because there is a requirement of the explosion-proof. The requirement restricts the amount of total energy in the device. client processing performance and power consumption are important. About R-7, we described the following in section 3: In the both of the systems, the end devices are basically connected to a local network by a twisted pair cable, which is a low band-width of 32 kbps. DCS uses a certain cable that is standardized in the Fieldbus Foundation. The constraint of band-width is derived from here. However, we agree that we need add a text about network latency to R-7. Please give a time to consider it. > 2) About 5.6. Pre-authentication problem in roaming scenarios > > There seems to be a rather strange assumption here which is > not discussed: that different realms of a SCADA system will be > interconnected by the public Internet. Well, when I was working > on control systems, I would never have dreamt of such a thing! > Surely interconnections between sites and contractors, whether > roaming or fixed, must be based 100% on a VPN approach, where the > access control could be tuned perfectly to avoid a pre-authentication > problem. Typically I'd expect a truly roaming user to connect into > the VPN and her home realm using an IPSec tunnel, and then have > exactly the same trust model as any fixed host in the same realm. > In any case, use of the public network with arbitrary authentication > seems to be a false assumption. > > In fact, in one of the Shell examples, you say: > > They are connected each other by a private ATM WAN. > so any roaming user would have to VPN herself right into > that WAN. Before a roaming user establishes VPN with its home network, the roaming user needs the right to connect to the network that the user is present, and needs the right to cross over the FW. In order to get these rights, the user is required to be identified by the home KDC of the user. There is a chicken-and-egg problem. As you mentioned: the access control could be tuned perfectly to avoid a pre-authentication problem. It means that the maintenance cost increases. > Minor issues: > ------------- > > This is basically a grammatical problem but the authors need to confirm what > the sentence means before it can be edited (last paragraph of section 2.2): > > > However, because the inter-realm trust model > > is not necessarily constructing the hierarchic approach anytime, the > > trust path must be specified manually. > > Does this mean ", because the inter-realm trust model may or may not > follow the hierarchical model,"? If not, what does it mean? Yes, it does. > Editorial issues: > ----------------- > > Just to note that the RFC Editor will have to make many grammatical > corrections to this draft. Now, we are making effort to improve text. Best regards and thank you very much for your valuable comments. ---- Shoichi Sakane _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
