Slashdot Mirror

The IETF's SIP / SIMPLE protocol work may be more important, depending on which press release you read about whether AOL is cooperating with them this month. Instant messaging systems and voice-over-IP systems both need to solve the problem of finding users who are connected (typically using a presence server of some kind) and also communicating between the endpoints (typically directly, but potentially through a relay.) The SIMPLE project proposes some extentions to SIP, which means that integration between instant messaging systems and VOIP become easier (because you can reuse code and also reuse management systems.)

RTSP and RTP are open protocols; did you try reading this and this?

RTSP and RTP are open protocols; did you try reading this and this?

The Web is a shared information space; GET is its designated means of making a safe, side-effect free request for retrieving a represntation of a resource.

This isn't debatable; it's enshrined in the protocol --

9.1.1 Safe Methods

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".

15.2 Attacks Based On File and Path Names

Implementations of HTTP origin servers SHOULD be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators.

and by the W3C's Architectural Principles of the World Wide Web (in progress) --

Representation retrieval is safe: Agents do not incur obligations by retrieving a representation.

Reuters did nothing wrong, because it isn't the act of linking to an object that makes it available on the Web (and doing so is still, in most reasonable people's minds, protected; see the deep linking issue). Rather, it's the act of, well, making it available, by exposing an interface that understands GET and other HTTP methods as appropriate.

After all, a protocol is, in a very real sense, a contract. If they had wanted to make the resource available but restrict access to it, they could have used HTTP authentication or even cookie authentication; in either case, they have control over who gets an authentication token. GETing a URI is not illegally obtaining access, because a URI in the request-line is an identifier, nothing else.

It's very likely that the publishers were using software that they didn't understand fully, and that is poorly designed, by making assumptions about the nature of the Web and how resources on it are accessed (i.e., "people only use browsers to navigate the Web").

• Be careful what you wish for with MPEG-4, however...
• I share your desire for RTSP world domination :)
• We will be announcing new terms for RealAudio and RealVideo in our October 29 webcast. However, I wouldn't get too excited about some of the possible applications you mention (sorry, I can't be any more specific than that for now). The bottom line is that RealAudio and RealVideo will not be available under the RPSL. I know from talking to Richard Stallman about that that he's not pleased with that. However, he was pleased to hear about our support for Ogg Vorbis (which is progressing nicely).
• There are benefits to us not giving away everything. The biggest benefit is that RealNetworks stays motivated to invest heavily in this technology. Because we've got a clear commercial motivation to stay ahead on the technology curve, we're not going to merely lob this over to the open source community and say "here, you deal with it". We absolutely intend to ensure the Helix media engine remains state-of-the-art. (Of course, don't take this to mean that we don't need the community; we do.)

Rob Lanphier
Helix Community Coordinator

look at me i'm karma whoring... no really I'm ANON...

this is an opportunity to get someone on slashdot to TALK ABOUT SOMETHING FSCKING USEFUL

why has NOONE mentioned ICMP traceback or the itrace project???

that combined with some well placed Layer-2 shunning would shut down DDoS!

props to Bill Stewart for not being brain-dead

