Slashdot Mirror

• Joining your local student ACM chapter. Better yet, run for office - I know they need the person power. If it doesn't exist, charter it!
• Want to attend a technical conference? Both USENIX and the IETF have programs designed to get students involved by providing stipends. Often, these programs are applied to by few students.
• If you prefer getting involved with a .com than a .org, consider that Apple gives away about 300 scholarships to their annual develpers conference in San Jose, WWDC.
• If you are an uber programmer, perhaps you should try registering as a student or evan as a competitor or presenter at MacHack.
• The Government is always hiring, and don't let anyone tell you that you have to get a security clearance to work on something cool.
• An earlier posted mentioned that the University IT department is a good place to work, and for the most part I agree - there are few other places with the budget and deployed network size of Univsersities that will teach you as you go.

How about IP over carrier pigeon?

Among many, many others, I saw Vernon Schryver, the guy behind Distributed Checksum Clearinghouse, on the list. It's been pretty high volume, though, and I haven't had a chance to really spend some time reading it yet.

Instead of shoehorning in functionality into a free-form field (or so I assume, by its name), why not use something more appropriate? Why not write an I-D about how DNS should include "MIRROR" records? I'll leave it to the mailing lists to debate whether DNS should know so much about a name, and the specifics of what exactly is meant by "mirror" (what content, what protocols, etc.).

The IETF has some great things cooking. RSerPool, e.g. -- though it's not designed primarily for load-distribution (rather uptime, AFAIK). Perhaps I'm suggesting you use a hammer to crack a nut, but this might abate the need for posting mirrors, like you said.

Open Source is such a beautiful thing. It's unfortunate that so much of its energy is spent writing competing implementations of various similar protocols. But I digress.

Looks like we have come a long way since this and this.

Hell, they KEPT DOCUMENTS FROM THEIR OWN PRESIDENT, and he eventually quit.

Karl Auerbach was elected to the Board of Directors (At-Large Representative for Canada and the United States), he was not the president.

Karl did win his case with support from the EFF.

Stuart Lynn is President and CEO of ICANN. He is the one that is attempting to control ICANN through both day-to-day operations as President, and the Board as CEO. Stuart seems very intent in increases his power, and his domain of power, the role and responsibilities of ICANN.

I am miffed that IANA was assigned by the US Dept. of Commerce to ICANN, and not the Internet Society / Internet Engineering Taskforce (IETF)

Although I agree with the poster who said that we should try all kinds of things, the one thing that seems to be missing is fixing the SMTP protocol. SMTP was never meant to be used the way it is today. Quite simply it is a relic of the 1980's originally written by Postel for reliable email communications but not secure, not authenticated and not scalable to the commercial realm. So when I read through these guys that are going to meet 2-3 times a year, I just see no real end in site coming from the standards community any time soon. SPAM will kill email as an effective tool and the costs, both hidden and measureable, are mounting.

The whole sender-pays email system has a lot of questions surrounding it. So can anyone point us in the direction of an RFC (informational/official/otherwise) which goes into detail describing it? The only thing that I could find is RFC 2753 which talks about sender-pays network services in general and a slight mention of sender-pays email in RFC 1192 which states that mailing list traffic is reduced in sender-pays situations like MCI-MAIL. It seems like an RFC would be the next logical step.

The whole sender-pays email system has a lot of questions surrounding it. So can anyone point us in the direction of an RFC (informational/official/otherwise) which goes into detail describing it? The only thing that I could find is RFC 2753 which talks about sender-pays network services in general and a slight mention of sender-pays email in RFC 1192 which states that mailing list traffic is reduced in sender-pays situations like MCI-MAIL. It seems like an RFC would be the next logical step.

Check here for BGP operation and here for BGP authentication.

Check here for BGP operation and here for BGP authentication.

When the L0pht group (now working for @stake) claimed in a Government Affairs Committee in May 1998 that they could make the Internet "unusable" in 30 minutes, they were largely talking about exploiting BGP.

RFC 2385 was released three months later referring to the problem . . .

