Slashdot Mirror

I haven't looked in on the politics of this one but there are two kinds of individual submissions

1 - Any idiot can mail something properly formatted to internet-drafts@ietf.org and get it published as an internet draft... don't believe me look here Individual Submissions - you will find this draft somewhere on this page

2 - A working group is looking for a new working group item - so they ask the author to post an individual submission so they can consider his work before making a decision - These actually become RFCs

Want a clue on WG items in the ietf - they come in the form draft-ietf-WGName-topic-rev.txt - The key is to not be fooled by people that post draft-ietf-lastname-topic-rev.txt

You'll see that in all cases, the "S" stands for Symmetric.

• Saying "TCP/IP" does not normally mean TCP.. it means the entire protocol suite. Saying something runs "on tcp/ip" is ambiguous.
• "Raw ethernet" usually means "another layer 3 protocol"
• iSCSI uses TCP as a transport. iSCSI IETF Draft.

• HyperSCSI is a layer 3 protocol. HyperSCSI Spec
• HyperSCSI on ethernet uses a EtherType field of 0x889a.
• With iSCSI, you can route over an IP network to your devices.. you could have a storage subnet, for instance.
• We want storage to be as fast as possible, and generally it will be local, so HyperSCSI makes more sense. It's just a new way to build a SAN rather than using Fiberchannel... now we have gigabit ethernet, and so on.

which was originally written as a joke but actually implemented a few years ago. The RFC is officially titled "A Standard for the Transmission of IP Datagrams on Avian Carriers" (note the date of publication : April 1). In short it's a method of IP transmission using carrier pigeon. The Bergen Linux Users Group in Norway actually performed the first documented transmission of CPIP (Carrier Pigeon Internet Protocol) back in 2001 and has a pretty detailed writeup of the event, including quite a number of pictures.

As Paul Vixie said, the major problem here is one of broken expectations. The .com and .net domains have behaved in the non-wildcard manner since day dot. There is a reasonable expectation that a DNS query on a non-existent .com or .net domain will return a "no such domain" response. VeriSign unilaterally broke this without warning. I believe that ".museum" has implemented the wildcard since day dot, so there are no broken expectations there. As the IAB said, it's reasonable to implement wildcards with the informed consent of everyone who is delegated a name in that zone (but it's still a bad idea, technically, for various reasons).

You're just trollin'.

VeriSign's mail server is called the Snubby Mail Rejector Daemon v1.5

v1.3 wasn't fully SMTP compliant: See here.

v1.5 now responds a little more properly: See here.

It rejects them anyway.

You're just trollin'.

VeriSign's mail server is called the Snubby Mail Rejector Daemon v1.5

v1.3 wasn't fully SMTP compliant: See here.

v1.5 now responds a little more properly: See here.

It rejects them anyway.

His advice is "Stop trying to reinvent the wheel and use the stuff that we already know works, like SSL and IPsec."

The problem is that there are too many people out there who think that these standards are too complex and so they go and try to make something simpler. But it's the complexity that makes them secure. It's like deciding that 3DES is too complex, so you'll just go use ROT-13 since you can wrap your head around it.

Good insight. SSL in commonly useage is version 3 (1995) the first version (1994) being seriously broken, and version 2 (also 1994) had serious flaws, and there is TLS (RFC 2246) 1.0 is a standard and recommended extensions are available. It has taken a lot of experts a long time to get it right, and it needs minor maintance from time to time.

Now, what WOULD be useful is for someone to refactor OpenSSL into a library that people could actually use. If they could just change a couple function calls, edit their makefile, and it would magically work, we'd see a lot more people using really secure protocols.

The reason OpenSSL is so complex is that it tries very hard to be the highest performance (read: platform and processor specific assembly) on a wide variety of processors and OSes, attempts to implement things correctly and includes tests to verify the library.

OpenSSL is not that hard for the application developer to actually use, but I am afraid that cryptography (and computer security in general) demands that the implmenter has a bit of a clue, and cannot simply #include and have it magically secure everything.

