mfnx
Anyone from mfn around can you contact me off list? Thanks! Scott
Re: VoIP over IPsec
On Tue, 18 Feb 2003, Stephen Sprunk wrote: > > It also allows precomputation of the key stream, adding nearly zero > > latency/jitter to the actual packet processing. > > You fail to note that this requires precomputing and storing a keystream for > every SA on the encrypting device, which often number in the thousands. > This isn't feasible in a software implementation, and it's unnecessary in > hardware. You don' have to store the entire keystream, just enough to allow on-the-fly packet processing. Besides, memory is cheap. 100 msec buffers for 100,000 simultaneous voice connections is an astonishing 80 Mb. More realistically, it's 10k calls and 30 msec of buffering. --vadim
225 Broadway
We are interested in colocating/peering with people at 225 Broadway in San Diego. Please contact me off-list. Thanks. Steve Rude
Re: VoIP over IPsec
On Tue, 18 Feb 2003, Stephen Sprunk wrote: > > In fact, a method to encrypt small parcels of data efficiently is > > well-known for decades. It is called "stream cypher" (surprise). > > Besides LFSR-based and other stream cyphers, any block cypher > > can be used in this mode. Its application to RTP is trivial and > > straight-forward. Just leave sequence number in clear text, so that > > position in the stream is recoverable in case of packet loss. > Most stream modes are chained in some way to intentionally disrupt > decryption if part of the ciphertext is missing; That would be CBC mode (where the output of one block becomes part of the input for the next) and I don't think this effect is a feature. At least, certainly not a desirable one because now we need a relatively large initialization vector in each encrypted packet. (It would of course be possible to negotiate some random data in advance from which the IVs can be taken in a way that is linked to the counter so the IV doesn't have to be included in the packet.) A stream cipher generates a random-looking data stream against which the payload is XORed. If you miss some payload you can still generate the data stream for the missing part and start XORing again for the data you have, as long as you exactly know how much is missing. This would be trivial to implement in IPsec with a fixed packet length because the anti-replay counter tells you the number of packets that were transmitted in the clear.
RE: OC3 to DS3 mux ?
This may help you, though I'm not sure what interface you're in need of: http://catalog.radusa.com/radinc/datasheets/amc-101.pdf > -Original Message- > From: joe mcguckin [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 14, 2003 9:10 PM > To: [EMAIL PROTECTED] > Subject: OC3 to DS3 mux ? > > > > Can someone recommend a vendor for an OC3 to DS3 DACS or mux? > I need a small one with capacity for a single OC3. > > Thanks, > > Joe > IMPORTANT:The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Re: VoIP over IPsec
> > On Crisco, if memory serves, default payload is 160 for G.711, not 40. The > sizing goes in multiples of 80s. > The increments go in 10ms. Default being 20ms or 30ms depending on your codec. Resulting data size obviously depends on this parameter and the codec. Quite many people compress their VoIP. (resulting in smaller payload) Pete
Re: VoIP over IPsec
Thus spake "Vadim Antonov" <[EMAIL PROTECTED]> > In fact, a method to encrypt small parcels of data efficiently is > well-known for decades. It is called "stream cypher" (surprise). > Besides LFSR-based and other stream cyphers, any block cypher > can be used in this mode. Its application to RTP is trivial and > straight-forward. Just leave sequence number in clear text, so that > position in the stream is recoverable in case of packet loss. Most stream modes are chained in some way to intentionally disrupt decryption if part of the ciphertext is missing; that is why IPsec resets the stream for each packet (currently). When NIST was standardizing AES, they added CTR mode specifically to address IPsec implementations. I think there's already been a draft out of the IRTF on how to modify IPsec for this, but it's not something I've followed closely. > It also allows precomputation of the key stream, adding nearly zero > latency/jitter to the actual packet processing. You fail to note that this requires precomputing and storing a keystream for every SA on the encrypting device, which often number in the thousands. This isn't feasible in a software implementation, and it's unnecessary in hardware. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking
RE: VoIP over IPsec
On Tue, 18 Feb 2003, Petri Helenius wrote: > > Maybe a stupid question... why would you need GRE tunneling while IPsec > > has a tunnel mode of its own? > Probably because a major router vendor, despite of repeated customer requests, > declined to implement routing across such tunnel mode. > So if the router uses tunnel mode (as per the RFC) despite the GRE > tunnel the packet has three IP headers... So that's 160 bits ethernet > layer 1 + 18 bytes ethernet layer 2 overhead, 24 bytes for the GRE > tunnel, 20 bytes for the IPsec tunnel mode IP header, 10 - 12 bytes for > the ESP header, 16 bytes for the initialization vector, 20 bytes for the > original IP header and finally 20 bytes for the RTP header. With a 40 > byte payload that adds up to 188 bytes on the wire of which 78% is > overhead... --- On Crisco, if memory serves, default payload is 160 for G.711, not 40. The sizing goes in multiples of 80s. Thanks, Christian * "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers."
RE: VoIP over IPsec
Well, sloppy thinking breeds complexity -- what I dislike about standards commitees (IETF/IESG included) is that they always sink to the lowest common denominator of the design talent or competence of its participants. In fact, a method to encrypt small parcels of data efficiently is well-known for decades. It is called "stream cypher" (surprise). Besides LFSR-based and other stream cyphers, any block cypher can be used in this mode. Its application to RTP is trivial and straight-forward. Just leave sequence number in clear text, so that position in the stream is recoverable in case of packet loss. It also allows precomputation of the key stream, adding nearly zero latency/jitter to the actual packet processing. --vadim On Wed, 19 Feb 2003, David Luyer wrote: > ...leaving a dream of RTP as true and presumably light-weight > protocol...
RE: VoIP over IPsec
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Comments inline: > At 01:34 PM 2/17/2003 -0500, Charles Youse wrote: > > >So do you suppose that in my scenario, I'd be better off > leaving the VoIP out > >of the encrypted tunnels and use a separate [cleartext] path > for them? > > Oh goodness no. VoIP (SIP specifically) has no real security > in it. Call > hijacking for example is a matter of sending a pair of > spoofed UDP packets to > each phone and having the voice streams arrive at the > attackers machine. Not > pretty, and I do this trick (and worse) daily. (in a lab as > part of work of > course) What about sips:/TLS, S/MIME, and digest auth? These are all integral to the 'standard', and many popular implementations support these facilities currently. IPSec may be less painful within a single domain, but in other cases, I'd think that these facilities (or their derivatives) are the only practical option for 'real' security. Granted it is all pretty worthless if you dont enable/use any of it... Am I missing something? Regards, Andrew Bender taqua.com
RE: IPv6 Peering Request
Thank you for the offer! I have checked the path to your site and while it is a decent path, it is over the pacific which is too far net-wise for us. All the same, I appreciate the offer! Regards, Jeff > -Original Message- > From: Ethern Lin [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 17, 2003 9:26 PM > To: Jeffrey Wheat; [EMAIL PROTECTED] > Subject: Re: IPv6 Peering Request > > > Dear Jeffery, > > We would like to provide a BGP tunnel for your site, and > here is the IPv4 address of tunnel end: 140.109.1.6. > I suggest that you can test the route quality, and if the > result fit your needs, you can send me a mail and I can create a > tunnel for you. > > We are the pTLA: > ASNET/TW3FFE:4001::/32 > > best regards, > > Ethern > ASCC/TW > > - Original Message - > From: "Jeffrey Wheat" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, February 15, 2003 2:17 AM > Subject: IPv6 Peering Request > > > > > > Is there anyone that would be interested in providing a > tunnel to the > > 6bone for us? We are in Charlotte, NC and would prefer to > establish a > > tunnel with someone close by. We'd be doing this via a > cisco router so > > brokers are no an option for us. We are AS8175. > > > > Thanks in advance, > > Jeff > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003 > > > > > > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.455 / Virus Database: 255 - Release Date: 2/13/2003 > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.455 / Virus Database: 255 - Release Date: 2/13/2003
Network/Server integration in Manhattan
Hi We are operating some POPs in Manhattan, but we are actually based in Israel, with nobody onsite. We are looking for a company that would be able to provide installation and other "remote-hands" support at this area. Any recomendations? Arie
RE: VoIP over IPsec
Iljitsch van Beijnum wrote: > So if the router uses tunnel mode (as per the RFC) despite the GRE > tunnel the packet has three IP headers... So that's 160 bits ethernet > layer 1 + 18 bytes ethernet layer 2 overhead, 24 bytes for the GRE > tunnel, 20 bytes for the IPsec tunnel mode IP header, 10 - 12 > bytes for > the ESP header, 16 bytes for the initialization vector, 20 > bytes for the > original IP header and finally 20 bytes for the RTP header. With a 40 > byte payload that adds up to 188 bytes on the wire of which 78% is > overhead... ...leaving a dream of RTP as true and presumably light-weight protocol, as per rfc753, 759, 760, 761, 793, etc. Was this RTP the protocol under NVP (as per rfc741)? It was mentioned in documents before UDP (first mentioned in rfc755 and defined in rfc768), but I don't see any RFC ever defining it, and it doesn't have a protocol number assigned in the early assigned number RFCs (eg. rfc755, which is after UDP was conceived but before anything was removed or re-used from the early allocations). Of course that won't help the other overheads. And there's still a lot of the internet where you'd want to add cell tax then block up to the next 53 bytes... do we have 90% overhead yet? ;-) It's interesting that the original 'ST' and 'RTP' were thought of in 1979 and 1981, but it was 1990 before 'ST-II' (rfc1190) and 1996 by the time the actual RTP was formalized (rfc1889, where it is mentioned as being "typically [..] on top of UDP", but the option is left open that it could be used directly as a protocol on top of IP). I'm sure I was using (commonly available) voice over the 'net before 1996, but I think it was a horrible application which sent duplicate UDP packets in the expectation of dropped packets... probably still with less overhead than today's VoIP over GRE over IPsec over EoMPLS over ATM type designs, despite the packet duplication... David.
Re: VoIP over IPsec
On Tue, 18 Feb 2003, Petri Helenius wrote: > > Maybe a stupid question... why would you need GRE tunneling while IPsec > > has a tunnel mode of its own? > Probably because a major router vendor, despite of repeated customer requests, > declined to implement routing across such tunnel mode. So if the router uses tunnel mode (as per the RFC) despite the GRE tunnel the packet has three IP headers... So that's 160 bits ethernet layer 1 + 18 bytes ethernet layer 2 overhead, 24 bytes for the GRE tunnel, 20 bytes for the IPsec tunnel mode IP header, 10 - 12 bytes for the ESP header, 16 bytes for the initialization vector, 20 bytes for the original IP header and finally 20 bytes for the RTP header. With a 40 byte payload that adds up to 188 bytes on the wire of which 78% is overhead...
Re: VoIP over IPsec
through the corporate enterprise net, Cisco routers with IPSEC/GRE tunnels over the public Internet. Maybe a stupid question... why would you need GRE tunneling while IPsec has a tunnel mode of its own? For running routing over the tunnels for example... - kurtis -
