Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
I am pleased to go with: The IESG has concluded that publication could potentially disrupt the IETF work done in WG X and recommends not publishing the document at this time. I'm OK with this as well. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
Thank you for your review. Can you point me to any standards track IETF documents which might need normative reference to this document? One example: draft-lee-sip-dns-sd-uri-03 Henning ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: more bad ideas, was uncooperative DNSBLs, was several messages
John Levine wrote: For instance, what would happen if mail servers provided feedback to both senders (on a per message basis in the form of NDNs) Well, since 95% of all mail is spam, and all the spam has fake return addresses, you'd increase the amount of bogus NDNs by more than an order of magnitude. No thanks. I should clarify. The way to notify the sender is for the check to be done at SMTP time, and for the rejecting SMTP server to issue a 5xx SMTP response to RCPT for that recipient. This should result in an NDN to be sent to the sender for legitimate mail. It will result in an NDN for spam only when the spam is submitted through somebody's MTA before being sent to the MX for the recipient. Incidentally, on a bad day I already get 400,000 NDNs from mail that I didn't send, just from the minority of MTAs that send NDNs in response to spam now. This is not a hypothetical problem. Agreed, it's a very real - and huge - problem. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IANA Office Hours at IETF-73 in Minneapolis
Greetings! The IANA will be holding Office Hours at the IETF-73 in Minneapolis. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. The IANA will have a table near the IETF registration area, staffed during the following hours: Monday - Wednesday, 0900 - 1600 Thank you and see you soon! Michelle Cotton Manager, IETF Relations Internet Assigned Numbers Authority ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
In message [EMAIL PROTECTED], Florian Weimer writes: * Stephane Bortzmeyer: Second question, the document indeed standardizes many things which are not in common use but does not point towards a rationale, so some choices are puzzling. Why TXT records to point to an URL and not NAPTR? Is this because of current usage in DNSxL? If so, this should be noted. But why IPv6 lists use a A record and not a ? I am not aware of existing IPv6 lists so this cannot be the current usage? The lack of a macro capability also means that it's basically impossible to secure DNSBL zones with DNSSEC when they contain larger chunks of address space; see the example in section 2.1. How so? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Names of People Encoded On RFID Cards
Names of people attending SIP / SIPPING who requested before noon Saturday were encoded in NYC and handed to Omer Boyaci [EMAIL PROTECTED]. The names are located here : http://groups.google.com/group/ietfrfid/files You dont need to login but if its inconvenient email me to request status of your request. Omer has five blank cards left with him. You can contact Omer directly at (646) 842 2342 . Since our team will depart by Friday noon I doubt the system will be available for Friday. -- Shiraz 500 Riverside Drive #425 New York, NY 10027 (703) 879-8342 (skype prefer) (703) 862 4796 (cell) (212) 316 8630 (landline) (extn 8630) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
* Mark Andrews: In message [EMAIL PROTECTED], Florian Weimer writes: * Stephane Bortzmeyer: Second question, the document indeed standardizes many things which are not in common use but does not point towards a rationale, so some choices are puzzling. Why TXT records to point to an URL and not NAPTR? Is this because of current usage in DNSxL? If so, this should be noted. But why IPv6 lists use a A record and not a ? I am not aware of existing IPv6 lists so this cannot be the current usage? The lack of a macro capability also means that it's basically impossible to secure DNSBL zones with DNSSEC when they contain larger chunks of address space; see the example in section 2.1. How so? The expectation is that error messages generated from TXT records contain the actual IP addresses which triggered the DNSBL lookups. As a result, if you list a /16 (say), you need publish 65,536 different TXT records. Currently, these records are synthesized using a macro capability in the DNS server. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Florian Weimer wrote: The expectation is that error messages generated from TXT records contain the actual IP addresses which triggered the DNSBL lookups. As a result, if you list a /16 (say), you need publish 65,536 different TXT records. Currently, these records are synthesized using a macro capability in the DNS server. How does that break DNSSEC? A number of DNSBLs merely suggest an error message in their usage instructions, and leave it up to the client to synthesize a combination of the suggested error message and the IP address. Macro expansion in the client (either of supplied TXT or client-configured string) seems common. Of course, they're still only suggestions, and some DNSBL users will generate their own. The worst of all is the clients that don't tell you what the IP was and no other way to remediate issues. There are situations like this which even leave admins scratching their heads. [While the BCP isn't yet on the table w.r.t. the spec (it may be), this issue is covered in the BCP.] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
* Mark Andrews: The lack of a macro capability also means that it's basically impossible to secure DNSBL zones with DNSSEC when they contain larger chunks of address space; see the example in section 2.1. How so? The expectation is that error messages generated from TXT records contain the actual IP addresses which triggered the DNSBL lookups. As a result, if you list a /16 (say), you need publish 65,536 different TXT records. Currently, these records are synthesized using a macro capability in the DNS server. Which is independent of DNSSEC. I ask again how this a DNSSEC problem. I didn't say it was a DNSSEC problem. I just wanted to note it's impossible to secure some existing DNSBL zones using DNSSEC without sacrificing some of the functionality which is mentioned in section 2.1 in the draft. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
The expectation is that error messages generated from TXT records contain the actual IP addresses which triggered the DNSBL lookups. As a result, if you list a /16 (say), you need publish 65,536 different TXT records. Some do, some don't. In any event I agree that DNSSEC is not ideally suited to signing DNSBLs, but I would think that with some judicious partitioning into subzones the problem wouldn't be intractable. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
* Chris Lewis: Florian Weimer wrote: The expectation is that error messages generated from TXT records contain the actual IP addresses which triggered the DNSBL lookups. As a result, if you list a /16 (say), you need publish 65,536 different TXT records. Currently, these records are synthesized using a macro capability in the DNS server. How does that break DNSSEC? You'd need online signature generation (which implies sharing the key with all mirrors), or hundreds of millions of precomputed signatures for some existing zones. (Due to the prevalent attack scenario, more frequent than usual key rollovers are needed, so this really hurts.) A number of DNSBLs merely suggest an error message in their usage instructions, and leave it up to the client to synthesize a combination of the suggested error message and the IP address. Macro expansion in the client (either of supplied TXT or client-configured string) seems common. I've been told that this approach would not be acceptable. But my source probably lacked your insight into the field. With macro expansion in the client, signing and serving typical DNSBLs is still somewhat of a challenge, but doable. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
* Mark Andrews: I didn't say it was a DNSSEC problem. I just wanted to note it's impossible to secure some existing DNSBL zones using DNSSEC without sacrificing some of the functionality which is mentioned in section 2.1 in the draft. I still don't believe your claim. I can't sign a thousand million RRsets and serve it in a DoS-resilient manner, even with John's partitioning idea (which is rather neat, thanks!). Macro expansion in the client brings down the number of RRsets to a challenging, but manageable level. Chris says there's precedent for that, so I think we can end this subthread (or move the discussion to some place where the topic of DNSSEC scalability would be more on-topic). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Florian Weimer wrote: I can't sign a thousand million RRsets and serve it in a DoS-resilient manner, even with John's partitioning idea (which is rather neat, thanks!). I may have to keep that in mind if I ever DNSSEC our internal composite DNSBL zone, which has probably near 500M IPs listed (both bad and good). [The zone file is 500Mbytes] Macro expansion in the client brings down the number of RRsets to a challenging, but manageable level. Chris says there's precedent for that, so I think we can end this subthread (or move the discussion to some place where the topic of DNSSEC scalability would be more on-topic). Even more for a client-supplied string being macro-expanded in the client. Eg: no TXT query at all. If I had to guess, I suspect that more than half of clients don't issue a TXT query and synthesize their own error message instead. The vast majority of DNSBLs are arranged so that a single message with macro substitution of IP is sufficient to produce a useful error message, so why wait for a TXT query if you can configure the client to generate its own? Even tho I publish TXT records in our internal DNSBL zone, the filters themselves don't query them. The TXT records are used by administrative tools as part of the FP process because they contain diagnostic information on the entries. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
In message [EMAIL PROTECTED], Florian Weimer writes: * Mark Andrews: The lack of a macro capability also means that it's basically impossible to secure DNSBL zones with DNSSEC when they contain larger chunks of address space; see the example in section 2.1. How so? The expectation is that error messages generated from TXT records contain the actual IP addresses which triggered the DNSBL lookups. As a result, if you list a /16 (say), you need publish 65,536 different TXT records. Currently, these records are synthesized using a macro capability in the DNS server. Which is independent of DNSSEC. I ask again how this a DNSSEC problem. I didn't say it was a DNSSEC problem. I just wanted to note it's impossible to secure some existing DNSBL zones using DNSSEC without sacrificing some of the functionality which is mentioned in section 2.1 in the draft. I still don't believe your claim. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
In message [EMAIL PROTECTED], Florian Weimer writes: * Mark Andrews: In message [EMAIL PROTECTED], Florian Weimer writes: * Stephane Bortzmeyer: Second question, the document indeed standardizes many things which are not in common use but does not point towards a rationale, so some choices are puzzling. Why TXT records to point to an URL and not NAPTR? Is this because of current usage in DNSxL? If so, this should be noted. But why IPv6 lists use a A record and not a ? I am not aware of existing IPv6 lists so this cannot be the current usage? The lack of a macro capability also means that it's basically impossible to secure DNSBL zones with DNSSEC when they contain larger chunks of address space; see the example in section 2.1. How so? The expectation is that error messages generated from TXT records contain the actual IP addresses which triggered the DNSBL lookups. As a result, if you list a /16 (say), you need publish 65,536 different TXT records. Currently, these records are synthesized using a macro capability in the DNS server. Which is independent of DNSSEC. I ask again how this a DNSSEC problem. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Audio Streaming - IETF 73 November 16-21, 2008
Greetings, quick update... Streaming got off to a good start with the iepg meeting this (sunday morning). commencing Monday all 8 parallel tracks will be broadcast starting with the at 0900 CST and continue until Friday the 21st at 1515 CST. The links for streaming sources and the schedule are available thanks to the continued support of the Network Startup Resource Center in their traditional location: http://videolab.uoregon.edu/events/ietf/ or via the tools team agenda at: http://tools.ietf.org/agenda/73/ Regards Joel Jaeggli ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-mpls-te-scaling-analysis (An Analysis of Scaling Issues in MPLS-TE Core Networks) to Informational RFC
The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'An Analysis of Scaling Issues in MPLS-TE Core Networks ' draft-ietf-mpls-te-scaling-analysis-03.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 [EMAIL PROTECTED] mailing lists by 2008-11-30. Exceptionally, comments may be sent to [EMAIL PROTECTED] 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-mpls-te-scaling-analysis-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16470rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-dasgupta-ccamp-path-comp-analysis (Performance Analysis of Inter-Domain Path Computation Methodologies) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Performance Analysis of Inter-Domain Path Computation Methodologies ' draft-dasgupta-ccamp-path-comp-analysis-02.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 [EMAIL PROTECTED] mailing lists by 2008-12-14. Exceptionally, comments may be sent to [EMAIL PROTECTED] 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-dasgupta-ccamp-path-comp-analysis-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16050rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