You should check out MANET.

There you will find OLSRD and AODV routing protocols for Mobile Ad-hoc Networks.

For some events, like "Denied - you're on the spammer's list", 5xx may be the correct Return Code, since it terminates the session at once and we are done with it (assuming that the spammer plays by the SMTP rules, which he may decide not to do - in fact he can put the mail back on queue or turn to some other host, regardless of Return Code). However, a 5xx mistake in a configuration may cause legitimate mail to bounce, which may be quite unfortunate.

/snip/

A 4xx response also makes the spammer's host re-queue the mail and if it really is his own host who gets to do this it is probably a good thing - fill up his disks with his own spam. If, on the other hand, he is using someone else as Relay Host, all the spam mail being queued is a fairly strong evidence that something bad is going on and should cause attention at that Relay Host.

I suggested a similar mechanism to constipate TCP connections on the IETF e-mail list last summer. The basic idea is to add some new calls to the TCP API so that an application could peek at the incoming traffic without it being acknolwledged at the TCP level. If the incoming stream were something bad, then the application could tell the TCP stack to go into a slow acknowledgement mode, thus capturing the spammer in slow-mode transfer.

For more, see http://www1.ietf.org/mail-archive/ietf/Current/msg 17009.html

The difficulty is getting enough of these deployed so that spammers, and open relays, have a good chance of getting stuck.

WHAT'S THE SOLUTION! Wireless? Pigeons carrying IP packets?

I suggest you read RFC 1149 before you make a decision.

Yes, but RAND is 128 bits! Even if the SIM didn't have defences against multiple requests (which many do), that's 3.4e28 triplets to record. It isn't going to happen.

More realistically, if an operator is using the COMP128 encryption algorithm, given physical access to the SIM, the secret key Ki could be cracked in which case you could make up the triplets. That's a real problem, but it's not peculiar to WLAN - it would allow cloning of generic SIMs for GSM use. The problem is that COMP128 was intended as an illustrative algorithm, not intended for production use. Wise operators either don't use it, or are replacing SIMs using it.

Actually, the full quote is:
: During the cut-over period, K will answer either using bind8 or nsd
( There is a load balancer in front of a number of machines performing the K-root function )

To answer your other question, being:

> How does one go about identifying which software is in use at a DNS server?

There are three methods. One is the defacto which was introduced with BIND4.mumble, by which you could send a TXT query of 'version.bind' to the nameserver, and it may answer with the actual version (depending on how the local administrators set it up - ref BIND documentation for further details).

Another method is currently going through the IETF process as draft-dnsop-serverid, and consists of sending a similar query for 'version.server'. (ref the draft for further specifics). NSD replies to this method since it is not BIND.

The third method is analysis of how the nameserver replies to queries. Even between BIND versions there are a variety of subtle differences in the packet that you get back.

But, we haven't answered the 'why'. One reason is if you are tracking obscure protocol bugs from servers not under your control. Another is purely for local administration and tracking which nameserver is doing what.

Actually, the full quote is:
: During the cut-over period, K will answer either using bind8 or nsd
( There is a load balancer in front of a number of machines performing the K-root function )

To answer your other question, being:

> How does one go about identifying which software is in use at a DNS server?

There are three methods. One is the defacto which was introduced with BIND4.mumble, by which you could send a TXT query of 'version.bind' to the nameserver, and it may answer with the actual version (depending on how the local administrators set it up - ref BIND documentation for further details).

Another method is currently going through the IETF process as draft-dnsop-serverid, and consists of sending a similar query for 'version.server'. (ref the draft for further specifics). NSD replies to this method since it is not BIND.

The third method is analysis of how the nameserver replies to queries. Even between BIND versions there are a variety of subtle differences in the packet that you get back.

But, we haven't answered the 'why'. One reason is if you are tracking obscure protocol bugs from servers not under your control. Another is purely for local administration and tracking which nameserver is doing what.

