Re: one data point regarding native IPv6 support
On 13 Jun 2011, at 16:28, Noel Chiappa wrote: If 6to4 has problems, fine, write a document that says something like '6to4 won't work for a host behind a NAT box because the host won't know it's true IPv4 global-scope address - so you should also not turn 6to4 on by default' and fix/publicize the issues. There has been a good deal of work making tunnel brokers work through IPv4 NATs and with changing IPv4 endpoints. Both SiXXS and HE brokers handle such issues, e.g. using a heartbeat method. So these ought to be (relatively) attractive to end users who want IPv6? Presumably the prefixes used by such providers, and others like gogo6, are known so brokenness stats for such services could be deduced? Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [PCN] Last Call: draft-ietf-pcn-cl-edge-behaviour-08.txt (PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation) to Informational RFC
Through confusion, I have perpetrated a major screw-up regarding this document and its companion, draft-ietf-pcn-sm-edge-behaviour. Somewhere around Christmas I received a number of comments on the two documents. I have fixed all of them except the comment requesting sections on operations and management considerations sections. I am wishing now that I had submitted interim updates reflecting that work, pending completion of the new sections. For various reasons I haven't had the time or energy to finish the job. When our AD came out with a revised set of comments I was confused and failed to respond. At first when Last Call was issued I thought this would do no real harm, since many of the fixes were really just editorial. Unfortunately, now that I look over some of the reviews, I realize that some substantive fixes were also included. As a result, I have wasted the time of a lot of people. I apologize to the community for this. What I propose is that I submit the documents with the fixes that were carried out, and the IESG restart the Last Call process. Failing that, I will go through and identify the substantive issues that need correction in any event. I note the discomfort with using the EXP code point. This is indirectly a matter of extensive debate in the PCN WG. My own view is that the solution is as suggested, make the CL-edge-behaviour draft Experimental rather than Informational. Tom Taylor, Editor On 27/05/2011 4:38 PM, The IESG wrote: The IESG has received a request from the Congestion and Pre-Congestion Notification WG (pcn) to consider the following document: - 'PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation' draft-ietf-pcn-cl-edge-behaviour-08.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 ietf@ietf.org mailing lists by 2011-06-10. 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 Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using three PCN marking states, not- marked, threshold-marked, and excess-traffic-marked. This behaviour is known informally as the Controlled Load (CL) PCN-boundary-node behaviour. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pcn-cl-edge-behaviour/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pcn-cl-edge-behaviour/ No IPR declarations have been submitted directly on this I-D. ___ PCN mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pcn ___ 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 Fri, Jun 10, 2011 at 9:18 AM, Noel Chiappa j...@mercury.lcs.mit.eduwrote: Mac OS 10.6.4, which uses 6to4 by default, has a ~50x greater failure rate when connecting to dual-stack servers than Mac OS 10.6.5 - and the only change is to not use 6to4 by default. ... So the existence of 6to4 is in itself a significant barrier for IPv6 deployment Surely you meant to say the _incorrect configuration_ of 6to4 is in itself a significant barrier? You cannot expect something to be configured correctly if it is simply turned on without a) being managed by someone or b) detection mechanisms to see if it's working. Sadly, anycasted 6to4 meets neither of these conditions. I get the impression that the problem comes in when 6to4 is configured on by default, and too high in the priority list (as opposed to native, other methods, etc). So fix the real issue, don't try and prematurely kill off something that's being used by lots of people. I fundamentally disagree. I really don't think that 6to4 is used by lots of people for applications that wouldn't just use (more reliable) IPv4 if 6to4 wasn't there. ___ 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 Fri, Jun 10, 2011 at 10:15 AM, james woodyatt j...@apple.com wrote: I don't want anybody to be misled by this statement. I think what Lorenzo meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 source addresses over 2002::/16 IPv6 source addresses. Yes, of course. I was trying to keep it short. ___ 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 10, 2011, at 09:38 , Lorenzo Colitti wrote: I fundamentally disagree. I really don't think that 6to4 is used by lots of people for applications that wouldn't just use (more reliable) IPv4 if 6to4 wasn't there. The same is often said about IPv6 in general. That's not meant to be snarky quip. When you limit the population under observation to just current IPv6 users and leave out the vast teeming masses of people who are routed IPv4-only, I suspect the data will show that a significant fraction of people are still using 6to4 as a general network-layer NAT-avoidance mechanism because it continues to work for them, setting up a manual tunnel-broker account takes an order of magnitude more effort, and who has time? 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. 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? -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
Michel, making 6to4 historic does not affect 6rd. I think the draft says that much too. I don't think we are saying that native necessarily is better than tunnels. we are saying unmanaged tunnels crossing the Internet is bad. 6rd is managed and contained within a single SP's network. cheers, Ole According to this: http://blogs.cisco.com/sp/france-is-famous-for-fine-wine-cheese-and-now- ipv6/ and some more recent direct talks in French, about half of worldwide IPv6 traffic is French. The bulk of it comes from a single ISP (Free, AS12322) and their IPv6 is 6RD (RFC5569, RFC5969), a variant of 6to4. Given the constant references in 6RD to 6to4, I will point out that making 6to4 historic somehow reduces the likeliness of another extremely successful ISP implementation based on it. Although Google (in http://www.pam2010.ethz.ch/papers/full-length/15.pdf) and other measurements classify AS12322's traffic as native, it is 6RD behind the scenes. If the argument is that IPv6 native should be the preferred solution over tunneled, it does not hold water. If you were to remove 6to4 and 6RD from the picture, that would set us back 10 years ago in terms of IPv6 adoption. Michel. ___ 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: one data point regarding native IPv6 support
On Jun 14, 2011, at 1:43 PM, Ole Troan wrote: making 6to4 historic does not affect 6rd. I think the draft says that much too. I don't think we are saying that native necessarily is better than tunnels. we are saying unmanaged tunnels crossing the Internet is bad. I think this misses the point. Most internet traffic is unmanged. The fact that in the case of 6to4 the traffic is protocol 41 doesn't affect this. The real problem here is that there are relay routers that advertise connectivity to one or both anycast addresses via BGP, that aren't properly managed. A related problem, I suppose, is that to a user, 6to4 looks like the network. And if there's a problem, the user will blame the network and ask the network support people to fix it. And quite often the problem is not in the access network but in another network. But (and please forgive my ignorance of operational issues) I don't see how that's inherently different from any case where there's a BGP advertisement to somewhere that blackholes traffic. Except maybe that there are a growing number of 6to4 users who can complain, and that all 6to4-related problems tend to get lumped together in the minds of support people even if they're caused by different networks and routers. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: one data point regarding native IPv6 support
Keith is correct, and the further issue is that the *-only-* reason the 'poorly managed' relays are in the path is that the content providers are refusing to deploy the matching 6to4 router that would take a direct connection from the customer. 6to4 direct between the content and consumer is still an 'unmanaged' tunnel which takes exactly the same path as IPv4 would, so the 'badness' is not due to managed vs. not. In the grand scheme of things, the last thing the content providers want is for the network to wrest control over streams into a walled-garden model. Unfortunately they are not thinking this through, they are just whining because the deployment of a second prefix on their content servers does not conform to their IPv4-think dream world. Tony -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Tuesday, June 14, 2011 10:56 AM To: Ole Troan Cc: Michel Py; IETF-Discussion Subject: Re: one data point regarding native IPv6 support On Jun 14, 2011, at 1:43 PM, Ole Troan wrote: making 6to4 historic does not affect 6rd. I think the draft says that much too. I don't think we are saying that native necessarily is better than tunnels. we are saying unmanaged tunnels crossing the Internet is bad. I think this misses the point. Most internet traffic is unmanged. The fact that in the case of 6to4 the traffic is protocol 41 doesn't affect this. The real problem here is that there are relay routers that advertise connectivity to one or both anycast addresses via BGP, that aren't properly managed. A related problem, I suppose, is that to a user, 6to4 looks like the network. And if there's a problem, the user will blame the network and ask the network support people to fix it. And quite often the problem is not in the access network but in another network. But (and please forgive my ignorance of operational issues) I don't see how that's inherently different from any case where there's a BGP advertisement to somewhere that blackholes traffic. Except maybe that there are a growing number of 6to4 users who can complain, and that all 6to4-related problems tend to get lumped together in the minds of support people even if they're caused by different networks and routers. Keith ___ 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: one data point regarding native IPv6 support
On Jun 14, 2011, at 2:16 PM, Tony Hain wrote: Keith is correct, and the further issue is that the *-only-* reason the 'poorly managed' relays are in the path is that the content providers are refusing to deploy the matching 6to4 router that would take a direct connection from the customer. Well, to be fair, they weren't supposed to have to get involved with 6to4 if they didn't want to. To the extent that 6to4 causes pain for operators that don't provide relay routers, this is a mostly-unanticipated and unintended consequence. (Operators weren't expected to *like* 6to4, because at the time 6to4 was written there was a general dislike for tunnels in general. But neither was it expected to cause them as much pain as it apparently does.) 6to4 direct between the content and consumer is still an 'unmanaged' tunnel which takes exactly the same path as IPv4 would, so the 'badness' is not due to managed vs. not. In the grand scheme of things, the last thing the content providers want is for the network to wrest control over streams into a walled-garden model. Unfortunately they are not thinking this through, they are just whining because the deployment of a second prefix on their content servers does not conform to their IPv4-think dream world. Though it's clear that some operators want to impose the walled garden, I think 6to4 can cause some pain even for those that don't. I'm hopeful that this pain will be short-lived and will be remedied in the short term by (a) relay router operators acting more responsibly, (b) content-providers providing their own 6to4 addresses, their own 6to4 gateways for return traffic, and/or (c) (less ideally) DNS tricks to minimize IPv6 exposure to networks known to have trouble with 6to4. In the not-so-much-longer term I hope the pain is relieved by widespread adoption of native IPv6 or at least managed transition schemes such as 6rd. But did we really expect there to not be growing pains associated with IPv6 transition and deployment? We certainly had them with IPv4 transition and deployment. After all, 6to4 is pretty much the ARPAnet/MILnet to Internet transition revisited; that's where I got the idea. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
On Jun 14, 2011, at 11:16 AM, Tony Hain wrote: Keith is correct, and the further issue is that the *-only-* reason the 'poorly managed' relays are in the path is that the content providers are refusing to deploy the matching 6to4 router that would take a direct connection from the customer. 6to4 direct between the content and consumer is still an 'unmanaged' tunnel which takes exactly the same path as IPv4 would, so the 'badness' is not due to managed vs. not. And the breakage still exists even if you do that. In the grand scheme of things, the last thing the content providers want is for the network to wrest control over streams into a walled-garden model. Unfortunately they are not thinking this through, they are just whining because the deployment of a second prefix on their content servers does not conform to their IPv4-think dream world. Really? More ip addresses on load balancers has never been a problem. Tony -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Tuesday, June 14, 2011 10:56 AM To: Ole Troan Cc: Michel Py; IETF-Discussion Subject: Re: one data point regarding native IPv6 support On Jun 14, 2011, at 1:43 PM, Ole Troan wrote: making 6to4 historic does not affect 6rd. I think the draft says that much too. I don't think we are saying that native necessarily is better than tunnels. we are saying unmanaged tunnels crossing the Internet is bad. I think this misses the point. Most internet traffic is unmanged. The fact that in the case of 6to4 the traffic is protocol 41 doesn't affect this. The real problem here is that there are relay routers that advertise connectivity to one or both anycast addresses via BGP, that aren't properly managed. A related problem, I suppose, is that to a user, 6to4 looks like the network. And if there's a problem, the user will blame the network and ask the network support people to fix it. And quite often the problem is not in the access network but in another network. But (and please forgive my ignorance of operational issues) I don't see how that's inherently different from any case where there's a BGP advertisement to somewhere that blackholes traffic. Except maybe that there are a growing number of 6to4 users who can complain, and that all 6to4-related problems tend to get lumped together in the minds of support people even if they're caused by different networks and routers. Keith ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
On Jun 14, 2011, at 2:36 PM, Joel Jaeggli wrote: On Jun 14, 2011, at 11:16 AM, Tony Hain wrote: Keith is correct, and the further issue is that the *-only-* reason the 'poorly managed' relays are in the path is that the content providers are refusing to deploy the matching 6to4 router that would take a direct connection from the customer. 6to4 direct between the content and consumer is still an 'unmanaged' tunnel which takes exactly the same path as IPv4 would, so the 'badness' is not due to managed vs. not. And the breakage still exists even if you do that. do what? As I understand it, the breakage mostly happens when the traffic doesn't take exactly the same path as IPv4 would, but rather when the traffic moves between the IPv4 world and the IPv6 world (or vice versa) via a relay router that's advertising a route to a network that it can't actually get traffic to. Though of course there are other sources of breakage: ISPs that filter protocol 41 (thus violating the best effort model); and NATs, including LSNs. Neither of these is 6to4's fault. The IPv4 network is supposed to make a best effort to convey traffic from source to destination, regardless of protocol type, without altering it other than the TTL field. If ISPs break 6to4 traffic by filtering protocol 41, that's clearly their fault. Likewise, if ISPs break 6to4 traffic by imposing NAT on their customers, that's also quite clearly their fault. It's not like we haven't known FOR TWENTY YEARS NOW (remember Kobe?) that the Internet was running out of addresses and had a standardized replacement in place FOR OVER FIFTEEN YEARS. If an ISP that has aggressively deployed IPv6 wants to whine about 6to4 support issues, I guess they have a legitimate gripe. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
On Jun 14, 2011, at 11:46 AM, Keith Moore wrote: On Jun 14, 2011, at 2:36 PM, Joel Jaeggli wrote: On Jun 14, 2011, at 11:16 AM, Tony Hain wrote: Keith is correct, and the further issue is that the *-only-* reason the 'poorly managed' relays are in the path is that the content providers are refusing to deploy the matching 6to4 router that would take a direct connection from the customer. 6to4 direct between the content and consumer is still an 'unmanaged' tunnel which takes exactly the same path as IPv4 would, so the 'badness' is not due to managed vs. not. And the breakage still exists even if you do that. do what? deploy your own relay, as observed by geoff and others that does not rehabilitate (by which I mean make it usable for those customers) 6to4. As I understand it, the breakage mostly happens when the traffic doesn't take exactly the same path as IPv4 would, but rather when the traffic moves between the IPv4 world and the IPv6 world (or vice versa) via a relay router that's advertising a route to a network that it can't actually get traffic to. Though of course there are other sources of breakage: ISPs that filter protocol 41 (thus violating the best effort model); and NATs, including LSNs. Neither of these is 6to4's fault. it results in a failure from the vantage point of the customer. you're splitting hairs pretty fine if you not willing to ascribe that to 6to4. The IPv4 network is supposed to make a best effort to convey traffic from source to destination, regardless of protocol type, without altering it other than the TTL field. If ISPs break 6to4 traffic by filtering protocol 41, that's clearly their fault. Likewise, if ISPs break 6to4 traffic by imposing NAT on their customers, that's also quite clearly their fault. It's not like we haven't known FOR TWENTY YEARS NOW (remember Kobe?) that the Internet was running out of addresses and had a standardized replacement in place FOR OVER FIFTEEN YEARS. If an ISP that has aggressively deployed IPv6 wants to whine about 6to4 support issues, I guess they have a legitimate gripe. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
On Jun 14, 2011, at 2:52 PM, Joel Jaeggli wrote: Keith is correct, and the further issue is that the *-only-* reason the 'poorly managed' relays are in the path is that the content providers are refusing to deploy the matching 6to4 router that would take a direct connection from the customer. 6to4 direct between the content and consumer is still an 'unmanaged' tunnel which takes exactly the same path as IPv4 would, so the 'badness' is not due to managed vs. not. And the breakage still exists even if you do that. do what? deploy your own relay, as observed by geoff and others that does not rehabilitate (by which I mean make it usable for those customers) 6to4. Ah yes. This reduces but does not eliminate the potential for breakage. Native IPv4 will still work better, and should generally be preferred over 6to4, for the cases where both endpoints have v4 addresses and the application can tolerate any NATs in the signal path. As I understand it, the breakage mostly happens when the traffic doesn't take exactly the same path as IPv4 would, but rather when the traffic moves between the IPv4 world and the IPv6 world (or vice versa) via a relay router that's advertising a route to a network that it can't actually get traffic to. Though of course there are other sources of breakage: ISPs that filter protocol 41 (thus violating the best effort model); and NATs, including LSNs. Neither of these is 6to4's fault. it results in a failure from the vantage point of the customer. you're splitting hairs pretty fine if you not willing to ascribe that to 6to4. Admittedly, to the customer's point-of-view the problems are associated with 6to4, or (more likely) IPv6 in general. But the problems can't be fixed by looking only at the vantage point of the customer. When network operators are the major cause of the problems, and they want to blame 6to4 for it... well, there's a word for that. Bottom line, that kind of attitude is not going to get the problem fixed either for 6to4 specifically or IPv6 in general. Keith ___ 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 Violeta, I am fine with the latest version of the document. Thank you, Yaron On 06/14/2011 09:41 PM, Cakulev, Violeta (Violeta) wrote: 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
RE: one data point regarding native IPv6 support
I did not say deploy you own relay ... that is braindead and doesn't even come close to understanding how the technology works. A 6to4 router at the content end is not a relay because it is strictly dealing with 2002:: on both sides. The only time a relay is required is to transit between the 2002:: prefix and the RIR prefixes. There is no reason to go there, but people insist because their IPv4-think myopia refuses to allow them to realize that their content server can simultaneously have an RIR prefix and a 2002:: prefix. Tony From: Joel Jaeggli [mailto:joe...@bogus.com] Sent: Tuesday, June 14, 2011 11:53 AM To: Keith Moore Cc: Tony Hain; 'Ole Troan'; 'Michel Py'; 'IETF-Discussion' Subject: Re: one data point regarding native IPv6 support On Jun 14, 2011, at 11:46 AM, Keith Moore wrote: On Jun 14, 2011, at 2:36 PM, Joel Jaeggli wrote: On Jun 14, 2011, at 11:16 AM, Tony Hain wrote: Keith is correct, and the further issue is that the *-only-* reason the 'poorly managed' relays are in the path is that the content providers are refusing to deploy the matching 6to4 router that would take a direct connection from the customer. 6to4 direct between the content and consumer is still an 'unmanaged' tunnel which takes exactly the same path as IPv4 would, so the 'badness' is not due to managed vs. not. And the breakage still exists even if you do that. do what? deploy your own relay, as observed by geoff and others that does not rehabilitate (by which I mean make it usable for those customers) 6to4. As I understand it, the breakage mostly happens when the traffic doesn't take exactly the same path as IPv4 would, but rather when the traffic moves between the IPv4 world and the IPv6 world (or vice versa) via a relay router that's advertising a route to a network that it can't actually get traffic to. Though of course there are other sources of breakage: ISPs that filter protocol 41 (thus violating the best effort model); and NATs, including LSNs. Neither of these is 6to4's fault. it results in a failure from the vantage point of the customer. you're splitting hairs pretty fine if you not willing to ascribe that to 6to4. The IPv4 network is supposed to make a best effort to convey traffic from source to destination, regardless of protocol type, without altering it other than the TTL field. If ISPs break 6to4 traffic by filtering protocol 41, that's clearly their fault. Likewise, if ISPs break 6to4 traffic by imposing NAT on their customers, that's also quite clearly their fault. It's not like we haven't known FOR TWENTY YEARS NOW (remember Kobe?) that the Internet was running out of addresses and had a standardized replacement in place FOR OVER FIFTEEN YEARS. If an ISP that has aggressively deployed IPv6 wants to whine about 6to4 support issues, I guess they have a legitimate gripe. Keith ___ 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
Resending, apologies if you see it twice. On 06/14/2011 11:18 PM, Yaron Sheffer wrote: Hi Violeta, I am fine with the latest version of the document. Thank you, Yaron On 06/14/2011 09:41 PM, Cakulev, Violeta (Violeta) wrote: 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
Re: one data point regarding native IPv6 support
From: Keith Moore mo...@network-heretics.com As I understand it, the breakage mostly happens when the traffic doesn't take exactly the same path as IPv4 would, but rather when the traffic moves between the IPv4 world and the IPv6 world (or vice versa) via a relay router that's advertising a route to a network that it can't actually get traffic to. Though of course there are other sources of breakage: ISPs that filter protocol 41 ... and NATs, Keith, I'm not sure that relay routers advertising incorrectly are the main problem (although none of the studies I've looked at are really comprehensive in terms of data on _all_ causes of 6to4 failure, especially on failures on the path _from_ the 6to4 host, which are obviously sort of impossible to detect at servers). First, RFC-3068 does say: Any 6to4 relay router corresponding to this specification must include a monitoring function, to check that the 6to4 relay function is operational. The router must stop injecting the route leading to the 6to4 anycast prefix immediately if it detects that the relay function is not operational. So if the 6to4 relay is operating properly, it shouldn't be advertising into the IPv4 world (i.e. using the anycast address) unless it has 'good' IPv6 connectivity, or into the IPv6 world (i.e. advertising the 6to4 block) unless it has 'good' IPv4 connectivity. (Advertising only the 6to4 variants of those pieces of the IPv4 space which it definitely has routes to is not allowed by the spec; reasonably, as it would add the size of the IPv4 routing table to the IPv6 routing table.) I'm not sure how exactly various boxes measure 'good' connectivity (and of course a poor implementation might not do a good job of this), but in _theory_ it shouldn't be the worst part of the problem. Second, while I don't know about failures on the '4to6_host-relay_router' (i.e. outbound) part of the path, when I read: http://www.potaroo.net/ispcol/2010-12/6to4fail.html it looked into failures on the 'relay_router-4to6_host' (i.e. inbound) path, and there, of the failures which were not due to a problem in the relay router itself, many were caused by failures on the inbound path between the relay router and the 4to6_host, failures which may well be not the fault of the ISP: - roughly 25% because of the presence of a NAT between the relay router and the 4to6 host (so that the host did not know its public IPv4 address, and probably didn't have a way to get packets to itself even if it did) - roughly 75% because of the presence of some device between the relay router and the 4to6 host that filtered _inbound_ protocol 41 (so that the host cannot get any return 6to4 traffic) While we don't know exactly what share of the overall 6to4 'problem' these two cause, we can guess that it's likely quite substantial: 'paranoid' firewalls are common, and NAT boxes are basically ubiquitous (anyone with IP service at home, and a wireless laptop - which is a lot of people - will have one). Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
In message 20110615022008.0816818c...@mercury.lcs.mit.edu, Noel Chiappa write s: From: Keith Moore mo...@network-heretics.com As I understand it, the breakage mostly happens when the traffic doesn't take exactly the same path as IPv4 would, but rather when the traffic moves between the IPv4 world and the IPv6 world (or vice versa) via a relay router that's advertising a route to a network that it can't actually get traffic to. Though of course there are other sources of breakage: ISPs that filter protocol 41 ... and NATs, Keith, I'm not sure that relay routers advertising incorrectly are the main problem (although none of the studies I've looked at are really comprehensive in terms of data on _all_ causes of 6to4 failure, especially on failures on the path _from_ the 6to4 host, which are obviously sort of impossible to detect at servers). First, RFC-3068 does say: Any 6to4 relay router corresponding to this specification must include a monitoring function, to check that the 6to4 relay function is operational. The router must stop injecting the route leading to the 6to4 anycast prefix immediately if it detects that the relay function is not operational. So if the 6to4 relay is operating properly, it shouldn't be advertising into the IPv4 world (i.e. using the anycast address) unless it has 'good' IPv6 connectivity, or into the IPv6 world (i.e. advertising the 6to4 block) unless it has 'good' IPv4 connectivity. (Advertising only the 6to4 variants of those pieces of the IPv4 space which it definitely has routes to is not allowed by the spec; reasonably, as it would add the size of the IPv4 routing table to the IPv6 routing table.) I'm not sure how exactly various boxes measure 'good' connectivity (and of course a poor implementation might not do a good job of this), but in _theory_ it shouldn't be the worst part of the problem. Second, while I don't know about failures on the '4to6_host-relay_router' (i.e. outbound) part of the path, when I read: http://www.potaroo.net/ispcol/2010-12/6to4fail.html it looked into failures on the 'relay_router-4to6_host' (i.e. inbound) path, and there, of the failures which were not due to a problem in the relay router itself, many were caused by failures on the inbound path between the relay router and the 4to6_host, failures which may well be not the fault of the ISP: - roughly 25% because of the presence of a NAT between the relay router and the 4to6 host (so that the host did not know its public IPv4 address, and probably didn't have a way to get packets to itself even if it did) Presumable non-RFC 1918 internal addresses being NAT'd as RFC 1918 address are already verboten. - roughly 75% because of the presence of some device between the relay router and the 4to6 host that filtered _inbound_ protocol 41 (so that the host canno t get any return 6to4 traffic) While we don't know exactly what share of the overall 6to4 'problem' these tw o cause, we can guess that it's likely quite substantial: 'paranoid' firewalls are common, and NAT boxes are basically ubiquitous (anyone with IP service at home, and a wireless laptop - which is a lot of people - will have one). And making 6to4 historic fixes these without breaking 6to4 for those that it works for how? draft-andrews-v6ops-6to4-router-option-02.txt provides a mechanism which allows network operators for signal that 6to4 should not be used in both of the above cases. Similarly testing that you can reach the 6to4 relay router before adding a route pointing to it or advertising a 6to4 prefix is a good backup without the option however no all 6to4 relays have machine listening on the all zeros address. HE for example listens on 2002:c058:6301::1 so you can't just ping it. A I-D saying how to test if a 6to4 relay is up may be needed. Mark Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- 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
WG Review: Content Delivery Networks Interconnection (cdni)
A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, June 21, 2011. Content Delivery Networks Interconnection (cdni) Current Status: Proposed Working Group Last updated: 2011-05-27 Chairs: TBD Transport Area Directors: Wesley Eddy w...@mti-systems.com David Harrington ietf...@comcast.net Transport Area Advisor: David Harrington ietf...@comcast.net Mailing lists: Address: c...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cdni Archive: http://www.ietf.org/mail-archive/web/cdni/ Description of Working Group: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A problem statement document providing a description of the problem and a common terminology. - A use case document describing scenarios for usage and applications of the CDNI solution and protocols. - A framework document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a threat analysis discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A requirements document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent and important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A specification of the CDNI request-routing interface. This interface will allow an upstream CDN request routing system to obtain from the downstream CDN the information necessary to perform request redirection. - A specification of the CDNI metadata interface. This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the CDNI logging interface. This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the CDNI control interface.
WG Action: IPv6 Site Renumbering (6renum)
A new IETF working group has been formed in the Operations and Management Area. For additional information, please contact the Area Directors or the WG Chairs. IPv6 Site Renumbering (6renum) --- Current Status: Active Working Group Chair: Tim Chown t...@ecs.soton.ac.uk Operations and Management Area Directors: Ron Bonica rbon...@juniper.net Dan Romascanu droma...@avaya.com Operations and Management Area Advisor: Ron Bonica rbon...@juniper.net Mailing list Address: re...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/renum Archive: http://www.ietf.org/mail-archive/web/renum/ Description --- As outlined in RFC 5887, renumbering, especially for medium to large sites and networks, is currently viewed as an expensive, painful, and error-prone process, avoided by network managers as much as possible. As that RFC describes, there are triggers that mean some cases of renumbering are unavoidable, so it should be considered a given that a site may need partial or complete renumbering at some stage. It is thus important to implement and deploy techniques that facilitate simpler IPv6 site renumbering, so that as IPv6 becomes universally deployed, renumbering can be viewed as a more routine event. This includes consideration of how the initial assignment and subsequent management of address information is performed, as this will affect future renumbering operations. If IPv6 site renumbering continues to be considered difficult, network managers will turn to PI addressing for IPv6 to attempt to minimise the need for future renumbering. However, widespread use of PI may create very serious BGP4 scaling problems. It is thus desirable to develop tools and practices that may make renumbering a simpler process to reduce demand for IPv6 PI space. Renumbering, or partial renumbering, can be complicated in an enterprise site where a short prefix is divided into subnets with longer prefixes. Aggregation, synchronisation, coordination, etc., need to be carefully managed, and the use of manually inserted address literals minimised. Other factors such as applications binding long-term to low level IP addresses may add constraints to what can be realistically achieved, but identifying and documenting such factors is a useful objective. In some scenarios, consideration may also need to be made for 'flag day' renumbering (in contrast to the procedure described in RFC4192). The task of the 6RENUM working group is to document existing renumbering practices for enterprise site networks and to identify specific renumbering problems or 'gaps' in the context of partial or site-wide renumbering. Completion of these tasks should provide a basis for future work to identify and develop point solutions or system solutions to address those problems or to stimulate such development in other working groups as appropriate. 6RENUM is chartered to perform an analysis of IPv6 site renumbering. If the analysis leads to conclusions that are also applicable to IPv4 that will be an advantage, but it is not an objective of the WG to make its outputs more widely available than IPv6. Similarly the WG is targeting enterprise networks, but the analysis may also be applicable to SOHO or other (e.g. ad-hoc) scenarios. It may be that for site renumbering to become more routine, a systematic address management approach will be required. By documenting current practices and undertaking a gap analysis, we should become better informed of the requirements of such an approach. Post-analysis rechartering may lead to further work in this area. RFC 4192, RFC 5887, and draft-jiang-ipv6-site-renum-guideline are starting points for this work. Goals/deliverables -- The goals of the 6RENUM working group are: 1. To undertake scenario descriptions, including documentation of current capability inventories and existing BCPs, for enterprise networks, including managed and unmanaged elements. These texts should contribute towards a gap analysis and provide an agreed basis for subsequent WG rechartering towards development of solutions (which may be more appropriate for other WGs to undertake) and improved practices. Operator input will be of high value for this text. 2. To perform a gap analysis for renumbering practices, to identify generic issues for network design, network management, address management and renumbering operations. The methodology for the WG will be to begin building the enterprise scenario description while in parallel constructing an initial gap analysis drawing on existing work in (at least) RFC4192 and RFC5887. As the scenario text hardens, its contributions will be incorporated into the more detailed gap analysis, which can be published once the scenario text is completed. The deliverables are thus the scenario and gap analysis texts. The following topics are out of scope for the working group:
WG Action: Protocol to Access White Space Databases (paws)
A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. Protocol to Access White Space Databases (paws) Current Status: Active Working Group Chairs: Gabor Bajko gabor.ba...@nokia.com Brian Rosen brian.ro...@neustar.biz Applications Area Directors: Pete Resnick presn...@qualcomm.com Peter Saint-Andre stpe...@stpeter.im Applications Area Advisor: Peter Saint-Andre stpe...@stpeter.im Mailing lists: General Discussion: p...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/paws Archive: http://www.ietf.org/mail-archive/web/paws/ Description of Working Group: Background Radio spectrum is a limited resource. National and international bodies assign different frequencies for specific uses, and in most cases license the rights to use these frequencies. Locally unused spectrum is commonly called white space and may be made available to other services on a basis of non-interference with the primary user of the frequencies concerned (if any). This technique can help unlock existing spectrum, for example to enable the wireless communications industry to provide more services over frequencies associated with unused television channels. An obvious requirement is that white space uses must not interfere with the primary use of the spectrum. This is achieved through spatial and/or temporal separation of the primary user and whitespace user with due consideration made to the radio characteristics of the two uses. Problem Statement The fundamental problem is enabling a radio device to determine, in a specific location and at specific time, if any white space is available for secondary use. There are two parties to such an interaction: 1. A database containing records about the protected contours (in space and time) of primary spectrum users. Typically, such databases will be populated by information provided by the appropriate spectrum regulation bodies and by spectrum licensees. 2. A radio device that wishes to query such a database. Typically, the nature of the query will depend on the needs of the device. The contents of white space databases, and the needs of radio devices, are being defined elsewhere. However, these parties need a protocol for communication that will enable radio devices to find out what white space is available at a given time in a given location. It is expected that white space databases will be reachable via the Internet, and that radio devices too will have some form of Internet connectivity, directly or indirectly. Therefore, it is appropriate to define an Internet-based protocol for querying white space databases and receiving responses from such databases. In rough outline, such a protocol would enable a radio device that knows its location and the current time to complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined access method. 3. Provide its geolocation and perhaps other data to the database using a well-defined format for querying the database. 4. Receive in return a list of currently available white space using a well-defined format for returning information. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database. 2. Standardize a method for accessing a white space database. 3. Standardize query and response formats to be carried over the database access method. 4. Ensure that the discovery mechanism, database access method, and query/response formats have appropriate security levels in place. By standardize is not meant that the working group will necessarily develop new technologies. In completing its work, the group will: - Evaluate existing discovery mechanisms to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for discovering a white space database. Examples might include DNS. - Evaluate existing application-layer transport protocols to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for use as a building block for communication between location- aware devices and white space databases. If such a method exists, the group will reuse it; if not, the group will
WG Action: RECHARTER: Web Authorization Protocol Working Group (oauth)
The Web Authorization Protocol Working Group (oauth) in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Web Authorization Protocol Working Group (oauth) --- Current Status: Active Working Group Chairs: Barry Leiba barryle...@computer.org Hannes Tschofenig hannes.tschofe...@gmx.net Blaine Cook rom...@gmail.com Security Area Directors: Stephen Farrell stephen.farr...@cs.tcd.ie Sean Turner turn...@ieca.com Security Area Advisor: Stephen Farrell stephen.farr...@cs.tcd.ie Technical Advisor: Peter Saint-Andre stpe...@stpeter.im Mailing List: Address: oa...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/oauth Archive: http://www.ietf.org/mail-archive/web/oauth/ Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account. OAuth encompasses * a mechanism for a user to authorize issuance of credentials that a third party can use to access resources on the user's behalf and * a mechanism for using the issued credentials to authenticate HTTP requests. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). The working group has since been developing OAuth 2.0, a standards-track version that will reflect IETF consensus. Version 2.0 will consider the implementation experience with version 1.0, a discovered security vulnerability (session fixation attack), the use cases and functionality proposed with OAuth WRAP [draft-hardt-oauth-01] and will * improve the terminology used, * consider broader use cases, * embody good security practices, * improve interoperability, and * provide guidelines for extensibility. The working group will develop authentication schemes for peers/servers taking part in OAuth (accessing protected resources). This includes * an HMAC-based authentication mechanism This document aims to provide a general purpose MAC authentication scheme that can be used both with OAuth 2.0 but also with other use cases. The WG will work with the security and applications area directors to ensure that this work gets appropriate review, e.g. via additional last calls in other relevant working groups such as HTTPBIS, * a specification for access protected by Transport Layer Security (bearer tokens), * an extension to OAuth 2.0 to allow access tokens to be requested when a client is in possession of a SAML assertion. A separate informational description will be produced to provide additional security analysis for audiences beyond the community of protocol implementers. Milestones will be added for the later items after the near-term work has been completed. Goals and Milestones May 2011Submit 'HTTP Authentication: MAC Authentication' as a working group item May 2011Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Jul 2011Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard Jul 2011Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Aug 2011Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard Oct 2011Submit 'SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0' to the IESG for consideration as a Proposed Standard Oct 2011Re-chartering working group ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'The A+P Approach to the IPv4 Address Shortage' to Experimental RFC (draft-ymbk-aplusp-10.txt)
The IESG has approved the following document: - 'The A+P Approach to the IPv4 Address Shortage' (draft-ymbk-aplusp-10.txt) as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ymbk-aplusp/ Technical Summary We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4-world without assigning a unique globally routable IPv4 address to each of them is a challenging problem. This draft proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional end point identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., CPE, mobile phones), each with its assigned port-range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process - not some smart boxes in the core. Working Group Summary This document is not the product of a working group. Document Quality - Are there existing implementations of the protocol? Yes, one (ISC AFTR A+P support), but without dynamic port allocations and no stateless support. Other implementations to follow, one of obstacles is current status (draft). - Have a significant number of vendors indicated their plan to implement the specification? Iskratel, possibly Cisco and Juniper. - Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? All last version thorough reviewers are now among authors: Mohammed Boucadair (FT) Reinaldo Penno (Juniper) Personnel Ron Bonica is document shepherd ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'SIP (Session Initiation Protocol) Usage of the Offer/Answer Model' to Informational RFC (draft-ietf-sipping-sip-offeranswer-18.txt)
The IESG has approved the following document: - 'SIP (Session Initiation Protocol) Usage of the Offer/Answer Model' (draft-ietf-sipping-sip-offeranswer-18.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipping-sip-offeranswer/ Technical Summary The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication. Also, this document tries to incorporate the results of the discussions on the controversial issues to avoid repeating the same discussions later. This document does not make normative changes. Rather, it recommends how to use the existing standards to best effect. Working Group Summary This document began in the SIPPING working group, which reached consensus to request publication of an earlier version. After IETF Last Call, the community identified several significant changes and additions to the document. There has been discussion around whether the document should be PS or BCP instead of informational, with the consensus being that this document should be published as is to capture discussion to date and inform any future efforts to update the various proposed standards it references. Document Quality This document has received detailed revew from Christer Holmberg, Rajeev Seth, Nataraju A B, Byron Campen, Jonathan Rosenberg, Gonzalo Camarillo, Yang Gao, and Ben Campbell. Personnel Mary Barnes is the document's shepherd, Robert Sparks is the responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
New Non-WG Mailing List: webapps -- Impact of web technologies on the future of applications development
A new IETF non-working group email list has been created. List address: weba...@ietf.org Archive: http://www.ietf.org/mail-archive/web/webapps/ To subscribe: https://www.ietf.org/mailman/listinfo/webapps Description: Post-IETF-80 discussion of the impact of .js, HTML5 and related work on the future of applications development. For additional information, please contact the list administrators. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-fecframe-framework-15.txt (Forward Error Correction (FEC) Framework) to Proposed Standard
The IESG has received a request from the FEC Framework WG (fecframe) to consider the following document: - 'Forward Error Correction (FEC) Framework' draft-ietf-fecframe-framework-15.txt as a Proposed Standard The IESG reviewed this draft and requested substantial changes. This is a second Last Call, running for one week, to ensure the community has an opportunity to review the changes. 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-22. 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 describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC scheme, and FEC schemes can be defined which are not specific to a particular Content Delivery Protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ 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
WG Action: Conclusion of Virtual Router Redundancy Protocol (vrrp)
The Virtual Router Redundancy Protocol (vrrp) working group in the Routing Area has concluded. The IESG contact persons are Adrian Farrel and Stewart Bryant. The mailing list will remain active. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
