April 2004 - Test - lists.nanog.org

U.S. Charges 4 Under New Anti-Spam Law
by Henry Linneweh 29 Apr '04

29 Apr '04

Hopefully this case will have a positive outcome to send and very clear message to providers and spammers http://customwire.ap.org/dynamic/stories/I/INTERNET_SPAM?SITE=FLTAM&SECTION…

1 0

RE: New IPv4 Allocations for APNIC
by Michel Py 29 Apr '04

29 Apr '04

> Brandon Butterworth wrote: > It doesn't matter what the email is signed > with I'd still go to the site to confirm One has to be careful with this (unless one re-types the URL); I understand that the reader here is generally aware of these tricks, nevertheless we all have some weak moments. Con artists have become very good at sending fake links (especially paypal ones) that point to fake sites that really look like the real one and that display the original URL in the browser's window and the https padlock in the bottom bar. Using a text-mode browser does help, but even there embedding VT100 (or similar) control codes into the stream might lead to interesting results. Making a site look real is a matter of Javascript and Photoshop, not security. Con art is about illusion, not about encryption. Those of who not convinced can visit https://arneill-py.sacramento.ca.us/ and move their mouse cursor over the yellow padlock on the left (yes, it requires Javascript like all the other ones). What's wrong with the seal? It's completely bogus; I made it myself. The Authentic Fake Identity Seal (tm) you have found. [a real one can be found here: http://www.trustlogo.com/] > Better to trust that Rob Thomas has done due > diligence than rely on email a virus may have > generated (signed or not) :-) Michel.

1 0

Fw: Spam Handling
by joe 29 Apr '04

29 Apr '04

Suresh thanks for explaining this point. I didn't get this email except from the tread Gregh send direct.. This was my only point. Not sure why Nanog didn't post/distribute. From: "Suresh Ramasubramanian" <@outblaze.com> To: "Gregh" <@ozemail.com.au> Cc: <@merit.edu> Sent: Thursday, April 29, 2004 2:06 PM Subject: Re: Spam handling Folks, you are missing something here. He was trying to write to SBC at an address they asked him to write to, and that address bounced when he emailed it. He's not doing what you think he's doing.

1 0

Re: Spam handling
by Gregh 29 Apr '04

29 Apr '04

----- Original Message ----- From: "Suresh Ramasubramanian" <suresh(a)outblaze.com> To: "Gregh" <chows(a)ozemail.com.au> Cc: <nanog(a)merit.edu> Sent: Thursday, April 29, 2004 2:06 PM Subject: Re: Spam handling > Gregh writes on 4/29/2004 9:27 AM: > > > A guide to how to be spammed. > > > > 1) Click on most spam emails to let them know your address is to be spammed. > > > > 2) Failing that in 1, click on a "remove me" so they know you are still > > around. > > Folks, you are missing something here. He was trying to write to SBC at > an address they asked him to write to, and that address bounced when he > emailed it. > > He's not doing what you think he's doing. > With all respect, he has replied to a remove me. Then he is saying the address doesn't exist. I send messages back, routinely, from this address as if my ISP's own mailer daemon had sent them. The address he emailed may WELL exist but it is set up to respond with a standard "User not known" style reply. I wasn't missing anything. What he was missing is as I said before and the above paragraph. The remove me address may exist and all email to it may be kept and read by a spam engine and the FROM address added to the spammer's database BUT the spam engine is set up to send "User Unknown" replies back to everyone. Easy to do with a simple program most people could write. Even Macafee have worked out how to do this. Greg.

2 1

IANA IPv4 allocations and bogon update: 58/8, 59/8
by Rob Thomas 28 Apr '04

28 Apr '04

-----BEGIN PGP SIGNED MESSAGE----- Hi, team. **NOTE WELL: Thanks to a donation from the RIPE NCC we have a new bogon prefix data offering. See below for the details. The numerous Team Cymru bogon projects have been updated as of 01 APR 2004 to reflect the following IANA allocation made on 01 APR 2004: 58/8 Apr 04 APNIC 59/8 Apr 04 APNIC IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to sundry lists, such as the bogon-announce list. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not blindly apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the Team Cymru master Bogon Reference Page can be found here: <http://www.cymru.com/Bogons/> A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List - <http://www.cymru.com/Documents/bogon-list.html> The Text Bogon Lists - <http://www.cymru.com/Documents/bogon-bn-nonagg.txt> - <http://www.cymru.com/Documents/bogon-bn-agg.txt> Secure BIND Template - <http://www.cymru.com/Documents/secure-bind-template.html> Secure IOS Template (Cisco) - <http://www.cymru.com/Documents/secure-ios-template.html> Secure BGP Template (Cisco) - <http://www.cymru.com/Documents/secure-bgp-template.html> Secure JUNOS Template (Juniper) - <http://www.qorbit.net/documents/junos-template.pdf> Secure JUNOS BGP Template (Juniper) - <http://www.qorbit.net/documents/junos-bgp-template.pdf> Ingress Prefix Filter Templates, Loose and Strict (Cisco) - <ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Templates/> Ingress Prefix Filter Template, Loose (Juniper) - <http://www.qorbit.net/documents/junos-isp-prefix-filter-loose.pdf> Ingress Prefix Filter Template, Strict (Juniper) - <http://www.qorbit.net/documents/junos-isp-prefix-filter-strict.pdf> BGP Bogon route-server for AUTOMATED updates of bogon filters - All bogon route-server peers have already received the appropriate BGP prefix updates. - <http://www.cymru.com/BGP/bogon-rs.html> RADb fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#radb> RIPE NCC fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#ripe> DNS Bogon (bogons.cymru.com) zone - <http://www.cymru.com/Bogons/index.html#dns> Monitoring Bogon prefix monitoring - <http://www.cymru.com/BGP/robbgp-bogon.html> Please feel free to contact Team Cymru <team-cymru(a)cymru.com> with any comments, questions, or concerns. Thanks! Rob, for Team Cymru. - -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty); -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQCVAwUBQJApa1kX3QAo5sgJAQHypAP+NF/noJVKOCT8jfTviUyOvEUmr/UwcCwC XsomXcCp9/QAfaMElUaa34Jm4OY3eVUqIvwm/cF1Pg7EhfzjzgHzpru9EWMtMuju eHxGXZpETdVbh+YB3oZIqIP/jydO0UpwiEUHuq9behvTgM3FGjs/yMot/sIs1/dp /22VF+/QhOc= =Bmje -----END PGP SIGNATURE-----