There is no silver bullet, even in cryptography.

His advice is "Stop trying to reinvent the wheel and use the stuff that we already know works, like SSL and IPsec."

The problem is that there are too many people out there who think that these standards are too complex and so they go and try to make something simpler. But it's the complexity that makes them secure. It's like deciding that 3DES is too complex, so you'll just go use ROT-13 since you can wrap your head around it.

Good insight. SSL in commonly useage is version 3 (1995) the first version (1994) being seriously broken, and version 2 (also 1994) had serious flaws, and there is TLS (RFC 2246) 1.0 is a standard and recommended extensions are available. It has taken a lot of experts a long time to get it right, and it needs minor maintance from time to time.

Now, what WOULD be useful is for someone to refactor OpenSSL into a library that people could actually use. If they could just change a couple function calls, edit their makefile, and it would magically work, we'd see a lot more people using really secure protocols.

The reason OpenSSL is so complex is that it tries very hard to be the highest performance (read: platform and processor specific assembly) on a wide variety of processors and OSes, attempts to implement things correctly and includes tests to verify the library.

OpenSSL is not that hard for the application developer to actually use, but I am afraid that cryptography (and computer security in general) demands that the implmenter has a bit of a clue, and cannot simply #include and have it magically secure everything.

There is no silver bullet, even in cryptography.

From RFC 2775:

Abstract

This document describes the current state of the Internet from the
architectural viewpoint, concentrating on issues of end-to-end
connectivity and transparency. It concludes with a summary of some
major architectural alternatives facing the Internet network layer.

[...]

3.5 Network address translators

Network address translators (NATs) are an almost inevitable
consequence of the existence of Intranets using private addresses yet
needing to communicate with the Internet at large. Their
architectural implications are discussed at length in [NAT-ARCH], the
fundamental point being that address translation on the fly destroys
end-to-end address transparency and breaks any middleware or
applications that depend on it. Numerous protocols, for example
H.323, carry IP addresses at application level and fail to traverse a
simple NAT box correctly. If the full range of Internet applications
is to be used, NATs have to be coupled with application level
gateways (ALGs) or proxies. Furthermore, the ALG or proxy must be
updated whenever a new address-dependent application comes along. In
practice, NAT functionality is built into many firewall products, and
all useful NATs have associated ALGs, so it is difficult to
disentangle their various impacts.

The IETF midcom group has been working on solutions for passing media streams through NATs and other middleboxes for a few years now. One protocol, STUN, is already a standards-track RFC, and the group has other tools in progress. These tools work with the IETF multimedia suite (SDP, SIP, RTP, etc).

The IETF midcom group has been working on solutions for passing media streams through NATs and other middleboxes for a few years now. One protocol, STUN, is already a standards-track RFC, and the group has other tools in progress. These tools work with the IETF multimedia suite (SDP, SIP, RTP, etc).

An error response that only works correctly in one situation would be as bad as an SMTP server that ignored its input and always produced a fixed sequence of responses: it would work in the one situation it was designed to expect, but cause chaos whenever presented with any other situation.

Standards from Microsoft are dangerous, even when royalty-free licensing is offered so that they can be implemented in Free Software.

Consider for example the ECMA standards 334 and 335 for the core parts of .NET - while Microsoft has promised royalty-free licensing for any and all patents that may be neccessary for implementing that standard, they are at the same time embracing and extending their own standard, and they have filed at least one patent application that seems to be designed to give them a monopoly on their extensions to the standard.

In some situations it may work to simply refuse to go along with the standards attempts from MS. Unfortunately, MS has so much leverage that this won't always work. For example, with .NET just ignoring it IMO won't work, that's why we're working on creating a competing "standard set of libraries" for the stuff which goes beyond the stuff that is safe from patent-based attacks (the safe parts are what is specified in the ECMA specs, for which MS has promised royalty-free licensing, plus everything which is thin wrappers around stuff that is simply too old to be affected by .NET patents, such as for example System.Windows.Forms). The strategy of the DotGNU project is to re-use a good number of existing Free Software libs (written in C) and compile them for .NET - again since those libs are old, they're safe from being affected by any .NET patents.