Funny this should come up; I was just reading RFC 1 this morning (read it; it's cool), and they mentioned the Lincoln Wand. "What's that?!", I asks myself; so I looked it up. 1966, guys.

I think this may set a new record for Slashdot missing the boat.

In general, it is a difficult problem to say "we need to be HIPAA-compliant". It generally needs to break down to finding all of the points where healthcare information flows outside the organization, and then protecting that information.

From the standpoint of email, there was a great amount of effort put into this in 2001. Check out this press release which summarizes the effort. Basically, there was a group of email vendors led by the Massachusetts Health Data Consortium (MHDC) that got together and standardized a method of doing server to server encryption of email. This effort is currently an Internet Draft, draft-ramsdell-enc-smime-gateway, and it will actually be moved to the IETF-SMIME working group in time for the next meeting. It is basically a profile of the DOMSEC effort, which is in turn a profile of S/MIME. I participated in this effort on behalf of Tumbleweed, and at the end of it all, the products were all working together, and I am a co-author and editor of the draft.

The bottom line is that there exist commercially available solutions from multiple vendors which satisfy the HIPAA requirements for secure email, which is most likely a large part of your charge. These products are generally usable in a "gateway" configuration where they can be placed next to an existing mail server to automatically encrypt / decrypt mail according to policy. Further, this effort is being discussed and documented in the IETF so that new implementations can be created.

I tried to run a wireless network in my house for awhile, and I can tell you that unless you live in a wharehouse or have those japanese-style paper walls, wireless is worthless.
First off, 802.11b uses the 2.4 GHz band, the same as the newer wireless phones and MICROWAVE OVENS. (as well as incedental radiation from some flourescent lights). 2.4 GHz is also the approximate resonating frequency of water molecules (hence its utilization in microwave ovens)so high humidity, waterpipes, and PEOPLE between the antennas tend to f0x0r up the reception.
I dropped WAAY too much money on a Linksys setup, and I hated it. Even with the newest drivers and hardware flash updates it was almost impossible to get the damn thing to transmit through more than one exterior wall or 2 interior walls. And even when I could make it work I got slower transfer rates than RFC1149.
Two tech calls to Linksys (at 45 min apice)later I finally broke down and dropped cat5. (I also learned that Linksys considers 802.11b to be a "Line of Sight" protocol.)
I faced similar restrictions in hole-drilling, but generally, with a little work (and a little sense) one can overcome such restrictions. Check your phone and cable drops. These do not have to be stapled in to meet code, so you can tag a picec of cat5 on and just pull it through into either your attic or crawlspace and BAM! You could even spring for those cool Leviton integrated faceplates and jack phone and data out on the same plate. Same goes for cable.
Or, as a last resort, talk to your landlord, tell him you'll pay to add value to his property. They like that.
If you absolutley MUST go wireless, though, hit wirelessanarchy.com. The pringles can antenna works pretty well sometimes. But Linksys uses proprietary antenna connectors-- gender inverted TNC and SMA connectors. Theyre a bitch to get a hold of.

Here's the rfc:

http://www.ietf.org/rfc/rfc1149.txt?number=1149

IPoAC (IP over avian carriers)

That would be RFC1149, right?

Before this, they were using carrier pigeon to transmit email. Just establishing a connnection to the mail server was a bitch.

There is open source code for tons of the traditionally G.7xx CODECs around. The issues many of them require licensing various peoples patents. A casual look at speex would make me think that it is quite likely to infringe someone's CELP patents. Does anyone have any thoughts on this? It's really cool to see something like speex happening but there are a few other things that you might want to think about.

Global IP Sound put out a codec for voice called iLBC. It is specifically designed to avoid infringing known patents. It's sound quality vs. packet loss is very good for IP systems. This is being standardized by the IETF. All the source code is open source and in the draft which you can find at http://www.ietf.org/internet-drafts/draft-ietf-avt -ilbc-codec-00.txt.

Sun has a free implementation of CCITT compression types G.711, G.721 and G.723 at ftp://ftp.cwi.nl/pub/audio/ccitt-adpcm.tar.gz. This is just a free implementation - it does not give you a license to the patents.

Various people including Cisco have been working with the license holders of G.729 IPR to make it available for "pre-commercial" systems, developers, and education. http://www.vovida.org/applications/downloads/G729A /

Great! This makes life much simpler.
According to the ENUM spec my new easy-to-remember all-purpose address will be:

7.2.4.8.7.5.3.2.2.6.8.8.e164.arpa

No longer will I have to use that impossible to remember email address (1st name)@(surname).org

RTP is the real-time protocol -- it's how
media streams (video, audio, etc) get
sent around UDP networks in the IETF
view of the world. See:

http://www.ietf.org/html.charters/avt-charter.html

RTP scales upwards OK in bandwidth --
there are uncompressed SMPTE packetizations
for HDTV in progress, which is a fair number
of bits moving through the pipe. The
advantage of designing to RTP (as an industry,
if not for your current prototype project) is
that an IF stream is a media stream, and so
a lot of the associated tools RTP offers are
a perfect fit (session management tools,
security tools, etc). So, the standards
writing job in minimized to just the basics
needed to describe the radio-specific stuff.

i know that it isn't ieee 1394, but if you want SAN capability hosted by an off the shelf linux box, you may want to take a look at some early implementations of the draft iSCSI spec. basically, it'll let you present scsi devices over IP, giving you a SAN over any IP network (preventing you from dropping $$$ on fibre channel infrastructure).
--------

but since they are modular, we could also use them for traditional pgp style encryption, no? instead of symmetric keys, you could use a public key.

SSL and PGP (or preferrably the newer OpenPGP) standard both use a hybrid scheme which uses both asymmetric and symmetric encryption algorithms.

If you mean could elliptic curves schemes (ECDLP, ECDSA, ECDH) be used in OpenPGP as well as SSL/TLS; then yes as long as it was added to the OpenPGP standards which I don't think includes ECC yet but has spaces reserved for future ECC use.

Again, if some type of security is added (like WEP), then proactive measures have to be taken to "break in"--much like building an RF scanning device would be the proactive measure that you would have to take to disarm the car alarm in you example.

Then tell him to do some research on SMB URL's. There's an IETF Draft here: http://search.ietf.org/internet-drafts/draft-crher tel-smb-url-03.txt. It's:

smb://dom;user:pass@server/path/to/file

and

smb://workgoup

not:

smb:/workgroup/server/path/share

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

what clients would actually need to support this for it to become really standard ?

Outlook (express)
Eudora
Lotus Notes

I cant think of any more really can you ?

regards

John Jones

2664

A TCP implementation that generates initial sequence numbers using a trivial time dependency may be secure against sequence number guessing attacks if it implements RFC 1948.

The idea is to add a bias to the sequence numbers that depends on the source address. A client will be able to predict his own sequence numbers but not the sequence numbers of others. The bias is calculated using a cryptographic hash of the connection ID and a secret value.

A TCP implementation that uses RFC 1948 may still get a very poor rating for initial sequence number predictability from tools like nmap.

Does anyone know any TCP stack that actually implements it?

Mozilla still doesn't seem to have the incremental layout capabilities of Netscape 0.9

"incremental layout" depends a lot on the HTML complexity and the HTML author. you need to define the sizes of layout objects before you can lay out things past them. the IMG WIDTH and HEIGHT tags introduced by netscape helped this a lot, where you can say "hey, I'm blocked on getting this image, but I know what size it will be, so let me render the stuff after it and I'll worry about putting the image in later". Tables and CSS add to the complexity of determining sizes. You never really know the size of a table until after you read the trailing TABLE tag and you may even need to know the sizes of multiple elements inside the table until you load them, so you essentially have to grabthe whole table before you can show anything inside. The state of HTML at the time of Netscape .9 was nothing like it is now, probably at least an order of magnitude simpler. Compare the First early specs of HTML with HTML 4 and that doesn't even include CSS. HTML 2 (which your comparison browser couldn't even render because it was too complex) is a 77 page spec, HTML 4.0 (linked above) is close to 286 pages.

