Hi Shoichi, I am sorry, I have checked my email and can find no record of receiving your message of 8th August. Perhaps I made a mistake, or perhaps the network made a mistake!
Some comments in line... On 2009-10-06 11:47, [email protected] wrote: > 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. Yes, and I have worked on control systems at CERN where the scientists wanted millisecond response times. The point is that there is a very wide range of requirements, and I suppose that the IETF is trying to produce general solutions. So 195 milliseconds may be reasonable for some control applications and not for others. I would rather say that this performance sets a limit, and the Kerberos solution *cannot* be used for control systems with a tighter requirement. > 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. That may be true, but R-6 and R-7 are quite imprecise. If there is a safety standard for power or power density, that is presumably very precise and the actual requirement here is to meet that standard, not to limit performance and bandwidth. Anyway, my point was not that. It was that if the performance of Kerberos is too slow for a given application, you can't use Kerberos. > > 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). > Exactly. You could describe that very precisely and make R-6 and R-7 much more useful. Thanks Brian >> 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. Right. Other people might build control systems using 100Mb optical fibre systems. I think you can consider a whole range of scenarios. > 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. Oh yes. Security costs money, and with roaming clients you may not be able to bootstrap the security using only Kerberos. > >> 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