Greetings,
Norbert.

The BSD syslog Protocol already has a scale that can be adapated with a little tweaking. And then we can have notification relayed to a plethora of Syslog consoles that can take appropriate action (backup, shutdown, pager, send T101 back in time to stop it, etc). So we have:

0 Emergency: system is unusable
1 Alert: action must be taken immediately
2 Critical: Critical conditions
3 Error: Error conditions
4 Warning: Warning conditions
5 Notice: normal but significant condition
6 Informational: Informational messages
7 Debug: debug-level messages

0 Emergency: planet is unusable
1 Alert: action must be taken immediately
2 Critical: Critical conditions
3 Danger: Danger Will Robison!
4 Warning: This is too close
5 Notice: This one is a bit close
6 Informational: Here's the orbit
7 Debug: Still figuring out the orbit

The only downside I see is that it is the BSD syslog protocol, and I understand that BSD is dead...

....since we're all suggesting LDAP implementations in our favorite languages. Get it here.

Note that it aims to be RFC 1823 compliant, so it'll work with OpenLDAP. If you pick an LDAP server that uses proprietary extensions, of course, you'll have to do some hacking...

Here's the current list of the 4 proposals that I know about.

RMX proposal

SMTP+SPF proposal

DMP proposal

DRIP proposal

All (4) of those perform pretty much identically, with various trade-offs. The 2 key questions that an SMTP server needs answered are:

- does this domain have reverse-MX information?

- is the origin IP address authorized to send e-mail for the purported origin domain?

And possibly a 3rd question for farther down the road (although this is possibly over-kill):

- has the e-mail been properly signed by the sender of the e-mail

IIRC, NSLookups fail because it makes the assumption that everyone is in control of their reverse IP info and that people don't service multiple domains from a single IP address.

The only legitimate reason for faking a From: address is so that replies go back to the correct mailbox while submitting them through a different mail server. It seems to me that the first step has to be to pressure all mail client and mail server programs to support using the MSA protocol/port. Sendmail has this enabled by default, I believe, and many mail clients can use it as well. If it was made pretty much universal and supported, the necessity of submitting to a local SMTP only (or using hideous kludges like SMTP-after-POP) would be eliminated.

Use all the different e-mail addresses you want, as long as you send them via a mail server that is authorized by the domain specified in the "From:" (or at least "Sender:") field. AMTP or something like it could be used to validate that. People who want to run their own mail servers can still do so. If something like AMTP becomes the standard, and you don't want to get your own certificate, you could still make arrangements with your ISP to deliver mail through their server, authenticating your server using their own certificates, knowledge of your IP address, or whatever.

https://www1.ietf.org/mail-archive/working-groups/ asrg/current/msg05876.html

I thought OID standard already gave hierarchical structural ID-numbers to every particle in the universe we ever want to give ID to.


http://www.ietf.org/rfc/rfc3061.txt

Will they implement OID-codes into the EPC-codes or put EPC-codes part of the OID-codes?

Maybe OIDs are too sparse and should be compressed losslessly and then encoded in BASE64, huh?

Or one of the other proposals (personaly, as a mail admin, I don't care which of the proposals make it so long as I can stop having my domain name forged onto e-mails that we didn't send):

RMX proposal

DMP proposal

DRIP proposal

Unfortunately, it'll probably be 2-3 years until the standard organizations get off their duffs and pass something.

There are currently (at least) 4 different proposals that I know about to end the process of domain spoofing (which is part of the battle).

RMX proposal

SMTP+SPF proposal

DMP proposal

DRIP proposal

