- NANOG - lists.nanog.org

Re: BCP regarding TOS transparancy for internet traffic
by sthaug＠nethelp.no 25 May '05

25 May '05

> > Beatiful idea, how in practice do you suggest this is done, how will > > my router know if it should just ignore the TOS bytes or do expedited > > forwarding as configured for given value of TOS byte? > > VLANs? Different route paths? Any of a dozen other ways to limit special > processing to the networks that have paid for it and dump everybody else > into the best-effort pool? Seems to me these are far more complex solutions than simply rewriting TOS at the borders. And yes, we also rewrite TOS at the borders for Internet traffic. We definitely intend to continue doing this. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

RE: Moscow: global power outage
by Jim McBurnett 25 May '05

25 May '05

Or maybe one of those upteen bazillion Generators that Soviet Government touted a year or so ago. -----Original Message----- From: Gadi Evron [mailto:ge@linuxbox.org] Sent: Wednesday, May 25, 2005 5:30 AM To: Dmitry Kiselev Cc: nanog(a)nanog.org Subject: Re: Moscow: global power outage Dmitry Kiselev wrote: > > http://www.mosnews.com/news/2005/05/25/blackout.shtml > > Regional internet exchange "M9" affected. Most RU networks lost from > full view. I suppose it's time to introduce the concept of a UPS. Gadi.

2 2

Moscow: global power outage
by Dmitry Kiselev 25 May '05

25 May '05

http://www.mosnews.com/news/2005/05/25/blackout.shtml Regional internet exchange "M9" affected. Most RU networks lost from full view. -- Dmitry Kiselev

3 2

FTC, Partners Launch Campaign Against Spam "Zombies"
by Fergie (Paul Ferguson) 25 May '05

25 May '05

