Re: [IPsec] AD review: draft-nir-ipsecme-erx-04.txt
Hi Sean Thanks for the review. My answers are inline. Yoav On Jul 3, 2012, at 2:17 AM, Sean Turner wrote: Yoav asked me to do an AD review of draft-nir-ipsecme-erx. We agreed that it'd be all right for me to send my comments here. They are as follows: 0) Overall: A couple of folks that I mentioned this to asked: is anybody really doing ERP? So I'm just curious if they are. This obviously non-blocking. My guess is that it is not widely deployed, because 802.1x is for now not widely deployed. EAP is used in some other contexts, like L2TP VPN clients and cable modem/ADSL dialers, but those don't tend to need support for roaming. 1) General: In case people missed it, the first EAP message for ERX is moved to the initial IKE_AUTH request. I haven't seen any objections to this but I'd like to make sure implementers are okay with this!? Maybe it's splitting hairs but could you do the following to maintain architectural integrity/purity (i.e., not mix them): first request -- EAP(EAP_Initiate/Re-auth), be this: first request -- N[EAP(EAP_Initiate/Re-auth)], I guess you could do the same thing for the first response. The responder has indicated support for ERX in the Initial exchange response, so it is expecting to get an EAP message in the first IKE_AUTH request. I guess architectural integrity is a matter of taste, but to me it seems that EAP messages should go in EAP payloads rather than Notify payloads. 2) expand AAA on first use Last paragraph of section 2. OK, will do. 3) s3 contains the following: This Notify replaces the EAP-Initiate/Re-auth-Start message of ERX, and therefore contains the domain name, as specified in section 5.3.1.1 of [RFC5296bis]. Is replaces the right word here? I think what you're saying is that the Notify serves the same purpose as the ERX EAP-Initiate/Re-auth-Start message? I went to 5.3.1.1 and I think what you're really pointing to is the Domain-Name in 5.3.1, which is an NAI from [RFC4282]? Maybe switch the pointer to 5.3.1. Right about the replace. Section 5.3.1.1 talks about the authenticator operation (sending the EAP-Initiate/Re-auth-Start message and including the domain name TLV), so it seemed appropriate. On the other hand 5.3.1 contains the format of the EAP message, which is different from that of the IKEv2 Notify payload. How about: This Notify serves the same purpose as the EAP-Initiate/Re-auth-Start message of ERX, as specified in section 5.3.1 or [RFC5296bis]. The domain name included in the payload is the same as that included in the Domain-Name TLV as specified in section 5.3.1.1 or the same document. 4) s3: In the intro to the protocol exchanges it says most of the optional bits are omitted, but that seems to only be true in the IKE_SA_INIT exchanges. Could the IKE_AUTH exchanged be trimmed down to (and depending on comment 0 the first line gets changed too): first request -- EAP(EAP_Initiate/Re-auth), IDi, SA, TSi, TSr, first response -- IDr, AUTH, EAP(EAP-Finish/Re-auth), last request-- AUTH last response -- AUTH, SA, TSi, TSr, Just curious if those optional fields aren't so optional anymore. You're right. I will, however leave the CERT payload in there, so as not to have this imply that we're not using certs anymore (we're not requiring RFC 5998 compliance) 5) s3: Do you think the following would help the not so plugged in reader to add the following to the figure of the exchanges: IKE_SA_INIT +- |init request -- SA, KE, Ni, | | | |init response -- SA, KE, Nr, +- N[ERX_SUPPORTED] IKE_AUTH Exchange with EAP +- |first request -- EAP(EAP_Initiate/Re-auth), |IDi, |SA, TSi, TSr, | |first response -- IDr, AUTH, |EAP(EAP-Finish/Re-auth), | |last request-- AUTH | |last response -- AUTH, |SA, TSi, TSr, +- I guess so. I'll add headlines next version. 6) s3/6: Don't you have to register the Identification Payload type in IKEv2 Identification Payload ID Types? I don't think so. ID_RFC822_ADDR is already registered, and that is the format of the KeyName-NAI. 7) s3.1: I think you need to be clear that the codes 5 and 6 came from RFC 5296: r/(5 and 6)/(5 and 6) [RFC5296] and maybe: r/or in this document/or in [RFC5296] To clarify, an implementation supporting this specification MUST accept and transmit EAP messages with at least the codes for Initiate and Finish (5 and 6) (RFC5296bis]), in addition to the four codes enumerated in RFC 5996. This
RE: Future Handling of Blue Sheets
This creates a distinguished identity, so if two Fei Zhangs attended in Paris (only case I found in the attendee list), this would distinguish which of them attended a particular meeting. It would not, however, tie them to an identity on the mailing list, or to the Fei Zhang who attends the Vancouver meeting, so I'm not sure what purpose it serves. Yoav -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Tim Chown Sent: 16 June 2012 13:54 To: Joel jaeggli Cc: IETF Chair; IETF; ietf-boun...@ietf.org Subject: Re: Future Handling of Blue Sheets If the purpose is simply differentiation of people with the same names, could we not ask people to enter the last four digits of their IETF registration number, which would presumably be unique, while being easy to remember? The number could even be on your badge to always be easy to look up. Unless there's some reason to keep registration numbers private? That would also allow poorly handwritten names to more readily be checked/corrected by OCR when the sheets are scanned. Tim On 16 Jun 2012, at 04:50, Joel jaeggli wrote: On 6/15/12 14:42 , edj@gmail.com wrote: I presume it is the same data that people input into the Organization field when they register for the meeting. I do change mine based on what capacity I'm attending a particular meeting in. That goes for email address on existing blue sheets as well... The nice people who send me a check every two weeks don't generally fund my attendance. Regards, Ed J. -Original Message- From: Eric Burger eburge...@standardstrack.com Sender: ietf-boun...@ietf.org Date: Fri, 15 Jun 2012 17:37:50 To: IETF Chairch...@ietf.org Cc: IETFietf@ietf.org Subject: Re: Future Handling of Blue Sheets Do we have guidelines as to what is an organization affiliation? On Jun 14, 2012, at 5:26 PM, IETF Chair wrote: Two things have occurred since the message below as sent to the IETF mail list. First, we got a lawyer in Europe to do some investigation, and the inclusion of the email address on the blue sheet will lead to trouble with the European privacy laws. Second, Ted Hardie suggested that we could require a password to access the scanned blue sheet. Based on the European privacy law information, the use of email will result in a major burden. If the email address is used, then we must provide a way for people to ask for their email address to be remove at any time in the future, even if we got prior approval to include it. Therefore, I suggest that we collect organization affiliation to discriminate between multiple people with the same name instead of email address. Based on Ted's suggestion, I checked with the Secretariat about using a datatracker login to download the scanned blue sheet. This is fairly easy to do, once the community tracking tools are deployed. However, with the removal of the email addresses from the blue sheets, it is unclear that there is any further need for password protection of these images. Therefore, I suggest that we proceed without password protection for the blue sheet images. Here is a summary of the suggested way forward: - Stop collecting email addresses on blue sheets; - Collect organization affiliation to discriminate between multiple people with the same name; - Scan the blue sheets and include the images in the proceedings for the WG session; - Add indication to top of the blue sheet so people know it will be part of the proceedings; and - Discard paper blue sheets after scanning. Russ On May 6, 2012, at 12:46 PM, IETF Chair wrote: We have heard from many community participants, and consensus is quite rough on this topic. The IESG discussed this thread and reached two conclusions: (1) Rough consensus: an open and transparent standards process is more important to the IETF than privacy of blue sheet information. (2) Rough consensus: inclusion of email addresses is a good way to distinguish participants with the same or similar names. Based on these conclusions, the plan is to handle blue sheets as follows: - Continue to collect email addresses on blue sheets; - Scan the blue sheet and include the image in the proceedings for the WG session; - Add indication to top of the blue sheet so people know it will be part of the proceedings; and - Discard paper blue sheets after scanning. On behalf of the IESG, Russ Scanned by Check Point Total Security Gateway.
Re: New Non-WG Mailing List: IETF-822
On Jun 15, 2012, at 12:44 AM, Peter Saint-Andre wrote: On 6/14/12 3:37 PM, IETF Secretariat wrote: List address: ietf-...@ietf.org Is no one thinking ahead to the 822nd meeting of the IETF in the year 2258?!? Well, I've started working on draft-nir-ipv6-were-finally-deploying-it but I'm not sure what format would be an appropriate submission format in the 23rd century. Doesn't it coincide with the 1st season of Babylon 5? Yoav
Re: [IPsec] New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt
On Jun 15, 2012, at 1:34 PM, Tero Kivinen wrote: 2. Since INIT always happens over UDP, as responder, I can immediately close any TCP connection that doesn't present an IKE header with an SPI I recognize. I don't agree that IKE_SA_INIT should always be over UDP. The first flight of packets from the server in TCP includes at most 2 packets. Then the server has to wait for an ACK to continue. Same goes for the request. So beginning with the IKE_AUTH exchange for TCP can add up to three roundtrips. This is a shame when dealing with a peer that we know supports IKE. I do not understand your statement above. Especially what does server has to wait for an ACK to continue? If there is space in window there is no need to wait for ACKs, you can just send next packet to the other end immediately when you have it. The application (in this context that is the IKE implementation) does not need to wait, it can send everything immediately. But TCP has slow start. Depending on OS, the first flight can be either 1 or 2 segments. If your IKE_AUTH message takes more than two segments, the third segment will wait for a TCP ack, effectively adding a round-trip. If you do the IKE_SA_INIT over TCP as well, then the ACK for the IKE_SA_INIT (usually delivered in the IKE_SA_INIT response) doubles the receive window, so the next request can be up to four segments. I don't think this is particularly significant, but this issue has come up in proposals for TLS, where the ServerHello-Certificate-[ServerKeyExchange]-ServerHelloDone flight can be very large, and break the 2 segment limit. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt
Hi Yaron Responses are inline. Yoav On Jun 14, 2012, at 1:40 AM, Yaron Sheffer wrote: Hi Yoav, thank you for the new draft. A few comments: - Please mention the question of IKE keepalive messages (liveness check). Do you expect these messages to each be on a new connection? Or to preserve one long-lived one? I think section 2.1 makes it clear that the TCP connections should be short-lived. Specifically, I would not send liveness checks, which are very short requests and responses over TCP. I would use UDP exclusively for those. - The draft kind of skirts the question, and I would prefer to be clear: we are standardizing new behavior for IKEv2, not for IKEv1. I think it's suitable for both versions. If this gets adopted by the working group, and people object to standardizing new stuff for IKEv1, I can remove all mention of it. hat type=vendor Our present implementation works with IKEv1, and has done so for over 10 years. I could submit an Informational describing how Check Point's implementation does IKEv1 over TCP. But just as new ciphers would apply to both versions, I think this transport can also be independent of version. /hat - In the security considerations, we should mention that (under certain assumptions), it is easier for an off-path attacker to reset a TCP connection than a UDP connection. Yes, TCP presents some DoS opportunities not available for UDP. I'll look for an RFC that talks about this. And if there isn't one, there d**n well should be. - There are obvious advantages to negotiating this capability: you don't have clients sending SYNs that will get rejected by firewalls/endpoints. Especially in IKEv2 where the heavy stuff only happens on message #3. SYN/SYN-ACK or SYN/RST is a kind of negotiation. Besides, sending a notification over UDP that says I support TCP doesn't help much, because it cannot vouch for the path allowing TCP port 500. I wonder if there's an actual use case for increasing the length field of payloads, so that IKE can support larger payloads when working over TCP. One use for this would be to send large CRLs in a CERT payload. - 2.3: disallowing retransmissions implies a change on both transmitter and receiver, and I think this is unnecessary. You can change the IKE timeouts on the sender to achieve the same behavior, even if rarely an odd retransmission does slip through. I guess. There is a MUST in section 2.4 for keeping retransmission detection, so when implementing the transmitter, you can do either. It doesn't make sense to retransmit at the application level when TCP does it for you. Thanks, Yaron On 06/14/2012 12:59 AM, Yoav Nir wrote: Hi I've submitted this draft as a possible solution to the problem discussed in the thread about fragmentation causing IKE to fail. Comments are welcome. Yoav Begin forwarded message: *From: *internet-dra...@ietf.org mailto:internet-dra...@ietf.org internet-dra...@ietf.org mailto:internet-dra...@ietf.org *Subject: **New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt* *Date: *June 13, 2012 7:13:55 PM GMT+03:00 *To: *Yoav Nir y...@checkpoint.com mailto:y...@checkpoint.com A new version of I-D, draft-nir-ipsecme-ike-tcp-00.txt has been successfully submitted by Yoav Nir and posted to the IETF repository. Filename:draft-nir-ipsecme-ike-tcp Revision:00 Title:A TCP transport for the Internet Key Exchange Creation date:2012-06-13 WG ID:Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-tcp-00.txt Status: http://datatracker.ietf.org/doc/draft-nir-ipsecme-ike-tcp Htmlized: http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp-00 Abstract: This document describes using TCP for IKE messages. This facilitates the transport of large messages over paths where fragments are dropped. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt
On Jun 14, 2012, at 10:34 PM, John Leser wrote: On 06/14/12 13:39, Yoav Nir wrote: Hi Yaron Responses are inline. Yoav On Jun 14, 2012, at 1:40 AM, Yaron Sheffer wrote: Hi Yoav, thank you for the new draft. A few comments: - Please mention the question of IKE keepalive messages (liveness check). Do you expect these messages to each be on a new connection? Or to preserve one long-lived one? I think section 2.1 makes it clear that the TCP connections should be short-lived. Specifically, I would not send liveness checks, which are very short requests and responses over TCP. I would use UDP exclusively for those. This section is a little unclear to me. Is the idea that the initiator of the exchange(s) may send up to IKEv2 request window requests, wait for the responses to arrive and then must close the connection? Or can the initiator perform as many exchanges as it likes over one TCP connection, so long as knows that it has requests it wants to send? If this connection closing requirement is designed to interact with the IKEv2 request window, please make it more clear. OK, I will. It has nothing to do with the request window. The Initiator can send as many requests as it wants as long as it has any to send. When it's idle (like if all the necessary child SAs are ready) it should close the connection rather than leave it idle. - The draft kind of skirts the question, and I would prefer to be clear: we are standardizing new behavior for IKEv2, not for IKEv1. I think it's suitable for both versions. If this gets adopted by the working group, and people object to standardizing new stuff for IKEv1, I can remove all mention of it. hat type=vendor Our present implementation works with IKEv1, and has done so for over 10 years. I could submit an Informational describing how Check Point's implementation does IKEv1 over TCP. But just as new ciphers would apply to both versions, I think this transport can also be independent of version. /hat I'd rather settle on the best possible solution for IKEv2 without worrying about making sure it works for IKEv1 as well. If that's where the group consensus is going, I am fine with making an Informational document about IKEv1 over TCP in CP products. - In the security considerations, we should mention that (under certain assumptions), it is easier for an off-path attacker to reset a TCP connection than a UDP connection. Yes, TCP presents some DoS opportunities not available for UDP. I'll look for an RFC that talks about this. And if there isn't one, there d**n well should be. I suggest adding a MUST that a lost TCP connection or truncated packet from the peer should never constitute a failed exchange (which in many cases, closes the SA). Agree - There are obvious advantages to negotiating this capability: you don't have clients sending SYNs that will get rejected by firewalls/endpoints. Especially in IKEv2 where the heavy stuff only happens on message #3. SYN/SYN-ACK or SYN/RST is a kind of negotiation. Besides, sending a notification over UDP that says I support TCP doesn't help much, because it cannot vouch for the path allowing TCP port 500. I wonder if there's an actual use case for increasing the length field of payloads, so that IKE can support larger payloads when working over TCP. One use for this would be to send large CRLs in a CERT payload. I agree with the concerns Yaron has raised here. I would much prefer that this be negotiated via notifications during the SA_INIT exchange. I see a number of benefits: 1. The TCP listening port could be explicitly exchanged (as data in the notification), rather than always assumed 500. This would allow operation in parallel with any legacy/proprietary use of that server port, and in general more deployment flexibility. 2. Since INIT always happens over UDP, as responder, I can immediately close any TCP connection that doesn't present an IKE header with an SPI I recognize. I don't agree that IKE_SA_INIT should always be over UDP. The first flight of packets from the server in TCP includes at most 2 packets. Then the server has to wait for an ACK to continue. Same goes for the request. So beginning with the IKE_AUTH exchange for TCP can add up to three roundtrips. This is a shame when dealing with a peer that we know supports IKE. 3. It fits better with the IKEv2 design of never assuming the peer has capabilities beyond the base requirements without a notification/vendor payload indicating otherwise. Just as clients may start IKE over UDP port 4500, they should be able to begin IKE_SA_INIT over TCP. We can still have those notifications for clients using UDP for IKE_SA_INIT, but it would be silly to send them over TCP. - 2.3: disallowing retransmissions implies a change on both transmitter and receiver, and I think this is unnecessary. You can change the IKE timeouts
RE: Change in I-D announcement format
This line is not too hot either: There's also a htmlized version available at: http://tools.ietf.org/html/submission.filename }}-01 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: 13 June 2012 10:48 To: IETF discussion list Subject: Change in I-D announcement format Did I miss an announcement of the change in format of I-D announcement messages? There's no longer a URL for the standard .txt format. That's mildly annoying for me (extra time and extra mouse clicks) and must be a nuisance for anyone who processes these messages automatically. At least, I would have expected a warning message about the change. -- Regards Brian Carpenter Scanned by Check Point Total Security Gateway.
[IPsec] Fwd: New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt
Hi I've submitted this draft as a possible solution to the problem discussed in the thread about fragmentation causing IKE to fail. Comments are welcome. Yoav Begin forwarded message: From: internet-dra...@ietf.orgmailto:internet-dra...@ietf.org internet-dra...@ietf.orgmailto:internet-dra...@ietf.org Subject: New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt Date: June 13, 2012 7:13:55 PM GMT+03:00 To: Yoav Nir y...@checkpoint.commailto:y...@checkpoint.com A new version of I-D, draft-nir-ipsecme-ike-tcp-00.txt has been successfully submitted by Yoav Nir and posted to the IETF repository. Filename: draft-nir-ipsecme-ike-tcp Revision: 00 Title: A TCP transport for the Internet Key Exchange Creation date: 2012-06-13 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-tcp-00.txt Status: http://datatracker.ietf.org/doc/draft-nir-ipsecme-ike-tcp Htmlized:http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp-00 Abstract: This document describes using TCP for IKE messages. This facilitates the transport of large messages over paths where fragments are dropped. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
Hi Yaron IPsec usually reduces the effective PMTU by 50-100 bytes. There are ways to overcome this: - the encrypting gateway can send ICMP fragmentation needed packets to the origin of the packet - the encrypting gateway can fiddle with the MSS on TCP SYN and SYN-ACK to reduce the size of TCP packets - the encrypting gateway can fragment before encrypting, thus making the ESP (with or without UDP) small enough and apparently not fragmented. Yoav -Original Message- From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] Sent: 11 June 2012 09:54 To: Valery Smyslov Cc: Tero Kivinen; ipsec@ietf.org; Yoav Nir Subject: Re: [IPsec] Fragmentation causing IKE to fail Hi Valery, This is not a different problem, because whatever solution we choose, we must ensure the whole system is functional: both IKE and IPsec. Routers that drop IKE fragments will not hesitate to drop ESP/UDP fragments, too. Thanks for pointing out Sec. 8 to me. I suppose you are right about the behavior of implementations in the case of ESP-in-UDP, but from a formalistic point of view, note that: - RFC 4301, Sec. 8 says nothing about NAT traversal (ESP-in-UDP). - RFC 3948 (IPsec-in-UDP) says nothing about fragmentation... So we have a hole here. By the way, I'm not sure that UDP packets are still typically small. There's more and more video on the Internet, and I'm sure some of it is NOT on Skype. Thanks, Yaron On 06/11/2012 08:37 AM, Valery Smyslov wrote: Hi Yaron, I think this is a different problem from dropping UDP fragments, and, from my point of view, less important. For most of UDP traffic this is not an issue, because packets are small. For TCP traffic IPsec gateway usually copies Don't Fragment Bit to outer IP header, and usually this bit is set. If some intermediate router has smaller MTU, it should drop packet and send ICMP Destination Unreachable. Having received it IPsec gateway may store needed MTU value in SA and then report this value to any host in protected network that tries to send bigger TCP packet. This behavior is irrespective to whether ESP-in-UDP employed or just plain ESP, and is documented in RFC4301 section 8. Regards, Valery Smyslov. Hi Valery, There's something I'm missing here. Let's say we go for a solution where we fragment IKE packets into pieces of 576 bytes, at the application level. Now, how do we determine the length of the ESP-over-UDP packets? Are you suggesting we fix them at 576 too, or do we need to have a (proprietary) path MTU discovery for this to *really* work? Thanks, Yaron Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
RE: [Fwd: Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
To be fair, nearly half the attendees come from that continent. Even when the meetings are held in Taipei or Paris. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Randy Bush Sent: 10 June 2012 03:33 To: Glen Zorn Cc: IETF Disgust Subject: Re: [Fwd: Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC] A quick check of the Upcoming IETF Meetings calendar (http://www.ietf.org/meeting/upcoming.html) shows that the next meeting in Asia is scheduled for November 2015, while the last was November 2011. How does a 4 year gap map to approximately once a year? this winter we are meeting in georgia (not the one in the caucasus) and florida. what more diversity do you want? canada? randy
[IPsec] Fragmentation causing IKE to fail
Hi I work for a vendor selling and IKE/IPsec solution. In the last few months, we've heard a troubling complaint from some of our customers. They say that some ISPs have begun to drop IP fragments. While specific ISPs were not named, most of the issues seem to be in south-east Asia. One customer has speculated that this has something to do with preparing to deploy CGNs. According to draft-ietf-behave-lsn-requirements, CGNs MUST comply with the NAT requirements for UDP as in RFC 4787, and that RFC says in section 11 that NAT devices MUST support fragments. So these routers are not compliant, but that doesn't help our customers much. Most traffic on the Internet is either TCP or small-packet UDP. The IKE protocol (both versions) has the rather rare distinction of having large UDP packets. These are packets #5 and #6 in IKEv1 Main Mode, or the IKE_AUTH packets in IKEv2, especially when using certificate authentication. For now, the customers managed to fix the ISP with an angry phone call. That got them into an exception list where fragments are not dropped. One had to change ISPs for that. While this can work for a while, it won't work when the carrier doing the dropping is not the one that the customer has a business relationship with, but another one downstream. Trying to think up ways to deal with this, I can think of some: * Get all ISPs to stop dropping fragments. This would be great, but as the saying goes, you are so not in charge. * Find ways of making the packets smaller: move to PSK, fiddle with trust anchors so that only one cert is needed, avoid sending CRLs, hash-and-URL, etc. These are not always successful, and often require more configuration than we would like. * Build a fragmentation layer within IKE, so IKE messages are broken into several packets that get reassembled at the destination. This is the path taken by one of our competitors [1]. This means that IKE has segmentation in addition to other TCP-like features such as retransmission. * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to ISAKMP. We have had IKE running over TCP for several years for remote access clients. This was done because remote access clients connect from behind some very dodgy NAT devices, and some of those do drop fragments. Getting this behavior at the ISP is novel. Have others on this list run into this issue? Yoav [1] http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_fragment_ike_pack.html [2] http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
On Jun 7, 2012, at 7:15 PM, Paul Hoffman wrote: * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to ISAKMP. We have had IKE running over TCP for several years for remote access clients. This was done because remote access clients connect from behind some very dodgy NAT devices, and some of those do drop fragments. Getting this behavior at the ISP is novel. * Use IKE over TCP only after IKE over UDP fails during transmission of a packet 512 bytes. That would be interoperable with current deployments (although they would not see the second attempt, of course), it costs little, and is trivial to implement. This is possible, but since UDP is not reliable, you'd have to retransmit several times before giving up on UDP. Even if we shorten the at least a dozen times over a period of at least several minutes, it's still long enough for users to feel - get the connection with Exchange lost message in Outlook, for example. You could begin both UDP (first IKE message) and TCP's 3-way handshake at the same time. If the 3-way handshake completed in time, the larger packets would go over that connection. If not, they would go over TCP. But all this is implementation-specific details. I'm more interested in hearing whether others are seeing this (I would guess yes, otherwise Cisco would not have developed the IKE fragments), and on whether there is interest in the group in an IKE-over-TCP draft. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
On Jun 7, 2012, at 8:26 PM, Nico Williams wrote: On Thu, Jun 7, 2012 at 11:54 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Jun 7, 2012, at 9:43 AM, Paul Wouters wrote: Also, if we are doing this, I'd prefer to be able to signal which tcp port to use, to make it more flexible to bypass port 500 blocks (which is part of the tcp 1 implementation I believe) That seems fine to me. However, assuming that a firewall that blocks TCP/500 will not block TCP/somerandomnewnumber is not wise. Use port 80. Well, we came up with IKE-over-TCP for clients in 2002. That worked OK with broken routers and NAT devices, but not with firewalls. So in 2003 we came up with sending both IKE and IPsec over port 443 (because at the time few firewalls other than ours validated that what goes on port 443 looks like SSL). Finally in 2005 we came out with a client that actually uses SSL for traffic, so that firewalls have to either be SSL proxies or do traffic flow analysis to recognize non-HTTPS. But this arms race between tunneling clients and firewalls is not the issue here. Without getting into the whole net neutrality controversy, ISPs are not supposed to, nor are they trying to block the creation of tunnels. What they are doing is saving themselves the need to keep state on received fragments, which allows better scale and better performance with the same hardware. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fragmentation causing IKE to fail
On Jun 8, 2012, at 1:01 AM, Paul Hoffman wrote: On Jun 7, 2012, at 2:53 PM, Yoav Nir wrote: On Jun 7, 2012, at 7:15 PM, Paul Hoffman wrote: * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is already allocated to ISAKMP. We have had IKE running over TCP for several years for remote access clients. This was done because remote access clients connect from behind some very dodgy NAT devices, and some of those do drop fragments. Getting this behavior at the ISP is novel. * Use IKE over TCP only after IKE over UDP fails during transmission of a packet 512 bytes. That would be interoperable with current deployments (although they would not see the second attempt, of course), it costs little, and is trivial to implement. This is possible, but since UDP is not reliable, you'd have to retransmit several times before giving up on UDP. Even if we shorten the at least a dozen times over a period of at least several minutes, it's still long enough for users to feel - get the connection with Exchange lost message in Outlook, for example. Good point. You could begin both UDP (first IKE message) and TCP's 3-way handshake at the same time. If the 3-way handshake completed in time, the larger packets would go over that connection. If not, they would go over TCP. Yuck. But possibly the right answer. But all this is implementation-specific details. I'm more interested in hearing whether others are seeing this (I would guess yes, otherwise Cisco would not have developed the IKE fragments), and on whether there is interest in the group in an IKE-over-TCP draft. Please consider IKE-with-TCP-and-UDP before IKE-over-TCP. I think we can accommodate different implementations by requiring: - that initiator MAY switch back and forth between TCP and UDP - that responder MUST respond in the same transport where the request arrived - that responder must not depend on all requests for a particular flow coming through the same transport. For example, it's perfectly acceptable for the first request of Main Mode to come over UDP, while the next two come over TCP. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsec SPD search
On Jun 6, 2012, at 5:54 PM, Sheng Hsin Lo wrote: Hello, Should the SPD search in IPsec support longest prefix match(LPM)? Hi The answer is no. The SPD is an ordered list of entries, and the first match is the one to follow. RFC 4301 defines a decorrelation algorithm (section 4.4.1 and appendix B) that remove overlaps for quicker searches, but that does not change the result fo the SPD search, which is first-match. Hope this helps Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [websec] Pinning
Hi The similarity of pinning and DANE has been discussed before. DANE relies on DNSSEC being deployed, which key-pinning does not. Come to think of it, the draft needs a section comparing with DANE, but that's for another thread. draft-perrin-tls-tack seems to tackle the same problem as key-pinning. Instead of the pins getting attested to in HTTP headers, you have a special public/private key pair, that you use to sign the SPKI from the server certificate within the a TLS extension. Like key-pinning there's a TOFU element here, because the client only learns about the special key when it encounters it in a TLS handshake. The obvious question is why would we need both key-pinning and tack. It has been asked on the TLS mailing list: http://www.ietf.org/mail-archive/web/tls/current/msg08818.html An answer by the draft authors is here: http://www.ietf.org/mail-archive/web/tls/current/msg08830.html In the grand scheme of things, it's not good for the IETF to make 1 standards, both of which need to be implemented in both servers and browsers, that accomplish the same thing, and Sean is correct that implementing more than one may lead to mismatching information. In a sense DANE is also doing the same thing, but DANE requires DNSSEC everywhere, so it's operational profile is different. But Tack and cert pinning both have no prerequisites and accomplish the same thing, so what if one's at the HTTP layer, while the other is at the TLS layer. I don't think the TLS WG is very excited about TACK (see the mailing list) but regardless, I think it's up to us to look at both options and decide if we would like to go on with cert-pinning, or whether we thing TACK is better. Yoav On Jun 5, 2012, at 11:47 PM, Paul Hoffman wrote: From the SAAG mailing list, but appropriate here. I bet that Sean would appreciate all discussion to go on on the SAAG mailing list... Begin forwarded message: From: Sean Turner turn...@ieca.com Subject: [saag] Pinning Date: June 5, 2012 12:55:29 PM PDT To: s...@ietf.org All, There are many proposals for how to say which key or certificate or trust anchor should be used by the client in a TLS session that it is about to open. These proposals include making that decision in the DNS (https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/), in the application after TLS has happened once, to be remembered in the future (https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/), and in the TLS handshake (https://datatracker.ietf.org/doc/draft-perrin tls-tack/). If more than one of these protocols are deployed, operational mistakes could lead to a client getting conflicting information. Similarly, there are also proposals on how to say whether or not a client should expect to see a particular service running under TLS. These proposals include making that indication in the DNS (draft hoffman-server-has-tls, expired but might be revived) and in the application after TLS has happened once, to be remembered in the future (https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport sec/). If more than one of these protocols are deployed, operational mistakes could lead to a client getting conflicting information. Is a standards-track operations statement needed to describe the choices that a TLS server administrator has, and to deal with conflicts between the proposals? spt ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: Colloquial language [Re: Last Call:draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice'sGuide to the Internet Engineering Task Force) to Informational RFC]
On Jun 1, 2012, at 11:13 AM, Randy Bush wrote: if i have to delete through much more about this bikeshed, i will give you some colloquial american to read. bikeshed ? :-) Yoav
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
Hi Peter I tend to disagree. I am not a native English speaker, although I will admit to watching way too much American TV in my teens. I believe most of these should be recognizable to anyone who has learned enough English to participate meaningfully in IETF mailing lists and discussions. What you haven't seen before, you can usually either deduce (cosmic significance would obviously mean a lot of significance), or else easily searchable on the net or in idiom books, although I did get some incorrect results searching google for warm fuzzy feeling. Yes, we should keep both messages and documents straight-forward, and avoid cultural references and memes (like home base or I do have a Dalek but I do not yet have a Tardis, or any reference to taking arrows to the knee), but I don't think it's necessary to go back and prune all idioms out of a document. Yoav On May 31, 2012, at 4:49 AM, Peter Saint-Andre wrote: Overall I continue to think that this is a helpful document, as were its predecessors. That said, I would assume that many potential readers of this document are not native English speakers. Thus I suggest that the more colloquial words and phrases might best be changed to more standard English. Naturally one can quibble about particulars, but here are some examples as I see them: get into the swing of things give them a warm, fuzzy feeling happenings unsung heroes home base pet project pet peeve leaps and bounds get technical discussions of cosmic significance gatherings of the tribes kicks in breath of fresh air big-name take the pluge I realize that such words and phrases lend a friendly tone to the document, but IMHO that friendliness will be lost on non-native speakers.
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On May 31, 2012, at 10:39 PM, Martin Rex wrote: Stephen Farrell wrote: I'm with Brian and Yoav on this. I don't see a need to change here. And I do think we might lose something if we become too PC. If a bunch of non-native speakers did say yes, I found that made the document less useful then I'd be more convinced that all these changes were worth it. +1 I do not believe that *over*simplyfying the language is beneficial for a clearly non-technical document. Using a language that is similar to discussion on mailing lists should be perfectly OK, as long as the colloquial expressions can still be googled easily, for those not familiar with them. I have to google Dilberts and xkcd every once in a while, an those sometimes contain very local expressions that are really difficult to find -- and still I'm OK with this. -Martin I had to look up some things when I ready The Adventures of ACTION ITEM for the first time[1], but the TAO draft is nowhere near that level. Besides, it's essential vocabulary for anyone seeking a career in project management. Yoav [1] http://professionalsuperhero.com/
[IPsec] Fwd: I-D Action: draft-nir-ipsecme-erx-04.txt
Hi I have just submitted a new version. This one contains some changes based on a review by Yaron Sheffer. It's mostly clarifications. The one bit-on-the-wire change is adding back the IDi payload (although it contains redundant information) to make the modified handshake less different. Yoav Begin forwarded message: From: internet-dra...@ietf.orgmailto:internet-dra...@ietf.org internet-dra...@ietf.orgmailto:internet-dra...@ietf.org Subject: I-D Action: draft-nir-ipsecme-erx-04.txt Date: May 21, 2012 8:53:57 AM GMT+03:00 To: i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org Reply-To: internet-dra...@ietf.orgmailto:internet-dra...@ietf.org internet-dra...@ietf.orgmailto:internet-dra...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An IKEv2 Extension for Supporting ERP Author(s) : Yoav Nir Qin Wu Filename: draft-nir-ipsecme-erx-04.txt Pages : 8 Date: 2012-05-20 This document describes an extension to the IKEv2 protocol that allows an IKE Security Association (SA) to be created and authenticated using the EAP Re-authentication Protocol extension as described in RFC 5296bis. NOTE TO RFC EDITOR: Replace 5296bis in the previous paragraph with the RFC number assigned to draft-ietf-hokey-rfc5296bis (now in the RFC Editor queue) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nir-ipsecme-erx-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-nir-ipsecme-erx-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: RFC 2119 terms, ALL CAPS vs lower case
On May 20, 2012, at 11:36 PM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/20/2012 12:41 PM, Stephane Bortzmeyer wrote: On Wed, May 16, 2012 at 11:06:25AM -0400, Simon Perreault simon.perrea...@viagenie.ca wrote a message of 12 lines which said: One dreams of a period in which precision and elegance were not mutually exclusive properties. You mean when French was the dominant language? Nice troll. Let me amend it: we now have languages which were conceived for writing precisely what you mean (not too much ambiguity, not too little). Lojban http://en.wikipedia.org/wiki/Lojban is the best known. I do not expect IETF to adopt it for RFCs (despite the imperfections of English) but I regret it. This would give me the push I need to really learn Lojban. Su'i pa la lojban satci .ije la lojban na'e nolmle
Re: [IPsec] Issue #219 - Star topology as an admin choice
On May 19, 2012, at 3:53 PM, Yaron Sheffer wrote: Hi Vishwas, Yoav, Check Point (IIRC) supports communities of IPsec endpoints, arranged either as a star or a full mesh. This is nice and simple to configure but obviously does not cover all use cases. Some networks cannot be represented either as a full mesh or as a simple star. More complex topologies can be achieved by having some IPsec endpoints be members of more than one community. That way, traffic can go from any member of one community to any member of another community through the common member. I think multiple communities with shared members does cover all the use cases, because taken to the edge case, an IPsec tunnel is a mesh with two members. Of course, if you configure your VPN as a large number of communities, each with two members, you've really lost all traces of simplicity, and you have to configure as much as simple IPsec, but a more common case would be several large communities, each either a star or a mesh, and then either an endpoint that is shared between them, or tunnels (2-member communities) to connect each pair of communities. While the configuration for a single star or mesh community is relatively simple, this moves the complexity to those connecting members. They need to know what is allowed to pass between the different communities. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
SecDir review of draft-ietf-ccamp-assoc-info-03
Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document does not define any new procedures or mechanisms, and mentions this fact three times throughout the document. It formalizes an email by Adrian Farrel clarifying the procedures for processing an ASSOCIATION object on a path message. The security considerations section repeats that the document does not define new procedures, and concludes that no security considerations are added. This is not a valid deduction, as clarification often involves prohibiting non-functional or insecure interpretation of the original document text. However, in this case the clarification is not about such insecure configurations, so the document is fine. One textual comment, though: section 2.2 near the bottom of page #5 lists 3 possible values for association ID. The second option is The LSP ID of the LSP protecting an LSP. This is not clear. I suggest rewording as The LSP ID of the protecting LSP without an indefinite an LSP. Yoav
Re: [IPsec] Issue #219 - Star topology as an admin choice
Hi. I think it should be more complicated than this. The suggested solution has a dichotomy of either a full mesh or a start topology. The requirements should cover scenarios such as a mesh within an organization connecting to a hub to gateways outside the organization, or multiple hubs connected among themselves in either a star or a mesh, or even certain routes that are manually configured along with all the auto-discovery stuff. Perhaps we can capture the needed complexity by talking about groups of nodes, where nodes that belong to a single group attempt to create a mesh among them, and packets can travel between nodes that do not belong to the same group through group intersection. I'm not sure if this level of detail is part of the problem statement, but it's more high level than a solution. On May 12, 2012, at 1:11 AM, Vishwas Manral wrote: Hi, I would like to start off by trying to resolve the issue. The notes from the IETF are attached below. Description:Some admins prefer a star topology so they can inspect traffic. They may not want to use this technology. Detail arguments: My take is similar to what Yaron and Yaov seem to state. There is no reason to exclude star topology at all from the Problem statement/ requirements document. In fact both the proprietary solutions I know of allow for such a topology. I however understand that some of the functionality on the Hub (of the star) could be achieved by using PFP flags in the SPD entry. Suggested Resolution: State in the document that Star topology is not excluded from the solution. The problem of configuration is however mainly limited to the Hub. For every spoke added/ deleted/ modified the configuration on the Hub needs to be changed, which is not desirable. May be update Section 3.2 with the same too. Thanks, Vishwas === Notes from meeting minutes: # 219 Star topology as an admin choice People don't need to use this if they don't want to Say this in the security considerations Yoav Nir: Has to be a requirement that any solution can implement different policies Yaron Sheffer: Agrees with Yoav, maybe becomes a use case Take this to the list ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #213/ #214 - Allow for non-direct end point connectivity
I'm not sure I understand the suggested resolution. The biggest barrier to direct connectivity is that the responder may be behind NAT. Is this considered a routing issue? In any case, there are protocols for getting to a responder behind a NAT. They work well enough that VoIP solutions work pretty much everywhere where there isn't a firewall that's specifically targeting VoIP. I think we should user them, adapt therm or profile them for IKE/IPsec, although this does not necessarily belong in the solution document. As for #214, I don't see how this is answered. If an gateway A would like to contact a host behind gateway Z, and does so through gateway B, must gateway B provide the addresses for gateway Z, or can it give the address of gateway D, which will then provide the address of gateway Z? IOW, must redirection be 1-step? Yoav On May 12, 2012, at 2:03 AM, Vishwas Manral wrote: Hi, Description: Direct endpoint-to-endpoint connectivity may not be possible. Should gateways figure things out completely or just punt endpoints to a closer gateway? Detail Arguments: As Izaac and John Lesser pointed out this is more of a routing issue. Though current solutions do not allow such connectivity unless through a hub, I think from the security plane, we should not preclude such connectivity. This could be achieved either transparently (no IPsec component except the SPD involved), or by stitching tunnel traffic. Suggested Resolutions: Specify explicitly that issues around direct connectivity between endpoints are more of a Routing issue. However IPsec should not prevent such a connectivity model. Thanks, Vishwas === Meeting notes: # 213 In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible Need to mention challenges in use cases section Paul: reminded that there will be a separate requirement section # 214 Should gateways figure things out completely or just punt endpoints to a closer gateway? Core gateway configuring is a solution, so premature Also in #213 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #219 - Star topology as an admin choice
I might have put it like this if it wan't so similar to the way things are configured on Check Point gateways :-) It makes sense to me, but I'm not sure it covers all the use cases. Imagine a topology that is entirely mesh, except for HTTP(S) traffic that is routed to a central site because they have some HTTP inspection gateway there. It's a requirement that came up a while ago. How does that fit the either mesh or star topology? Also, a gateway that is part of more than one topologies (at Check Point we call them communities) would have to have a different view of the network in these two contexts. As far as its peers in community A are concerned, it is protecting all the networks behind any gateways in community B, but for members on community B, it is protecting all the addresses behind gateways in community A. On May 12, 2012, at 10:53 PM, Vishwas Manral wrote: Hi Yaov, If I udnerstand correctly, what you seem to be talking about is a Star-of-meshes or a mesh-of-star topology. In my view this would be dealt with in 2 different iterations of the Mesh VPN topology. So there would be a Mesh VPN for the Star topology and a separate instance of the Mesh VPN for the mesh topology. Let me know if that makes sense. I think we can state that the requirement should allow for such iterative use cases, however at one instance we only look at star or mesh topology. Do I make sense? Thanks, Vishwas On Sat, May 12, 2012 at 11:34 AM, Yoav Nir y...@checkpoint.commailto:y...@checkpoint.com wrote: Hi. I think it should be more complicated than this. The suggested solution has a dichotomy of either a full mesh or a start topology. The requirements should cover scenarios such as a mesh within an organization connecting to a hub to gateways outside the organization, or multiple hubs connected among themselves in either a star or a mesh, or even certain routes that are manually configured along with all the auto-discovery stuff. Perhaps we can capture the needed complexity by talking about groups of nodes, where nodes that belong to a single group attempt to create a mesh among them, and packets can travel between nodes that do not belong to the same group through group intersection. I'm not sure if this level of detail is part of the problem statement, but it's more high level than a solution. On May 12, 2012, at 1:11 AM, Vishwas Manral wrote: Hi, I would like to start off by trying to resolve the issue. The notes from the IETF are attached below. Description:Some admins prefer a star topology so they can inspect traffic. They may not want to use this technology. Detail arguments: My take is similar to what Yaron and Yaov seem to state. There is no reason to exclude star topology at all from the Problem statement/ requirements document. In fact both the proprietary solutions I know of allow for such a topology. I however understand that some of the functionality on the Hub (of the star) could be achieved by using PFP flags in the SPD entry. Suggested Resolution: State in the document that Star topology is not excluded from the solution. The problem of configuration is however mainly limited to the Hub. For every spoke added/ deleted/ modified the configuration on the Hub needs to be changed, which is not desirable. May be update Section 3.2 with the same too. Thanks, Vishwas === Notes from meeting minutes: # 219 Star topology as an admin choice People don't need to use this if they don't want to Say this in the security considerations Yoav Nir: Has to be a requirement that any solution can implement different policies Yaron Sheffer: Agrees with Yoav, maybe becomes a use case Take this to the list ___ IPsec mailing list IPsec@ietf.orgmailto:IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: Future Handling of Blue Sheets
On May 10, 2012, at 12:10 PM, Doug Barton wrote: On 5/10/2012 1:48 AM, Tobias Gondrom wrote: What I dispute is that make available to those who are interested necessarily leads to the need to broadcast the data (i.e. publish in the proceedings). What is the harm you are trying to guard against by requiring the request? Well, there's the obvious issue of spam, although this post that I'm making right now provides my email address to the spammers in a much more convenient form. It's also convenient for headhunters. It also allows my employer to check whether I really went to sessions instead of just touring Paris. Is it the business of the IETF to help in these activities? I still don't get why you would want this published. My name on a blue sheet could mean that I was presenting for half the session, or that I was at the mike telling people they were wrong, or just sitting quietly in the back minding my own business and reading email. Blue sheets (unlike minutes and jabber logs) don't make such a distinction. Or, to take a completely different tack, given that there are a non-zero number of people who think the data should be published, how do you intend to deal with someone who makes the request, and then puts it up on their own website? I think this would be a copyright violation, unless the IETF specifically authorized them to do so (which it shouldn't). I don't think the IETF should prosecute, but it's still a violation. I don't hesitate to criticize when I think that the IESG gets it wrong, but in this case I think they threaded the needle about as well as it could be threaded. I think that needle should not be threaded at all. A list of participants should maybe be kept (scanned or not) but never published without subpoena, just as it is now. I don't see any reason why publishing it (as opposed to recording actual participation) is a requirement for an open process. Yoav
Re: Future Handling of Blue Sheets
On May 10, 2012, at 8:42 PM, Melinda Shore wrote: On 5/10/12 9:32 AM, Martin Rex wrote: There has never been a need to actively broadcast these massive amounts of personally identifiable information (PII), and I haven't seen any convincing rationale for doing it now. To be honest, I don't want to receive more spam and My boss might find out I skipped a session are not reasons not to be open about who's participating in sessions, particularly as we drift towards a meetings/voting model. Participating is one thing. Presence is another. Reporting that I spoke up against the hard-fail requirement at Websec is part of the openness. Reporting that I was at SCIM, where I never once approached the microphone is not. I understand sensitivity about broadcasting travel plans but in general some of the arguments being offered for being a less open organization with a less open process are drifting into The FBI implanted a radio transmitter in my teeth territory, and it seems to me that making blue sheets available after meetings does not reveal much PII beyond what's already available on the mailing lists. The FBI needn't bother. They can just read the blue sheets :-) There's a serious question here about tradeoffs between privacy and openness. Openness is not just a core institutional value (although it is one - do not forget that), but it's also a defense against charges of collusion, which, unfortunately, we've been seeing. And how does the existence of such a lame attempt to list attendees help in this? Yoav
RE: Last Call: draft-farrresnickel-ipr-sanctions-05.txt (Sanctions Available for Application to Violators of IETF IPR Policy) to Informational RFC
I think that regardless of how it's worded, the real question is whether liability falls to the person who sent the email (to a public mailing list) or the IETF. The difference between believe and shown seems minor in comparison. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: 09 May 2012 09:52 To: ietf@ietf.org Subject: Re: Last Call: draft-farrresnickel-ipr-sanctions-05.txt (Sanctions Available for Application to Violators of IETF IPR Policy) to Informational RFC I'd like to be reassured that this has been carefully reviewed by the IETF counsel and the IETF Trust. In particular I would be interested in its possible interaction with the IETF's liability insurance. Any IETF participant can call for sanctions to be applied to anyone they believe has violated the IETF's IPR policy. This can be done by sending email to the appropriate IETF mailing list. That seems reasonable, but publishing such a belief without having the wording checked by a libel lawyer might be risky. I think the draft should state that a call for sanctions should be based on factual evidence and not on belief. How about Any IETF participant can call for sanctions to be applied to anyone shown to have violated the IETF's IPR policy. This can be done by sending email to the appropriate IETF mailing list, including a a short summary of the relevant facts and events. Regards Brian Carpenter On 2012-05-07 22:56, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Sanctions Available for Application to Violators of IETF IPR Policy' draft-farrresnickel-ipr-sanctions-05.txt as 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 2012-06-04. 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 IETF has developed and documented policies that govern the behavior of all IETF participants with respect to Intellectual Property Rights (IPR) about which they might reasonably be aware. The IETF takes conformance to these IPR policies very seriously. However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied. This document discusses these issues and provides a suite of potential actions that may be taken within the IETF community. The file can be obtained via http://datatracker.ietf.org/doc/draft-farrresnickel-ipr-sanctions/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-farrresnickel-ipr-sanctions/ball ot/ No IPR declarations have been submitted directly on this I-D. Scanned by Check Point Total Security Gateway.
Re: Last Call: draft-farrresnickel-ipr-sanctions-05.txt (Sanctions Available for Application to Violators of IETF IPR Policy) to Informational RFC
I am not a lawyer either, but I think it depends on jurisdiction whether a mailing list will be considered as a media outlet or merely a conduit. What the IETF writes in its policy amounts to a plea to users to pretty please send only factual information. I don't know that it makes a difference as to who is liable if the information turns out to be non-factual. On May 9, 2012, at 10:19 AM, Brian E Carpenter wrote: Yoav, IANAL, but as far as I know libel suits are normally against individuals (or media outlets such as newspapers). The defence against a libel suit in the British courts, the most popular jurisdiction for international libel suits, is factual accuracy. Therefore, I think the draft should state the need for factual evidence. And to be clear, there are plenty of precedents for libels originating outside the UK leading to successful suits in the UK courts, if they have been received in the UK via the Internet. Regards Brian Carpenter On 2012-05-09 08:07, Yoav Nir wrote: I think that regardless of how it's worded, the real question is whether liability falls to the person who sent the email (to a public mailing list) or the IETF. The difference between believe and shown seems minor in comparison. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: 09 May 2012 09:52 To: ietf@ietf.org Subject: Re: Last Call: draft-farrresnickel-ipr-sanctions-05.txt (Sanctions Available for Application to Violators of IETF IPR Policy) to Informational RFC I'd like to be reassured that this has been carefully reviewed by the IETF counsel and the IETF Trust. In particular I would be interested in its possible interaction with the IETF's liability insurance. Any IETF participant can call for sanctions to be applied to anyone they believe has violated the IETF's IPR policy. This can be done by sending email to the appropriate IETF mailing list. That seems reasonable, but publishing such a belief without having the wording checked by a libel lawyer might be risky. I think the draft should state that a call for sanctions should be based on factual evidence and not on belief. How about Any IETF participant can call for sanctions to be applied to anyone shown to have violated the IETF's IPR policy. This can be done by sending email to the appropriate IETF mailing list, including a a short summary of the relevant facts and events. Regards Brian Carpenter On 2012-05-07 22:56, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Sanctions Available for Application to Violators of IETF IPR Policy' draft-farrresnickel-ipr-sanctions-05.txt as 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 2012-06-04. 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 IETF has developed and documented policies that govern the behavior of all IETF participants with respect to Intellectual Property Rights (IPR) about which they might reasonably be aware. The IETF takes conformance to these IPR policies very seriously. However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied. This document discusses these issues and provides a suite of potential actions that may be taken within the IETF community. The file can be obtained via http://datatracker.ietf.org/doc/draft-farrresnickel-ipr-sanctions/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-farrresnickel-ipr-sanctions/ball ot/ No IPR declarations have been submitted directly on this I-D. Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway.
Re: Last Call: draft-farrresnickel-ipr-sanctions-05.txt (Sanctions Available for Application to Violators of IETF IPR Policy) to Informational RFC
On May 9, 2012, at 12:28 PM, SM wrote: Hi Yoav, At 00:44 09-05-2012, Yoav Nir wrote: What the IETF writes in its policy amounts to a plea to users to pretty please send only factual information. I don't know that it makes a difference as to who is liable if the information turns out to be non-factual. Section 3 text mentions several paths for the issue, i.e. responsibility lies with the working group chair with escalation to area directors. Paragraph 2 and 3 discusses about that. The issue which predates this draft is mentioned in the message at http://www.ietf.org/mail-archive/web/ietf/current/msg71484.html Do you know any IETF participant who is dumb enough to send a public request for sanctions? :-) Dean Anderson often linked to his website: http://www.av8.net/IETF-watch/People/ (also loads of fun without the People path). IANAL but this does sound like libel. More recently, but not related to IPR issues, during the last IETF quite a few of our prominent members were calling for sanctions (removal of posting privileges) after some of the IETF.Fact.Check posts. That can affect the individual's carrier path in the IETF and in the corporate world. Some IETF participants might even ask lawyers to take action. Watching Behind enemy lines (disambiguation required) might be instructive in this context. At the end of the day, this draft is simply a matter of having an RFC for those who might find the information helpful. Sometimes all one can do is to say pretty please. I'll +1 this draft as it stands. I'm fine with it as it is. I just hope the IETF is not held responsible for postings by individuals.
Re: Gender diversity in engineering
On May 8, 2012, at 1:12 PM, Yaakov Stein wrote: Around 30%-40%. I don't have hard numbers, but I have a feeling that it has gone down a bit in the last 10 years. Yoav, Your feelings are quite accurate as to the range, but less so regarding the trend. According to a recent study, 35.6% of high-tech employees in Israel are women, and this percentage has been relatively stable for the past 10 years. Women make up 47.5% of all employees with academic credentials (as of 2010) in all sectors, so high-tech is actually comparatively under-represented. On the other hand, only 32.9% of managerial positions (in all sectors) are occupied by women. I can believe that. It could be specific to Check Point. OTOH there are those companies with departments where only women work. That could be keeping the balance. Yoav
Re: Is the IETF aging?
On May 5, 2012, at 4:58 AM, Marshall Eubanks wrote: On Fri, May 4, 2012 at 9:50 PM, Phillip Hallam-Baker hal...@gmail.com wrote: On Wed, May 2, 2012 at 3:14 PM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi PHB, the IETF is not like an enterprise where you can decide (as part of the hiring process) what characteristics your employees should have. True, but that does not mean that you should decide that there is nothing the IETF can do to change those characteristics or is in fact doing albeit unintentionally. So, what would you do to adjust things ? I'm not PHB, but an obvious idea would be to change the requirements for a new work item from rough consensus to a bunch of people willing to do the work and at least one willing to implement. Some working groups already work like this, but it's not universal.
Re: [IPsec] New Version Notification for draft-nir-ipsecme-erx-03.txt
Hi again. The response has so far been underwhelming. As I said in my previous message, I'm perfectly willing to go the individual route, but I think this would be a shame. The protocol extension described can have applications in both remote access VPN (opening multiple tunnels with multiple gateways) and in seamless roaming between remote access VPN and local area wireless networks. I also think that it touches a lot of different areas, and would benefit from the input of people better versed than me in the needs of cellular providers and AAA. I am CC-ing the HOKEY mailing list (as I should have done earlier) because this draft actually adapts IKE to work with their protocol, and they may be willing to review and contribute, even if this is IPsecME work. So if any of you are interested, and are willing to review, please let us know. Yoav Qin On Apr 12, 2012, at 10:31 PM, Paul Hoffman wrote: On Apr 12, 2012, at 11:17 AM, Yoav Nir wrote: We would like this working group to accept this, and have it added to charter. Of course, if it gets accepted, we volunteer to be authors. If it is not accepted, we will try to progress it as an individual submission, but we believe that this changes IKE enough that it should come from the working group. Statements of interest and disinterest on this document are welcome. If you prefer to make such a statement off-list please send it to me or Yaron. A statement of interest that include a promise to review in WG LC count for more than a bare statement of interest. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: 'Geek' image scares women away from tech industry ? The Register
On May 1, 2012, at 12:31 AM, Janet P Gunn wrote: My own anecdotes. Yes, it starts early. When I was 3 I announced that I was going to be a physicist when I grew up. WHY? 1 - a physicist has a chair that is on WHEELS, and spins ROUND and ROUND 2 - a physicist has a blackboard with COLORED CHALK 3 (and MOST important) a physicist has a CANDY machine in the hall outside his office. But engineers get to drive trains. Trains swivel chairs.
Re: 'Geek' image scares women away from tech industry ? The Register
On Apr 30, 2012, at 10:52 PM, Mary Barnes wrote: Here is an article that does a far better job of explaining the situation than I did: http://www.todaysengineer.org/2011/May/women-in-engineering.asp The largest reason women leave engineering is due to the work environment and perceived lack of support from colleagues. Interesting, but I don't really get some of the distinctions they are making. Women *are not* leaving engineering to spend time with their families, but they *are* leaving engineering because of 60-hour weeks and having to work weekends. I'm also not sure that stereotype is still valid. It's the romantic image of a technology start-up trying to get a product out before funding runs out, but most engineers won't work in those. Most will work at established companies or in corporate IT, and in those places, the 60-hour week is either rare or non-existent. There may be other things that scare women away from IT/engineering jobs, but there are plenty of those available that do not require that type of having no life. Yoav
Re: 'Geek' image scares women away from tech industry ? The Register
On May 1, 2012, at 4:45 PM, Mary Barnes wrote: The article clearly states that women leave for the two reasons you mentioned, which are certainly the exact same things males deal with, but you missed a few others that the article notes, specifically and directly quoted below: ...lack of real or perceived opportunities for advancement, and uncivil work environments where women were treated in condescending or patronizing manners. Only 25 percent of the women who left engineering did so for family reasons. Well, it says this: The common perception is that women are leaving for taking care of their families, says Fouad. But that's clearly not true. They left the profession for organizational culture reasons. And then this: Among the common factors that women cited as their reasons for leaving the profession were too much travel, working too many hours, lack of real or perceived opportunities for advancement, and uncivil work environments where women were treated in condescending or patronizing manners. Only 25 percent of the women who left engineering did so for family reasons. So on the one hand they claim that women are not leaving to take care of their families, but on the other the first two correct reasons they mention are too much travel and too many hours. I think these two are pretty much the same, and the primary reason why someone (male or female) would object to travel and long hours is because it takes time away from family. Sure, it's possible they don't want to work long hours so that they can spend more time playing online games (http://iqu.com/blog/women-dominate-mobile-game-spending) or gambling online (http://ezinearticles.com/?UK-Online-Gambling-Dominated-by-Women-Playersid=6934242), but I suspect that few people are quitting their jobs to spend more time on gaming. I could be wrong. IOW I don't see the difference between not wanting to spend too much time at work and wanting to spend more time with your family.
Re: 'Geek' image scares women away from tech industry ? The Register
On May 1, 2012, at 8:44 PM, Janet P Gunn wrote: This is VERY narrow minded, and, to be honest, somewhat insulting. You suggest that time at work and family are the only important things to women. I'm suggesting no such thing. This authors of this survey say that women who left engineering did not do so to take care of their families, although their own data says that 25% of them did. They mention long hours and travel, but they offer no explanation why these would be different between men and women. The one issue that would seem to be different between men and women is the attitude of co-workers and superiors towards women, and workplace climate issues, yet only one in three give that as the reason for leaving. So if women go from 20% when they graduate to 11% at the workplace, only about 3 of those percent are explained by workplace climate. I still don't see how those other things are different for women. It should also be noted, that this study is not about the kind of engineering we do at the IETF. The women interviewed are mechanical, industrial, and chemical engineers. In fact in a couple of places computer programming is mentioned as one of those alternative careers women can take when they leave engineering: ...I got to a certain point in my engineering career when I NO LONGER ADVANCED. I felt I needed additional education to move forward, but no topics interested me as much as computer programming, so I changed my career to that. It was a good change. I have been more successful in the computer field than I was in the engineering field.” I don't know the figures for the IT industry, but I would guess that they're not as lopsided as those for those so-called real engineering. Yoav
Re: Is the IETF aging?
Hi Phil After each meeting, Ray sends out a survey to all participants. The results from the latest one: When were you born? Before 19502.9% 1950 - 1960 16.6% 1961 - 1970 33.7% 1971 - 1980 32.8% After 198014.0% I think an earlier survey had the 1971-1980 crowd inch past the 1961-1970 one, but it does seem like the 30-50 age groups dominate. I don't believe you really are among the youngest, and neither am I (I'm 40). There are quite a few WG chairs, and some area directors who are younger than either of us. 20 years ago, was the balance of industry vs government and academia the same as today? I am guessing that it was not, and that only a small minority came from industry. I am also guessing that doctoral students and post-docs are more eager than tenured professors to publish internet drafts, so the average age of an academic at the IETF is low. OTOH in industry you get to participate in things like the IETF only after you've been around for a while. How many of the participants from Cisco carry the distinguished engineer title? A lot. I think that explains why the average age has moved up. Are things any different in ITU or even W3C? Yoav On Apr 27, 2012, at 5:06 PM, Phillip Hallam-Baker wrote: A question arose on the RFC-interest list, I observed that 20 years ago I was one of the youngest IETF participants and 20 years later that still seems to be the case. I see some grad students and some postdocs in their 20s but not as many as I think there should be. By now at least a third of the organization should be younger than me, preferably half. That is certainly not what I see when I attend IETFs. And yes, the lack of women is also highly noticeable. If this is the case it should worry us greatly. But first I think we need to determine if it is the case or not. I suggest an optional demographic survey of participants in the next IETF meeting to be repeated at regular intervals (no more than 5 years apart). People can argue about process, RFC formats and governance but it should be beyond argument that any institution that cannot recruit younger members is going to die. -- Website: http://hallambaker.com/ Scanned by Check Point Total Security Gateway.
Re: Is the IETF aging?
On Apr 27, 2012, at 6:05 PM, Carsten Bormann wrote: On Apr 27, 2012, at 16:41, Yoav Nir wrote: Before 19502.9% 1950 - 1960 16.6% 1961 - 1970 33.7% 1971 - 1980 32.8% After 198014.0% Nice bell curve, יואב, but you can't pop that soap bubble of perception with the bluntness of raw data :-) Only 350 out of 1200 people answered the survey, so all caveats about bias apply. It's also possible that the 20-somethings tend to sit in the back more, and go to the microphone less. Maybe them young'uns are too busy clicking Like on pictures of LOL-cats :-) Maybe just the areas where PHB likes to work in are growing old? :-) The old people in the security area do tend to look older than the old people in other areas. Maybe the bell curve for the security area is different. Many of the people doing the real work in CoRE are in their 20s, or have left that age range just recently. And no, they aren't all academics. I think we have a healthy age mix, with some pretty good gray-haired input as well. I'm going to argue for an age column on the blue sheets so we get better data :-) Grüße, Carsten PS.: Please, don't take any of this seriously. Except for the CoRE age statistics. Dave Cridland's observations also definitely don't apply to CoRE, except that we do have the stunning range of experience that makes the IETF so valuable. PPS.: Is the overall median really 42? Wait a couple of years, and most participants won't get why 42 is funny.
Re: Proposed IESG Statement on the Conclusion of Experiments
RFC 2026 says this about Experimental RFCs: The Experimental designation typically denotes a specification that is part of some research or development effort. However, I do not believe that this is still typical. Authors come up with ideas that they think are useful. If when the documents are ready for publication it is still not clear whether there are enough implementers convinced by the use case (some definition of running code), they are encouraged to publish them as experimental rather than proposed standard. I am the author of two Experimental RFCs. In both cases I was going for standards track, and in both cased an AD was the document shepherd and he told me to go for Experimental. The first of these (4478) has three independent, interoperable implementations in shipping code, although I don't know if it's used much. I am not aware of any implementations of the other one (6023), although there may be some. When I asked an AD about promoting 4478 to standards track (seeing as we have all this running code) his response was why bother? (these are three different ADs in this story...) Neither of these can really be called an experiment except in the sense of let's see if the Internet needs this specification. They may be used more later than they are now, but they're in no way stopping. I don't see why we should waste precious cycles on maintaining old Experimental RFCs. Either they're in use or they're not, and a search engine can usually reveal this. It may be a good idea to have former authors or ADs or volunteers write a paragraph that can be displayed on, say, the tools page for the RFC, along the lines of In seven years, this RFC has seen three independent implementations, but it is not in wide use, or the protocol in this RFC is used everywhere on the web, and this could be progressed to PS if we had the energy. I don't think we should waste our energy by creating an RFC for each of those experimental RFCs. Yoav On Apr 19, 2012, at 11:31 PM, Adrian Farrel wrote: All, The IESG has been discussing how to tidy up after Experimental RFCs. We have developed the following draft IESG statement. This does not represent a change in process, and continues to value Experimental RFCs as an important part of the IETF process. It does, however, seek to encourage documentation of the conclusion of experiments. We are aware that there may be other discussion points around Experimental RFCs, and we would like to discuss these, but we also believe that there is merit in making small, incremental improvements. The IESG would welcome your thoughts on this draft before they approve the final text on April 26th. Thanks, Adrian = IESG Statement on Conclusion of IETF Experiments Experiments are an established and valuable part of the IETF process. A number of core Internet protocols were first published as Experimental RFCs while the community gathered experience and carefully investigated the consequences of deploying new mechanisms within the Internet. In the case where an experiment leads on to the development of a Standards Track RFC documenting a protocol, the new RFC obsoletes the old Experimental RFC and there is a clear conclusion to the experiment. However, many experiments do not lead to the development of Standards Track RFCs. Instead, the work may be abandoned through lack of interest or because important lessons have been learned. It is currently hard to distinguish between an experiment that is still being investigated, and an old experiment that has ceased to be of interest to the community. In both cases an Experimental RFC exists in the repository and newcomers might easily be misled into thinking that it would be helpful to conduct more research into an abandoned experiment. In view of this, the original proponents of experiments (that is, authors of Experimental RFCs, and Working Groups that requested the publication of Experimental RFCs) are strongly encouraged to document the termination of experiments that do not result in subsequent Standards Track work by publishing an Informational RFC that: - very briefly describes the results of the experiment - obsoletes the Experimental RFC - if appropriate, deprecate any IANA code points allocated for the experiment - may request that the Experimental RFC is moved to Historic status. If there is no energy in the community for the producing such an Informational RFC, if the authors have moved on to other things, or if the Working Group has been closed down, Area Directors should author or seek volunteers to author such an Informational RFC. Scanned by Check Point Total Security Gateway.
Re: [IPsec] draft-bhatia-moving-ah-to-historic
On Apr 16, 2012, at 1:53 PM, Nick Hilliard wrote: I'd like to add a voice of support to this draft. AH adds little except complication to ipsec implementations and confusion to end users. It only adds confusion and complication in the sense that telnet adds them (ESP is SSH in this analogy). If you don't implement it you and your users don't get confused. Besides, the end users of IPsec who actually have to know what ESP is vs what AH is are very sophisticated. They're not the people who simply press Connect on their L2TP or VPN clients. Regarding ipv4 NATs, they are ubiquitous and will become more so once ipv4 scarcity is realised worldwide (particularly in asia, which is currently the fastest growing global region, and has already reached RIR exhaustion). Maybe, maybe not. As ISPs move large blocks of users to a combination of IPv6 and CGN, blocks of IPv4 address space may be freed up. But regardless, NAT *is* going to be with us for a while, even in IPv6. There was a previous comment about this draft about the NAT/AH issue being a NAT problem rather than an AH problem. Well, yeah, in the purest sense this is true, but we live in the real world and need to work within its limitations. You can apply fixups and ALGs to lots of protocols which are NAT sensitive, but AH is cryptographically incompatible with NAT and this cannot be fixed. Nothing's stopping you from proposing 4302bis, which will be compatible with NATs. There just isn't much demand for changing AH like that. I see little value in the IETF formally supporting a protocol which simply cannot work for most end-users on the basis of the access addressing provided. Formal deprecation / designation to historic status is appropriate in this case. Formal deprecation is pretty much meaningless. Consider this example: Suppose the TICTOC working group decide that they need packet authentication for time signals, but not encryption. (makes sense, as they only deliver the time of day). They can go with either AH or ESP-Null. They also don't care about NAT, because NATs introduce so much jitter, that they'll ruin the accuracy of PTP, so PTP does not go through NAT anyway. They also first construct the IPsec packet, then paste the timestamp where it's needed, and quickly calculate the hash. If they can do this with less jitter with AH than with ESP, do you think they'll actually care whether they're using a current or historic standard? They'll just use whatever gets the job done better. Even historic does not mean everyone has to stop using it, even in new standards. It just means that you have to have a really good justification why you need that rather than ESP. That's the situation already. Declaring it so doesn't help. Also +1 to the following arguments: - ESP + NULL == substantially equivalent - less mailing list chatter Well, this draft generated a 77-post thread. Then the mailing list got quiet about it, and we had three months without any mention of AH. I think moving it to historic creates a lot more mailing list chatter than ignoring it. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Fwd: New Version Notification for draft-nir-ipsecme-erx-03.txt
Hi all. This is the 3rd iteration of the draft I presented about in Paris. We would like this working group to accept this, and have it added to charter. Of course, if it gets accepted, we volunteer to be authors. If it is not accepted, we will try to progress it as an individual submission, but we believe that this changes IKE enough that it should come from the working group. Yoav Qin Begin forwarded message: From: internet-dra...@ietf.org internet-dra...@ietf.org Subject: New Version Notification for draft-nir-ipsecme-erx-03.txt Date: April 12, 2012 1:33:48 PM GMT+03:00 To: Yoav Nir y...@checkpoint.com Cc: sunse...@huawei.com sunse...@huawei.com A new version of I-D, draft-nir-ipsecme-erx-03.txt has been successfully submitted by Yoav Nir and posted to the IETF repository. Filename: draft-nir-ipsecme-erx Revision: 03 Title: An IKEv2 Extension for Supporting ERP Creation date: 2012-04-12 WG ID: Individual Submission Number of pages: 7 Abstract: This document describes an extension to the IKEv2 protocol that allows an IKE Security Association (SA) to be created and authenticated using the EAP Re-authentication Protocol extension as described in RFC 5296bis. NOTE TO RFC EDITOR: Replace 5296bis in the previous paragraph with the RFC number assigned to that document. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [vmeet] Minutes from the Paris meeting
On Apr 9, 2012, at 7:58 PM, Paul Hoffman wrote: ...are available at http://www.ietf.org/proceedings/83/minutes/minutes-83-rpsreqs.txt. Send me any corrections. My apologies for taking so long to do the transcription, but there was a lot of good material there. There are many ideas that were brought up at the meeting that should be separate threads on this list. Interesting read. I see that the audio recording page ( http://www.ietf.org/audio/ietf83/ ) still doesn't have recordings for Friday. Any idea when that will change? Yoav ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [IPsec] SPI Collision
Hi Daniel On Apr 5, 2012, at 9:22 PM, Daniel Migault wrote: Hi, I am wondering how SPI collision is considered by IKEv2, and have not found any documentation on it, so if there are some, please let me know. My current understanding is that when an CREATE_CHILD_SA exchange is performed the Initiator and Responder announce the SPI in the SA payload. If the Initiator announces an SPI that is already used by the Responder (with another peer), the Responder cannot accept this proposition and must send an error message. I haven't found anything like this in RFC5996. Am I missing something ? Furthermore I cannot find any message for this error. INVALID_SPI does not seems to be used for the creating of an SPI, but only if an ESP/AH/IKE packet comes with an unrecognized SPI. In addition it seems the Notify Payload MUST be sent out of the IKE_SA Can anyone tell me which error message is used? BR Daniel In IKE (both v1 and v2) it's always two IPsec SAs that are negotiated at the same time. Each side sends in its CCSA message the SPI for the inbound SA. So for traffic going from the initiator to the responder, it's the responder that chooses the SPI, while for traffic going from the responder to the initiator, the initiator chooses the SPI. This allows both peers to make sure that inbound SAs have unique SPIs. The same guarantee cannot be made for outbound traffic. The SPI for outbound traffic is chosen by the peer, and one particular implementation that I'm aware of assigns them serially, so with many peers like that, you have a high chance of collision. The fact is that it is usually not a problem. In outbound IPsec processing the stack sees the cleartext packet, chooses an SA based on attributes of the packet, and constructs the protected packet based on encryption keys, MAC keys, the replay counter and the SPI which are part of the SA. The SPI is a value, not a key in the table of outbound SAs, so there's no harm done even if all the outbound SAs have the same SPI. This is different from the inbound case, where the SPI is used as a key to the SA table, and therefore has to be unique. Hope this helps Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [vmeet] Issue: is PSTN access really required?
On Mar 30, 2012, at 1:11 PM, Dean Willis wrote: From today's meeting, taking to list. Remote participation for users connecting via the PSTN though gateways into a VoIP conference platform raises some issues. One of these is registration . There are hacks like PINs that can be made to work. But to me, the biggest problem is that it is just really hard to make it work, especially for participants on the fringe of the PSTN. Echo cancellation may be impossible to provide without exceeding the 150ms latency interaction/interrupt threshold determined in Brian Rosen's research. One doesn't necessarily need broadband to use IP. I've talked quite successfully between participants with EDGE mobile connections. But going over a long path of telephone network to a PSTN gateway, thence over IP to a conference platform is a recipe for disaster. I therefore propose that our remote participation system neither require nor support dial-in telephone numbers. This assumption can greatly simplify the system, reduce operating expense, and reduce the probability of systemic marginal failure where the system works but not well enough to actually use. Some argue that this would unfairly exclude people who can't get Internet connections, but I counter that it's certainly less of an exclusion than requiring them to physically attend the meeting, and it's far more unfair to make an IETF meeting fail for these who are actually using the Internet to participate in it. I disagree that providing service to people connecting from PSTN or through a gateway from the wrong software (like Skype) needs have any effect on the service provided for the other remote participants. People might be excluded because they are behind a corporate firewall or because the particular solution we chose does not run on their favorite distribution of Linux or z/OS. I also disagree with Brian's claim that 150ms is a limit for the kind of discussion that takes place in IETF working groups. It does apply to phone calls, but WG discussion tends not to be interrupt-driven. People politely wait their turn at the mike, with the chairs signaling the use of the floor. Not having the ability to connect from work (when the IETF is in a suitable time zone) means having to take the day off or relying on cellular internet that seems to have higher latency anyways. So I think some ability to connect via PSTN (and Skype) should be a requirement. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Issue: is PSTN access really required?
On Mar 30, 2012, at 1:11 PM, Dean Willis wrote: From today's meeting, taking to list. Remote participation for users connecting via the PSTN though gateways into a VoIP conference platform raises some issues. One of these is registration . There are hacks like PINs that can be made to work. But to me, the biggest problem is that it is just really hard to make it work, especially for participants on the fringe of the PSTN. Echo cancellation may be impossible to provide without exceeding the 150ms latency interaction/interrupt threshold determined in Brian Rosen's research. One doesn't necessarily need broadband to use IP. I've talked quite successfully between participants with EDGE mobile connections. But going over a long path of telephone network to a PSTN gateway, thence over IP to a conference platform is a recipe for disaster. I therefore propose that our remote participation system neither require nor support dial-in telephone numbers. This assumption can greatly simplify the system, reduce operating expense, and reduce the probability of systemic marginal failure where the system works but not well enough to actually use. Some argue that this would unfairly exclude people who can't get Internet connections, but I counter that it's certainly less of an exclusion than requiring them to physically attend the meeting, and it's far more unfair to make an IETF meeting fail for these who are actually using the Internet to participate in it. I disagree that providing service to people connecting from PSTN or through a gateway from the wrong software (like Skype) needs have any effect on the service provided for the other remote. Whatever solution we choose may be blocked by flaky network or corporate firewall. It might require remote participants to take the day off to attend a single meeting. I also disagree with the claim that the 150ms limit applies to IETF WG discussions. These are not equivalent to phone conversations. They are structured and controlled by the chairs. Even the people who are physically present politely wait their turn at the mike. I think the ability to patch in from a PSTN or Skype should be part of the requirements. Yoav ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Issue: is PSTN access really required?
[sorry for the resend] ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: IETF.Fact.Check IETF Participants that were also at ICANN Costa Rica Meeting ?
Oh, this guy pre-dates RFC 4633 http://www.google.com/search?q=%22jim%20fleming%22%20site:ietf.org On Mar 29, 2012, at 11:48 PM, Eric Burger wrote: I was about to say we are at a point for an RFC 4633 action. Thanks. On Mar 29, 2012, at 2:26 PM, JORDI PALET MARTINEZ wrote: Hi Jim, This is my last message to you as IETF Sergeant-at-arms. I've asked the Secretariat avoid your posts going thru the email exploder. Regards, Jordi -Mensaje original- De: Jim Fleming ietf.fact.ch...@gmail.com Responder a: ietf.fact.ch...@gmail.com Fecha: Thu, 29 Mar 2012 07:09:50 -0500 Para: ietf ietf@ietf.org Asunto: IETF.Fact.Check IETF Participants that were also at ICANN Costa Rica Meeting ? IETF.Fact.Check IETF Participants that were also at ICANN Costa Rica Meeting ? https://www.ietf.org/registration/ietf83/attendance.py http://www.registration123.com/ICANN/CR43/ Registration list as of: 03/29/2012 NAME AFFILIATION COUNTRY AARON STEWARTCLOUD VINE United States Aarón Quesada Méndez Ice Costa Rica Abdoul-Akim Adjibola Benin Telecoms BENIN Abel Brenes University of Cosra RicaCosta Rica ABELARDO FONSECA LA NACIÒN Costa Rica Abiodun Olawale Reboot Associates Ltd Abraham ArayaMMSoluciones Seguridad en Informatica Costa Rica Abraham Djekou AtciCote d''Ivoire Abraham RodriguezAgencia Datsun Nissan Costa Rica Acc Va Cac Ac Ac CR Adalberto López NIC Costa Rica Adam Eisner Tucows Inc. Adam Peake Glocom Japan Adaobi Okeke Nigerian Communications Commission Nigeria Adebiyi Oladipo Nigeria Internet Registration Association (NIRA) Nigeria Adebunmi Akinbo Young Internet Professionals (YiPS)/(NiRA) dotNG Nigeria Adela Elena Danciu Fellowship Romania Adrian Carballo South School On Internet Governance Argentina Adrian GarciaISOC Costa Rica Chapter Costa Rica Adrian Kinderis ARI Registry Services Australia Adrián Pérez CcssCosta Rica Adrián Quesada Rodríguez Costa Rica Adrián SolanoAcoprot Costa Rica ADRIANA DIAZ ICANN Costa Rica Adriana González Sulá Batsú Costa Rica Adriana Rivero Lacnic Uruguay Adriana UlateCOSTA RICA AGARWAL SWAPNA .INDIA India Ague Alain Ministry of agriculture Bénin Ahsan Fahmi Pakistan Aimee Deziel Mad Akewushola Adisa Sanbak Communications CommissionNigeria Akinori Maemura JPNIC Japan Alain Artero European Broadcasting Union France Alain Berranger Centre d'étude et de coopération internationale Canada Alain Bidron France Telecom/ETNO France Alain Patrick Aina AFRIMIC Bénin Alan Barrett AfriNIC / ASO-ACSouth Africa Alan Fernández Marín Universidad de Costa Rica Costa Rica Alan Fernández Marín Universidad de Costa Rica Costa Rica Alan Greenberg Alac/gnso Canada Alan Gutierrez Att Bolivia Alberto GomezRed.es España Alberto Medrano Cáceres Universidad NacionalCosta Rica Alejandra Castro Arias Muñoz Costa Rica Alejandra Fernández Bonilla TV Channel 15, University of Costa Rica Costa Rica Alejandra ReynosoFellowship Guatemala Alejandro Berrocal Valverde Viceministrerio Telecomunicaciones MINAET Costa Rica Alejandro Cruz Ministro de CIencia y TecnologiaCosta Rica Alejandro Esquivel Rodriguez Cisco Systems Costa Rica Alejandro Guzman ASO AC - LACNIC - GoogleColombia Alejandro JimenezIce Costa Rica Alejandro LizNic Do Dominican Republic Alejandro Moscol Fellow PERÚ Alejandro PisantyISOC Mexico Mexico Alejandro Portilla Navarro Radio Universidad de Costa Rica Costa Rica Alejandro Rivera ICE Costa Rica Alejandro Solis Unimer Costa Rica Alex Blowers Nominet United Kingdom Alex Mwangangi Municipal Council Of Mavoko KENYA Alex Siffrin Key-Systems GmbH Alex Stamos iSEC Partners United States Alexa Raad Architelos United States Alexander AlíCosta Rica Alexander Flores Universidad de Costa Rica Costa Rica Alexander Mora CAMTIC Costa Rica Alexander Mora Universidad de Costa Rica Costa Rica Alexander OtárolaOmd Costa Rica Alexander Panov Ru-Center Russia Alexander Rojas Coral Technologies Costa Rica Alexander Salas Arce Oficina Digital - CentroAmerica Hosting Costa Rica Alexander Schubert dotgay LLC USA Alexander Schwertner EPAG Domainservices GmbHGermany Alexander Seger Council of Europe France Alexis Coto Colegio AgropecuarioCosta Rica Alexis Sandoval Ice Costa Rica
Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy
Hi Dan I have no opinion about the level of review needed for changes to IKEv1, and I share your unhappiness with the way PAKE turned out. If I had to guess the reasons for the slow adoption of IKEv2, I would guess that it's because IKEv1 (with XAuth/hybrid, Config, odd-numbered messages, and poor PSK support for mobile peers) just works. The big vendors have at least server-side support, and Microsoft has a client in Win7. I think EAP is a hindrance, because XAuth works better with older backend servers. Your proposal will be more secure than XAuth and require less round trips, but won't integrate with AAA servers. I think anyone who is going to go to the effort of implementing this (replace or update all IKEv1 endpoints) might as well move them to IKEv2. The big hurdle to implementing what you suggest for remote access is that XAuth works. What doesn't work is a gateway with a dynamic external IP address that doesn't have a certificate. But I don't see how upgrading the gateways to support your extension is easier than upgrading them to support IKEv2. Yoav On Mar 28, 2012, at 9:49 AM, Dan Harkins wrote: Hi, Let me answer David here in a response to Yaron To be equally blunt, it is because this PAKE work became extremely political and I was, and still am, very unhappy with the way it turned out. Repeating it, this time with an obsoleted protocol, would cause (more) people to question my sanity-- i.e. doing the same thing and expecting a different result. I'd like to just get a stable reference for this minor change that has the potential to do good. I don't want to fight over it anymore. regards, Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy
On Mar 28, 2012, at 2:12 PM, Michael Richardson wrote: Yoav == Yoav Nir y...@checkpoint.com writes: Yoav If I had to guess the reasons for the slow adoption of IKEv2, Yoav I would guess that it's because IKEv1 (with XAuth/hybrid, Yoav Config, odd-numbered messages, and poor PSK support for mobile Yoav peers) just works. The big vendors have at least server-side Yoav support, and Microsoft has a client in Win7. I think EAP is a Yoav hindrance, because XAuth works better with older backend Yoav servers. Let me suggest that enhancements to IKEv1 are point releases, for which you get with your maintenance. But, IKEv2 is a major release, for which the customer pays again. I don't know about other vendors, but for us IKEv2 was introduced in a version called R71. Customers eventually do upgrade, whether it's to get IKEv2 or get one of the other features. Similarly in Windows, customers buy Windows 7 for the 64-bit support, or the aero interface, or for IPv6 support, and they also get the IKEv2. I don't think anyone is going to add new enhancements to old releases now, unless those enhancements begin with the words prevent an attack where… ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [ipsecme] #217: Temporary credentials
On Mar 26, 2012, at 9:52 AM, Michael Richardson wrote: Geoffrey == Geoffrey Huang ghu...@juniper.net writes: Geoffrey My initial inclination is to say that won't fly: that many Geoffrey deployments still require preshared key authentication. Geoffrey Rather, they would object to certificates because of Geoffrey perceived complexity. That said, I could see arguments Geoffrey that what we're discussing are already fairly Geoffrey sophisticated topologies, so perhaps the certificate Geoffrey allergy doesn't hold? Tero isn't proposing using certificates. Tero is proposing that the gateway/hub provides each leaf node with a gateway mediated, ASN.1 encoded, scalable, asymmetric, transitive proofs of identity. It would be used only for the leaf to leaf connection. It would be retained for a convenient period of time and then destroyed. Not just leaf-to-leaf, but also leaf to any other node, even if it's not a real leaf. This is beginning to look a lot like Kerberos, no? Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?
On Mar 26, 2012, at 10:47 AM, Michael Richardson wrote: Yaron == Yaron Sheffer yaronf.i...@gmail.com writes: Yaron I don't want to speak for MCR, but I think you are taking his Yaron question too far towards the implementation aspects. What I Yaron read in the question is, do we allow for a situation where Yaron (by policy and/or because of limitations in the solution) an Yaron endpoint cannot connect directly to the ultimate peer, but Yaron needs instead to go through some sort of relay. You didn't take my comments too far; I think you realized that I was in fact saying two things: 1) when traffic is redirected, MUST it be redirected directly to the real endpoint? (There might be issues of in-band double NAT that matter if the traffic doesn't get all the way there... I dunno, IPv6 RFC6145 is my answer to double NAT) 2) when traffic is redirected, MAY it be redirected more than once? Aren't these really the same question? My answer is that it's OK for redirection to happen more than once, but it's better to have less redirections than more. IOW it should be a requirement that H1 (in the diagram of your previous mail) be able to send more information about the topology behind H2 than just B is behind H2, such as D and H3 are also behind H2. But A should be required to not expect it. So H1 MUST be able to tell A that B is behind H2. It MAY be able to tell A that D is also behind H2, or that B is actually behind H3, or the actual address of B. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] draft-nir-ipsecme-erx
Hi This is about my presentation from the IPsecME meeting today (which for some reason is not on the website) Anyways, RFC 5266 mentions that RFC 4306 must be updated to carry ERP messages. This caused some controversy a year ago, but regardless, I did think of a use case, so I partnered with Qin Wu and wrote the draft. The use case is being able to seamlessly move between two networks were network access is granted or denied based on EAP. Examples are 802.1x and IKEv2. IEEE has already revised 802.1x so that moving between two 802.1x access points can use ERP to be seamless, but IKEv2 has not. a mobile device could use 802.1x within the corporate network and move to IPsec as soon as it leaves the building. MCR has called this the Elvis use case, but it actually should work seamlessly in the other direction, when the mobile node enters the building, detects the 802.1x network, establishes an association, and deletes the no-longer-needed IKE and child SAs. My first priority is for this to become a WG item. It probably needs some work, and there is an open question about whether there is any use case for multiple AAA domains. If not, I'm also fine with taking this directly to Sean. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-nir-ipsecme-erx
On Mar 26, 2012, at 6:43 PM, Tero Kivinen wrote: Yoav Nir writes: This is about my presentation from the IPsecME meeting today (which for some reason is not on the website) Anyways, RFC 5266 mentions that RFC 4306 must be updated to carry ERP messages. This caused some controversy a year ago, but regardless, I did think of a use case, so I partnered with Qin Wu and wrote the draft. RFC5996 says: While this document references [EAP] with the intent that new methods can be added in the future without updating this specification, some simpler variations are documented here. [EAP] defines an authentication protocol requiring a variable number of messages. and A short summary of the EAP format is included here for clarity. So my take there is that the EAP description in the RFC5996 is just for clarity, and is not meant to be exhaustive, meaning it does not limit codes we can use in the EAP messages. Agree. That's why my draft calls it clarification On the other hand RFC5996 also says that: Following such an extended exchange, the EAP AUTH payloads MUST be included in the two messages following the one containing the EAP Success message. which means that as ERX uses different message to finish the authentication, update to the RFC5996 is needed (i.e. not to allow codes 5 and 6, but to say we can have EAP payloads in exchanges where they normally do not be and tell that EAP exchange can finish with these other codes too). My first priority is for this to become a WG item. It probably needs some work, and there is an open question about whether there is any use case for multiple AAA domains. I agree it could be WG item. On the other hand I also think it might be quite fast document, so getting it out as individual rfc might be faster. They're not necessarily faster. What the draft needs is review, especially regarding the assumption that multiple AAA domains are not needed. I think WG documents get better review, but even that is not really clear. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[websec] Issue #41
Hi It was my review that triggered this, so I'd like to explain my position. There are several things that could be considered failures of the TLS layer: 1. Revoked certificate 2. No CRL/OCSP response 3. Expired certificate 4. Expired CRL (yes, I know NextUpdate is not expiry…) 5. Mismatch between hostname and certificate (CN or alt name) 6. Some other things I forgot? I believe we all agree that #1 should be a hard fail. Maybe even in the absence of HSTS. #2 is usually not treated as a failure today - it doesn't trigger a warning screen in any browser. I haven't tested this with HSTS, but I'd be surprised if this causes a hard fail. Same for #4. AFAIK the most common failure cases are #3 and #5. Certificates do expire, and even some well-run, security conscious site administrators have been known to let them expire. Mismatching domain names is an issue, because two FQDNs might point to the same server. IMO this is a good argument for a report-only setting, whereas the expiry is something that will bite you far after your supposedly successful deployment. I guess my issue with this is because when I read the draft for the first time, I thought this would be a good idea for websites that only do HTTPS and do not do HTTP except to redirect to HTTPS. I thought it would allow them to signal this information, and allow them to defeat HTTP-based MiTM attacks. The draft as it stands is not a good fit for this use case, because it requires more of the administrator than is currently reasonable to expect. I could propose an HSTS-light header for this use case, but I don't think anybody would like to have that. Yoav ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
[websec] Issue #42
Hi This is about fetching CRLs from a domain that happens to be the same as that of a website. Obviously you can't get a CRL or an OCSP response over HTTPS. Jeff's response was that they should use a different domain name for the CRLs (if they want to deploy HSTS) Obviously, it's too late to change AIA or CDP in existing certificates. But I think it goes deeper. HSTS affects what the browser is doing. Different resources from the same domain should all be protected by TLS. But we don't expect this to affect things that are outside the browser, like email or system updates. IMO the fetching of CRLs or OCSP responses is not part of the browsing, but part of the HTTPS handshake. The fact that some browsers implement both is besides the point. Internet Explorer uses an OS library to do the TLS handshake, including any checking of revocation. In fact getting the CRL fetch function to apply the HSTS policy would require extra effort from the browser implementer. I think we should simply say that HSTS does not apply to non-content. Fetching CRLs or browser software updates is not content, and HSTS should not apply to it. Yoav ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible
Sure. A VPN host (whether client or gateway) that is behind NAT is generally
unreachable from a random host.
To allow random hosts to get there, the VPN host needs to punch a hole in the
NAT by sending a binding request to a STUN server. The IP routable IP address
and port that it uses should be stored somewhere, in case some random VPN host
wants to contact it. It has to be stored outside the VPN host itself, because
that host is unreachable.
So if one or both of the VPN peers are behind NAT, we need some 3rd-party or
parties to broken the NAT traversal. We need:
- a STUN (or STUN-like) server for punching the hole
- storage for the discovered address and port
In SIP these functions are done by the SBC.
So just like the #214 and #217 issues, we need a 3rd party to broker the
host-2-host tunnel that we want to set up. It's tempting to assign this
function to a hub gateway as the VPN host already has the ability to
authenticate to it, but that should be part of the design, not the requirements
Yoav
P.S: Sorry if my SIP/RTP terminology is off. It's all based on a cursory
reading of a Wikipedia article.
On Mar 22, 2012, at 7:58 AM, yogendra pal wrote:
I agree to what Yoav stated, that signalling part (SIP) and media part (RTP)
both SHOULD work even if there is NAT in the configuration today. However, I
could not get why we need to have new NAT traversal mechanism using hub
gateway, can you elaborate on this...
Thanks and Regards,
Yogendra Pal
Ericsson, India
+91-9686202644
On Wed, Mar 21, 2012 at 6:49 PM, Yoav Nir
y...@checkpoint.commailto:y...@checkpoint.com wrote:
direct endpoint-to-endpoint connectivity may not be possible if both endpoints
are NATed
Why? There are several protocols (SIP/RTP come to mind) that manage
endpoint-to-endpoint connectivity even when both are behind NAT. Why shouldn't
IPsec endpoints do this?
If this requires some new NAT traversal mechanism, perhaps using a hub gateway
in place of the SIP SBC, then this should be part of the requirements.
This mechanism is needed even if only one endpoint is NATted, otherwise we're
constraining who the initiator has to be.
Yoav
On Mar 21, 2012, at 3:31 AM, Stephen Hanna wrote:
Another issue. Please comment on Suggested Resolution.
Thanks,
Steve
-Original Message-
From: ipsecme issue tracker
[mailto:t...@tools.ietf.orgmailto:t...@tools.ietf.org]
Sent: Tuesday, March 20, 2012 6:58 PM
To: yaronf.i...@gmail.commailto:yaronf.i...@gmail.com;
draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.orgmailto:draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint
connectivity may not be possible
#213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be
possible
In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible
if both endpoints are NATed.
Suggested Resolution: Mention this in section 2.1.
--
-+-
Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn-
yaronf.ietf@… | problem@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: p2p-vpn-| Severity: -
problem| Keywords:
Resolution: |
-+-
Ticket URL: http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/213#comment:1
ipsecme http://tools.ietf.org/ipsecme/
___
IPsec mailing list
IPsec@ietf.orgmailto:IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
IƧ��[�(^rC�{S�֥I�.�+r �^��
___
IPsec mailing list
IPsec@ietf.orgmailto:IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [ipsecme] #219: Star topology as an admin choice
I don't think this is an all-or-nothing choice. You might want a mesh for VoIP, but a star for HTTP, FTP and mail protocols. Or you may want a mesh within your organization, but to trunk and inspect all traffic going somewhere else. On Mar 21, 2012, at 3:37 AM, Stephen Hanna wrote: Please comment. Steve -Original Message- From: ipsecme issue tracker [mailto:t...@tools.ietf.org] Sent: Tuesday, March 20, 2012 7:04 PM To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org Subject: [ipsecme] #219: Star topology as an admin choice #219: Star topology as an admin choice Some admins prefer a star topology so they can inspect traffic. They may not want to use this technology. Suggested Resolution: Mention this in the Security Considerations section. -- -+- Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- yaronf.ietf@… | problem@… Type: defect | Status: new Priority: normal | Milestone: Component: p2p-vpn- | Severity: - problem| Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/219 ipsecme http://tools.ietf.org/ipsecme/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec �jy�u$���:-jT�r��!��� ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible
direct endpoint-to-endpoint connectivity may not be possible if both endpoints
are NATed
Why? There are several protocols (SIP/RTP come to mind) that manage
endpoint-to-endpoint connectivity even when both are behind NAT. Why shouldn't
IPsec endpoints do this?
If this requires some new NAT traversal mechanism, perhaps using a hub gateway
in place of the SIP SBC, then this should be part of the requirements.
This mechanism is needed even if only one endpoint is NATted, otherwise we're
constraining who the initiator has to be.
Yoav
On Mar 21, 2012, at 3:31 AM, Stephen Hanna wrote:
Another issue. Please comment on Suggested Resolution.
Thanks,
Steve
-Original Message-
From: ipsecme issue tracker [mailto:t...@tools.ietf.org]
Sent: Tuesday, March 20, 2012 6:58 PM
To: yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
Subject: [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint
connectivity may not be possible
#213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be
possible
In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible
if both endpoints are NATed.
Suggested Resolution: Mention this in section 2.1.
--
-+-
Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn-
yaronf.ietf@… | problem@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: p2p-vpn-| Severity: -
problem| Keywords:
Resolution: |
-+-
Ticket URL: http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/213#comment:1
ipsecme http://tools.ietf.org/ipsecme/
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
IƧ��[�(^rC�{S�֥I�.�+r�^��
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?
I agree that this pre-supposes that the solution will involve gateways figuring things out for endpoints in either one step or more than one step. It pre-supposes a two-tier system. We've had a presentation in Taipei that did not involve gateways, but rather specialized servers carrying authoritative information, with all the IPsec hosts, whether gateways or endpoints querying those servers. Those servers could be specialized IPsec information servers, dispensing PAD and SPD entries through a web service, or they could be the DNS system. Either way, this is a different model to the one that has the information flowing through the overlay network. So I agree that answering this question is pre-mature. Whatever the model, there will be an equivalent question, but I think it's too early now. Yoav On Mar 21, 2012, at 9:59 PM, Stephen Hanna wrote: Again, this issue was based on Michael Richardson’s March 12 email, which said: The dual trunk scenario should perhaps be further motivated and clarified. Are there some situations where a spoke should not contact another spoke directly, but in fact should contact a hub closer to the other spoke. I can see some solutions where a hub would not have complete knowledge of the mesh, and so would in fact simply punt a connection closer. I hope this clarifies the issue for you. I think that Michael is asking an important question. There are many ways to solve the P2P VPN problem. One way is to have satellites with little configuration that connect to core gateways with lots of dynamic information. A core gateway (a “hub” in Michael’s parlance) can download things to a satellite (maybe a new SPD and PAD, credentials, etc.), thus causing some traffic from the satellite to be sent to a different core gateway or satellite. In that circumstance, I think Michael’s question is about whether the core gateway that a satellite initially connects (which I’ll call the “initial core gateway”) to should be expected to have or obtain all the information needed to configure the satellite or whether the initial core gateway can send the satellite to another core gateway where it can get more information. At least, that’s how I understand Michael’s question. Perhaps he can affirm or deny this interpretation. Personally, I think that this question is premature. It presupposes too much about the eventual solution. That’s why I think it should be answered in the solution not included in the problem statement. Apparently, Yaron doesn’t agree with me. I’d like to hear more from him on this matter. Does he believe that all solutions to this problem (or at least all the good ones) must necessarily employ the model that I described above? What about a solution that doesn’t rely on core gateways to refer satellites but instead has satellites querying for the information that they need? Or one that has some external entity (not the core gateway) configuring the satellites? In my view, there may be many possible P2P VPN solutions. However, I’m not an IPsec expert. Maybe this is the only practical approach. I’d like to hear views from Yaron and from others on this topic. Thanks, Steve From: ipsec-boun...@ietf.orgmailto:ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Vishwas Manral Sent: Wednesday, March 21, 2012 3:18 PM To: Stephen Hanna Cc: IPsecme WG Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? Hi Steve, This is unclear to me. Isn't it routing that we send a packet across to a closer gateway/ router? What does everything mean in the question below? If we are talking about say security and routing, I think that is true. The logical gateway (could be multiple interactions and devices) should be able to provide the functionality. Thanks, Vishwas On Tue, Mar 20, 2012 at 6:33 PM, Stephen Hanna sha...@juniper.netmailto:sha...@juniper.net wrote: Please comment on Suggested Resolution. Note that Yaron has already supplied his comment below. Steve -Original Message- From: ipsecme issue tracker [mailto:t...@tools.ietf.orgmailto:t...@tools.ietf.org] Sent: Tuesday, March 20, 2012 6:59 PM To: yaronf.i...@gmail.commailto:yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.orgmailto:draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org Subject: [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? #214: Should gateways figure things out completely or just punt endpoints to a closer gateway? Suggested Resolution: We should not specify this in the problem statement. It should be specified in the solution. YS: sounds like a requirements-level question to me. -- -+- Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- yaronf.ietf@… | problem@… Type: defect | Status: new
Re: [IPsec] [ipsecme] #218: Exhaustive configuration
+1 Not only IP addresses, but actual peers may come and go. A user database changes every day as employees (for example) come and go. On Mar 21, 2012, at 9:26 PM, Vishwas Manral wrote: Hi Steve, Like I mentioned the problem is not just exhaustive configuration but also the fact that configuration parameters like IP address change. I agree we should expand the section you mention below. Thanks, Vishwas On Tue, Mar 20, 2012 at 6:37 PM, Stephen Hanna sha...@juniper.netmailto:sha...@juniper.net wrote: Keeping you entertained in the week before IETF 83... Steve -Original Message- From: ipsecme issue tracker [mailto:t...@tools.ietf.orgmailto:t...@tools.ietf.org] Sent: Tuesday, March 20, 2012 7:03 PM To: yaronf.i...@gmail.commailto:yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.orgmailto:draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org Subject: [ipsecme] #218: Exhaustive configuration #218: Exhaustive configuration Exhaustive configuration can work fine if there are good automated configuration protocols. Suggested Resolution: Exhaustive configuration doesn't scale for constrained devices in large networks. Explain this in section 3.1. -- -+- Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn- yaronf.ietf@… | problem@… Type: defect | Status: new Priority: normal | Milestone: Component: p2p-vpn- | Severity: - problem| Keywords: | -+- Ticket URL: http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/218 ipsecme http://tools.ietf.org/ipsecme/ ___ IPsec mailing list IPsec@ietf.orgmailto:IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.orgmailto:IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Some comments to the draft-ietf-ipsecme-p2p-vpn-problem-00
On Mar 14, 2012, at 8:00 AM, Tero Kivinen wrote: In section 2.1 where there is dicsussion about the endpoint to endpoint vpn use case, it should be noted, that this might require different temporary credentials. Endpoints (especially remote access users) do use passwords or similar credentials which cannot be forwarded. I.e. if the shared secret is used to authenticate the end node to the gateway, that same shared secret cannot be given to the another end point as that would allow it to impersonate the first peer. Also the endpoint most likely cannot access the same AAA server than what security gateway does, so if peer uses EAP to authenticate itself to the security gateway, the endpoint to endpoint vpn cannot use the same credentials. Users use passwords, but endpoints can use PSKs and certificates. PSKs should be pairwise, so they have to be provisioned dynamically. It's all part of having to create the PAD entries dynamically. If we anyway have to provision peer's IP address/locator and identity (DN, username) we might as well also provision a PSK. If we really want to authenticate users, we need to use EAP to authenticate to some trusted (by whom?) server. Then we can extend that authentication to other endpoints and gateways that are not connected to the same AAA server, perhaps using some mechanism like tickets or session resumption or ERP, or by having the gateway provision the shared secrets for the client and the other peers. This means that we might need to add creation of temporary credentials to the protocol. I think that unless we are going to mandate a system based solely on certificates, that's a given. In section 3.1 exhaustive configuration I think it is incorrect to claim it does not scale, as if the configuration is pushed to all devices using some kind of out of band configuration tool it is completely possible to make extreamly large setups. Dynamic updates do cause some problems there, as every change might require policy to be pushed to every single node. I think the main problem with this setup is that it requires that out of band configuration system, and those are proprietary which means you cannot use implementations from different vendors. Take a company the size of IBM. They have 400,000 employees. Probably hundreds of thousands of smartphones, hundreds of thousands of PCs, and thousands of VPN gateways. It doesn't make sense that each smartphone holds the entire PAD for all this, and we haven't even mentioned partners and customers yet. You could keep a kind of star topology, where the phones are secondary nodes, and they connect to some primary nodes (using IKE or something else). When they need to connect to some other primary or secondary node, they get that information from the primary node. And you can have the primary nodes know everything, or make it hierarchical or DNS-based or something else entirely. This discovery mechanism is a big part of the charter item, and I think it should avoid having to push the entire policy to each endpoint. In section 3.2 about star topology it should be noted, that quite often adminstrators do require star topology because they want to do some kind of inspection for all traffic inside the vpn. This kind of policy might make it impossible to do endpoint to endpoint connections, and might limit which kind of gateway to gateway cases are allowed. That's a matter of policy. Sometimes they want to inspect traffic going in and out of their organizational VPN, but not traffic flowing within it. So traffic from the Maastricht office can flow freely to the Quebec City office, and doesn't have to go through the New York datacenter. But traffic going to Facebook needs to be scanned, and goes through the datacenter. I do not see how the last paragraph in section 3.2 does not seem to belong there: The challenge is how to build large scale, fully meshed IPsec protected networks that can dynamically change with minimum administrative overhead. The section 3.2 talks about existing star topology solutions, and making large scale fully meshed network is not even in scope for such systems. I think the point of section 3.2 is that stars are defined partly because they're easier (just one credential to configure on each satellite). The challenge is to overcome the difficulty in defining a mesh. In section 3.2 we should also mention that with proprietary approaches it is not clear whether they implement all checks required by the IPsec architecture, i.e tunnel exit checks, firewall rules, security policy checks etc. They might do those, or they might skip them... In general the current use case description was quite good, and I think this document is good start. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: Add a link to the HTML version in i-d-announce mails ?
Even better, also add the XML2RFC output if it's available at the same time: http://tools.ietf.org/id/draft-name.html for example, (just picking my own latest draft as an example): http://tools.ietf.org/id/draft-nir-websec-extended-origin-02.html I don't know which drafts get this version (perhaps those submitted along with XML?), but they're sure easier to read than TXT. Yoav On Mar 6, 2012, at 3:41 PM, Xavier Marjou wrote: As a subscriber of the i-d-annou...@ietf.org list, I generally prefer reading the HTML version of the draft rather than the TXT version. I thus often need to manually rewrite the TXT link to fetch the HTML version of the draft. I can not believe I'm the only one. Hence, would it be possible to also include a link like http://tools.ietf.org/html/draft-name in the mail of the announced draft? Cheers, Xavier ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
The XML2RFC version is not linked from there. If that was added to the Other versions field, that would be great. On Mar 6, 2012, at 5:11 PM, Xavier Marjou wrote: With a link like https://datatracker.ietf.org/doc/draft-name/ (e.g. https://datatracker.ietf.org/doc/draft-nir-websec-extended-origin/ ), I will most often then click again on the html top right link. But I'm fine with it too. On Tue, Mar 6, 2012 at 3:12 PM, Russ Housley hous...@vigilsec.com wrote: I would be much happier with a link to the datatracker HTML version: https://datatracker.ietf.org/doc/draft-name/ Would this meet your needs? Russ On Mar 6, 2012, at 8:41 AM, Xavier Marjou wrote: As a subscriber of the i-d-annou...@ietf.org list, I generally prefer reading the HTML version of the draft rather than the TXT version. I thus often need to manually rewrite the TXT link to fetch the HTML version of the draft. I can not believe I'm the only one. Hence, would it be possible to also include a link like http://tools.ietf.org/html/draft-name in the mail of the announced draft? Cheers, Xavier ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Scanned by Check Point Total Security Gateway. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Add a link to the HTML version in i-d-announce mails ?
On Mar 6, 2012, at 11:44 PM, Julian Reschke wrote: On 2012-03-06 16:26, Yoav Nir wrote: The XML2RFC version is not linked from there. If that was added to the Other versions field, that would be great. ... Indeed. HTMLized plain text is progress over plain text, but properly generated HTML is better. But I fear we're getting close to our beloved permathread. Pictures in RFCs? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
[IPsec] P2P VPN Problem Statement - why is this hard?
Hi Steve On Mar 6, 2012, at 11:54 PM, Stephen Hanna wrote: So please review this short document and send comments. While the draft does a good job of describing use cases, and certain inadequate solutions, I think it's missing a description of why this is hard. Even if we accept the solution of a star topology, where a satellite needs only have one single tunnel, there are really two choices: 1. that each satellite know about all the protected networks of all the gateways in the configuration, or 2. that satellites send all traffic to the core or hub gateways. This includes clear traffic (as in HTTP to facebook.com). This increased the load even more. If you don't want #2, then the satellite still needs to know about every IP address whether it is protected by some gateway (and therefore needs to go in the tunnel), or not (and so packets with that destination should go out in the clear). Since the protected networks change, this requires that information to propagate throughout the network, and dynamic updates to SPD If we don't want a star topology, the gateways or endpoints still need to know what is or is not encrypted. They also need to either know about all peers, or be able to find the peer and (securely) learn how it should authenticate. Either way, without a star topology, you need dynamic updates to PAD. I think the draft should mention this. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [websec] I-D Action: draft-nir-websec-extended-origin-00.txt
Hi Tobias, Replies inline. On Mar 3, 2012, at 6:07 PM, Tobias Gondrom wrote: Hello Yoav, thank you for the interesting draft. hat=individual I have a few points as feedback: - the 3-tupel of origin consists of real parameters (protocol, URL, port), while the introduction of the 4th tupel feels like an artificial parameter extension as it is not mapped to anything visible to the client and in fact will be spliced by the middle-server (vpn server). This makes me very hesitant, whether this would be a good idea. As far as the client is concerned, there is only one server. If that server does not give any hints to the client, it's going to treat all these different resources as belonging to the same origin. So it does map to something the server sends. - As Adam mentioned that there will be migration problems. At the moment all browsers and other systems operate on the SOP with 3-tupel to compare for identity. It will be difficult (read: near impossible) to enforce that all deployed systems out there shall from now on be compliant with a 4-tupel and no longer assume identity of two sites when only the first three parameters are equal. So, although I agree that economic reasons are absolutely viable reasons for such an idea, I have concerns that this draft is only a workaround for certain closed areas (i.e. where a company can basically enforce that all accessing clients are in fact updated using such a 4-tupel policy) but will create severe consistency issues in the Internet where you would then see a mix of 3-tupel and 4-tupel clients, with the risk of messing up the predictability of handling of SOP. Actually, SSL VPNs are deployed where the company has no control over the clients. Sure you can enforce that users only use one kind of browser, but typically SSL VPNs are deployed so as to support any type of client, from phones to desktop. Companies that have that level of control tend to equip their employees with laptops that run IPsec VPNs. However, these SSL VPN portals exist today, and hide multiple servers behind a single hostname and port. Typically these will be mostly internal servers with a few external ones. For example, our deployment has the mail server (OWA), the internal Wiki, The automated build system, the SAP web application, and the web application of an external service provider that delivers lunch. These are not just random sites on the Internet, but specific servers that the administrator has chosen. The way these are deployed now, the lunch service provider can steal the cookies from the mail server, or script it. Having the SSL VPN server provide this extra information might help security (if the browsers use that information). It won't make it worse. Maybe a question regarding the use cases: As in general, systems use sub-domains for such purpose (as explained by you and James), I am wondering whether there are other scenarios (beyond VPN) that may need this 4th origin parameter? I guess any HTTP reverse proxy may hide multiple servers behind it. Reverse proxies are used for caching, load balancing, access control to web application. Even CDNIs are a type of reverse proxy. I believe that SSL VPNs are a little different. The other types of reverse proxy are typically installed and maintained by experts. SSL VPNs are installed and maintained by people whose knowledge of networking can range from NOC team material to the CEOs nephew who's really good with computers. So I think all reverse proxies could benefit from a 4th origin parameter, but I think most of the others can work around that need, while some SSL VPN customers can't. Yoav ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
On Feb 26, 2012, at 2:44 AM, Mark Nottingham wrote: I proposed a plan that I think might allow us to make progress on that. I believe we could. OK, great. Could you please explain why you think tying this effort to HTTP/2.0 is necessary to achieve that? To me that's the critical bit, and I still haven't seen the reasoning (perhaps I missed it). I think I have *an* answer to this, though probably not *the* answer. There's two stages to adoption - implementation and roll-out. Obviously you can't roll out new authentication before the browsers and servers implement it. For my website, I wouldn't roll out new auth if only one or two of the browsers out there implemented it. Even if all the big ones (IE, Firefox, Chrome, Opera) did, I would still have to provide a backwards compatibility authentication scheme to support older browsers. This would lead to both inconsistent UI and to ugly javascript that detects the browser version, and makes the roll-out slower. If any HTTP/2.0 browser is bound to have new authentication it makes things much easier. This could be circumvented by adding request headers that advertise capabilities, but I don't think we like those much. Yoav ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
On Feb 24, 2012, at 5:02 PM, Paul Hoffman wrote: On Feb 24, 2012, at 4:54 AM, Stephen Farrell wrote: Proposals for new HTTP authentication schemes are in scope. How would a plan like the following look to folks: - httpbis is chartered to include auth mechanism work as per the above (or whatever text goes into the charter) snip/ Might that be a way forward that'll give enough folks enough of what they want/need? It would, but I would like to give a counter-proposal that I think will use people's different talents better: - new wg on developing http authentication mechanisms is chartered soon (BoF in Paris); call it the ham wg - httpbis is chartered to follow the work of the ham wg and is required to make sure that the authentication framework in http 2.0 works for as many of the proposals from the ham wg as possible - ham wg is responsible for most of what you list above - http2.0 document says the mandatory to implement auth mechanisms are named in that RFC over there, which comes from the ham wg There will be overlap in wg membership, but not nearly as much as would be needed for your proposal. I like the idea, but there is always the danger of the HAM working group either getting stuck with multiple non-interoperable proposals like we've seen at IPsecME with the PAKE work. There is also the possibility of getting stuck with conflicting requirements. For example, there will be a need to use existing user databases (RADIUS/DIAMETER servers, LDAP directories), but that is hard to reconcile with the preference for ZKPs. I'm not really worried, because HTTP/2.0 is bound to take a long time, and there will be plenty of opportunity for chair and ADs to step in and intervene if the wg actually does that. On a more technical note, we are 12 days past the cutoff date for new BoF session requests, so it's probably too late for a BoF in Paris. Yoav ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Calls and Godwin-like rules
On Feb 16, 2012, at 4:09 PM, Måns Nilsson wrote: Subject: IETF Last Calls and Godwin-like rules Date: Thu, Feb 16, 2012 at 09:04:03AM -0500 Quoting John C Klensin (john-i...@jck.com): ... first appearance of many no-information I support this endorsements from people and constituencies who are not regular participants on the IETF list should immediately trigger a state in which all further statements from that side would be ignored or would end the discussion entirely? Yes, I see the difficulties in figuring out the details of such a rule and implementing it and am mostly joking. Mostly. I support this. +1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Calls and Godwin-like rules
On Feb 16, 2012, at 4:04 PM, John C Klensin wrote: A current Last Call has apparently brought on another of the please tell all your friends to send in supportive notes, even if they don't say much of anything substantive campaigns that we see from time to time. When those notes come from people who do not routinely participate on IETF lists, they provide very little real information unless we have suddenly taken up voting or otherwise counting notes. Whatever we might otherwise think of company positions, a note that said I work for xyz and we need this and intend to implement and deploy it would be real information that the community could consider where I am an individual and +1 does not. Sadly, such endorsements, especially from people who are not active IETF participants, add to the noise and might prevent someone who was still genuinely trying to understand the pros and cons (presumably including all of the IESG) from seeing a new and substantive argument, no matter how well-grounded. I note that there are some folks in the community who seem to favor these campaigns when they like the cause and not if they do not. But I wonder whether, in the interest of noise reduction and/or support of our no voting, even by active participants position, there be any sympathy for a Godwin-like rule that the first appearance of many no-information I support this endorsements from people and constituencies who are not regular participants on the IETF list should immediately trigger a state in which all further statements from that side would be ignored or would end the discussion entirely? Yes, I see the difficulties in figuring out the details of such a rule and implementing it and am mostly joking. Mostly. Because we don't vote, the show of support with all the +1s really doesn't amount to much. I don't think even promises to implement carry much weight at last call. By the time some proposal has gone to last call, especially IETF last call, the issue of whether this will be useful to someone should have already been settled. I think that an endorsement like I work for Cisco and we intend to implement this in every one of our products is useful. But it's not nearly as useful as this is a terrible idea, and doing this will prevent IPv6 from ever gaining traction. The objections raised in last call are really the point, not the endorsements. Yoav ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Calls and Godwin-like rules
On Feb 16, 2012, at 4:48 PM, Roger Jørgensen wrote: On Thu, Feb 16, 2012 at 3:34 PM, Yoav Nir y...@checkpoint.com wrote: snip I think that an endorsement like I work for Cisco and we intend to implement this in every one of our products is useful. But it's not nearly as useful as this is a terrible idea, and doing this will prevent IPv6 from ever gaining traction. The objections raised in last call are really the point, not the endorsements. Think I've read somewhere that the ground of good engineering (the E in IETF) are being able to argue against your own idea, search and look for flaws in it, and all in the name of testing it to see how it can be made even better, is it good enough? Or simple to consider the bigger picture, can my idea hurt the rest no matter how good it is? There are great and very good ideas out there that isolated are fantastic, but considered in just a bit bigger picture are horrible, they've ruin everything around them. I agree. IPv4 forever using CGNs may work for a lot of people and a lot of uses. If people remain double- or triple-natted it won't matter a bit to the big web sites. It's far more important to hear what is not going to work with this solution. It's great if you can find such deficiencies in your own ideas, but we still need design reviews, code reviews, QA departments and IETF last calls so that others can get at your idea. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Variable length internet addresses in TCP/IP: history
On Feb 15, 2012, at 1:56 AM, Bob Hinden wrote: Martin, On Feb 14, 2012, at 2:45 PM, Martin Rex wrote: Brian E Carpenter wrote: Martin, One the one hand, the IETF was frowning upon NATs when they were developed outside of the IETF. But if you look at the IETFs (lack of) migration plan, the translation that you need in order to make old-IPv4 interoperate with new-IPv6, is actually worse than an IPv4 NAT. I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and hosts that are numbered out of an address space greater than 32 bits requires some form of address sharing, address mapping, and translation. It doesn't matter what choice we made back in 1994. Once you get to the point where you've run out of 32 bit addresses and not every node can support 32 bit addresses, you have the problem. But what is your point? With a fully backwards compatible transparent addressing scheme, a much larger fraction of the nodes would have switched to actively use IPv6 many years ago. Right, just like they could have deployed dual stack many years ago too. The deployment problem was not due to technical issues, it was because the Internet changed to only deploy new technology that generated revenue in the short term. After a lot of thought, I have come to the conclusion that it wouldn't have mattered what the IETF did, we would still be facing the same problems. It wouldn't be seriously deployed until IPv4 address ran out. These if we had only done foo discussions all miss the biggest deployment factor. I disagree with that. With things that take considerable effort to develop and deploy, any sane business or agency would do a cost/benefit analysis, and not deploy unless they can see how it pays off. Smaller projects sometimes go under the radar. Maybe the cost-benefit analysis says it's not worth doing a cost-benefit analysis. When investment is low, people do things even without assurances that those would in fact be needed. I'll leave example from our employer out of this thread. If adding support for the next IP version in products was easy (say, 1-2 man-years for an OS, and 1-2 man months for an application), then Windows XP, Mac OS 10.1 and whatever Linux was running at the time and Solaris 2.9 would have had the support, and applications would follow quickly, long before IPv4 addresses became scarce. Yoav ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [therightkey] Paris too soon for a meeting...
On Feb 12, 2012, at 10:19 PM, Kai Engert wrote: On 12.02.2012 01:57, Stephen Farrell wrote: If folks wanna meet during IETF week then I'd suggest a doodle poll to pick a time slot. How about this? http://www.doodle.com/8c5s43ayqbrft5rm That's about it, but usually we do this after the preliminary agenda has been posted. Also, Friday after 18:00 is a non-starter. ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: Room sharing in Paris?
Hi Kevin You can register at https://www.ietf.org/meeting/register.html You can hold off on paying until early March. That will give you the ability to edit the meeting wiki: https://www.ietf.org/registration/MeetingWiki/wiki/ietf83 You can easily add a page there for what you're looking for. Alternatively, you can register to the 83attendees list, and ask there. Note, however, that there are currently about 290 people on the list, and there has been no traffic. That's less than a third of the people going to the meeting https://www.ietf.org/mailman/listinfo/83attendees On Jan 23, 2012, at 10:04 PM, Kevin P. Fleming wrote: Is there an appropriate list/wiki/etc. to discuss possible room sharing arrangements? I'm not going to be able to register for the event until I get this worked out, so I can use the meeting-specific attendees list for that purpose. If there is no such place, I'll state here that I'm interested in discussing sharing a double room for IETF 83 in Paris from March 25th through 31st. Contact me off-line to discuss. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Scanned by Check Point Total Security Gateway. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt
So if I understand this correctly, the notarized data contains the acceptable mode and the allowed member groups, signed (and time-limited?) by the SeGW. The tunneled protocol between the FAP and the core network would change, so that instead of the FAP sending unsubstantiated claims, it would replay the notarized data from the SeGW. Wouldn't this require an update of both core network components, SeGW and FAPs? I would think that the SeGW could instead look at the decrypted protocol between the FAP and the core network (it is decrypting it after all), and block it if it contains lies. A change like this would require modifying only the SeGW. I may be showing some serious firewall vendor bias here... Anyway, yes, your clarification helped me very much. Regarding the term notarized, I would prefer not to bring in a new term that is burdened with other meaning. But legal notaries are obscure enough that it doesn't matter much. Perhaps some explanation as to what it means in the draft would help. You are correct in the draft, that it is out of scope for the working group what the exact content of the new attribute is. However, the CP payload is contained in the biggest packet of all of IKE - the IKE_AUTH packets. Can you tell us how large these attributes may be? Since IKE is still UDP-only, size matters very much. Thanks Yoav From: zong.zaif...@zte.com.cn [mailto:zong.zaif...@zte.com.cn] Sent: 21 January 2012 11:08 To: Yoav Nir Cc: ipsec@ietf.org Subject: 答复: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt Hi Yoav: Thank you for your email. Regarding to your question on what is the malicious FAP lying about, I would like to give you some further background. In real femto deployment, not every mobile terminal is allowed to attach via an FAP. In fact, in the real deployment, there are 3 kinds of FAPs: open mode FAP, close mode FAP, and hybrid mode FAP. The open mode means that the FAP is open to everyone, close mode means the FAP only allows a closed group of members to access, and the hybrid mode means that the FAP is open to everyone, but only a closed group of members will have higher priority or have authority to visit certain resources. According to some SDO (e.g. 3GPP), the access control of the mobile terminals attaching via a FAP is done in core network, thus, it is the core network that decide whether the mobile terminal can attach to an FAP. In order to help the core network make decision on whether the mobile terminal can attach to an FAP, the FAP needs to send information, such as the mode of the FAP, and the allowed member group of the FAP, to the core network. A compromised FAP could send false mode and false allowed member group to the core network, so that a not allowed mobile terminal could be allowed by the core network. I wish the above clarification helps you understand the problem. Regarding to the term notarized, since I am green to this group, I am not sure, do you prefer to replace the notarize with signature? Please let me know, thank you! BR Zaifeng Yoav Nir y...@checkpoint.com 2012-01-21 15:30 收件人 zong.zaif...@zte.com.cn zong.zaif...@zte.com.cn zong.zaif...@zte.com.cn 抄送 ipsec@ietf.org ipsec@ietf.org 主题 Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt Hi Zaifeng Reading your draft, I'm trying to understand the problem you are solving. It is about the FAP being compromised and sending false information through the tunnel. What is the malicious FAP lying about? How does sending some information (does notarized mean signed?) from the SeGW to the (compromised) FAP help? One general comment: notarized is a legal term, similar to signature. Although there is some analogy between the legal concept of signature and the digital signatures, such analogies only go so far. Using such a borrowed term has IMHO led to more confusion than clarity. I would rather not use legal terms in protocols (although protocol is also a borrowed term) Thanks, Yoav On Jan 20, 2012, at 8:40 AM, zong.zaif...@zte.com.cn zong.zaif...@zte.com.cn wrote: Hi Folks: There is a new draft available that some of you may be interested in looking at. The draft is available via the following link: http://www.ietf.org/id/draft-zong-ipsecme-ikev2-cpext4femto-00.txt Please send your comments to the list. Thanks! BR Zaifeng ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [websec] preparing for Paris
I believe that Alexey has requested a session on 19-Dec. On Jan 17, 2012, at 7:08 PM, Peter Saint-Andre wrote: Just a friendly reminder that WG sessions for IETF 83 need to be scheduled less than 2 weeks from now: http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83 Peter ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert
Interesting.
But I don't see how subdomains help. If I have a website called
charcount-5.example.com, and I use a wildcard *.example.com certificate, the
HSTS entry is still written for charcount-5.example.com. Adding subdomains
would affect *.charcount-5.example.com, not 0-H.example.com.
I wouldn't want to force the includeSubdomains, as there may be valid reasons
to have a subdomain of example.com that is HTTP, whereas the decision on buying
a wildcard certificate is a matter of cost and convenience.
Yoav
On Jan 15, 2012, at 4:52 AM, websec issue tracker wrote:
#34: HSTS cache manipulation and misuse by server enabled by wildcard cert
See..
The Double-Edged Sword of HSTS Persistence and Privacy -- by Mikhail
Davidov
http://haxsys.net/2011/04/the-double-edged-sword-of-hsts-persistence-and-
privacy/
summary:
This technique allows a web app on one domain to surreptitiously send a
message to another web app on another domain via manipulation of the HSTS
cache...
If server wields a wildcard cert, eg for *.example.com, then example.com
can create any number of subdomains of example.com, with any subdomain
name, and then direct user agents to fetch resources from these
subdomains. If HSTS Policy is returned for each of these subdomains, and
includeSubDomains is not used, then any number of entries will be created
in in the user agent's HSTS store. E.g., an web page like the below would
accomplish this..
[img]https://charcount-5.example.com/setbit.png[/img] -- this
stores the char count of the msg
[img]https://0-H.example.com/setbit.png[/img]
[img]https://1-E.example.com/setbit.png[/img]
[img]https://2-L.example.com/setbit.png[/img]
[img]https://3-L.example.com/setbit.png[/img]
[img]https://4-O.example.com/setbit.png[/img]
These entries can be read back by some other web application under some
other domain name by causing the user agent to send HTTP requests to
example.com in order to brute-force the character count subdomain name --
the server responds whether the name is available over just http -- which
means it is a miss, or over HTTPS, which is a hit..
http://charcount-1.trackingexampledomain.com/getbit.png [ Server: HTTP ]
http://charcount-2.trackingexampledomain.com/getbit.png [ Server: HTTP ]
http://charcount-3.trackingexampledomain.com/getbit.png [ Server: HTTP ]
http://charcount-4.trackingexampledomain.com/getbit.png [ Server: HTTP ]
http://charcount-5.trackingexampledomain.com/getbit.png [ Server: HTTPS!
] -- msg char count is 5
Then the web app can brute force each character of the message in a
similar fashion.
the original message-sending domain web app can clear the cached message
by causing the user agent to re-request resources from the same dubdomains
and returning a HSTS header for each with max-age=0.
For a resolution, Mikhail suggests..
My proposal is to amend the draft to force the includeSubDomains flag on
wildcard certificates. This would limit them to only one entry in the
browsers HSTS database and make the technique above prohibitively
expensive to non-CA owners as a separate signed SSL certificate would be
needed for every bit of information stored and limit encoding options.
--
-+-
Reporter: | Owner: draft-ietf-websec-strict-transport-
jeff.hodges@… | sec@…
Type: defect | Status: new
Priority: major| Milestone:
Component: strict- |Version:
transport-sec | Keywords:
Severity: Active WG|
Document |
-+-
Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/34
websec http://tools.ietf.org/websec/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
IƧ��[�(^rC�{S�֥I�.�+r�^��
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
Re: [IPsec] Large Scale VPN
Hן Mike On Dec 22, 2011, at 3:16 AM, Mike Sullenberger wrote: Everyone, I noticed that in the four vendor presentations in the P2P VPN - side meeting in TAIPEI that none of vendors chose to extend or augment IKE/IPsec to solve this class of problems. This is not to say that vendors haven't chosen to extend IKE/IPsec to solve other classes of issues, I.e. XAuth and Mode-config. My firm belief is that IKE/IPsec is at the wrong level to solve or standardize the creation of encrypted dynamic mesh networks. DMVPN, as one example, has for over 8 years solved this issue by using protocols that are specifically designed for the different needs for creating encrypted dynamic mesh networks. If you modify IKE/IPsec to perform these functions then you will end up having to add (redo) the functionality of already existing protocols in IKE/IPsec and the result will not be able to do as good a job. I believe that IPsec tunnels work very well. The current standards lack two things: 1. The ability to discover how to get to some address (what is the next gateway to which I should establish a tunnel 2. The ability to establish trust between two gateways. It's not enough to find an IP address for the next hop, you also need to learn how to authenticate it. Routing protocols can do #1 on real networks. Running them on tunnels seems to be like using links as metaphors for tunnels. But that's just my bias. They don't do much for #2 unless you extend them, and then you might as well extend any other protocol. 1. I have no problem with creating a problem statment including use cases, but I am not sure how usefull this will be coming from the ipsecME WG when the solution for the problem statement shouldn't be done in IKE/IPsec. I think the solution is for the IPsecME group regardless of whether it is in IKE, in a web service, or in a combination of mGRE, NHRP and OSPF. This is about building large scale IPsec VPNs, and that's the job of the IPsecME group, even if it involves extending a routing protocol. 2. I don't see how nor why the ipsecME WG should be involved in vendors publishing an informational RFCs about their solutions. I didn't think that there is a need for a WG's approval or help to publish an informational RFC. Note, we (Cisco) have said that we are willing to submit an informational RFC about DMVPN and having it ready by August 2012 is fine. The term I used was review and help publish. It's going to be an Informational document describing an existing technology. Of course the WG has no input on the technical issues in DMVPN. The comments you'll be able to get from the group are along the lines of section #3 is not clear, or could you rephrase section 2.3 in RFC 4301 terminology?, not let's change the encoding here to XML 3. Again I firmly believe that a standardized solution to encrypted dynamic mesh networks should not be done by modifying IKE/IPsec. Therefore the ipsecME WG is the not the right IETF WG to analyze and or select a solution. I think otherwise, regardless of the specific technology. 4. At least three vendors (Cisco, Juniper and Alcatel) have very successfully implemented large-scale encrypted dynamic mesh networks by using IKE/IPsec for encryption, GRE for protocol independent tunneling, NHRP for endpoint discovery and Routing protocols (even static routing) for the routing/forwarding of data traffic (subnets) through the encrypted tunnels. I seem to remember from the Juniper presentation that they did not use GRE (except as a Cisco compatibility feature - Check Point has that too). No idea about Alcatel I therefore vote against this change to the ipsecME WG charter. -1 Thanks, Mike Sullenberger If we want Paul and Yaron to take this to our AD, we need to show that there are more people who think these work items are a good idea. More people than just me and MCR. So please show your support (or objections!) soon. An I think this is a good idea, I think we should use ternary logic, or +1 is all it takes. Yoav On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote: Agree. How about: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, etc. The IPsecME working group will handle this large scale VPN problem by delivering the following: * The working group will create a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. Should reach WG last call
Re: [IPsec] Question about ECDSA cert usage for IKEv2 auth
On Dec 22, 2011, at 9:07 PM, Gaurav Poothia wrote: Hello, The basic IKEv2 cert auth mechanism for RSA (from RFC 5996) seems to be to hash using SHA-1 before signing. However when using ECDSA certs for IKEv2 I am trying to make sure I am reading RFC 4754 correctly when it says the following: “Moreover, ECDSA cannot be specified for IKEv2 independently of an associated hash function since IKEv2 does not have a transform type for hash functions. For this reason, it is necessary to specify the hash function as part of the signature algorithm. Furthermore, the elliptic curve group must be specified since the choice of hash function depends on it as well. As a result, it is necessary to specify three signature algorithms, named ECDSA-256, ECDSA-384, and ECDSA-521. Each of these algorithms represents an instantiation of the ECDSA algorithm using a particular elliptic curve group and hash function. The three hash functions are specified in [SHS]. For reasons of consistency, this document defines the signatures for IKE in the same way. Digital Signature AlgorithmElliptic Curve GroupHash Function -------- ECDSA-256 256-bit random ECP groupSHA-256 ECDSA-384 384-bit random ECP groupSHA-384 ECDSA-521 521-bit random ECP groupSHA-512” Does this mean we proceed just like RSA here but hash with SHA-256 and not SHA-1 for ECDSA-256 cert and then proceed to sign as usual. Similarly use SHA-384 and SHA-512 for ECDSA-384 and ECDSA-521 respectively. Is that the correct reading of this excerpt? Hi Gaurav This is pretty much correct. With ECDSA you first hash with the specified hash function, and then sign the hash with the ECDSA group. Note how the numbers almost match up, so the size of the has is exactly the size of the buffer to be signed. This is different from RSA, where the hash is much shorter than the buffer to be signed. Even the longest hash anyone uses has only a 512-bit output, while 1024-bit signatures are considered too short these days, and 512-bit signatures are apparently grounds for blacklisting a CA. With RSA you use the RSASSA-PKCS1-v1_5 signature scheme, and that includes an identifier for the hash algorithm, so you can use any hash you want. Hope this helps Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[openssl.org #2663] Apparent bug in the x86 ghash function
Hi I've compiled a recent SNAP of OpenSSL 1.0.1 (from 18/12). I am pretty sure that the assembly language code generated for the ghash function (in ghash-x86.s) is incorrect. The gcm_init_4bit() function generates a 16-entry table of 128-bit values, to be used as a multiplication table. The first value is always zero, while the others usually aren't. The supposedly equivalent gcm_init_clmul() function does not touch indexes 2-16 of the table, and pushes two usually non-zero entries into the first two entries of the table. Notice how %edx holds a pointer to the Htable, while %eax holds a pointer to H. The final two lines of the function put a value in the first ((%edx)) and second (16(%edx)) positions of the table. Clearly, this is wrong. .globl gcm_init_clmul .type gcm_init_clmul,@function .align 16 gcm_init_clmul: .L_gcm_init_clmul_begin: movl4(%esp),%edx movl8(%esp),%eax call.L010pic .L010pic: popl%ecx leal.Lbswap-.L010pic(%ecx),%ecx movdqu (%eax),%xmm2 pshufd $78,%xmm2,%xmm2 pshufd $255,%xmm2,%xmm4 movdqa %xmm2,%xmm3 psllq $1,%xmm2 pxor%xmm5,%xmm5 psrlq $63,%xmm3 pcmpgtd %xmm4,%xmm5 pslldq $8,%xmm3 por %xmm3,%xmm2 pand16(%ecx),%xmm5 pxor%xmm5,%xmm2 movdqa %xmm2,%xmm0 movdqa %xmm0,%xmm1 pshufd $78,%xmm0,%xmm3 pshufd $78,%xmm2,%xmm4 pxor%xmm0,%xmm3 pxor%xmm2,%xmm4 .byte 102,15,58,68,194,0 .byte 102,15,58,68,202,17 .byte 102,15,58,68,220,0 xorps %xmm0,%xmm3 xorps %xmm1,%xmm3 movdqa %xmm3,%xmm4 psrldq $8,%xmm3 pslldq $8,%xmm4 pxor%xmm3,%xmm1 pxor%xmm4,%xmm0 movdqa %xmm0,%xmm3 psllq $1,%xmm0 pxor%xmm3,%xmm0 psllq $5,%xmm0 pxor%xmm3,%xmm0 psllq $57,%xmm0 movdqa %xmm0,%xmm4 pslldq $8,%xmm0 psrldq $8,%xmm4 pxor%xmm3,%xmm0 pxor%xmm4,%xmm1 movdqa %xmm0,%xmm4 psrlq $5,%xmm0 pxor%xmm4,%xmm0 psrlq $1,%xmm0 pxor%xmm4,%xmm0 pxor%xmm1,%xmm4 psrlq $1,%xmm0 pxor%xmm4,%xmm0 movdqu %xmm2,(%edx) movdqu %xmm0,16(%edx) ret .size gcm_init_clmul,.-.L_gcm_init_clmul_begin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [IPsec] Large Scale VPN
Hi all If we want Paul and Yaron to take this to our AD, we need to show that there are more people who think these work items are a good idea. More people than just me and MCR. So please show your support (or objections!) soon. An I think this is a good idea, I think we should use ternary logic, or +1 is all it takes. Yoav On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote: Agree. How about: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, etc. The IPsecME working group will handle this large scale VPN problem by delivering the following: * The working group will create a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. Should reach WG last call around October 2012. * The working group will review and help publish Informational documents describing current vendor proprietary solutions. These should be ready for IETF last call by August 2012. * The working group will choose a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Large Scale VPN
Hi all. The discussion has died down a bit, so I thought I'd chime in with proposed charter text. What do people think of the following? The first paragraph is taken from Steve's email of 18-Nov. Yoav In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand mesh IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, etc. The IPsecME working group will handle this large scale VPN problem by delivering the following: * The working group will create a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. Should reach WG last call around October 2012. * The working group will review and help publish Informational documents describing current vendor proprietary solutions. These should be ready for IETF last call by August 2012. * The working group will choose a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may consider multiple proposals, and then choose one to bring to the standards track. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Large Scale VPN
On Dec 8, 2011, at 6:04 PM, Paul Hoffman wrote: On Dec 8, 2011, at 1:55 AM, Yoav Nir wrote: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand mesh IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, etc. I don't think mesh is a well-defined term here. How about point-to-point? point to point sounds to me too much like the old host-to-host IPsec idea that never quite took off. I know this is part of Chris's use case, but I don't think that's our main focus. I can live with either point-to-point or mesh, but either way we'll have to define it in the first deliverable. The IPsecME working group will handle this large scale VPN problem by delivering the following: * The working group will create a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. Should reach WG last call around October 2012. * The working group will review and help publish Informational documents describing current vendor proprietary solutions. These should be ready for IETF last call by August 2012. * The working group will choose a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may consider multiple proposals, and then choose one to bring to the standards track. We would need a deadline for the last item. I suggest December 2013. Works for me. I was hesitant to suggest a date. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Large Scale VPN
On Dec 8, 2011, at 8:14 PM, Yaron Sheffer wrote: We as a group can commit to deliverable #1 and #3 (problem statement and standardized solution). But deliverable #2 (vendor protocols) is mostly out of our hands. That's why I used review and help rather than write or produce. So before we approve this charter, I would like to hear from people that represent vendors that they can commit to publish such a draft for their favorite solution. With a mostly complete -00 draft in, say, 4/2012. Please respond to the list or privately to Paul and myself. Also, I suggest to replace the sentence The working group may consider multiple proposals, and then choose one to bring to the standards track. by The working group may standardize one of the vendor solutions, a combination of several, or a new protocol. The latter is clearer, at least to me. Agree. How about: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, etc. The IPsecME working group will handle this large scale VPN problem by delivering the following: * The working group will create a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. Should reach WG last call around October 2012. * The working group will review and help publish Informational documents describing current vendor proprietary solutions. These should be ready for IETF last call by August 2012. * The working group will choose a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Preparing a charter change for P2P VPN
On Nov 21, 2011, at 10:09 PM, Stephen Hanna wrote: The conclusion of Wednesday night's P2P VPN side meeting was that we would start a new thread on the proposed ipsecme charter change and resolve the open questions by email. Let's start off with the text that came out of Wednesday's meeting and the questions raised there. The text from the meeting describing the problem to be solved was: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand mesh IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, etc. And the main open questions from the meeting were: * Should we create a problem statement and requirements draft? Yes, but I wouldn't mind if that PS/Requirements/Use-case document never got published. It's a means, not an end. * Should we create a Standards Track document with the solution or just document existing proprietary vendor solutions in Informational RFCs? Both. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKEv2 and ERP
On Aug 6, 2011, at 10:37 PM, Yoav Nir wrote: Hi At the meeting in Quebec, I gave a presentation at the hokey meeting about http://tools.ietf.org/html/draft-nir-ipsecme-erx . The draft covers using the EAP extensions for re-authentication in IKEv2. The obvious (to me) use-case is a phone connected to a 802.1x network. As you leave the building, the same phone automatically using IKEv2 over a 3G network without the user authenticating, by using the handed-over keys from 802.1x. ERP (RFC 5296) works in two cases: 1. when the new AAA backend and the old AAA backend are the same, and 2. when they are different - you connect to a local EAP server There is an open question here. Obviously, when you use EAP for 802.1x or PPP or some other network access, you often connect to a local Authenticator that is not the same as your home network. But is this relevant in IKEv2? IKEv2 is used over the Internet. Why would you ever want to connect to a server other than your home (or a server that relies on the same AAA backend) In other words: is there a use-case for connecting to a local rather than a home server in IKE, a use-case that uses EAP. My feeling is that the answer is no, and there were some phone operators in the room who agreed with me. Someone did bring up the case of host-to-host IPsec, but I don't think that ever uses EAP. Does anybody have different thoughts about this? (crickets) As there were no replies to this email, and as there was pretty much an uncalled consensus at the HOKEY meeting, I have submitted version -02 of the draft with an extra paragraph in section 3.2 to explain that roaming to a different EAP server scenario is probably not relevant. http://www.ietf.org/internet-drafts/draft-nir-ipsecme-erx-02 I would be happy for this to become a working group item, but if not, I would like to take it to our ADs (not sure which one, as this involves both IPsecME and HOKEY). I would also appreciate any suggestions for the Security Considerations section, other than just moving the rest of section 3.2 into it. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
On Nov 18, 2011, at 2:06 AM, Nico Williams wrote: On Wed, Nov 16, 2011 at 8:17 PM, Yoav Nir y...@checkpoint.com wrote: On Nov 17, 2011, at 9:31 AM, Paul Wouters wrote: But seriously, IPsec tunnels are based on RFC 4301 and there SPDs and PADs are static, so there is only one peer where a particular source IP might come from. Openswan supports MARKing the packet based on which SPI the packet came out of, ip_conntrack then follows its around and reply packets get the MARK as well, so we know which tunnel to send it to despite the overlapping IP address on the client end. We even provide a setsockopt() option so you MARK your socket before connecting to 192.168.1.1 and the kernel knows which SPI to send the packet to. And each IPsec policy can optin to allowing a range that would overlap. Yeah, we do something similar. We are a stateful firewall, so every packet is associated with a connection (well defined for TCP, SCTP; kind of bogus for UDP), and every connection is associated with a tunnel, so outbound packets get to use the correct SA (or at least one matching the SA that inbound packets came through). Oh, this is good news. It means you're both close to having RFC5660 implemented :) Yeah, except without those pesky APIs. :-) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] P2P-VPN - Side Meeting - Announcement
Posting again with a different subject so that this doesn't drown in the other back and forth. Please do not reply to this message. Hi. Steve has come up with a formulation for the subject for discussion tonight: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (single domain or multi-domain), customers want to get full mesh IPsec connectivity for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, etc. We aim to solve this problem in an interoperable manner using IPsec and IKE and other new or existing IETF standards. The draft does contain other use cases, which I will mention in my presentation, but the above use case will get most of the attention. Those of you wishing to download the presentation material: - Original format (1.3 MB) http://dl.dropbox.com/u/28687906/P2P-VPN.zip - Converted to PDF (56.3 MB) http://dl.dropbox.com/u/28687906/P2P-VPN-PDF.zip During the Plenary meeting (16:30-19:30 local time) I will be in the Jabber room most of the time, so if you remote participants want to test it, and say hi, go ahead. Otherwise see y'all at 20:00 in room 101D. Yoav On Nov 14, 2011, at 10:09 AM, Yoav Nir wrote: Hi all This is to announce a side meeting about peer to peer VPN, as described in our recently published draft: http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00 In the meeting we will discuss the use case of directly connecting two IKE implementations that already have a path of trust between them, for example turning star topologies into meshes. The introduction of strangers (AKA opportunistic encryption) is explicitly out of scope for this meeting. Where: TICC building, room 101-D When:Wednesday, 16-Nov, at 20:00 (8:00 PM) local time Jabber: xmpp:ipse...@jabber.ietf.org?join Streaming audio: http://ietf82streaming.dnsalias.net/ietf/ietf824.m3u Tentative Agenda: - A 20-minute presentation about the draft - 3-5 really short presentations about existing proprietary (or not) solutions - Open discussion on the problem (which will inevitably get into solutions) - Next Steps (this is when we ask the who will edit/contribute/review) Note: the streaming audio may or may not work. They don't switch off the audio after hours, but you won't get support from the NOC team either. If that fails, we'll try to make do with Skype ( http://portal.campaigncc.org/SkypeConferencing ), but that is at best a best-effort solution. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
OK. A dumber but more practical question: Do you have any idea how we can get microphones? The projector is indeed here, but the microphones seem to be missing. Keeping the audio stream running all night doesn't help if the mikes are gone... On Nov 16, 2011, at 7:13 PM, Stephen Hanna wrote: I think we will benefit greatly if we focus tonight's meeting mainly on discussion of and perhaps agreement on the PROBLEM TO BE SOLVED. Comparison and analysis of proposed solutions should wait until we have agreed on the problem statement and the requirements derived from that. And, as we've just seen, it's very hard to have a clear discussion of different alternative proposals without having those proposals described in detail as Internet-Drafts. The goal of the 7 minute presentations of solutions tonight (as I understand it) is simply to show that there are some interesting solutions out there, not to promote comparisons of them. I already regret the decision to include those solutions on the agenda since we've now spent lots of time insulting each others' approaches without actually understanding them. Please let's skip more shouting matches about solutions tonight. We don't have enough facts on the table. Instead, let's focus on discussing which problem we should be trying to solve. Thanks, Steve -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Frederic Detienne Sent: Wednesday, November 16, 2011 4:24 AM To: Yoav Nir Cc: ipsec@ietf.org WG; Tero Kivinen; Mike Sullenberger Subject: Re: [IPsec] P2P VPN - Side Meeting You are mixing everything up. It is too much work to correct you over email. I will try to help you at the meeting. regards, fred On 16 Nov 2011, at 15:35, Yoav Nir wrote: OK. Routing protocols are not security protocols. That's fine. Neither is HTTP. BGPSEC and SIDR implement a layer of security on top of BGP to overcome this issue, and that may be used in the Internet. OSPF and NHRP are designed to be used in closed environments (corporate networks), where everyone is assumed to be playing nice, so there has never been as much requirement for a security layer, and in fact there is no security layer to NHRP. When you extend NHRP to an overlay network over the Internet, as you do with GRE, you are still fine as long as everybody plays nice. With the obvious example of a corporate network with tunnels to the branches in New York, London, Paris, and Shang-hai you're still fine, because all the gateways are configured by the same person or organization, or at least they are part of the same hierarchy, although by this point you may need to be worried about misconfiguration. With a multiple-administrative-domain use case, all bets are off. What would prevent a gateway anywhere from claiming responsibility for the addresses of the facebook.com server? That would cause several bad things: - that gateway gets access to all facebook traffic in the entire overlay network - all the gateways have to work extra hard encrypting facebook content for no reason at all. This is a real problem regardless of whether we use IPsec tunnels or GRE tunnels. Neither IKE nor NHRP has a secure routing layer. Whichever solution we pick (as a working group) we will still need to develop a security layer, which may or may not be based on what the BGP people are doing. This is especially important for cross-domain use cases, but would be very helpful for same-domain as well. Yoav On Nov 16, 2011, at 3:11 PM, Frederic Detienne wrote: Security is a matter of architecture and end-to-end design. Several mechanisms are used to achieve an efficient balance with complexity. Features and security protocols are only building blocks. IPsec and IKE are not the only features that protect a network and routing as a security policy really is not a problem until shown otherwise. Again, I urge you to be specific because there is nothing tangible in your claims. I understand what you mean but if you rationalized it, you would see your intuition fools you. On 16 Nov 2011, at 14:17, Yoav Nir wrote: On Nov 16, 2011, at 1:45 PM, Tero Kivinen wrote: Yoav Nir writes: So you still didn't explain what GRE does better than modern IPsec tunneling? I think GRE (or any tunnel that is not IPsec - like L2TP) allows them to avoid having to deal with RFC 4301 stuff like SPD. The only selector they need is for the GRE tunnel (protocol 43?) or the L2TP tunnel (UDP 1701). I.e. bypass the security mechanishms provided the security protocol. Yes! That means that your security policy is effectively determined by the routing protocol. I.e. move the security from the security protocol to something else which is not a security protocol. Is this really something we want to do? Define we Who is going to make sure the end result is secure
Re: [IPsec] P2P VPN - Side Meeting
On Nov 17, 2011, at 2:17 AM, Michael Richardson wrote: Mike I am not sure where you are getting a set of extended Mike access-lists. There aren't any extended access-lists added. Mike If a packet is routed through the tunnel it is encapsulated Mike and then encrypted. There isn't any access-list necessary. Oh, I'm sorry, I thought you were creating a secure network! What you are saying is that you are creating an overlay network, where different sites can impersonate each other! Not necessarily. If your device drops packets that come through the wrong tunnel, you're safe. Typically in a complex network you will allow multiple paths through the overlay network, and then some spoofing can happen. Mike I have worked some with other vendor's IPsec when Mike troubleshooting interaction issues. I still believe that Mike IPsec at the base is not a good tunneling protocol. CISCO IOS IPsec is a poor tunneling protocol. Many other vendors do a better job. Ohhh (blush) But seriously, IPsec tunnels are based on RFC 4301 and there SPDs and PADs are static, so there is only one peer where a particular source IP might come from. That is good for security, but poor for traffic engineering. We would like to have more than one path through the overlay network, and that requires some kind of routing protocol. And yes, such a routing protocol needs to be secure and not degenerate into a free-for-all. Whether any vendor provides that now is a subject for (intense) debate. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
On Nov 17, 2011, at 9:31 AM, Paul Wouters wrote: On Thu, 17 Nov 2011, Yoav Nir wrote: Not necessarily. If your device drops packets that come through the wrong tunnel, you're safe. Typically in a complex network you will allow multiple paths through the overlay network, and then some spoofing can happen. So you want privacy, not security. IPsec is meant to deliver both. No, I want security, and this goes back to the administrative domain issue. If I have installed and configured all of the gateways in the overlay network, I could trust them enough to have the packets routed through any of them. With that assumption gone, I agree that your peer can spoof you. CISCO IOS IPsec is a poor tunneling protocol. Many other vendors do a better job. Ohhh (blush) Don't worry, we have interop issues with checkpoint too :) I'll buy dinner to the firs person showing me how to use the gui tools to build rfc1918/XX - 0/0 on tcp 443 tunnel. Heck, I'll buy dinner if you can do it with the cli command too. I think this can be accomplished by adding some table entries in user.def, and the support database has instructions on this, but I'll admin that it's obscure enough that I can't find that out from here. The UI is designed according to marketing requirements to answer what they believe customer needs are. I think that is true for all vendors. But seriously, IPsec tunnels are based on RFC 4301 and there SPDs and PADs are static, so there is only one peer where a particular source IP might come from. Openswan supports MARKing the packet based on which SPI the packet came out of, ip_conntrack then follows its around and reply packets get the MARK as well, so we know which tunnel to send it to despite the overlapping IP address on the client end. We even provide a setsockopt() option so you MARK your socket before connecting to 192.168.1.1 and the kernel knows which SPI to send the packet to. And each IPsec policy can optin to allowing a range that would overlap. Yeah, we do something similar. We are a stateful firewall, so every packet is associated with a connection (well defined for TCP, SCTP; kind of bogus for UDP), and every connection is associated with a tunnel, so outbound packets get to use the correct SA (or at least one matching the SA that inbound packets came through). That is good for security, but poor for traffic engineering. We would like to have more than one path through the overlay network, and that requires some kind of routing protocol. And yes, such a routing protocol needs to be secure and not degenerate into a free-for-all. Whether any vendor provides that now is a subject for (intense) debate. If you need that, just run GRE with BGP on your routers connected with simple static IPsec tunnels. Don't degrade the IPsec security within the tunnels. I think that is a narrow, IPsec-centric view. It says that IPsec is secure and does not support dynamic SPDs in order to be secure. If you need dynamic tunnels, then use GRE, and then it's BGP (or RIP or OSPF) problem. For network administrators (and thus vendors) it's their problem: they want both the security and the ability to get around failed links and nodes that routing provides for the Internet. I would be happy to have an IKE/IPsec-only solution. But I don't think there is one now. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: Plagued by PPTX again
On Nov 15, 2011, at 5:55 PM, Ray Bellis wrote: On 15 Nov 2011, at 16:26, Bob Hinden wrote: +1 The Datatracker does officially support PPTX, so I don't believe it's unreasonable to use it. If you don't like that policy, I'm not sure where you would take that up. It also hadn't occurred to me that people might actually prefer PPT over the more open PPTX format. It may be open, but there are fewer implementations. Yes, Open/Neo/LibreOffice supports it, but those presentations run much slower than equivalent PPT. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Plagued by PPTX again
On Nov 16, 2011, at 2:28 AM, Martin Rex wrote: todd glassey wrote: Marshall Eubanks wrote: Should the system reject PPTX files ? If people can't read them, why are we accepting them ? I would appreciate if that datatracker simply rejected PPTX on upload. It is several mangnitudes more efficient to have the uploaded simply select a different option on save rather than to bother dozens of consumers with having to spend hours and/or $$ to obtain a computing environment that is capable of visualizing PPTX. I agree in principle, but I have just converted a .pptx presentation (with some animations that will be lost) into PDF. The PPTX was 250K, the PDF is 2MB. 8 times as much. I know that bandwidth is cheap and all, but I really don't like the inefficiency. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IPsec] P2P VPN - Side Meeting
On Nov 15, 2011, at 12:12 PM, Frederic Detienne wrote: On 15 Nov 2011, at 12:05, Yoav Nir wrote: Hi Frederic Inline... On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote: Hi Yoav, We will be there (following offline with you for the details). I do not think there is a need to spend 20 minutes on the draft which everyone should have read. There are three vague points in it and 10 min seem largely sufficient. 20 minutes includes time spent on hellos, introductions, asking if everyone has read the draft, jabber scribe, testing the audio, and all other kinds of administrivia. You've been to IETF sessions before, and you know how that goes. absolutely. Then we agree on the 20 min. At this stage several vendors think they have a fair understanding of the requirements and a gap analysis is much more productive and constructive. I have just asked Chris Ulliott to provide his feedback in case audio fails on us. We can factor his reply in the discussions. To me the biggest gap in existing solutions is that they require kludges like GRE tunnels and route-based VPN, and also that they don't cover the provisioning of credentials. GRE tunnels and route-based VPNs I consider a kludge because you are then required to treat VPN tunnels as interfaces. Interfaces are much more resource intensive when compared to simple SAs, and most operating systems are very limited in the number of interfaces that they support. These are all very vague but generally misinformed statements. I'm sorry if they have offended you or your company. My point remains, that IPsec does define a mechanism for tunneling packets. It's called tunnel mode IPsec. That Cisco and perhaps other vendors choose to use other tunneling mechanisms such as GRE when they need some fancy features such as peer discovery or dynamic protected domain discovery, tells me that something is lacking in IPsec tunnels. That is what I meant by kludge. It may be that the problem with IPsec tunnels is not in the tunnels themselves, but that there are no configuration protocols associated with them, such as the routing protocols or such as NHRP that can be used with GRE tunnels. I will take your word that using GRE+NHRP can scale as far as anyone would like. However, in evaluating solutions, we should not automatically go with the analogy that IPsec VPNs are like overlay networks on top of the Internet, and that tunnels are analogous to links. GRE is an overhead that is added to every packet. NHRP is yet another protocol that needs to be implemented and carried over the IPsec SA. All that should be compared with cost and complexity of potential extensions to IKE and IPsec that would carry the same information. We will have plenty of opportunity to discuss these things at the meeting on Wednesday, but just to make things clear, I am not advocating any solution, and I have no unsubmitted draft with some extension to IKE. The purpose of the meeting is to review the use cases and the solutions that currently exist. If anyone intends to pull out a new never-before-published solution that's fine as well, but I have no such intentions. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
Hi Mike On Nov 15, 2011, at 6:25 PM, Mike Sullenberger wrote: Hi Yoav, Please see inline. Mike. On Nov 15, 2011, at 12:12 PM, Frederic Detienne wrote: On 15 Nov 2011, at 12:05, Yoav Nir wrote: Hi Frederic Inline... On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote: Hi Yoav, We will be there (following offline with you for the details). I do not think there is a need to spend 20 minutes on the draft which everyone should have read. There are three vague points in it and 10 min seem largely sufficient. 20 minutes includes time spent on hellos, introductions, asking if everyone has read the draft, jabber scribe, testing the audio, and all other kinds of administrivia. You've been to IETF sessions before, and you know how that goes. absolutely. Then we agree on the 20 min. At this stage several vendors think they have a fair understanding of the requirements and a gap analysis is much more productive and constructive. I have just asked Chris Ulliott to provide his feedback in case audio fails on us. We can factor his reply in the discussions. To me the biggest gap in existing solutions is that they require kludges like GRE tunnels and route-based VPN, and also that they don't cover the provisioning of credentials. GRE tunnels and route-based VPNs I consider a kludge because you are then required to treat VPN tunnels as interfaces. Interfaces are much more resource intensive when compared to simple SAs, and most operating systems are very limited in the number of interfaces that they support. These are all very vague but generally misinformed statements. I'm sorry if they have offended you or your company. My point remains, that IPsec does define a mechanism for tunneling packets. It's called tunnel mode IPsec. That Cisco and perhaps other vendors choose to use other tunneling mechanisms such as GRE when they need some fancy features such as peer discovery or dynamic protected domain discovery, tells me that something is lacking in IPsec tunnels. That is what I meant by kludge. It may be that the problem with IPsec tunnels is not in the tunnels themselves, but that there are no configuration protocols associated with them, such as the routing protocols or such as NHRP that can be used with GRE tunnels. I will take your word that using GRE+NHRP can scale as far as anyone would like. However, in evaluating solutions, we should not automatically go with the analogy that IPsec VPNs are like overlay networks on top of the Internet, and that tunnels are analogous to links. GRE is an overhead that is added to every packet. NHRP is yet another protocol that needs to be implemented and carried over the IPsec SA. All that should be compared with cost and complexity of potential extensions to IKE and IPsec that would carry the same information. We use other tunnel mechanisms (GRE), because IPsec tunneling mode is lacking in functionality. For example, when you use GRE for the tunneling you also reduce the IPsec SA's that are needed to describe the traffic for IPsec to encrypt. If you use IPsec tunnel mode only then for each pairing of subnets behind each peer you need a separate IPsec SA. For example if there are 5 subnets each behind two peers then you need up to 25 SA pairs to describe exactly what needs to be encrypted and nothing more. If you tunnel the data traffic first then you only need 1 SA pair for all traffic, since IPsec encrypts the tunnel itself and not the traffic within the tunnel. This was correct in IKEv1, but in IKEv2 you can have a bunch of ranges for each traffic selector. Regardless, it has long been a (undocumented) practice, by more than one vendor, to negotiate universal tunnels, so that a single IPsec SA can be used for all the traffic between two peers. What you call other fancy features is what I call functional separation. IPsec does encryption well, but in reality it does a fairly poor job of tunneling. So lets have IPsec do what it does well and have GRE do what it does well and that is tunneling. Then you add NHRP do to next-hop resolution, which is what it was specifically designed to do, so that you can dynamically find peers and dynamically build new GRE tunnels protected by IPsec. Note, NHRP runs through the GRE tunnel so the single IPsec SA, since it encrypts the tunnel, also protects NHRP. Finally you add a routing protocol to advertise the reachablity of subnets/networks through the tunnel. Again this all goes through tunnel so the single IPsec SA protects this traffic as well. Basically you now have a system where you are using the proper tool to do the job that it was designed to do and that it does best. If you were to to try to overload these functions back into IPsec/IKE then you would end up with a less efficient system. I agree that this is a solution, but I don't agree that this is necessarily the best solution. I'm also missing
Re: [IPsec] P2P VPN - Side Meeting UNCLASSIFIED
On Nov 15, 2011, at 7:36 PM, Ulliott, Chris wrote: Classification:UNCLASSIFIED The problem with a single SA is that it usually means a single key (what ever form that takes) such that a compromise of a single spoke puts all traffic at risk... So what ever solution we go for - we need to keep one eye on the security requirements... Chris Hi Chris I don't mean a single SA for the whole configuration. I mean a single SA for every pair of gateways, rather than lots of SAs, one for each pair of subnets. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
On Nov 15, 2011, at 10:52 PM, Michael Richardson wrote: Mark == Mark Boltz mark.bo...@stonesoft.com writes: Mark With all due respect to Cisco, the larger problem we're trying Mark to address, is in part the fact that DMVPN and ACVPN are Mark vendor specific implementations. And the goal of the Mark implementation we're seeking is *large scale* P2P VPNs. Assume that they are available on a wide variety of platforms, what is broken in the technology? I don't know, but I've been told that ACVPN and DMVPN both rely on NHRP and GRE tunnels. I have also heard (and please someone correct me if I'm wrong) that they don't interoperate. So the tools are apparently not enough. Mark Picture a hypothetical where a larger interest desires an Mark IPsec VPN, in, say the airline industry. We're talking about Mark several thousand aircraft from several manufacturers. All in We've been through all of this 15 years ago with AIAG's ANX. You really want to tout that experience as a success story? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] P2P VPN - Side Meeting
OK. Routing protocols are not security protocols. That's fine. Neither is HTTP. BGPSEC and SIDR implement a layer of security on top of BGP to overcome this issue, and that may be used in the Internet. OSPF and NHRP are designed to be used in closed environments (corporate networks), where everyone is assumed to be playing nice, so there has never been as much requirement for a security layer, and in fact there is no security layer to NHRP. When you extend NHRP to an overlay network over the Internet, as you do with GRE, you are still fine as long as everybody plays nice. With the obvious example of a corporate network with tunnels to the branches in New York, London, Paris, and Shang-hai you're still fine, because all the gateways are configured by the same person or organization, or at least they are part of the same hierarchy, although by this point you may need to be worried about misconfiguration. With a multiple-administrative-domain use case, all bets are off. What would prevent a gateway anywhere from claiming responsibility for the addresses of the facebook.com server? That would cause several bad things: - that gateway gets access to all facebook traffic in the entire overlay network - all the gateways have to work extra hard encrypting facebook content for no reason at all. This is a real problem regardless of whether we use IPsec tunnels or GRE tunnels. Neither IKE nor NHRP has a secure routing layer. Whichever solution we pick (as a working group) we will still need to develop a security layer, which may or may not be based on what the BGP people are doing. This is especially important for cross-domain use cases, but would be very helpful for same-domain as well. Yoav On Nov 16, 2011, at 3:11 PM, Frederic Detienne wrote: Security is a matter of architecture and end-to-end design. Several mechanisms are used to achieve an efficient balance with complexity. Features and security protocols are only building blocks. IPsec and IKE are not the only features that protect a network and routing as a security policy really is not a problem until shown otherwise. Again, I urge you to be specific because there is nothing tangible in your claims. I understand what you mean but if you rationalized it, you would see your intuition fools you. On 16 Nov 2011, at 14:17, Yoav Nir wrote: On Nov 16, 2011, at 1:45 PM, Tero Kivinen wrote: Yoav Nir writes: So you still didn't explain what GRE does better than modern IPsec tunneling? I think GRE (or any tunnel that is not IPsec - like L2TP) allows them to avoid having to deal with RFC 4301 stuff like SPD. The only selector they need is for the GRE tunnel (protocol 43?) or the L2TP tunnel (UDP 1701). I.e. bypass the security mechanishms provided the security protocol. Yes! That means that your security policy is effectively determined by the routing protocol. I.e. move the security from the security protocol to something else which is not a security protocol. Is this really something we want to do? Define we Who is going to make sure the end result is secure? The customer Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
