Re: DNSSEC is NOT secure end to end
Christian Huitema wrote: That is, security of DNSSEC involves third parties and is not end to end. That is indeed correct. An attacker can build a fake hierarchy of secure DNS assertions and try to get it accepted. The attack can succeed with the complicity of one of the authorities in the hierarchy. It is a classic attack by a trusted party. Yes, the hierarchy has hops. For my domain: necom830.hpcl.titech.ac.jp, hierarechy of zones have hops of ., jp, ac.jp, titech.ac.jp and hpcl.titech.ac.jp. The authority hops are IANA, JPNIC, my university, and my lab. Though you may have direct relationship with IANA, JPNIC is the third party for both you and me. If an intermediate authority has been compromised, it can just as well insert a fake NS record -- that's not harder than a fake record signature. So, with a compromised hop of an intermediate authority, record signature on the faked next hop key can be generated. Then, with a private key corresponding to the faked next hop key, record signature on the faked second next hop key can be generated. Then, with a private key corresponding to the faked second next hop key, record signature on the faked third next hop key can be generated. Yes, security of DNSSEC is totally hop by hop. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
On 1 jun 2009, at 16:56, Jari Arkko wrote: I do think though that additional information at the level of This RFC describes FOO. A standardized version of FOO can be found from RFC . is useful. I think -07 version of the 3932bis is an improvement over the previous one, and should be approved. The proposed text would allow for these sort of suggestions to be made to the Independent Series Editor (ISE, the approval body for the Independent Submissions Stream). IMHO these relational notes would be useful additions to Independent stream documents. Maybe not even as an IESG Note but as language in the abstract and/or introduction. However, the proposed language would also allow standard templates to be added. That would IMHO be wrong. I understand that for many people the distinction between the various streams is not always clear and that a large number of folk think that the RFC series is synonymous with Internet Standard documents, but I do not think that the IESG Note is the magic bullet to solve that. In any case: RFC4846 section 5 uses the word recommend If the IESG, after completing its review, identifies issues, it may recommend explanatory or qualifying text for the RFC Editor to include in the document if it is published. That wording is chosen in such a way that the decision is with the RFC Editor, more specifically the ISE. I would try to bring 3932bis in line with that: OLD: The IESG may choose to add an IESG note to an Independent Submission or IRTF Stream document that explains the specific relationship, if any, to IETF work. NEW: The IESG may recommend [to the RFC Editor] to add an IESG note . The text in section 3 uses request which IMHO is in line with the spirit of 4846. And makes clear that the ISE could in fact push back on the recommendation or request. --Olaf PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Masataka Ohta wrote: Christian Huitema wrote: That is, security of DNSSEC involves third parties and is not end to end. That is indeed correct. An attacker can build a fake hierarchy of secure DNS assertions and try to get it accepted. The attack can succeed with the complicity of one of the authorities in the hierarchy. It is a classic attack by a trusted party. Yes, the hierarchy has hops. For my domain: necom830.hpcl.titech.ac.jp, hierarechy of zones have hops of ., jp, ac.jp, titech.ac.jp and hpcl.titech.ac.jp. The authority hops are IANA, JPNIC, my university, and my lab. Though you may have direct relationship with IANA, JPNIC is the third party for both you and me. This is exactly like a chain of PKI CA's (replacing the path from bottom to top of zone hierarchy): For my [end-user administrative units], [chain of CA's] have hops of [CA run by IANA], [CA run by JPNIC], [CA run by my university], and [CA run by my lab]. I don't know what is meant by a direct relationship with IANA. If an intermediate authority has been compromised, it can just as well insert a fake NS record -- that's not harder than a fake record signature. So, with a compromised hop of an intermediate authority, record signature on the faked next hop key can be generated. Exactly the same with a compromised intermediate CA. Then, with a private key corresponding to the faked next hop key, record signature on the faked second next hop key can be generated. Exactly the same with a private key corresponding to the next intermediate CA along the chain (i.e. the one certified by the compromised CA). Then, with a private key corresponding to the faked second next hop key, record signature on the faked third next hop key can be generated. Same thing. Yes, security of DNSSEC is totally hop by hop. Thus, you imply a definition of hop by hop along digital signature relationships. Indeed, DNSSEC security is limited to the weakest link along the chain from the bottom to the top of the DNS hierarchy. Nothing new there. I don't think any DNSSEC expert ever claimed differently. Regards, - Thierry Moreau Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
This debate has nothing to do with the security properties of DNSSEC. A basic assumption of the DNS is that what the authoritative server for zone says is, well, authoritative. The structure of DNS itself entitles JPNIC to point ac.jp wherever they want; by using a name within the .jp domain, you are agreeing to act within JPNIC's domain of control. JPNIC could set up an authoritative server for hpcl.titech.ac.jp completely independently of you, regardless of DNSSEC, and from the perspective of the DNS, that would be the right answer. All DNSSEC does is make the assertions made in the DNS reliable -- it does nothing to change the locus of control. On the other hand, you can certainly use the DNSSEC protocol elements to do peer-to-peer security, just like you can use private DNS servers, and just like you can use TLS without trust anchors (i.e., with self-signed certs). Just hand out the public half of your ZSK to people you want to be able to verify names within your zone. --Richard Masataka Ohta wrote: Christian Huitema wrote: That is, security of DNSSEC involves third parties and is not end to end. That is indeed correct. An attacker can build a fake hierarchy of secure DNS assertions and try to get it accepted. The attack can succeed with the complicity of one of the authorities in the hierarchy. It is a classic attack by a trusted party. Yes, the hierarchy has hops. For my domain: necom830.hpcl.titech.ac.jp, hierarechy of zones have hops of ., jp, ac.jp, titech.ac.jp and hpcl.titech.ac.jp. The authority hops are IANA, JPNIC, my university, and my lab. Though you may have direct relationship with IANA, JPNIC is the third party for both you and me. If an intermediate authority has been compromised, it can just as well insert a fake NS record -- that's not harder than a fake record signature. So, with a compromised hop of an intermediate authority, record signature on the faked next hop key can be generated. Then, with a private key corresponding to the faked next hop key, record signature on the faked second next hop key can be generated. Then, with a private key corresponding to the faked second next hop key, record signature on the faked third next hop key can be generated. Yes, security of DNSSEC is totally hop by hop. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Richard Barnes wrote: This debate has nothing to do with the security properties of DNSSEC. A basic assumption of the DNS is that what the authoritative server for zone says is, well, authoritative. The structure of DNS itself entitles JPNIC to point ac.jp wherever they want; by using a name within the .jp domain, you are agreeing to act within JPNIC's domain of control. JPNIC could set up an authoritative server for hpcl.titech.ac.jp completely independently of you, regardless of DNSSEC, and from the perspective of the DNS, that would be the right answer. I guess what Masataka was referring to is a different source of variance, i.e. an impersonation of JPNIC's authority over its domain of control (using a compromised JPNIC's private key). All DNSSEC does is make the assertions made in the DNS reliable -- it does nothing to change the locus of control. Reliable through a chain fo digital signatures. Reliable to the extent an impersonation attack (on the locus of control) does not occur based on a compromised private signature key. On the other hand, you can certainly use the DNSSEC protocol elements to do peer-to-peer security, just like you can use private DNS servers, and just like you can use TLS without trust anchors (i.e., with self-signed certs). Just hand out the public half of your ZSK to people you want to be able to verify names within your zone. Then you reduce the chain of digital signatures to a single one, raising confidence level at the cost of more key management hindrance. Indeed, this thread seems to be another attempt to understand the basic DNSSEC properties. - Thierry --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
unsubscribe
unsubscribe skar...@verisign.com smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Unicode Announcement] New Public Review Issue #147: Proposed Deprecation of U+0673 ARABIC LETTER ALEF WITH WAVY HAMZA BELOW
Looking at character frequencies in web documents, the frequency of U+0673 cannot be separated from noise. Haven't yet looked at URLs. Mark 2009/6/1 Shawn Steele shawn.ste...@microsoft.com I'm curious how this impacts IDNA2003 compatibility and particularly the proposed IDNA2008 mappings. I suppose it is unlikely that this character is currently registered in a real URL? -Shawn -Original Message- From: idna-update-boun...@alvestrand.no [mailto: idna-update-boun...@alvestrand.no] On Behalf Of Patrik Fältström Sent: Saturday, May 30, 2009 1:56 AM To: IETF Discussion; IDNA update work Subject: Fwd: [Unicode Announcement] New Public Review Issue #147: Proposed Deprecation of U+0673 ARABIC LETTER ALEF WITH WAVY HAMZA BELOW As the liaison from IETF to the Unicode Consortium, I would like to make the IETF community aware of the following opening for public comments. The character U+0673 ARABIC LETTER ALEF WITH WAVY HAMZA BELOW that the review is related to has today the derived property value PVALID in the current proposal discussed in the IDNABIS working group. Because of this, I encourage interested parties to respond to the questions stated below. I am confident IETF and Unicode Consortium will be able to synchronize the two standards so that there is no incompatibility issues. Patrik Fältström Begin forwarded message: From: announceme...@unicode.org Date: fr 29 maj 2009 00.25.49 GMT+02:00 To: announceme...@unicode.org Subject: [Unicode Announcement] New Public Review Issue #147: Proposed Deprecation of U+0673 ARABIC LETTER ALEF WITH WAVY HAMZA BELOW Reply-To: r...@unicode.org The Unicode Technical Committee has posted a new issue for public review and comment. Details are on the following web page: http://www.unicode.org/review/ Review periods for the new item closes on August 3, 2009. Please see the page for links to discussion and relevant documents. Briefly, the new issue is: PRI #147: Proposed Deprecation of U+0673 ARABIC LETTER ALEF WITH WAVY HAMZA BELOW The UTC has recently approved a proposal to encode an ARABIC WAVY HAMZA BELOW for a future version of the Unicode Standard. That character is used productively in Kashmiri and other languages, and is applied to letters other than ALEF. The intent is to deprecate the existing character U+0673 ARABIC LETTER ALEF WITH WAVY HAMZA BELOW, in favor of the sequence of an ALEF plus the new ARABIC WAVY HAMZA BELOW. (Because of normalization stability constraints, a canonical equivalence relation cannot be established.) The UTC is seeking feedback on whether U+0673 should be deprecated when ARABIC WAVY HAMZA BELOW is encoded. Pertinent information would include data on how widespread usage of this character is. Note that deprecation of a character does not mean removal of that character from the standard; it merely constitutes a strong recommendation not to use the character. If you have comments for official UTC consideration, please post them by submitting your comments through our feedback reporting page: http://www.unicode.org/reporting.html If you wish to discuss issues on the Unicode mail list, then please use the following link to subscribe (if necessary). Please be aware that discussion comments on the Unicode mail list are not automatically recorded as input to the UTC. You must use the reporting link above to generate comments for UTC consideration. http://www.unicode.org/consortium/distlist.html All of the Unicode Consortium lists are strictly opt-in lists for members or interested users of our standards. We make every effort to remove users who do not wish to receive e-mail from us. To see why you are getting this mail and how to remove yourself from our lists if you want, please see http://www.unicode.org/consortium/distlist.html#announcements ___ Idna-update mailing list idna-upd...@alvestrand.no http://www.alvestrand.no/mailman/listinfo/idna-update ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Richard Barnes wrote: (That is: You already trust the zones above you to maintain the integrity of the zone on the *server*; This assumption does not stand universally. For some DNS users/usage, DNSSEC signature verification will be a must. The discussion implicitly referred to such uses. Then, it is legitimate to appraise the overall confidence in the DNSSEC chain of signatures, and to pinpoint the weakest link (e.g. the zone manager having the greatest likelihood of lousy private key protection in place). Indeed, DNS+DNSSEC is no different from plain DNS for those who are satisfied with the plain DNS. For those awaiting DNS+DNSSEC for some uses, it is useful to understand DNSSEC chains of digital signatures. Accesssorily, the zones above you means nothing to a relying party that is not validating its own domain. Regards, -- - Thierry Moreau ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
On Tue, 2 Jun 2009, Masataka Ohta wrote: For my domain: necom830.hpcl.titech.ac.jp, hierarechy of zones have hops of ., jp, ac.jp, titech.ac.jp and hpcl.titech.ac.jp. The authority hops are IANA, JPNIC, my university, and my lab. Though you may have direct relationship with IANA, JPNIC is the third party for both you and me. Yes, security of DNSSEC is totally hop by hop. Just as DNS was designed to work. hierarchical. If you want to add additional protection because you don't trust your parents, no one stops you from using a DNSSEC capable resolver that has DNSSEC zones configured directly, without relying on the parent. I can't preload 50 million keys. I cannot build trust relations with 50 millions domains. Just like we could not preload 50 million nameserver pointers. Hierarchy is the strength of DNS, not its weakness. DNSSEC allows you to specifically bypass the hierarchy for whatever zone you want. The only real question is, how does Masataka Ohta scale? My suspicion is that you don't scale to 50M domains, and that you will be forced to outsource some of that trust. DNSSEC does the outsourcing of trust distributed to the same people who are already responsible for the data you're about to trust. And note that even if you scale to 50M domains, I don't, so don't expect me to setup a trust relationship with you specifically. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-ietf-ippm-more-twamp-02.txt
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This draft does two things in connection with the Two-Way Active Measurement Protocol (TWAMP) a protocol which builds on the One-Way Active Measurement Protocol (OWAMP): (1) Add an extension whereby the TWAMP-Test protocol can be done in an unauthenticated mode while TWAMP-Control is authenticated and encrypted, where previously they had been required to have the same security mode. TWAMP-Control is used to initiate, start, and stop, etc. test sessions, while TWAMP-Test is used to exchange test packets. (2) The draft establishes an IANA registration called TWAMP-Modes for adding features. Establishing the IANA registry as such is not security relevant. This draft has a brief Security Considerations section. It incorporates by reference the lengthy Security Considerations in RFC 4656, which specified OWAMP, and from RFC 5357, which specifies TWAMP and adds considerations for one DoS attack which overlooked in RFC 4656. Generally, this incorporation by reference is adequate. However, the draft Security Considerations sections has one additional sentence which includes the words thus making it possible to increase overall security when compared to the previous options. That would only be true if the additional burden, under previous options where both control and test had the same security mode, of securing both TWAMP-Control and TWAMP-Test was prohibitive, forcing less security for TWAMP-Control and where having TWAMP-Test unauthenticated is not a problem with respect to the security threats in the particular instance. I believe the Security Considerations section should be re-worded to either drop the claim of increase overall security or at least make it clear that the claim only applies under resource constraints that would, under previous modes, have forced less security for TWAMP-Control and where unauthenticated TWAMP-Test is not a significant security concern. Thanks, Donald = Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Thierry Moreau wrote: That is, security of DNSSEC involves third parties and is not end to end. This is exactly like a chain of PKI CA's (replacing the path from bottom to top of zone hierarchy): Exactly the same with a compromised intermediate CA. Exactly the same with a private key corresponding to the next intermediate CA along the chain (i.e. the one certified by the The paper of David Clark says PKI is not secure end to end. Some tried to argue against by saying DNSSEC is so special that it is secure end to end. But, as you can observe, DNSSEC is no special and not secure end to end. I don't think any DNSSEC expert ever claimed differently. I am the DNSSEC expert and see some people having a lot less expertise than me says DNSSEC secure end to end. They are incorrect or using different terminology on end to end not acceptable to the Internet community. Masataka Ohtqa ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Thierry Moreau wrote: (That is: You already trust the zones above you to maintain the integrity of the zone on the *server*; This assumption does not stand universally. For some DNS users/usage, DNSSEC signature verification will be a must. The discussion implicitly referred to such uses. A problem of blindly believing a zone administration is that it is only as secure as blindly believing an ISP administration. Attacking a router of a large ISPs is as easy/difficult as attacking a signature generation mechanism of a large zone. Moreover, administration of LAN of a local organization (my universty, for example) is as secure as administration of a zone local to the organization. You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Paul Wouters wrote: I can't preload 50 million keys. I cannot build trust relations with 50 millions domains. Just like we could not preload 50 million nameserver pointers. That is the essential point of the paper of David Clark: These certificates are principal components of essentially all public key schemes, except those that are so small in scale that the users can communicate their public keys to each other one to one, in an ad hoc way that is mutually trustworthy. A credit card brand (VISA, for example) may manage more than 50 million PIN numbers. But, it uses agents to do so. The security of the system depends on not only (cryptographical) security between the brand holder and agents but also social security of the agents. Though 4 digit PIN or 16 bit message ID of DNS is cryptographically not very secure, it is a cryptographical issue of each hop, having nothing to do with social security between hops, introduction of which is inevitable for large infrastructures. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
On Wed, 3 Jun 2009, Masataka Ohta wrote: You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. You have never heard of a Hardware Security Module? Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
In message 4a25b8ef.70...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes: Thierry Moreau wrote: (That is: You already trust the zones above you to maintain the integrity of the zone on the *server*; This assumption does not stand universally. For some DNS users/usage, DNSSEC signature verification will be a must. The discussion implicitly referred to such uses. A problem of blindly believing a zone administration is that it is only as secure as blindly believing an ISP administration. Attacking a router of a large ISPs is as easy/difficult as attacking a signature generation mechanism of a large zone. The difference is we *have* to trust the zone administration. There is no scalable way to avoid that trust issue. We don't have to trust the router adminstration or caching server administration or authoritative server adminstration. Moreover, administration of LAN of a local organization (my universty, for example) is as secure as administration of a zone local to the organizati on. I've been on plenty of LAN's which I would treat as hostile. You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. Which is not a arguement for not doing DNSSEC. Knowing where the risks are is how you do risk management. If you arn't willing to accept some risks then don't connect to the net. Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
In message alpine.lfd.1.10.0906022034140.22...@newtla.xelerance.com, Paul Wou ters writes: On Wed, 3 Jun 2009, Masataka Ohta wrote: You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. You have never heard of a Hardware Security Module? HSM doesn't stop the wrong data being signed. It just stops it being signed on machines other that the designated servers. Mark Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
On Wed, 3 Jun 2009, Mark Andrews wrote: You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. You have never heard of a Hardware Security Module? HSM doesn't stop the wrong data being signed. It just stops it being signed on machines other that the designated servers. The context was the false security of DNSSEC and the third party trust. Obviously changing the raw dns data is possible both with and without DNSSEC. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
In message alpine.lfd.1.10.0906022057560.22...@newtla.xelerance.com, Paul Wou ters writes: On Wed, 3 Jun 2009, Mark Andrews wrote: You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. You have never heard of a Hardware Security Module? HSM doesn't stop the wrong data being signed. It just stops it being signed on machines other that the designated servers. The context was the false security of DNSSEC and the third party trust. Obviously changing the raw dns data is possible both with and without DNSSEC. Paul If you are bribing personel you need to assume they can do anything the orginisation they work for can do. HSM's don't help in this case. HSM's have their place but you need to understand the limitations of the devices. HSM's are better than just having the private component of a public key sitting on a disk somewhere but in most operational enviornments they don't add that much more security to the process. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
At 09:09 PM 6/2/2009, Mark Andrews wrote: HSM's are better than just having the private component of a public key sitting on a disk somewhere but in most operational enviornments they don't add that much more security to the process. It depends on the HSM. For example, there are HSMs that allow you to program just about any policy you want - including the requirement to have at least N people agree that something needs to be signed. The size of N is chosen to balance need for accountability with that of usefulness. I.e. requiring 20 people to turn the keys to get something signed is probably not useful. Permitting 1 person to sign without further oversight is probably not enough accountability. So saying they don't add much more security is really a statement that might be correct under really bad management practices, but mostly isn't. For example, even a simple version of keeping the set of HSM PIN holders distinct from set of people allowed to physically access the HSM for signing provides a substantial amount of operational security. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Document Action: 'Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets' to Experimental RFC
The IESG has approved the following document: - 'Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets ' draft-ietf-tcpm-ecnsyn-10.txt as an Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-10.txt Technical Summary This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document specifies the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN-marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmit timer). This document updates RFC 3168 Working Group Summary The WG process on this document was fairly smooth. The most interesting bump in the road was that after successfully completing the first WG last call, the authors obtained additional simulation results that warranted changes in the document and a 2nd WG last call. Document Quality There are existing implementations. There is (at least) a Linux implementation in addition to the simulation code. No vendors have formally indicated plans to the WG to implement the modifications in the document, but it is a backwards compatible end-host modification, not a full new protocol or one requiring additional infrastructure support. Personnel Wesley Eddy (we...@grc.nasa.gov) was the document shepherd. Lars Eggert (lars.egg...@nokia.com) reviewed the document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal' to Proposed Standard
The IESG has approved the following document: - 'DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal ' draft-ietf-dccp-simul-open-08.txt as a Proposed Standard This document is the product of the Datagram Congestion Control Protocol Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dccp-simul-open-08.txt Technical Summary This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g. a DCCP server behind a firewall, or a Network Address Port Translator), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. Working Group Summary A copy of the last-call note was also sent to the BEHAVE WG list. Document Quality Compliance of implementations with the final spec. has not been verified. No interops were performed. Personnel Lars Eggert reviewed this document for the IESG. RFC Editor Note In section 2.2.2, OLD: transitions to the LISTEN' NEW transitions to the LISTEN1 In Caption to Figure 3, OLD: Updated DCCP pseudocode for INVITED and LISTEN' states NEW Updated DCCP pseudocode for INVITED and LISTEN1 states ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-l2tpext-circuit-status-extensions (L2TPv3 Extended Circuit Status Values) to Proposed Standard
The IESG has received a request from the Layer Two Tunneling Protocol Extensions WG (l2tpext) to consider the following document: - 'L2TPv3 Extended Circuit Status Values ' draft-ietf-l2tpext-circuit-status-extensions-04.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-06-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-circuit-status-extensions-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17747rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pwe3-ms-pw-arch (An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge) to Informational RFC
The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge ' draft-ietf-pwe3-ms-pw-arch-06.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-06-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-arch-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14143rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pce-inter-layer-frwk (Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering) to Informational RFC
The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering ' draft-ietf-pce-inter-layer-frwk-10.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-06-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-frwk-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14628rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-ospf-dynamic-hostname (Dynamic Hostname Exchange Mechanism for OSPF) to Proposed Standard
The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Dynamic Hostname Exchange Mechanism for OSPF ' draft-ietf-ospf-dynamic-hostname-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-06-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dynamic-hostname-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17203rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