I don't know what (or if) your role at Rutgers is. But I can say this. If the departments won't report MTAs, then things are out of control. The central networking policy can in fact fix that with proper advance notification. They can always "smart host" forward to the central campus mail server. If they want to be able to connect SMTP direct, then access-list permit them to do so (of course that means they have to tell you, or whoever handles that, what the address is). If you don't want the access-list cluttered with a bunch of individual addresses, then set up a virtual subnet and access-list permit that, and route all those addresses around campus as /32's. Everything else will just have port 25 blocked (but not port 587, so you can still allow use of outside mail services when those services have deployed the message submission protocol as defined in RFC2476, which is AUTH-SMTP compatible).

Among other petty annoyances, AOL is incorrectly refusing connections from blacklisted hosts, as follows:

$ telnet mailin-01.mx.aol.com 25
554- (RTR:BB) The IP address you are using to connect to AOL is a dynamic
554- (residential) IP address. AOL will not accept future e-mail transactions
554- from this IP address until your ISP removes this IP address from its list
554- of dynamic (residential) IP addresses. For additional information,
554 please visit http://postmaster.info.aol.com.

According to RFC 821 (sections 4.3 and 4.2.2), the server can respond to new connections in with a 220 ("let's dance") or a 421 ("go away, I have a headache") response. Not a 554 ("you're lousy in bed") code. Among other things, the manner in which they reject mail from residential IPs causes it to languish in the queue, rather than bouncing as it should if they intend to permanently refuse delivery.

I'm sure they do this intentionally so that it will look like your mail server is at fault ("sorry, couldn't get through") rather than theirs ("buzz off, I don't like your IP address").

I hear you and agree. OTOH, I'm not so sure trademarking is going to help prevent frivolous suits either.

One way to convince a judge, if you had to, would be with a demonstration. Set up a quickie sendmail server on a laptop and telnet to port 25 from another. Type in a simple RFC 821 conversation with incorrect from: and to: info and then show him how it looks in the receiving client. Also give him a copy of RFC 821.

You are overestimating the power of the routing equipment that ISPs have deployed. Filtering is not as easy as you might think. There is *significant* performance impacts depending on platform, vendor and even software release. If you're too dumb to operate your machine securely, don't connect it to the network. Period. I work for an ISP that operates an international network, the only network-wide filters that have lived for more than a few hours are the ms-sql slammer ones, and we had zero customer complaints. There is a *lot* of legit tcp/135 and tcp/445 activity out there, so we can't do this for you all. Plus the vendors don't provide good ways to put filtering on all the interfaces or automatically push these things out to hundreds (or thousands) of routers with ease. This is one reason I (and others have looked at) some automated protocol to push out such filters and updates. If you're interested and so inclined, please check this out.

The MSN Messenger protocol tried to get opened a long, long, time ago, when Microsoft was trying to make it the big standardised open standard (i.e. around the time AOL was being reamed in court for being proprietary about this sort of thing)

http://www.abraxis.co.uk/draft-movva-msn-messenger -protocol-00.txt

This was because of involvement with these guys:

http://www.ietf.org/html.charters/impp-charter.htm l

But they took a slightly different direction.

Of course it lapsed and the spec for the current protocol additions is hidden, but then it's a fairly plaintext protocol, uses XML & HTTP for auxiliary functions, so it's nothing you can't find out with Ethereal.

One thing I am wondering, though, is MSNP9 SSL for logins only, or is it SSL for the entire protocol? It will definitely be nice not to have some bastard snooping on my Messenger traffic if the latter is true, and it certainly doesn't stop people from snooping the traffic on a legitimate connection (i.e. Gaim connects, logs in, dumps all protocol traffic to a file so people can look at it..)

Ah well.

Oh.... I've always wanted to meet someone that's had a successful CPIP implementation that's rfc 1149 compliant..... Maybe we should all get duck calls and have a duck naming service to make sure the pigeons know which duck to follow. Next thing you know the DNS will do round robin going duck duck goose until you're crazy as a loon.

Dammit.. too many bird jokes.. I know I'm running afowl of the etiquette.. Hell with it, I'm not chicken.
-B

Indeed! It's a constant source of annoyance for me that no Linux software implements RFC 3512. We really need an evil bit.