Interestingly, nobody in the article or here mentions the fact that there's a very active group at the IETF that's working on securing all kinds of authentication messaging systems, including EAP (the method for 802.1x wired/wireless authentication). EAP is the focus, but the papers presented at the various conferences cover many authentication methods and methods of securing them.

Protocols like EAP (Extensible Authentication Protocol) are intended to provide a generic mechanism over any transport system to handle legacy and modern handshaking and exchange to authenticate a user in a system.

In 802.1x/EAP, included as of the 802.11i wireless security update, 802.1x defines the roles of a client, access point authentication passthrough, and an authenticator. 802.1x restricts access to the network until the access point using EAP has been told by the authentication system that the client is okay to be on the network. It hands off a key, which eliminates spoofing, as even if you spoof the MAC address, you don't have the key. The key can be swapped frequently, like every 10,000 packets.

The problem with 802.1x/EAP is the same as with the SIM/GSM authentication system as described here. The authentication is sent in the clear! So you have three flavors of tunneled, SSL-like EAP: EAP-TLS (requires a pre-installed certificate on the client), EAP-TTLS (Meetinghouse, Funk support, tunnels EAP inside a tunnel), and PEAP (Microsoft, Cisco, same tunneling but ignores legacy protocols supported within EAP-TTLS).

Don't forget this protocol, too.

Of course its insecure, they programmed their security in basic.

Those of us who wonder what the "basic" in HTTP's "basic authentication" really stands for should read RFC 2617.

Why not start off with whitelisting? Add some extension to SMTP that would sign outgoing mail with a domain certificate. Old, noncompliant software could ignore the extension. Newer versions could verify the signature and bypass the spam (message content) filters, but check the domain name against a domain blacklist. Once a domain was found to be a source of spam, it could be added to a domain blacklist (or better yet, request that they get put on the CRL!). Eventually, you'd get to the point where you (the mail server admin) would feel comfortable requiring all domains to sign their mail to you.

How about it, guys? (I looked, and this was the closest thing I could find.)

The Internet backbone has coded IPv4 into silicon to support the speeds it does. The backbone will never change, so 6to4 utilizes it as a layer2 unicast interconnect, but *way* more efficiently than 6bone.

I prefer callto:// URI:s any day.

It's spelled "tel:". See section 2.7.2 of RFC 2806.

BTW, RFC2616 has obsoleted RFC2068.

Also, sections 3.12 and 14.35 are pretty good, if anyone here is looking for info on resuming HTTP downloads.

I highly recommend using the Berkeley:

SafeTP

for secure ftp transfers. The SafeTP client & server code runs well on Unix / Linux as well as those MS-based boxen.

Our ISP has been successfully using SafeTP for several years. Their windoz users transparently use SafeTP with any Windoz FTP application.

Unix folks get that good ol' command line tool. Other Unix interfaces exist for HP-UX, Solaris, Linux, DEC OSF, FreeBSD, OpenBSD, Irix, AIX, etc. SafeTP works across firewalls as well.

With cryptographic protection and authentication, SafeTP is a nice ftp solution.

http://[66.35.250.150]:80/

http://[66.35.250.150]:80/

I believe that this extension will become standard soon, but then of course you need all the SSL browsers and servers to implement the extension before we can solve that particular problem.

I believe that this extension will become standard soon, but then of course you need all the SSL browsers and servers to implement the extension before we can solve that particular problem.

There are several other benefits to IPv6 IETF is implementing while they are updating the protocol. They don't wish to do it too often for obvious reasons and will try to get as much useful stuff in the new version while they're at it.

IPv6...

- ... will support IPSec intrinsically to provide end-to-end security on protocol level.

- ... eliminates the need of NAT with special "local" addresses.

- ... supports QoS features.

- ... supports multihomed devices and load balancing, since an IPv6 address specifies a network interface, not a computer as in IPv4.

- ... uses "modularized" headers where only the necessary fields are used. This essentially makes IPv6 more optimized than IPv4. For example, if the payload of a packet is larger than 64KB, IPv6 will attach another field for "jumbo payloads" and set the 16-bit value to 0.