1 0

Re: New IPv4 Allocations for APNIC
by Brandon Butterworth 28 Apr '04

28 Apr '04

> I'd prefer a PGP signed message, but I know that > the people who use S/MIME would probably object. It doesn't matter what the email is signed with I'd still go to the site to confirm > It would be too easy to get many people to pull an entry from a filter > with a forged message and have the space used "improperly". There's easier space to steal though they may like the challenge of doing it in your face. Better to trust that Rob Thomas has done due diligence than rely on email a virus may have generated (signed or not) brandon

2 1

New IPv4 Allocations for APNIC
by Steve Conte 28 Apr '04

28 Apr '04

Greetings, This is to inform you that the IANA has allocated the following two (2) IPv4 /8 blocks to APNIC: 58/8 59/8 For a full list of IANA IPv4 allocations please see: <http://www.iana.org/assignments/ipv4-address-space>. Thanks, Steve --------------- Steve Conte - IANA conte(a)iana.org PGP KeyID: 0x0972C473

4 4

Winstar says there is no TCP/BGP vulnerability
by Rodney Joffe 28 Apr '04

28 Apr '04

Perhaps we are all making too much of this... It appears that Winstar feels that there is no need for MD5 authentication of peering sessions. One of our customers has just had the following response from Winstar following a request to implement MD5 on their OC3 connection to Winstar. My first suggestion is to locate another upstream provider (they have 3 already). However, perhaps someone from Winstar would care to help us all understand what the alternative solution is to securing the session via MD5? I would *love* an alternative to the 5 days of work we've just gone through. > -----Original Message----- > From: Justin Crawford - NMCW Engineer [mailto:jcrawford@winstar.net] > Sent: Tuesday, April 20, 2004 11:13 AM > To: xxxxxx > Subject: Re: *****SPAM***** MD5 implimentation on BGP > > xxxxx, > > Winstar does not currently run MD5 authentication with our peers. > > Thanks > > Justin > > Thank you for your time and business > > Justin Crawford > Winstar NMCW > Ph: 206-xxx.xxxx Has anyone else run in to this with Winstar? -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(SM)

16 24

Re: Lazy network operators - NOT
by Paul Vixie 28 Apr '04

28 Apr '04

> I suggested using something like HINFO in the in-addr.arpa address > zones for service providers to give similar information about IP > addresses. Yes, I know, using DNS for yet something else. LDAP or > RWHOIS or any other global mechanism could be used. more uses for dns is actually a good thing in my opinion. but this isn't one of the times when hierarchical autonomy is the best data model -- we already know that the average broadband provider is not even aware of their role in the overall spam problem, and does not have the budget to employ anyone who could (a) become aware of an HINFO-like registry, (b) know what category their netblocks belong in, (c) have the technical ability to update the RFC1101-like info at the apex of the appropriate zones, and (d) get approval from management/legal/marketing/sales to put this data in. so, it's going to have to be an external entity like a RIR or DNSBLP who runs a global "BBL" and externally categorizes these netblocks. > If you don't want to accept connections from indeterminate or > unauthenticated addresses, its your choice. If you are a porn vendor > and don't want K12 users to accidently stumble on to your web site, > its your choice. If you are a credit card vendor and don't want to > accept credit card orders from prisons or jails, its your choice. yes, that's how it works, it's just that right now there's no way to know, and the way-to-know that you proposed requires broadband gross margin not in evidence (or expected to appear).

3 2

juniper & md5 auth on bgp
by Wei Keong 28 Apr '04

28 Apr '04

Hi guys, I've come across a strange problem while implementing MD5 auth on bgp between a juniper (5.6R2.4) & cisco (12.1.9a) router. The bgp for the juniper side is in a non-main routing instance. I've configured the MD5 password on both routers, but the bgp can't be established. Following the recommended resolution in this mailing list also didn't help either. On the juniper router, the log shows a lot of these: tcp_auth_ok: Packet from x.x.x.x:29594 unexpectedly has MD5 digest last message repeated 3 times On the cisco router, the log shows these: %TCP-6-BADAUTH: No MD5 digest from x.x.x.x:2124 to x.x.x.x:179 The strange finding is the moment i move the bgp group to the main routing instance, everthing works as per expected... Has anyone encounter similar problem? What could be the cause? Thanks, Wei Keong

1 0