169.254.0.0/16 - This is the "link local" block. It is allocated for communication between hosts on a single link. Hosts obtain these addresses by auto-configuration, such as when a DHCP server may not be found.

More information here

Well of course the article's slashdotted right now so I can't RTFA, but I wonder how the quality of the randomness from this thing compares to, for example, thermal noise from a sound digitizer such as many computers have built into them.

RFC 1750, "Randomness Recommendations for Security", has some interesting info on randomness. Regarding reading your mic port for random numbers it says,

Combining this with compression to de-skew one can, in UNIXese,
generate a huge amount of medium quality random data by doing

cat /dev/audio | compress - >random-bits-file

The benefit of doing this of course is that many (most?) computers already have a mic port.

Anyone know if this technique is in wide use already? If not, why not?

* A. Hitchcock, p.235, April 2003, Journal of Avian Protocol Experimenters.

I request that the next feature to develop is an option where you just wave or shake the miniCD at the computer to remedy any problems. This would alleviate the hassle of putting the miniCD into the tray and running it.

Sounds like a great Open Source project to make your fame with. Please make it RFC 2321 compliant.

Standards are very important, after all.

The chip in the doll was pretty much unusable, so we bypassed it (I prefer the word upgrade) to be able to do the new sounds. The bonus was having it so we retained the original Bob personality for when the PHB wanted it, and making it turn Evil when the rest of us had him.

Now you just need to make it switch automatically...maybe RFC 3514 support would be useful here.

2) A way of verifying what e-mail addresses & domains are allowed on outgoing e-mails from said mail sever. That would be new, but should be easy to develop.

There is a proposal for this, which was covered here a while back. I like the idea, although it's going to mean more ISPs will have to offer authenticated SMTP relays for roaming users (not exactly a bad thing, in any case).

Also, to those people saying Bayesian filtering is so great, this doesn't solve my problems. To filter a message on content means I have to accept the damned thing first, and I don't know about anyone else but my inbound traffic costs me money. If I accepted every piece of mail destined for my server, the costs would have me off the net in no time - I have a pretty low-budget operation. Blacklisting servers and not accepting connections from them (and accepting the collateral damage) is the only practical option I have.

This is a rather silly article. If you want to create a new protocol - do it. If you want to create an RFC - do it. The IETF publishes instructions on the steps that must be followed to create an RFC - see RFC 2418. There is nothing stopping you and you don't need Slashdot approval to accomplish it.

Go to the ietf's application protocol division, and request a working group be formed. I'm pretty sure they'd be willing to let you form one. And i'm also pretty sure that alot of people would be interested. Or if you prefer; form an ID and submit it for approval. I personally prefer the working group approach, because it may take a bit longer, but allows for a broader range of input.

Hey, you think that's latency, consider people forced to use this protocol.

Sorry, djrogers, but you're incorrect, and the origninal corrector is accurate. See RFC 1918, Section 3.

Maybe it's not your day that's slow, but your brain! heh heh :)

Before programming, thinking has a proven effect on the outcome of your endavour. I have programmed computers for about half my life (started at 15 and turned 31 last year), and thinking seems paramount when considering what to do before actually coding. It is amazing to see how many forget this basic rule of thumb.

Next, read books and standards . Not knowing that your problem has been (partly) solved already or can be solved better is a sure path to theeth-grinding reinventions of the wheel.

Then, when you're really set to start coding (after thinking for half a day, reading a book and three standards), eat. Real food.

"Kroupware and the others are nice. But what we really need is for CALSCH to finish with CAP . As you can see CAP is on it's tenth public revision."

What I see is you're way behind. February 2003 and here we are four month's later. Hopefully this "standard" is XML based.

"James needs IMAP and CAP support. And then we will have a decent shot at the less entrenched sector of the exchanges market."

I'm certain there's java code floating around on the net, that can be integrated to give IMAP. CAP is a maybe, I don't know enough about it, but it shouldn't be an onerous burdon to put this in as well. And is there really any such thing as a "less entrenched" exchange market?