- ... contains improved multicast support (as an extension header), support for an authentication header (also an optional extension header), and an encryption header (also an optional extension header).

- ... provides enhancements for DNS.

- ... provides automatic neighbor discovery which is especially useful for ad hoc networks and wireless devices.

- ... has a completely rewritten adress autoconfiguration.

See also:
IPv6: The Promise, The Problems, The Protocol
RDC 2373

It's not TCP/IP over power lines that's interesting, it's electricity over TCP/IP (RFC 3251). That is a much newer and hotter idea, and much more interesting to smoke in the long run.

1.4 Scalability The primary reasons to deploy Zeroconf protocols are simplicity and ease-of-use. Scalability is important but it is a secondary goal. Thus, scalability should not detract from the primary goals of simplicity and ease-of-use.

Rendezvous is not just an Apple product - it is on the way to being an Internet standard, with an IETF working group and two Internet drafts in progress - one on Auto configuration of hosts and the other on the Dynamic configuration of IP Addresses.

At the ZeroConf WG meetings I have been to, Microsoft was very much present, so I assume that they are well aware of this technology.

Rendezvous is not just an Apple product - it is on the way to being an Internet standard, with an IETF working group and two Internet drafts in progress - one on Auto configuration of hosts and the other on the Dynamic configuration of IP Addresses.

At the ZeroConf WG meetings I have been to, Microsoft was very much present, so I assume that they are well aware of this technology.

Rendezvous is not just an Apple product - it is on the way to being an Internet standard, with an IETF working group and two Internet drafts in progress - one on Auto configuration of hosts and the other on the Dynamic configuration of IP Addresses.

At the ZeroConf WG meetings I have been to, Microsoft was very much present, so I assume that they are well aware of this technology.

As mentioned, since Rendezvous is based on zeroconf, here is a paper explaining how to secure a zerconf network. Facts vs. FUD. Let the better approach win.

Since Rendezvous is based on Zeroconf, here is an paper explaining how to secure a zerconf network. Perhaps this will slow the FUD.

My net connection runs over the protocol in rfc 1149.
Their claims are only on information sent over standard telephone, cable or satellite broadcast channels . INAL, but i think Avian Carriers are safe from them!

Anonymous Coward trolls:
Give us a phone number to call this company:
Well Jim, I would love to confirm your employment when Kevin damaged your system. I imagine your full of it. Just my personal opinion.

Well first off, to confirm that the account belongs to Jim Gettys, this account has been posting to slashdot for years, including posting in articles about himself and his work, and you are the first person I've seen accuse him of being "full of it". If the jg account on slashdot were a fake, I'm certain there would be a number of his friends and coworkers pointing this out. There haven't been, so I will assume it's him.

Secondly, since you appear to have been asleep for the past ten years, you cannot call Digital Equipment Corporation, because they no longer exist. They were acquired by Compaq, which was acquired by Hewlett Packard. Sure enough, Mr. Gettys works for Hewlett Packard now, in the HP Labs division.

His employment at Digital is a matter of public record. He's even listed as a DEC employee in RFC 2068. If you really want to confirm his employment, I suggest you hunt down HP's Human Resources (or Media Relations, they might have a biography) department yourself.

While I am aware that Kevin Mitnick is a more recognized name for many people, Jim Gettys is far more deserving of fame. Both The X Window System and HTTP are the way they are today partially due to his hard work. Kevin Mitnick did something stupid, got caught doing it, and was abused by the government; Jim Gettys actually created things we use every day.

Examination of RFC821 and RFC2505 shows that any 55x error is (paraphrase) a permanent negative result code indicating that the receiving system cannot accept the message.

The third digit allows for fine gradation of replies, and "552" is a common return code from a spam filter.

This is a design decision -- in many cases, you don't want your anti-spam filter to return a result that could be interpreted to mean:

"What you just sent me triggered a threshold limit, if you take out some exclamation points and only mention viagra once, I might let it through next time"

He did make the @!$@!~~# internet!

