Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
Hello Boris, all, FYI, authors of draft-holsten-about-uri-scheme allowed me to become the co-author of this draft. We got to your message. The -07 is almost prepared for publication, but Lachlan pointed these comments were not addressed. Let me express my opinion regarding them. 22.01.2011 7:02, Boris Zbarsky wrote: There seem to be two differences between what the draft specifies right now and what Gecko, at least, does: 1) Section 5.3 says: Applications SHOULD resolve unrecognized about URIs in the same way as about:blank. Gecko treats unknown about:* as unparseable URIs, and is not likely to change that behavior. While that's allowed by the SHOULD, it's not clear to me why this is a SHOULD as opposed to a MAY, nor is it clear why this is present at all. In particular, as specified this will cause situations where an empty resource is silently returned instead of a failure that the consumer can notice (e.g. in the DOM case via error event handlers and the like). I don't think MAY is fine here, as this is a recommendation. Moreover, as Gecko seems to be an only browser with such behavior, I don't think changing the Standards Track specification should mention/change this; as you noted, SHOULD is not a restriction. 2) Section 6 says: For example, about:blank, about:blan%6B and about:blan%6b are equivalent In Gecko they are not. The string after ':' is treated as a literal string; when looking up a way to handle the URI the second and third URIs above are treated as unparseable by Gecko in its default configuration. Changing this has some security implications that would require careful auditing of not only Gecko code but some specifications (e.g. HTML5 defines certain special-case security behavior for about:blank that's not obviously safe to apply to the other strings above). The same section says: Similarly, about:blank%3F is not equivalent to about:blank?. which I think is trying to explain by example that only unreserved characters need to be unescaped. But that assumes an implementation of RFC 3986 which may or may not be the case in web browsers (and is NOT the case in Gecko, for example, for various web-compatibility reasons). Unless there are very strong reasons for it, I would recommend that no normalization is performed on about: URIs, period. The point of this comment is to propose abandoning normalization of 'about' URIs because of some ad hoc behavior of an only application - Gecko. The purpose of our draft is to give a stable specification of the scheme and normalize all existing types of behavior with regard to handling 'about' URIs. It will be easier for Gecko to change its behavior rather than for other apps to do this. Boris, could you please let me know whether you have some strong opinion regarding your January comments/insist on incorporating them in the draft. Thanks, Mykyta Yevstifeyev -Boris ___ 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: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
On 2011-06-15 11:07, Mykyta Yevstifeyev wrote: ... 2) Section 6 says: For example, about:blank, about:blan%6B and about:blan%6b are equivalent In Gecko they are not. The string after ':' is treated as a literal string; when looking up a way to handle the URI the second and third URIs above are treated as unparseable by Gecko in its default configuration. Changing this has some security implications that would require careful auditing of not only Gecko code but some specifications (e.g. HTML5 defines certain special-case security behavior for about:blank that's not obviously safe to apply to the other strings above). The same section says: Similarly, about:blank%3F is not equivalent to about:blank?. which I think is trying to explain by example that only unreserved characters need to be unescaped. But that assumes an implementation of RFC 3986 which may or may not be the case in web browsers (and is NOT the case in Gecko, for example, for various web-compatibility reasons). Unless there are very strong reasons for it, I would recommend that no normalization is performed on about: URIs, period. The point of this comment is to propose abandoning normalization of 'about' URIs because of some ad hoc behavior of an only application - Gecko. The purpose of our draft is to give a stable specification of the scheme and normalize all existing types of behavior with regard to handling 'about' URIs. It will be easier for Gecko to change its behavior rather than for other apps to do this. ... I agree that not treating them as equivalent is a bug. That being said, if our Mozilla friends do not want to fix this it might be a good idea to warn readers that certain implementations fail to properly unescape, thus it's unwise to rely on that behavior (why would you anyway?). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: one data point regarding native IPv6 support
From Noel analysis, it seems that a lot of the issues could be mitigated by a simple connectivity test. Have the 6to4 router perform a simple ping test through the tentative 6to4 relay, towards some well-known IPv6 host. Or an HTTP test, if we fear that ICMPv6 might be somehow tampered with. If the test succeed, then it shows that the path to that 6to4 relay is clear of firewalls and other obstructions. If the path is not clear, pick another 6to4 relay, or do not enable 6to4. Of course, this does not solve the problem of intermittent failures on the IPv4 path to the relay, e.g. due to congestion. It also does not solve the problem of routers advertising an IPv6 route to 2002::/16 and then failing to deliver the IPv4 packets. But this return problem is easily solved by IPv6 ISP deploying their own 6to4 routers, and thus avoiding dependencies on a generic path to 2002::/16. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
15.06.2011 13:13, Julian Reschke wrote: On 2011-06-15 11:07, Mykyta Yevstifeyev wrote: ... 2) Section 6 says: For example, about:blank, about:blan%6B and about:blan%6b are equivalent In Gecko they are not. The string after ':' is treated as a literal string; when looking up a way to handle the URI the second and third URIs above are treated as unparseable by Gecko in its default configuration. Changing this has some security implications that would require careful auditing of not only Gecko code but some specifications (e.g. HTML5 defines certain special-case security behavior for about:blank that's not obviously safe to apply to the other strings above). The same section says: Similarly, about:blank%3F is not equivalent to about:blank?. which I think is trying to explain by example that only unreserved characters need to be unescaped. But that assumes an implementation of RFC 3986 which may or may not be the case in web browsers (and is NOT the case in Gecko, for example, for various web-compatibility reasons). Unless there are very strong reasons for it, I would recommend that no normalization is performed on about: URIs, period. The point of this comment is to propose abandoning normalization of 'about' URIs because of some ad hoc behavior of an only application - Gecko. The purpose of our draft is to give a stable specification of the scheme and normalize all existing types of behavior with regard to handling 'about' URIs. It will be easier for Gecko to change its behavior rather than for other apps to do this. ... I agree that not treating them as equivalent is a bug. That being said, if our Mozilla friends do not want to fix this it might be a good idea to warn readers that certain implementations fail to properly unescape, thus it's unwise to rely on that behavior (why would you anyway?). I fully agree with you, Julian. I think we'll do certainly as you propose, unless Boris will provide some strong reasons to do in other way. Mykyta Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt j...@apple.com wrote: Very few of the people using 6to4 in this way will show up in Google's user behavior analysis, of course, because Google doesn't run its own 6to4 return-path relay as I-D.ietf-v6ops-6to4-advisory recommends. We would not see these users even if we operated reverse path relays as recommended in the draft - from the point of view of the server, in both cases it's just a TCP connection to a 2002::/16 address, regardless of whether the relay is inside the Google network or outside it. Those users would become visible if we added records with 6to4 addresses, but that's a bad plan because it would likely lead to the double-digit connection failure rates that Geoff observes. It would also become visible if Google operated an open anycast relay, which we do not plan to do. The way to find these people is to crawl the BitTorrent networks. What's that old maxim? You can't test what you don't measure. Do you measure the BitTorrent networks? No, we don't. The measurements we conduct have the purpose of determining the impact of adding records to web sites, so we don't measure the population of users that has 6to4 but does not use it to make HTTP connections to dual-stack websites. We do measure the impact of 6to4 on the reliability of websites indirectly, e.g., by observing the difference between OSes that prefer IPv4 over 6to4 and OSes that don't. Also, is there a way we can put this debate to rest using real data? What if we asked someone like Hurricane Electric how much traffic on their network is native IPv6 vs. 6to4? That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [IPsec] Last Call: draft-ietf-dime-ikev2-psk-diameter-06.txt (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard
Hi Yaron, Thanks for the suggestions. Please see inline. -Violeta -Original Message- From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] Sent: Friday, June 03, 2011 4:32 PM To: Cakulev, Violeta (Violeta) Cc: ietf@ietf.org; IPsecme WG; d...@ietf.org; draft-ietf-dime-ikev2-psk-diame...@tools.ietf.org Subject: Re: [IPsec] Last Call: draft-ietf-dime-ikev2-psk-diameter-06.txt (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard Hi Violeta, thanks for your response. I understand now where you're coming from. But the next person to read the document might not have the authors so readily available :-) Implementors need to understand the motivation for this solution as well as the missing pieces. [VC] And the next person indeed had the same concern. Therefore, in v8 we made the changes as proposed below. So I would suggest that you add: - A short paragraph in the Introduction putting this document in perspective and referencing (non-normative references of course) the 3GGP2 documents. - Another paragraph in the Security Considerations that says that generation/derivation of the PSK is security-critical, and provides the 3GPP2 docs again as an example of a solution to this problem. [VC] Please see v8. We added statements both in Introduction and Security Considerations as proposed above. Regarding usage of the SPI, the document says: Upon receiving the IKE_AUTH message from the IKEv2 Peer, the IKEv2 Server uses the information received in IDi *and the SPI* if available, to determine if it has the PSK for this IKEv2 Peer.This sounds to me as if the SPI is used as part of the PSK lookup operation. Maybe the SPI should not be mentioned in the above text. [VC] We modified this paragraph in v8. Please see v8. Best regards, Yaron On 06/01/2011 11:04 PM, Cakulev, Violeta (Violeta) wrote: Hi Yaron, Thanks for the comments. Please see inline [VC]. -Violeta -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer Sent: Sunday, May 22, 2011 2:38 PM To: ietf@ietf.org Cc: IPsecme WG; draft-ietf-dime-ikev2-psk-diame...@tools.ietf.og; d...@ietf.org Subject: Re: [IPsec] Last Call:draft-ietf-dime-ikev2-psk-diameter-06.txt (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard Hi, Having read this document only now, I think there's a number of serious issues with it. This document was sent to the ipsec mailing list a while ago but unfortunately got no review. Summary: 1. I think the wrong architectural choice was made, in preferring PSK over EAP authentication. 2. There is not enough detail in the document to result in interoperable implementations. [VC] Please see responses to detailed comments. Detailed comments: * The appropriate ref for IKEv2 is RFC 5996. This was actually noted in the shepherd review back in March. [VC] This is fixed in v7. * The document notes that EAP is one of the authentication modes supported by IKEv2. EAP is designed for interaction with backend AAA servers, and is quite capable of performing shared-secret authentication, using a variety of EAP methods (and see also RFC 5998, on IKEv2 mutual auth with EAP). Yet the document does not explain why EAP is not used, instead preferring the IKE PSK authentication method. [VC] Diameter application for Diameter client to server communication for IKEv2 with EAP has been specified in RFC 5778. However, there is no Diameter application specified for IKE PSK authentication method. This is stated in the draft both in Abstract and Introduction. The draft does not recommend one or the other, it is simply specifying what is not specified. It is up to a specific use case to decide what to use. For example 3GPP2 decided to use IKEv2 PSK (in 2 of its specifications), and that is what triggered this effort in IETF. * 4.1: how can the incoming SPI be used to identify the peer? [VC] As stated in Section 4.1 IDi payload is extracted from the IKE_AUTH message and this payload 'MUST contain an identity that is meaningful for the Diameter infrastructure, such as a Network Access Identifier (NAI), since it is used by the IKEv2 Server to populate the User-Name AVP in the Diameter message'. SPI is not used to identify the peer. * Packing additional semantics into SPI may conflict with elements of the IPsec architecture (see for example Sec. 9.3 of draft-ietf-ipsecme-failure-detection-08). [VC] Agreed. * 4.1, 2nd paragraph: generation of the PSK is central to this solution, so it cannot be outside the scope of the document. There is no way to interoperate otherwise. [VC] This draft focuses on IKEv2 server, as a Diameter client, to the Diameter server communication for IKEv2 with pre- shared secret based authentication, and specifies Diameter
RE: Gen-ART LC review of draft-ietf-dime-ikev2-psk-diameter-07
Ben, Thanks for the comments. Please see inline [VC]. -Violeta -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Friday, June 03, 2011 4:10 PM To: draft-ietf-dime-ikev2-psk-diameter@tools.ietf.org; gen-...@ietf.org Review Team Cc: The IETF Subject: Gen-ART LC review of draft-ietf-dime-ikev2-psk-diameter-07 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dime-ikev2-psk-diameter-07 Reviewer: Ben Campbell Review Date: 2011-06-03 IETF LC End Date: 2011-06-03 Summary: This draft is almost ready for publication as a proposed standard. I have a question concerning the procedure for generating PSKs, and a number of minor and editorial comments. Major issues: The draft says that the procedure that the HAAA follows to generate the PSK is out of scope. But doesn't the IKE2 initiator need to understand the procedure? If the procedure is not defined somewhere, how you achieve any degree of interoperability? [VC] Indeed the IKEv2 initiator needs to understand the procedure. However, this draft focuses on IKEv2 server, as a Diameter client, to the Diameter server communication for IKEv2 with pre-shared key based authentication, and specifies Diameter application for this communication. It is left to specifications that make use of this Diameter application to specify where the PSK comes from and how it is generated. There are two 3GPP2 specs that make use of this Diameter application and both of those specs specify generation of the PSK. Statements to clarify this are added in v8. Minor issues: -- section 4.1, 1st paragraph:The IDi payload extracted from the IKE_AUTH message MUST contain an identity that is meaningful for the Diameter infrastructure, such as a Network Access Identifier (NAI), since it is used by the IKEv2 Server to populate the User-Name AVP in the Diameter message. Do you mean that as a normative MUST, or a statement of fact? If normative, isn't that a requirement on the initiator? [VC] Good point. It is changed to statement of fact in v8. -- section 10: The security considerations should describe the threat models. We're talking about requesting an authentication key from a third party, which is tricky from a security perspective. Does the PSK have greater security concerns than for Diameter AVPs in general? In particular, what are the consequences if the PSK is disclosed or tampered with? [VC] If the PSK is disclosed to an adversary then it would present a security breach. Hence we recommend that the PSK be short-lived. As well, the assumption is that the IKEv2 Server and the Diameter Server where the PSK is generated are in a trusted relationship. They may be in the same Administrative domain (typical case) or third party but nevertheless there is a trust relationship between them. As such we assume that there is an appropriate security mechanism to protect the communication between these servers. For example the IKEV2 Server and the Diameter server would be deployed in the same secure network or would utilize transport layer security as specified by Diameter 3588 specification. We added statements in v8 to reflect this. -- section 10, 1st paragraph: Furthermore, any agents that process IKEv2-PSK-Answer messages can see the contents of the Key AVP. For this reason, this specification strongly recommends avoiding Diameter agents when they cannot be trusted to keep the keys secret. Should that be normative? Is there no way to protect the PSK AVP from diameter agents? E.g. can it be encrypted? [VC] It is hard to use normative text here as this application can be used for many uses cases. Depending on the use case it may be possible to encrypt the PSK, however it is not possible to make it a requirement. -- section 10, 2nd paragraph: this specification also recommends the use of nonces included in IKEv2-PSK-Request. Actually, the spec requires it using a normative SHALL. [VC] In v8 it is aligned as 'recommended' throughout the document. Nits/editorial comments: -- IDNits reports an out-of-date reference [VC] I missed this one in v8. This will be fixed in v9. -- Section 1, general: It's probably worth elaborating that we are talking about a PSK used during the IKEv2 authentication process, which is distinct from any shared secrets negotiated by IKE for use in the resulting SA. [VC] In v8 there are statements clarifying that it is a PSK used for IKEv2 authentication. -- Section 1, paragraph 1, 1st sentence: The use, and lack of, commas in this sentence is confusing. It's easy to parse as saying IKE2 is a protocol and a set of algorithms, when I think you meant to say that the resulting SA has a set of algorithms along with the shared secret. [VC] Changed in v8 to 'The Internet Key
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
The youtube folks made the decision to leave the video-serving hostnames available in blacklist-mode, meaning only very broken networks won't get s. This is being watched, and could easily change back. The exact policy for blacklisting has yet to be fully formalized. But re: 6to4 in this case, it still gains you nothing you didn't already have while risking randomly crappy performance. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, 14 Jun 2011 10:59:47 -0700 Lorenzo Colitti lore...@google.com wrote: On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt j...@apple.com wrote: Very few of the people using 6to4 in this way will show up in Google's user behavior analysis, of course, because Google doesn't run its own 6to4 return-path relay as I-D.ietf-v6ops-6to4-advisory recommends. We would not see these users even if we operated reverse path relays as recommended in the draft - from the point of view of the server, in both cases it's just a TCP connection to a 2002::/16 address, regardless of whether the relay is inside the Google network or outside it. Those users would become visible if we added records with 6to4 addresses, but that's a bad plan because it would likely lead to the double-digit connection failure rates that Geoff observes. It would also become visible if Google operated an open anycast relay, which we do not plan to do. I don't know if it is intentional, however if I use Google's public 8.8.8.8 and 8.8.4.4 resolvers, and prefer 6to4 over native IPv4 (via /etc/gai.conf under Linux/glibc), it seems that the video content of all youtube videos is now being delivered over IPv6. The same thing happens if I use my ISP's resolvers - I know they're doing IPv6 work behind the scenes, however I don't know but dont think their resolvers are Google whitelisted. That suggests that if there are hosts out there that blindly prefer tunnelled IPv6 over native IPv4, and have 6to4 available, there is a likelyhood that more people are using 6to4 now than there was before World IPv6 day. I'm having no performance problems at all with any videos I select, including 1080P ones. The way to find these people is to crawl the BitTorrent networks. What's that old maxim? You can't test what you don't measure. Do you measure the BitTorrent networks? No, we don't. The measurements we conduct have the purpose of determining the impact of adding records to web sites, so we don't measure the population of users that has 6to4 but does not use it to make HTTP connections to dual-stack websites. We do measure the impact of 6to4 on the reliability of websites indirectly, e.g., by observing the difference between OSes that prefer IPv4 over 6to4 and OSes that don't. Also, is there a way we can put this debate to rest using real data? What if we asked someone like Hurricane Electric how much traffic on their network is native IPv6 vs. 6to4? That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? I'm having and have been having 100% success rate (or near enough to it that I can remember) using 6to4 for a number of years, including with an IPv6 MTU of as large as my PPPoE connection will support i.e. my 6to4 tunnel has an IPv6 MTU of 1472. Since noticing that youtube videos are coming over IPv6, I've paid a bit more attention to the quality of experience I've had, and have not found any reasons to change my preference back to native IPv4 instead of 6to4. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Tue, 14 Jun 2011 16:05:33 -0700 Erik Kline e...@google.com wrote: The youtube folks made the decision to leave the video-serving hostnames available in blacklist-mode, meaning only very broken networks won't get s. This is being watched, and could easily change back. The exact policy for blacklisting has yet to be fully formalized. But re: 6to4 in this case, it still gains you nothing you didn't already have while risking randomly crappy performance. A less used content cache could give me better performance. Not that it has happened recently, however in the past there have been IPv4 delivered performance issues with youtube here in .au. That's the reason I've paid a bit more attention to the quality of IPv6 delivery and tried 1080P videos when they've been available. Regards, Mark. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Liaison and request for review of ITU-T document
Brian - thanks for your review and comments. - Ralph On Jun 10, 2011, at 10:45 PM 6/10/11, Brian E Carpenter wrote: Ralph, As far as I can tell this seems to describe some sort of a Layer 2 stateful per-flow QoS mechanism using new Ethertype headers. As such I don't see why the IETF would care. The point of it escapes me, since we have plenty of reason to believe that such solutions are impractical and do not scale, but that doesn't seem like our problem. I only looked at this to check if it impacted current work in 6MAN on the IPv6 Flow Label, and there doesn't appear to be any impact or relevance. Regards Brian Carpenter On 2011-06-08 08:27, Ralph Droms wrote: The IETF has recently received a liaison from ITU-T Q5/SG-11 regarding a Draft Recommendation. That liaison is available as https://datatracker.ietf.org/liaison/1054/. The official liaison is available at https://datatracker.ietf.org/documents/LIAISON/file1232.pdf. The liaison asks for IETF review of Draft Recommendation Signalling protocols and procedures relating to Flow State Aware QoS control in a bounded sub-network of a NGN, which is available at https://datatracker.ietf.org/documents/LIAISON/file1231.pdf. This note opens an IETF comment period on the document, ending midnight, anywhere on earth, 2011/7/5. After the comment period, a summary will be prepared and returned in a liaison to ITU-T Q5/SG-11. Of specific interest to the IETF are any ways in which the signalling protocols and procedures defined in the Draft Recommendation might interact with existing IETF Internet protocols. We are especially interested in potential adverse interactions or interference with IETF Internet protocols. The technical merits of the signalling protocols and procedures defined in the Draft Recommendation are of interest inasmuch as the IETF community might provide technical advice and recommendations to improve the Draft Recommendation itself. Please respond with any comments on the Draft Recommendation to ietf@ietf.org. Thanks in advance for your review of the Draft Recommendation. - Ralph Droms, Internet Area Director for the IESG ___ 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: [Gen-art] Gen-ART LC review of draft-ietf-dime-ikev2-psk-diameter-07
Hi Ben, Please see inline... -- Avi Lior --Bridgewater Systems eview Date: 2011-06-03 IETF LC End Date: 2011-06-03 Summary: This draft is almost ready for publication as a proposed standard. I have a question concerning the procedure for generating PSKs, and a number of minor and editorial comments. Major issues: The draft says that the procedure that the HAAA follows to generate the PSK is out of scope. But doesn't the IKE2 initiator need to understand the procedure? If the procedure is not defined somewhere, how you achieve any degree of interoperability? [VC] Indeed the IKEv2 initiator needs to understand the procedure. However, this draft focuses on IKEv2 server, as a Diameter client, to the Diameter server communication for IKEv2 with pre-shared key based authentication, and specifies Diameter application for this communication. It is left to specifications that make use of this Diameter application to specify where the PSK comes from and how it is generated. There are two 3GPP2 specs that make use of this Diameter application and both of those specs specify generation of the PSK. Statements to clarify this are added in v8. The effect of this is that this spec, as written, cannot be implemented in an interoperable way. I don't think that meets the usual expectations for a proposed standard. Now, I realize there are some situations where the IETF has chosen this approach, and deliberately created a standards track RFC that must be profiled for actual use--but hopefully that's the exception rather than the rule. I guess it's up to the IESG to decide if that is reasonable in this instance. (I'm explicitly not counting situations where the IETF puts out a standard as a series of modular RFCs, since I gather there's no immediate intent to publish PSK generation RFCs.) Additionally, whether or not PSK generation mechanisms are specified in the IETF vs somewhere else, how does an implementation (that might support more than one such mechanism) know which to use for any given SA? Is there a negotiation mechanism? I agree with your comments in general. What we need to keep in mind though is the intent of this draft, which is to deliver the PSK key to the IKEv2 server. The issues you discuss relating to PSK are issues that are there with or without this document. The document uses all the information that is available in IKEv2 to fetch that PSK and to allow a PSK to be derived (via the nonces). Minor issues: [...] [...] -- section 10, 1st paragraph: Furthermore, any agents that process IKEv2-PSK-Answer messages can see the contents of the Key AVP. For this reason, this specification strongly recommends avoiding Diameter agents when they cannot be trusted to keep the keys secret. Should that be normative? Is there no way to protect the PSK AVP from diameter agents? E.g. can it be encrypted? [VC] It is hard to use normative text here as this application can be used for many uses cases. Depending on the use case it may be possible to encrypt the PSK, however it is not possible to make it a requirement. I don't see why a SHOULD or RECOMMENDED would cause problems here, along with some short explanation of why it might not always be possible. Otherwise, the text says strongly recommends, when, without normative text, such recommendation is really pretty weak. I may be okay with using stronger terms (SHOULD or RECOMMEND). I actually wish now that this entire paragraph be deleted. The reason being is that the security issues relating to multi-hop Diameter communication is well understood and documented in 3588 (and we already make a reference to that document). I don't see a need for recommendation. [...] Nits/editorial comments: [...] -- section 8, first paragraph: whether the AVP MAY be encrypted. I don't see anything about encryption in the table. [VC] The text referring to encryption is deleted. So how does an implementor know if it can be encrypted? We used an old style of table which is not really used. There is no end to end encryption mechanisms in Diameter. And Diameter provides transport level security (integrity and privacy protection). If the end to end encryption that is between the Diameter Client (IKEv2 Server) and the Diameter Server (where the PSK is stored/generated) is needed it would have to be built on-top of this document - so the implementor will know. [...] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
On Wed, Jun 15, 2011 at 06:05:33PM +0300, Mykyta Yevstifeyev wrote: 15.06.2011 13:13, Julian Reschke wrote: That being said, if our Mozilla friends do not want to fix this it might be a good idea to warn readers that certain implementations fail to properly unescape, thus it's unwise to rely on that behavior (why would you anyway?). I fully agree with you, Julian. I think we'll do certainly as you propose, unless Boris will provide some strong reasons to do in other way. If I am reading the document and the above correctly, then you are proposing the following: 1. The document proposes to make standard rules about what applications do with input that is, by definition, completely internal to that application; and, 2. You propose in addition to state what is the standard, but note that nobody should rely on it because one of the largest implementers of the scheme doesn't follow the supposed standard. Do I have this correct? If so, I would like to request that the WINDMILL or perhaps TILT WG be chartered to deal with this manner of work. More substantively, I fail to understand how this specification proposes to create a class of reserved about: URIs when the about: scheme seems to be internal information to an application. I think the Security Considerations section doesn't address any of that, and probably ought to, particularly in light of the proposal to add text that users ought not to depend on standard behaviour. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 14, 2011, at 1:59 PM, Lorenzo Colitti wrote: That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? it can communicate with hosts that have only IPv6, it can communicate with hosts that are stuck behind a single IPv4 address (if the router acts as a 6to4 gateway) without a NAT being in the way, it can be used to develop and test IPv6 applications without having to build a special-purpose network, it can be used to deploy applications now that already support IPv6 and so are in some sense future-proofed, it can be deployed on either a single host or a network again, trying to judge how well 6to4 works by how well it works with web sites that also support IPv4 is entirely missing the point. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 15, 2011, at 7:10 PM, Lorenzo Colitti wrote: On Wed, Jun 15, 2011 at 3:58 PM, Keith Moore mo...@network-heretics.com wrote: That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? it can communicate with hosts that have only IPv6, it can communicate with hosts that are stuck behind a single IPv4 address (if the router acts as a 6to4 gateway) without a NAT being in the way, it can be used to develop and test IPv6 applications without having to build a special-purpose network, it can be used to deploy applications now that already support IPv6 and so are in some sense future-proofed, it can be deployed on either a single host or a network ... about 80% of the time. A single figure doesn't really describe the situation. The successes/failures aren't independent of one another. It's not that you get only an 80% probability of things working on every connection. It's more like, it either works fairly well for what you need it to do, or it doesn't. Again, don't assume that this is like the web and the connections are mostly client-to-server, or one source to large numbers of different destinations. I would argue that cases 1, 3, 4, 5, and 6 can be solved more reliably using configured tunnels, There are lots of different tunneling methods each with strengths and weaknesses. What you probably do in practice is try one, and if that doesn't work for your purposes, try another. 6to4 is very easy to try, and it often works. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF Fellowship Announcement (IETF 82 and 83)
Dear Colleagues, The Internet Society has announced that it is inviting applications for its latest Internet Society Fellowships to the IETF, part of its Next Generation Leaders (NGL) programme (www.InternetSociety.org/Leaders). The Fellowship programme allows engineers from developing countries to attend an Internet Engineering Task Force (IETF) meeting. As you know, the IETF is the Internet's premier standards-making body, responsible for the development of protocols used in IP-based networks. IETF participants represent an international community of network designers, operators, vendors, and researchers involved in the technical operation of the Internet and the continuing evolution of Internet architecture. Fellowships will be awarded through a competitive application process. The Internet Society is currently accepting fellowship applications for the next two IETF meetings: * IETF 82, 13 - 18 Nov 2011, Taipei, TW * IETF 83, 25 - 30 March, Paris, FR http://www.isoc.org/educpillar/fellowship/index.php Fellowship applications for both IETF meetings are due by 15 July 2011. Please note that this fellowship is aimed at individuals from developing regions that possess a solid level of technical education and enough knowledge about concrete areas of IETF work to follow and benefit from the meeting’s technical discussions. I encourage you to pass on information about this program to individuals involved in your network that have a keen interest in the Internet standardisation activities of the IETF. The Internet Society Fellowships to the IETF are sponsored by Afilias, Google, Microsoft, and Intel. The Internet Society’s Next Generation Leaders programme is sponsored by Nominet Trust, the Association Française pour le Nommage Internet en Coopération (AFNIC), SIDN, and the European Commission. If you have questions, please do not hesitate to contact Steve Conte conte[at]isoc[dot]org. Kind Regards, Steve Conte Internet Society - Steve Conte co...@isoc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
In message 22f6318e46e26b498abc828879b08d4f16f...@tk5ex14mbxw653.wingroup.wind eploy.ntdev.microsoft.com, Christian Huitema writes: From Noel analysis, it seems that a lot of the issues could be mitigated by= a simple connectivity test. Have the 6to4 router perform a simple ping tes= t through the tentative 6to4 relay, towards some well-known IPv6 host. Or a= n HTTP test, if we fear that ICMPv6 might be somehow tampered with. If the= test succeed, then it shows that the path to that 6to4 relay is clear of f= irewalls and other obstructions. If the path is not clear, pick another 6to= 4 relay, or do not enable 6to4. Of course, this does not solve the problem of intermittent failures on the = IPv4 path to the relay, e.g. due to congestion. But happy-eyeballs does mostly solve that problem. If the path is congested and dropping packets then the IPv6 connect will likely not succeed before the IPv4 connect succeeds. happy-eyeballs also deals with relay routers that are topologically bad for the destination machines which are dual stack. It also does not solve the problem of routers advertising an IPv6 route to = 2002::/16 and then failing to deliver the IPv4 packets. But this return p= roblem is easily solved by IPv6 ISP deploying their own 6to4 routers, and t= hus avoiding dependencies on a generic path to 2002::/16. -- Christian Huitema -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
In message BANLkTi=ggay2u0sx54hnv7bz7qdgrajz9h+8rwhmwkjk+9s...@mail.gmail.com , Lorenzo Colitti writes: On Wed, Jun 15, 2011 at 3:58 PM, Keith Moore mo...@network-heretics.comwrot e: That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? it can communicate with hosts that have only IPv6, it can communicate with hosts that are stuck behind a single IPv4 address (if the router acts as a 6to4 gateway) without a NAT being in the way, it can be used to develop and test IPv6 applications without having to build a special-purpose network, it can be used to deploy applications now that already support IPv6 and so are in some sense future-proofed, it can be deployed on either a single host or a network ... about 80% of the time. Or 99.999% of the time once you get it setup. The problem isn't 6to4, it's *automatic* 6to4. I would argue that cases 1, 3, 4, 5, and 6 can be solved more reliably using configured tunnels, and that case 2 is today solved more reliably, and in more cases (e.g., when no public IPv4 address is available at the border) by the various NAT traversal mechanisms that are implemented in applications. But I think we're just going around in circles here. Which often times requires special software to be installed. Tunnels are a lot more hassle to setup and yes I've used both so I know. 6to4 historic is throwing the baby out with the bath water. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On 14 Jun 2011, at 18:59, Lorenzo Colitti wrote: On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt j...@apple.com wrote: Very few of the people using 6to4 in this way will show up in Google's user behavior analysis, of course, because Google doesn't run its own 6to4 return-path relay as I-D.ietf-v6ops-6to4-advisory recommends. We would not see these users even if we operated reverse path relays as recommended in the draft - from the point of view of the server, in both cases it's just a TCP connection to a 2002::/16 address, regardless of whether the relay is inside the Google network or outside it. Running the relay inside your network lets you correlate the failure rate you observe to the direction of the path the failures occur in, though. That data may be valuable to you. And since it's HTTP we're talking about, it might be a consolation to know that it's your side of the network generating the most traffic. Those users would become visible if we added records with 6to4 addresses, but that's a bad plan because it would likely lead to the double-digit connection failure rates that Geoff observes. It would also become visible if Google operated an open anycast relay, which we do not plan to do. Your (Google's) problem is the relays. So, if we take this thought a step further, by deploying (no, I'm not suggesting you do this, obviously) a 6to4-reachable presence you may actually reduce the total traffic by volume reaching you over native IPv6, if it transpires that 6to4 is a good portion of the majority of tunnel traffic, the vast majority of IPv6 traffic reaching you. That's not to speak of address selection algorithms which would do the right thing (in theory) given the choice of native or 6to4, of course. The way to find these people is to crawl the BitTorrent networks. What's that old maxim? You can't test what you don't measure. Do you measure the BitTorrent networks? No, we don't. The measurements we conduct have the purpose of determining the impact of adding records to web sites, so we don't measure the population of users that has 6to4 but does not use it to make HTTP connections to dual-stack websites. We do measure the impact of 6to4 on the reliability of websites indirectly, e.g., by observing the difference between OSes that prefer IPv4 over 6to4 and OSes that don't. That's a real shame, because the use of peer-to-peer applications is a solid reason to turn various tunnel techniques on. One popular Windows BitTorrent client makes it a single-button operation; others simply take the IPv6 connectivity for granted, when available. See: http://thepiratebay.org/blog/146 Also, is there a way we can put this debate to rest using real data? What if we asked someone like Hurricane Electric how much traffic on their network is native IPv6 vs. 6to4? I agree, this would be a good thing. That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? Others have beaten me to this one but I will say one thing in your favour: NAT traversal techniques are ubiquitous and, curse them, actually fairly transparent. This is probably a good thing and it does support your view that at least in the case of BitTorrent or other vanilla address-neutral protocols the end-user transparency really doesn't usually justify the added tunnels for v4-to-v4 communication, regardless of technical impropriety. However this does nothing to address other real concerns, most of them brought up by Keith already. Most importantly, new protocols or uses of the Internet shouldn't be sabotaged by the need for some sort of imaginary all-or-nothing transition to IPv6. One final thought: assuming we ever get to the stage of minority native IPv6 worth service providers' time to set up IPv6 reachability for, and not just the big ones either, what exactly do all the tunnel brokers of the world do about the sudden demand for their services? Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
In article 20110615213858.9853.22165.idtrac...@ietfa.amsl.com you write: The IESG has received a request from the Domain Keys Identified Mail WG (dkim) to consider the following document: - 'DomainKeys Identified Mail (DKIM) Signatures' draft-ietf-dkim-rfc4871bis-12.txt as a Draft Standard I've reviewed this document, indeed my fingerprints are all over it. It's definitely an improvement to 4871: folds in the errata, takes out a lot of gratuitous and often wrong non-normative advice, cleans up the 2119 MUSTage, and otherwise improves the text. Except for the one obscure feature that is deprecated due to lack of use, I think that any implementation that is compliant with 4871+errata should still be compliant with this draft. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-burgin-ipsec-suiteb-profile-00.txt (Suite B Profile for Internet Protocol Security (IPsec)) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Suite B Profile for Internet Protocol Security (IPsec)' draft-burgin-ipsec-suiteb-profile-00.txt as an Informational RFC 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 i...@ietf.org mailing lists by 2011-07-13. 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. Abstract The United States Government has published guidelines for NSA Suite B Cryptography dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in IP Security (IPsec). The file can be obtained via http://datatracker.ietf.org/doc/draft-burgin-ipsec-suiteb-profile/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-burgin-ipsec-suiteb-profile/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1500/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The SSL Protocol Version 3.0' to Historic (draft-mavrogiannopoulos-ssl-version3-06.txt)
The IESG has approved the following document: - 'The SSL Protocol Version 3.0' (draft-mavrogiannopoulos-ssl-version3-06.txt) as a Historic This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-mavrogiannopoulos-ssl-version3/ Technical Summary This document specifies Version 3.0 of the Secure Sockets Layer (SSL V3.0) protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. Working Group Summary The document was proposed to be published as a TLS WG item, but the consensus to the discussion was that the WG was not needed to publish a Historic document. Document Quality The document describes the SSL 3.0 protocol which is widely implemented by various vendors. Personnel Nikos Mavrogiannopoulos is the Document Shepherd. Sean Turner is the Area Director. RFC Editor Note Please retain the Foreword section. Please add the following to the beginning of the Abstract: This document is published as a historical record of the SSL v3.0 protocol. The original Abstract follows. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-law-rfc4869bis-01.txt (Suite B Cryptographic Suites for IPsec) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Suite B Cryptographic Suites for IPsec' draft-law-rfc4869bis-01.txt as an Informational RFC 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 i...@ietf.org mailing lists by 2011-07-13. 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. Abstract This document proposes four cryptographic user interface suites (UI suites) for IPsec, similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. This document obsoletes RFC 4869, which presented earlier versions of these suites. The file can be obtained via http://datatracker.ietf.org/doc/draft-law-rfc4869bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-law-rfc4869bis/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1499/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-polk-local-emergency-rph-namespace-01.txt (IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications' draft-polk-local-emergency-rph-namespace-01.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 i...@ietf.org mailing lists by 2011-07-13. 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. Abstract This document creates the new Session Initiation Protocol (SIP) Resource Priority header field namespace esnet for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations, and places this namespace in the IANA registry. The file can be obtained via http://datatracker.ietf.org/doc/draft-polk-local-emergency-rph-namespace/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-polk-local-emergency-rph-namespace/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
The IESG has received a request from the Domain Keys Identified Mail WG (dkim) to consider the following document: - 'DomainKeys Identified Mail (DKIM) Signatures' draft-ietf-dkim-rfc4871bis-12.txt as a Draft 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 i...@ietf.org mailing lists by 2011-06-29. 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. Abstract DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and querying the signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC4871 and RFC5672. DIffs from RFC 4871 Changes from RFC 4871 can be found at: http://www.trusteddomain.org/dkim-diff.html DOWNREFs This specification contains two normative references to proposed standard RFCs: RFC 3447 and RFC 5890. This specification contains two normative references to non-IETF RFCs: FIPS-180-3-2008 (SHA) and ITU-X660-1997 (ASN.1). This specification contains one normative reference to an informational RFC: RFC 5598. This specification also contains one informative reference to a historical document: RFC 4870. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dkim-rfc4871bis/ Implementation Report can be accessed at http://www.ietf.org/iesg/implementation/report-rfc4871.txt IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dkim-rfc4871bis/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1547/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