"Kroupware and the others are nice. But what we really need is for CALSCH to finish with CAP . As you can see CAP is on it's tenth public revision."

What I see is you're way behind. February 2003 and here we are four month's later. Hopefully this "standard" is XML based.

"James needs IMAP and CAP support. And then we will have a decent shot at the less entrenched sector of the exchanges market."

I'm certain there's java code floating around on the net, that can be integrated to give IMAP. CAP is a maybe, I don't know enough about it, but it shouldn't be an onerous burdon to put this in as well. And is there really any such thing as a "less entrenched" exchange market?

Kroupware and the others are nice. But what we really need is for CALSCH http://www.ietf.org/html.charters/calsch-charter.h tml to finish with CAP http://www.ietf.org/internet-drafts/draft-ietf-cal sch-cap-10.txt . As you can see CAP is on it's tenth public revision.

We need a standard that specifies the transport of the calendar protocol, badly. We need CAP finished.

The special folder in IMAP scheme will work. But is a little on the hackish side, and incompartibility between servers is a serious problem, even with standard formats, like iCal based schemes.

Next we need a cross platform messaging server. Although, it does not support IMAP as yet, Apache James is my favorite, at http://james.apache.org. First of all it has a strong group endorsing it, the Apache group. That's going to be important for selling this thing to risk-adverse corporate types. Second, it's Java, so I trust it a little more in the buffer-overflow department. Also it would probably integrate nicely in current J2EE setups. I've heard people are doing this.

James needs IMAP and CAP support. And then we will have a decent shot at the less entrenched sector of the exchanges market.

Kroupware and the others are nice. But what we really need is for CALSCH http://www.ietf.org/html.charters/calsch-charter.h tml to finish with CAP http://www.ietf.org/internet-drafts/draft-ietf-cal sch-cap-10.txt . As you can see CAP is on it's tenth public revision.

We need a standard that specifies the transport of the calendar protocol, badly. We need CAP finished.

The special folder in IMAP scheme will work. But is a little on the hackish side, and incompartibility between servers is a serious problem, even with standard formats, like iCal based schemes.

Next we need a cross platform messaging server. Although, it does not support IMAP as yet, Apache James is my favorite, at http://james.apache.org. First of all it has a strong group endorsing it, the Apache group. That's going to be important for selling this thing to risk-adverse corporate types. Second, it's Java, so I trust it a little more in the buffer-overflow department. Also it would probably integrate nicely in current J2EE setups. I've heard people are doing this.

James needs IMAP and CAP support. And then we will have a decent shot at the less entrenched sector of the exchanges market.

Three years ago when the IETF met in London (UK), the crypto geeks took a little excursion north on a train to Bletchley Park. It was good fun to visit, particularly in that company. There is also a small computer museum there, too.

For those of you who are in/around Europe, I recommend it.

-Erik

okay, but i'm still left with questions. note these are not snide critisism cause I'm ignorant. I just want to understand.

why cant you just connect to the work mailhost or to comcasts mail host.

what has sending your e-mail out directly bought you?

And what does mobility have to do with anything here. that is, cant you see the comcast mailhost from anywhere and access it via an smtp connection that uses a password even if its not on their net?

if not then, mail programs (like mail.app) are happy to let you select the outgoing mail server so again its no big deal to switch from one to the other when at work/home. Am I missing something?

and finally my comapny recently started blocking port 110 connection FROM mailhosts outside the local network. thus you can only get mail sent to you through the companies mailhost. (they did this to force all e-mail to go through a virus sniffer on their host). Would this cause problems for sendmail?

yes I realize its outgoing but presumably it also gets info sent back regarding the success of the mail delivery.

This is why I always suggest alternatives to Cisco such as IP over Avian and actual implementaion on Linux

Rus

I've always preferred CHAOSnet over RFC1149

What's next? TCP/IP over carrier pigeons?

+++ATH0

NO CARRIER