making as many connections as you wanted (later capped at 20)
It still does this, defaulted at 4. You can change this in user.js, it's just not a pref you can see in the UI anymore because folks abused it too much, and there definitely is a diminishing returns thing, and mostly - you just don't need to change it. HTTP 1.1 also lessens the need for this, drastically reducing the overhead for small objects, where socket start and teardown time is a much more significant part of the overall time.

These days the thing will freeze as it loads some plugin or other, maybe this is somehow harder than images
This is harder, and the memory requirements are huge. You're loadoing a bunch of new code, having to dynamically link stuff all over the palce, establish communication links, allocate memory, a nuch of stuff. The image library is already loaded, and showing an image takes a lot less memory than say, showing a 10 meg shockwave game.

It's hard to make comparisons now, since our browsers are required to do so much more. I tried to look at some old browsers just for the hell of it, and I couldn't even get NCSA Mosaic to run, just blew up on me.

maybe this will help:
(and yes it's blatant googled karma whoring)

icalendar mailing list page
IETF iicalendar working group site

remo

iCal uses an industry-standard iCalendar (.ics) specification. This is a text file that can be easily shared on the Internet. For more information on the iCalendar format, see http://www.imc.org/pdi/ or RFC2445. So yes, it's documented rather well and is far from a proprietary thing, you can relatively easily setup your own .mac iCal style server :)

Does anybody know if this format is used somewhere else or even documented?

Uhhh... you mean vCalendar? Yeah, I think I saw some somewhere.

Does anybody know if this format is used somewhere else or even documented?

Uhhh... you mean vCalendar? Yeah, I think I saw some somewhere.

Does anybody know if this format is used somewhere else or even documented?

Uhhh... you mean vCalendar? Yeah, I think I saw some somewhere.

The Enum initiative. I refer you to this IETF page and also this article on Enum in NetworkWorldFusion.

Anna B

Jabber Inc. does not have "patents on stuff you need to implement Jabber"

Check the minutes of the Jabber BOF held at the IETF in Yokohama: "[P]ortions of the Jabber, Inc., implementation have IPR protection, but there are at least two commercial XMPP implementations from other companies, and the Jabber, Inc. lawyers aren't suing them."

And that was from a member of Jabber, Inc's Senior Management Team (Joe Hildebrand). Not actually being with Jabber, Inc anymore, do you think you know better than their management team what IPR they hold, Peter?

No, I didn't think so.

Read this and come back if you need help.

--

Apple has proposed Zeroconf has an internet standard. It's still only in draft form: http://www.zeroconf.org/

If you're pushing for an Internet standard, it certainly helps to have an open source implementation of the standard. Check out the RFC describing the Internet Standards Process. You'll note that a proposed standard: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable.

This doesn't state that you have to release open source, but it helps the case when you want to can get other people to look at your code and see what you've done.

Also note that a draft standard requires: A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. Yes, they are independent implementations, but it can help other people develop theirs if they can see your source code. When my implementation doesn't interoperate with Apple's, I can actually figure out why, and whose fault it is.

So yes, releasing the source code is good if Apple wants this to become a standard.

-alain

Funny, any link for the draft you might find refers to draft-ietf-zeroconf-reqts-10.txt which just doesn't exist on the ietf site. So being real clever I flipped that 10 to an 11 and behold theres a new version dated the 26th.

http://www.ietf.org/internet-drafts/draft-ietf-zer oconf-reqts-11.txt

Mod parent up! The reason that the recent IE certificate bug exists at all is that they don't follow the standard.
A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize
IE does not process the critical basicConstraints extension (as well as others) and still accepts the certificate. Netscape (even back to version 4) will reject a critical extension that it does not recognize.

Uh, dude... you do know that PigeonRank was an April Fools joke.

Please tell me you know that.

The exchange cited shows that Linux gods are no different from other humans....
The DNS is good at looking up strings. It's a lousy search engine.
The idea that one should try to "control" a name in all domains is silly - but happened BECAUSE people tried DNS as a search engine.
Personally, I type names into Google when I want to look them up, not my browser bar.
There are other angles of attack - see draft-klensin-dns-search, for instance - but currently that works.
AND Google gives me enough context to show me WHAT kind of "good vibrations" I'm headed for....

Untill there is a standard calendar protocol, and that protocol is supported by exchange, you won't be able to get rid of it.

What ever happened to iCalendar, sometimes known as vCalendar?

Aren't there any LDAP-based solutions or proposals?

Instead of going to the expense of laying a few thousand miles of fibre, why not just adapt RFC 1149 to the local conditions? In addition to a huge cost-saving, it's a Linux friendly solution!

The largest contibution to latency is the encoding and decoding codecs -- that is, the translation from an audible analog signal to a digital signal and back again. The more compression that is desired, the longer this takes. The actual transmission over a network -- using UDP or anything else -- is negligable and has little to do with the packets being UDP or old-world "TDM" voice.

Of course, those UDP packets (the VoIP traffic) can be prioritized over non-VoIP traffic, if the routers support such prioritization and there is a way to mark high-priority packets. DIFFSERV is one such mechanism to do this.

Be a good test for RFC1149 and RFC2549!!

Be a good test for RFC1149 and RFC2549!!

there is a RFC on OpenPGP

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

I wonder if they will follow it or just pay themselves out of the 15million they got
(the RFC is explained here )

I just hope they do the decent thing

regards

John Jones

(yes I know its a repost but I could not see it with my GF's threshold)

there is a RFC on OpenPGP

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

I wonder if they will follow it or just pay themselves out of the 15million they got
(the RFC is explained here )

I just hope they do the decent thing

regards

John Jones

(yes I know its a repost but I could not see it with my GF's threshold)

there is a RFC on OpenPGP

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

I wonder if they will follow it or just pay themselves out of the 15million they got
(the RFC is explained here )

I just hope they do the decent thing

regards

John Jones

there is a RFC on OpenPGP

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

I wonder if they will follow it or just pay themselves out of the 15million they got
(the RFC is explained here )

I just hope they do the decent thing

regards

John Jones

The current laws do not protect security or privacy...

Well, there is a flaw in the laws regarding IP networks.

...nor do they allow law enforcement access for wiretaps

Again, I'd say this is a flaw in the law.

The article points out that older analog telephone lines are covered by laws that prevent people from tapping the lines unless it is someone with the authority and authorization to do so. The article makes it look like the laws regarding VoIP are less advanced, and desperately need updated.

Legal things aside, I would have thought that by now, in this day and age, people would consider security when providing a new service that runs over a computer network. I'm dissapointed in the comapnies who have disregarded security here.

Is there no easy way to make it all tunnel through SSH?

Many of the current VoIP deployments today are not using the security features that you might expect to see. In large, this is because the standard itself is maturing and the manner in which security will be implemented is still under investigation. In the case of SIP, the article points out that although the payload (voice) might be encrypted, the signalling isn't. This is not entirely true. One thing that SIP permits is to tunnel SIP as a payload within SIP. The external session serves only as a routing mechanism for the fully encrypted 'real' signaling session contained within. These mechanisms are just completing peer review and implementors are just wrapping their heads around it all. One thing is for sure; unlike protocols that have preceeded them, SIP and it's designers are taking security very seriously. How else could they consider using SIP as an integral part of 3GPP and/or it's use for inter-carrier peering.

Sure, the protocol itself may have exposure issues, and problems with NAT/PAT devices, but there are companies on the market that are addressing these issues as they arise.

Informational 1xx
100 Continue
101 Switching Protocols
Successful 2xx
200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content
Redirection 3xx
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
306 (Unused)
307 Temporary Redirect
Client Error 4xx
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
Server Error 5xx
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported

The abstract of the paper suggests that the attacks largely fail when the data is compressed before encryption. From the GNU Privacy Guard manpage of version 1.0.7, the default is to use RFC1950 compression (which is ZLIB compressed data format) and the default compression level of the zlib library (normally 6). Note that all this applies to GNU Privacy Guard 1.0.7. According to the same manpage, the NAI PGP implementation uses RFC1951 compression, which is the DEFLATE compressed data format.

The abstract of the paper suggests that the attacks largely fail when the data is compressed before encryption. From the GNU Privacy Guard manpage of version 1.0.7, the default is to use RFC1950 compression (which is ZLIB compressed data format) and the default compression level of the zlib library (normally 6). Note that all this applies to GNU Privacy Guard 1.0.7. According to the same manpage, the NAI PGP implementation uses RFC1951 compression, which is the DEFLATE compressed data format.