Re: The IETF and the SmartGrid
Is there any planned ad-hoc meeting/session related to this topic in Hiroshima meeting? Peny On Tue, Oct 6, 2009 at 5:47 AM, Fred Baker f...@cisco.com wrote: Thanks. You already know this, as does Russ Housley, but I'll say it out loud for others to hear. At the third NIST workshop on the Smart Grid, which was the week following the IETF meeting, several IETFers were invited by David Su of NIST to a workshop on the role of the Internet Architecture in the Smart Grid. He specifically asked for a document that could be used to discuss and describe the Internet Architecture, specifically to support the profiling (eg, subseting) of its architecture for the purpose. To that end, I started http://tools.ietf.org/html/draft-baker-ietf-core Core Protocols in the Internet Protocol Suite, Fred Baker, 3-Oct-09, draft-baker-ietf-core-03.txt The initial document essentially described the protocols appropriate to a host; at the request and behest of several commentators, I have since added a brief description of unicast and multicast routing, QoS, address allocation and assignment (DHCP and ND), NTP, DNSSEC, SIP, the ISO Transport Service Interfaces (necessary for ACSE, which is used in the Smart Grid) and something of the business architecture of the Internet and therefore firewalls, NATs, and VPNs. I have in the can a version that puts in references for MPLS, and given that NIST is asking about calendaring and SNMP will likely include a few sentences on those. I'm trying to walk what is at best a grey line; The things that are at the Internet Architecture's absolute core, at least to my mind, are described in RFCs 1122, 1123, and 1812. However, NIST is asking about the place of more things (like calendaring and timekeeping) and other possible users of the document are also asking for things that are more core to the business than the architecture, like NATs and MPLS. So I am trying to describe things that are core, and also answer useful questions about less-core things, all without trying to provide a list of all 1574 proposed standards, 89 draft standards, and 82 standards. Individuals who have noticed the draft have commented; folks who care should also do so. I have asked the IESG for directorate reviews, but have not gotten anything from any directorates. As you say, NIST is requesting commentary on http://www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf. Those of us that work for US corporations or educational institutions would likely be wise to be involved in corporate reviews and replies, as that is how most review of this type comes back. The exact structure to reply in has not yet been announced, but I would imagine that will be remedied soon. On Oct 5, 2009, at 2:20 PM, Richard Shockey wrote: The general internet community needs to be aware of activities in North America that directly relate to the use of IETF protocols in the Electric Utility industry. This activity is generally referred to as the SmartGrid. Though the issues immediately deal with technical and policy decisions in the US and Canada, the SmartGrid concept is gaining significant momentum in Europe and Asia as well. http://www.smartgrids.eu/ http://en.wikipedia.org/wiki/Smart_grid#Countries The SmartGrid has many definitions but as a practical matter it is a substantial re-architecture of the data communications networks that utilities use to maintain the stability and reliability of their power grids. Many of the requirements for the SmartGrid in North America came out of the 2003 North East power outage which demonstrated a substantial lack of investment in Utility IT systems. http://www.ferc.gov/EventCalendar/Files/20040915141105-blackout.pdf Of particular note, is the desire by utilities to extend the reach of their communications networks directly to the utility meter and beyond ultimately into the customer premise itself. This is generally referred to as the Advanced Meter Interface (AMI). One of the use cases driving this requirement is the next generation of plug-in hybrid electric vehicles. The utilities, correctly IMHO, want to precisely control the timing of how these vehicles are recharged so not to create a unique form of DOS attack and take out the grid when everyone goes home at night. This is a principal use case in 6lowpan ( ID below ). Increasingly energy flows are becoming bi-directional creating needs for more computational intelligence and capability at the edge. What is going on? Why should the IETF community care? The United States Government, as part of the Energy Independence and Security Act of 2007 gave the National Institute of Standards and Technology ( NIST ) principal responsibility to coordinate development of a framework that includes protocols and model standards for the SmartGrid. http://www.nist.gov/smartgrid/ After several meetings sponsored by NIST in recent months, NIST
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Tue, Sep 22, 2009 at 12:29 AM, Randall Gellens ra...@qualcomm.com wrote: At 5:45 PM +0800 9/21/09, Peny Yang wrote: However, IMHO, your experience may be the story 10 years ago. I am a smoker. When I would like to smoke, I always go find the smoking corner. Now, in Beijing, smoking is prohibited in most of public areas. From my experience, the policies on smoking in China are more restrict than some other countries like EU, Japan. My experience was a couple of years ago, not ten, but it's good to hear that things have improved. Can you tell me what this smoking corner is? [Peny] OK. Smoking corner means some areas for smoking. China Government surely respects the right of smokers, when they tried to protect the health of non-smokers. I recall that a few years ago Copenhagen airport, for example, had such things, but they were simply designated indoor areas, and as such, were no help at all. Likewise, a few years ago, meetings in Japan officially prohibited smoking in many public areas, but the hotel simply wheeled in portable smoking areas which did nothing to help. [Peny] Well, every country has similar issues as you mentioned. In China, we also have such kind of smoking areas. I couldn't say they are 100% isolated from other areas. Can you tell me more about the smoking policy in China now? [Peny] OK. Originally, I was trying to find a English webpage for you. However, I didn't find it. Anyway, the link below is the policy on smoking in Beijing since Mar. 2008. http://www.gov.cn/gzdt/2008-04/10/content_941252.htm I am not sure if you have some Chinese friends to translate it for you. And I agree with you about Japan, although that in the last few years I've been able to find 100% non-smoking restaurants (it takes some work). [Peny] Well, I have to say quite a lot of EU countries are also the same style. Anyway, just like other countries, China is just a country, which has smokers and non-smokers. This issue should not be a barrier for a IETF meeting in China. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -- Randomly selected tag: --- Thoughts, like fleas, jump from man to man. But they don't bite everybody. --Stanislaw Lec ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
Just try to clarify somethings here, check inline please: On Mon, Sep 21, 2009 at 9:42 AM, Randall Gellens ra...@qualcomm.com wrote: Personally, I have three specific concerns with a meeting in China: (1) The law and associated hotel rule Marshall quoted could be violated by what may appear to IETF participants as technical discussion. For example, the manipulation/censorship of Internet traffic by or under orders of the Chinese government is well known. If this were to be mentioned or discussed during the IETF, perhaps in the context of encryption, tunneling, web proxy, DNS, or some other technical area, we could run be violating the law and hence the rule. [Peny] Well, I am afraid IETF is basically a technical standard organization. Actually, we have been discussing the technologies mentioned by you in China every day. But, I personally don't have any trouble. Did somebody else have? Again, I am afraid your concern is a bit too political. We basically will only have technical discussion in IETF. (2) This is a very personal concern, but my experience with China is that it is among the worst places to try and avoid tobacco smoke. [Peny] I am sorry for your bad experience. However, IMHO, your experience may be the story 10 years ago. I am a smoker. When I would like to smoke, I always go find the smoking corner. Now, in Beijing, smoking is prohibited in most of public areas. From my experience, the policies on smoking in China are more restrict than some other countries like EU, Japan. (3) Similarly to (2), my experience in Bejing has been that the air is exceptionally polluted. Hence, I'd be concerned for those IETF members who would find this makes participation difficult. [Peny] At this moment, I am pretty sure that I can see the blue sky out of my office. I guess your last visit to Beijing is probably 5 years ago. If IETF could have a meeting in Beijing, I strongly recommend to have it in autumn. It's the most lovely season of Beijing. BR Peny -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -- Randomly selected tag: --- The solution to a problem changes the nature of the problem. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
Hi, Yaron: Please check my response inlines: BRG Peny 2009/9/3 Yaron Sheffer yar...@checkpoint.com: Hi Peny, Thank you for reviewing this draft. Please see my comments below. Regards, Yaron -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Peny Yang Sent: Wednesday, September 02, 2009 17:18 To: ietf@ietf.org Cc: IPsecme WG Subject: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard Sorry, I should cc IPsec mail list. Comments are sent again. Hi, floks: I have two comments on the draft of IKEv2 Session Resumption: 1) Sorry, I have to talk about my concern on the new IKE_SESSION_RESUME. In WG last call, actually I made this comment. However, no feedback was given, maybe because my comment was a little late for WG last call. So, I just copy it here again as a comment for IESG last call. Well, we've discussed pros and cons of IKE_SA_INIT and IKE_SESSION_RESUME for quite a long time. However, IMHO, the consensus is still not fully achieved on this item. So far, I still prefer to choosing extended IKE_SA_INIT for ticket presenting. This solution is specified in http://tools.ietf.org/html/draft-xu-ike-sa-sync-01 As a summary, the virtues are as follows: - RFC5077 (TLS session resumption) also uses the similar scheme, which extends the message of clienthello with session ticket extension. The extended IKE_SA_INIT solution has the similar way. It's easy to extend the base IKEv2 protocol stack to support session resumption. - Considering the case of failing session resumption, the extended IKE_SA_INIT solution can save one round trip. - As indicated in 4.3.3 IKE_AUTH exchange, IKE_AUTH must be initiated after IKE_SESSION_RESUME. In this sense, the extended IKE_SA_INIT way need less code to be supported compared with IKE_SESSION_RESUME. The down side: - some people thought the way of extended IKE_SA_INIT will make the base IKEv2 protocol stack more complex. IMHO, it's an issue of implementation. Again, I still support to use extended IKE_SA_INIT for ticket presenting instead of IKE_SESSION_RESUME. [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in fact an early version of our work did exactly that. But the working group gave us a clear direction to use a separate exchange , and this is where we disagree: I believe we did have a strong WG consensus that the implementation benefits of having a separate exchange (i.e.) outweigh the benefits of the alternative. [Peny] I know WG chair have the right to judge rough consensus. However, I can't agree that IPsecme WG has achieved the so called strong consensus on this issue. Maybe IESG can further judge it. I also can't agree benefits of having a separate exchange outweigh the benefits of the alternative. Actually, we didn't achieve consensus on it yet. not overloading even more the non-trivial IKE_SA_INIT exchange [Peny] I am sorry. I just can't see any evidence that the solution of extending IKE_SA_INIT extension will *OVERLOAD* current IKE_SA_INIT exchange? Or I missed something? 2) Maybe I missed some discussions. There is the case: responder may receives a ticket for an IKE SA that is still active and if the responder accepts it. In one of previous versions of this draft, there once was some description on this case. [YS] I believe you are referring to the text now in Sec. 4.3.4. [Peny] OK. This is the part I referred to. But, it can't deal with the issue when IPsec client *continuously* believes failure of gateway. I know that how a client detects the need for resumption is out of the scope of this draft. But, there is the possibility that IPsec client may be continuously deceived and believe the fail of IPsec gateway. It may continuously present the ticket and update the ticket. In this sense, IMHO, this draft should take care of this case. [YS] If I understand the scenario correctly, it is similar to an attacker repeatedly sending notifications to an IKE client, making it believe that the IKE exchange has failed and needs to be reinitiated. [Peny] Well, this case may not cause this problem. If attacker has IPsec connection with the client, the client will only believe the attacker fails, not Gateway. Here is one of the cases. Sometimes, temporary unavailability of network access may also cause this problem. For example, in mobile network, mobile terminals may lose radio resources in some time. In this situation, all the packets outward of client will be timeout. Then IKEv2 protocol stack has the possibility to believe failure of gateway. It will send one or more message to initiate the session resumption. However, as far as I know, many cellular card now will not discard the packets when radio resources lose for a while. It will buffer the packets and send them out when radio resources are available. This attack against plain-vanilla IKE
Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
On Thu, Sep 3, 2009 at 5:11 PM, Tero Kivinenkivi...@iki.fi wrote: Yaron Sheffer writes: [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in fact an early version of our work did exactly that. But the working group gave us a clear direction to use a separate exchange, and this is where we disagree: I believe we did have a strong WG consensus that the implementation benefits of having a separate exchange (i.e. not overloading even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of the alternative. I agree on that (both to the WG having consensus and also that using separate exchange is better). I know that how a client detects the need for resumption is out of the scope of this draft. But, there is the possibility that IPsec client may be continuously deceived and believe the fail of IPsec gateway. It may continuously present the ticket and update the ticket. In this sense, IMHO, this draft should take care of this case. [YS] If I understand the scenario correctly, it is similar to an attacker repeatedly sending notifications to an IKE client, making it believe that the IKE exchange has failed and needs to be reinitiated. This attack against plain-vanilla IKE would be much more CPU-intensive to the client and to the (real) gateway, compared to repeated session resumption. Even when you factor in the cost of generating a new ticket. Moreover, the regular IKEv2 anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. Regardless what notifications or ICMP messages you send to any of the IKE end points that MUST NOT cause them to consider IKE SA failed. It MUST conclude that the other endpoind has failed only when repeated attemtps to contact it have gone unanswered for timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE SA to the same authenticated identity. (RFC 4306 section 2.4) Notifications and ICMP messages may trigger other end to send empty INFORMATIONAL message to check whether the other end is alive or not and only if that times out then the other end is considered dead. This means this kind of attack is not possible with notifications and ICMP. [Peny] Agree. I did not mean this kind of attacking originally. On the other hand I do agree with Peny that, as resumption draft makes it out of scope for this draft, how a client detects the need of resumption, we might need more text explaining this attack. I.e. we might need to add text to security considerations which says that the client implementations should not trust any untrusted source when they are trying to detect whether the resumption is needed. [Peny] Agree. I also think we need more text to clarify this issue. In this meanwhile, I think the way in section 4.3.4 is not appropriate. Gateway should not silently delete the related SAs in this case. One possible solution is to use the anti-DOS cookie mechanism of IKEv2 to handle this issue. -- kivi...@iki.fi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IPsec] Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
Hi, floks: I have two comments on the draft of IKEv2 Session Resumption: 1) Sorry, I have to talk about my concern on the new IKE_SESSION_RESUME. In WG last call, actually I made this comment. However, no feedback was given, maybe because my comment was a little late for WG last call. So, I just copy it here again as a comment for IESG last call. Well, we've discussed pros and cons of IKE_SA_INIT and IKE_SESSION_RESUME for quite a long time. However, IMHO, the consensus is still not fully achieved on this item. So far, I still prefer to choosing extended IKE_SA_INIT for ticket presenting. This solution is specified in http://tools.ietf.org/html/draft-xu-ike-sa-sync-01 As a summary, the virtues are as follows: - RFC5077 (TLS session resumption) also uses the similar scheme, which extends the message of clienthello with session ticket extension. The extended IKE_SA_INIT solution has the similar way. It's easy to extend the base IKEv2 protocol stack to support session resumption. - Considering the case of failing session resumption, the extended IKE_SA_INIT solution can save one round trip. - As indicated in 4.3.3 IKE_AUTH exchange, IKE_AUTH must be initiated after IKE_SESSION_RESUME. In this sense, the extended IKE_SA_INIT way need less code to be supported compared with IKE_SESSION_RESUME. The down side: - some people thought the way of extended IKE_SA_INIT will make the base IKEv2 protocol stack more complex. IMHO, it's an issue of implementation. Again, I still support to use extended IKE_SA_INIT for ticket presenting instead of IKE_SESSION_RESUME. 2) Maybe I missed some discussions. There is the case: responder may receives a ticket for an IKE SA that is still active and if the responder accepts it. In one of previous versions of this draft, there once was some description on this case. I know that how a client detects the need for resumption is out of the scope of this draft. But, there is the possibility that IPsec client may be continuously deceived and believe the fail of IPsec gateway. It may continuously present the ticket and update the ticket. In this sense, IMHO, this draft should take care of this case. BRG Peny On Mon, Aug 31, 2009 at 10:09 PM, The IESGiesg-secret...@ietf.org wrote: The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'IKEv2 Session Resumption ' draft-ietf-ipsecme-ikev2-resumption-07.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17990rfc_flag=0 ___ IPsec mailing list ip...@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
