- Test - lists.nanog.org

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

L2TPv3 encaps performance
by Joe Abley 28 Apr '04

28 Apr '04

Someone asked me the other day if I could recommend some L2TPv3 tunnel termination devices which might be capable of encaps/de-encaps of traffic which bursts near to 1Gbit/s (e.g. with GE uplinks to a core/transport network, and GE interfaces for hand-off towards the subscriber). Application is providing transparent/pseudowire wide-area ethernet transport service over a routed-IP but non-LDP-capable core. This didn't sound like a particularly hard question, but I couldn't find any performance numbers on L2TPv3 edge boxes anywhere. What boxes exist that can do this stuff at gig speeds? Replies off-list would be fine, I can summarise if there's interest.

1 0

Check Your Routing Table! 85-88/8 active
by Daniel Karrenberg 28 Apr '04

28 Apr '04

It is *now* high time to check whether you see the following pilot prefixes: 85.192/16, 85.255.248/21, 86.192/16, 86.255.248/21, 87.192/16, 87.255.248/21, 88.192/16, 88.255.248/21. If you do not see all of these prefixes it is extremely likely that you will have a connectivity problem shortly. We also suggest that you check any packet filters you may be responsible for. Regards Daniel Karrenberg RIPE NCC ------ Notes: This address space has been allocated by the IANA on April 4th 2003, almost a month ago. The fact has been widely announced then. Routing decisions are fully within the responsibility of the network operators. The IANA and the RIRs will only announce which parts of the address space are currently in use. They have no authority whatsoever over routing decisions taken by you and other network operators. More details about this pilot service of the RIPE NCC can be found at http://www.ripe.net/ripe/draft-documents/deboganising-draft.html . A visibility comparison of the pilot prefixes with some production prefixes can be found at http://www.ris.ripe.net/debogon/debogon.html . Those interested in history, see http://www.ris.ripe.net/debogon/ . Pingable targets exist in all pilot prefixes at t{85,86,87,88}-{16,21}.rrc03.ripe.net , i.e. the target within the /21 pilot prefix of 85/8 is t85-21.rrc03.ripe.net . For testing purposes it is possible to do ping and traceroute originating within the pilot prefixes via http://www.ris.ripe.net/cgi-bin/debogon.cgi . Please use this with prudence. More information on how to do Bogon filtering efficiently and reliably can be found at Team CYMRU: http://www.cymru.com/Bogons/index.html

1 0

Re: TCP/BGP vulnerability - easier than you think
by Iljitsch van Beijnum 28 Apr '04

28 Apr '04

On 23-apr-04, at 8:35, Florian Weimer wrote: >> So I believe filtering out all BGP RSTs on all >> edges is probably a good idea. (Edges and borders.) > The problem is that even if you filter the RST, the state transition > occurs at the side which receives the SYN and generates the RST. This > means that the connection has been desynchronized and will eventually > come down, no further data transfer is possible. Although it doesn't follow from earlier text, on page 71 RFC 793 states that an in-window SYN should reset an ESTABLISHED session. So you are right. This is very bad. BTW, anyone seen anything supporting Paul Watson's claim that all it takes to break a session is four packets? I assume he's talking about this vulnerability that was fixed in FreeBSD in 1998: http://ciac.llnl.gov/ciac/bulletins/j-008.shtml I certainly hope our collective favorite vendors didn't overlook this one.

6 7