A patent pending technology for electronic commerce that [uses a] "variable length key that is encrypted using blowfish algorithm then merged with the image of the stamp using another variable length password" with no peer review of the securtiy of the system? Users can "exhange stamps online and many users can use one internet stamp until it runs out of funds"? A sales site (interstamps.net) with no indication of parent company, physical address, telephone number? A completely anonomous system with a tracking serial number?

This sounds like the worst of horror stories that can be devices by Open Source and Privacy advocates combined, but we're singing its praises because it released some code under the GPL?

So apart from the many pointers that indicate that no self respecting online purchaser should hand over ANY details to this site, what about security and anonomity?

Sites you purchase from clearly can't track your identity across transactions (assuming you use a different stamp). Or can they?

Well, Centipaid or Internetstamps can certainly track all purchases you make, by virtue of the stamp's serial number. While they promise nicely in their Privacy Notice not to "materially change" their privacy policy, they reserve the right to. They also say they won't divulge "account contact or payment information", but that's easy to sidestep in a number of ways (is what your purchased and where you bought it "payment information"?).

Since Centipaid has close ties with the sellers (producer and consumers of the technology, right?), can we be sure that our purchasing trends aren't being syndicated to ALL of the sellers? Or maybe to Doubleclick or a similar organisation. All you're really doing in this system is trusting a third party to behave responsibly ... one that doesn't even provide a physical address or indication of incorporation on their website. Ouch.

As for security, well, they're rather scant on details. A quick look over the PHP source code available from the site seems to indicate that you get redirected to a gateway under Centipaid's control - a standard mechanism for payments through Trusted Third Parties. But it would also seem (although I could be mistaken) that the communication between the merchant and Centipaid is not encrypted or authenticated (signed).

Without going into detail, any third party payment system that does not use a PKI and does not have secure communication between pair of parties can be attacked. In this case it is most likely that the merchant could be attacked. Nice for the purchaser, not so nice for the seller.

Besides this is the original claim that users can "exhange stamps online and many users can use one internet stamp until it runs out of funds". So this is really a debit facility (prepaid account) with a gimmick (a pretty picture ... oooh, aaah!). Your stamp is no more or less secure than a credit card -- you just have a better ability to limit your losses.

No, I wouldn't trust the security of this system...

It may be interesting to take a read over this Internet draft, written by the guy who appears to own/run Centipaid. The paragraph entitled "Electronic postage support" is especially interesting, as is this notice: "Adonis El Fakih has a patent pending that may relate to AMDP internet draft specifically to the work derived from draft-amdp-00.txt", after which some reference is made to non-discriminatory terms.

I'll let you draw your own conclusions...

There is a patent by walid.com on substituting national characters with ASCII in DNS systems. (So ærø.dk would be looked up as aro.dk etc.) IETF tried to build a standard but were told (bottom mail) that they could use the patent based on "reciprocity" meaning that companies using internationalised domain names would grant walid license to all their patents.

Actually IDNs have their IETF approved standard called "Internationalizing Domain Names In Applications" (IDNA). It calls for changes to individual applications to support IDNs. It is composed of three standards that are going to be published as RFCs and are currently in the queue of RFC editor.

The IDNA standard is currently used by many application developers. For example Mozilla guys are including IDNA in some parts of the Mozilla project

Actually IDNs have their IETF approved standard called "Internationalizing Domain Names In Applications" (IDNA). It calls for changes to individual applications to support IDNs. It is composed of three standards that are going to be published as RFCs and are currently in the queue of RFC editor.

The IDNA standard is currently used by many application developers. For example Mozilla guys are including IDNA in some parts of the Mozilla project

Uhm no. Pipelining is often made parallel. Just look at http - serial is keep-alive. parallel is pipelining.
To quote RFC 2068: Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time. (for more details see RFC 2068, 8.1.2.2)
Serial is done using the Connection: keep-alive header.

I hear of all these proprietary ways to handle non-ascii domain names and constantly fail to see why people cannot wait for the IETF IDN Working Group to finish their work.

by the IETF. At least it's so according to this RFC.

I think this'll be included in the next version of KMail