I think this has direct operational relevance--it will be interesting to see if this "campaign" has any direct impact of the spam zombie/botnet problem -- especially when even temporarily "disconnecting" customer computers is a revenue impacting activity (even if it does violate AUP's). :-) I guess we'll see.... Excerpt from Reuters article: [snip] "Home computer users who unwittingly send out spam e-mail should be disconnected from the Internet until their machines are fixed, the U.S. Federal Trade Commission said on Tuesday. "The FTC said it would ask 3,000 Internet providers around the globe to make sure that their customers' computers haven't been hijacked by spammers who want to cover their tracks and pass bandwidth costs on to others." [snip] Article on Reuters: http://today.reuters.com/news/newsArticle.aspx?type=internetNews&storyID=20… FTC announcement: http://www.ftc.gov/opa/2005/05/zombies.htm - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

4 3

draft-savola-mtufrag-network-tunneling-04.txt
by Pekka Savola 24 May '05

24 May '05

Hi, Some of you may remember about half a year - year ago, I asked for feedback (and got some) for an internet draft on MTU issues in the tunnels which are set up in the network. This is a topic with pretty high operational relevance. I've revised the draft again based on some really good feedback, and it's getting very near publication soon. So, I'd like to solicit more comments (on- or off-list). Please comment within about a week or so. http://www.ietf.org/internet-drafts/draft-savola-mtufrag-network-tunneling-… Abstract Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided. This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

1 0

Vulnerability Issue in Implementations of the DNS Protocol
by Fergie (Paul Ferguson) 24 May '05

24 May '05

UNIRAS (UK Gov CERT)/NISCC: http://www.niscc.gov.uk/niscc/docs/al-20050524-00433.html [snip] Summary - ------- A vulnerability affecting the Domain Name System (DNS) protocol was identified by Dr. Steve Beaty from the Department of Mathematical and Computer Science of Metropolitan State College of Denver. The Domain Name System (DNS) protocol is an Internet service that translates domain names into Internet Protocol (IP) addresses. Because domain names are alphabetic, they're easier to remember, however the Internet is really based on IP addresses; hence every time a domain name is requested, a DNS service must translate the name into the corresponding IP address. The vulnerability concerns the recursion process used by some DNS implementations to decompress compressed DNS messages. Under certain circumstances, it is possible to cause the DNS server to terminate abnormally. All users of applications that support DNS are recommended to take note of this advisory and carry out any remedial actions suggested by their vendor(s). [snip] - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

3 2

Cisco Various Products Compressed DNS Messages Denial of Service
by Fergie (Paul Ferguson) 24 May '05

24 May '05

Apologies for responding to my own post, but Secunia has released more details on this vulnerability alert, specifically: [snip] A vulnerability has been reported in various Cisco products, which can be exploited by malicious people to cause a DoS (Denial of Service). The vulnerability is caused due to an error in the DNS implementation during the decompression of compressed DNS messages and can be exploited via a specially crafted DNS packet containing invalid information in the compressed section. Successful exploitation crashes a vulnerable device or causes it to function abnormally. The vulnerability affects the following products: * Cisco IP Phones 7902/7905/7912 * Cisco ATA (Analog Telephone Adaptor) 186/188 * Cisco Unity Express The following Cisco ACNS (Application and Content Networking System) devices are also affected: * Cisco 500 Series Content Engines * Cisco 7300 Series Content Engines * Cisco Content Routers 4400 series * Cisco Content Distribution Manager 4600 series * Cisco Content Engine Module for Cisco 2600, 2800, 3600, 3700, and 3800 series Integrated Service Routers. Solution: See patch matrix in vendor advisory for information about fixes. http://www.cisco.com/warp/public/707/cisco-sn-20050524-dns.shtml#software Provided and/or discovered by: NISCC credits Dr. Steve Beaty. Original Advisory: Cisco: http://www.cisco.com/warp/public/707/cisco-sn-20050524-dns.shtml NISCC: http://www.niscc.gov.uk/niscc/docs/al-20050524-00433.html [snip] http://secunia.com/advisories/15472/ - ferg -- "Fergie (Paul Ferguson)" <fergdawg(a)netzero.net> wrote: UNIRAS (UK Gov CERT)/NISCC: http://www.niscc.gov.uk/niscc/docs/al-20050524-00433.html [snip] Summary - ------- A vulnerability affecting the Domain Name System (DNS) protocol was identified by Dr. Steve Beaty from the Department of Mathematical and Computer Science of Metropolitan State College of Denver. The Domain Name System (DNS) protocol is an Internet service that translates domain names into Internet Protocol (IP) addresses. Because domain names are alphabetic, they're easier to remember, however the Internet is really based on IP addresses; hence every time a domain name is requested, a DNS service must translate the name into the corresponding IP address. The vulnerability concerns the recursion process used by some DNS implementations to decompress compressed DNS messages. Under certain circumstances, it is possible to cause the DNS server to terminate abnormally. All users of applications that support DNS are recommended to take note of this advisory and carry out any remedial actions suggested by their vendor(s). [snip] - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: soBGP deployment
by Suresh Ramasubramanian 24 May '05

24 May '05

On 5/24/05, Brad Knowles <brad(a)stop.mail-abuse.org> wrote: > If you're talking about users, then all you have to do is > implement SPF at a few large sites like AOL, where they don't support > forwarding and therefore they don't care if they break forwarding, > where they want to force everyone to use their outbound mail relay > servers anyway, etc.... Do that, and you've got a "majority". Two levels of SPF - 1. publishing conservative enough spf records to do the least damage but look good (~all or ?all instead of -all) - every man and his dog (e&oe people like us who have removed all our spf records) does that these days after AOL announced they'd use published spf records to maintain their whitelist and feedback loop 2. Rewriting return paths using SRS/SES for forwarded mail, and checking + rejecting based on spf failures srs (http://www.circleid.com/article.php?id=1039_0_1_0_C/ for more) > > If you're talking about mail systems, it's a whole different > picture. Setting up TLSSMTP or SMTPAUTH is non-trivial, even for > experienced admins. Indeed, many experienced admins may own their > own domains, but not run their own machines. Even if the server side > is capable of supporting TLSSMTP and/or SMTPAUTH, they may well be > using clients which are not capable of doing so, or not capable of > doing so interoperably with the server side. Much, much more > difficult to get large numbers of installations. > > > Penetration of SPF is pretty low, and it's likely to stay that > way for the foreseeable future. The problems with SPF are pretty > basic, and I don't see them being eliminated any time soon with a > casual wave of your royal hand. > > > This obsession with perfection will (as usual) result > > in exactly no progress. Folks need to be willing to get 70% of the benefit > > for 10% of the effort. > > And if twelve people told you that you'd have to implement twelve > different incompatible systems, and each of them would give you a > different 70% of the benefit for 10% of the effort (but only if they > were the only solution implemented), what would you do? > > The IETF has taught us that multiple incompatible partial > solutions is not a particularly desirable outcome. That way lies > madness. > > -- > Brad Knowles, <brad(a)stop.mail-abuse.org> > > "Those who would give up essential Liberty, to purchase a little > temporary Safety, deserve neither Liberty nor Safety." > > -- Benjamin Franklin (1706-1790), reply of the Pennsylvania > Assembly to the Governor, November 11, 1755 > > SAGE member since 1995. See <http://www.sage.org/> for more info. > -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

1 0

New IANA IPv6 allocation for APNIC (2400::/19)
by Doug Barton 24 May '05

24 May '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, This is to inform you that on 20 May 2005 the IANA allocated the following one (1) IPv6 /19 block to APNIC: ~ 2400:0000::/19 APNIC For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-unicast-address-assignments> - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCkm/+wtDPyTesBYwRAoF2AKCauGLNaAEcyvyCEH5S2ev1KuDH/ACfakit cJ3TQ6O4MiYq9mb2L/JaAC0= =mJiE -----END PGP SIGNATURE-----

1 0

VZ and VZW are completely separate (from an SMTP point of view)
by Steven J. Sobol 23 May '05

23 May '05

To get an answer on the VZW mail filtering issue, we'd have to talk to a mail admin at Verizon Wireless, as described by my acquaintance at Verizon Online. ---------- Forwarded message ---------- Date: Fri, 20 May 2005 09:45:00 -0500 From: <REDACTED(a)verizon.net> To: Steve Sobol <sjsobol(a)JustThe.net> Subject: Re: [Fwd: VerizonWireless.com Mail Blacklists] Steve, Verizon Wireless is a completely different animal with no, repeat no, relation to VOL at any business or technical level other than being owned by the same mother ship. That would definitely include SMTP or any other mail related protocols transiting my platforms. I have no idea what kind of filters or block lists they use. I will make some inquiries but don't hold your breath, they really are a seperate entity from the trenches perspective. Please do not put my info on NANOG. Thanks.

2 1