- Test - lists.nanog.org

RE: OC3 to DS3 mux ?
by Temkin, David 18 Feb '03

18 Feb '03

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:joe@via.net] > Sent: Friday, February 14, 2003 9:10 PM > To: nanog(a)merit.edu > 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.

1 0

RE: VoIP over IPsec
by Kuhtz, Christian 18 Feb '03

18 Feb '03

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."

2 1

RE: VoIP over IPsec
by Bender, Andrew 18 Feb '03

18 Feb '03

> -----Original Message----- > From: tedawson(a)attbi.com [mailto:tedawson@attbi.com] > > 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

1 0

RE: IPv6 Peering Request
by Jeffrey Wheat 18 Feb '03

18 Feb '03

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:ethern@ascc.net] > Sent: Monday, February 17, 2003 9:26 PM > To: Jeffrey Wheat; nanog(a)merit.edu > 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/TW 3FFE:4001::/32 > > best regards, > > Ethern > ASCC/TW > > ----- Original Message ----- > From: "Jeffrey Wheat" <jeff(a)cetlink.net> > To: <nanog(a)merit.edu> > 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

1 0

Network/Server integration in Manhattan
by Arie Vayner 18 Feb '03

18 Feb '03

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

1 0

RE: VoIP over IPsec
by tedawson＠attbi.com 17 Feb '03

17 Feb '03

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) >I'm worried about the security implications, not because I feel there is a >huge security risk but because I'm sure the topic will be brought up. >(Communicating over one provider's >backbone provides little opportunity for third parties to snoop packets >between points, of course.) See above, SIP security sucks and H323 isn't much better. >Has the issue of VoIP security ever been addressed? Not really. There are two parts to VoIP, the signalling and the bearer channel (actual RTP streams with the voice). The signalling channel is by far the easiest to abuse so if you are worried about security, go after this first. Encrypting the itty bitty RTP packets is a challenge that has yet to be entirely overcome, but encrypting the signalling is about 90% of the battle (according to me YMMV). So if you want this done without buying any new toys, and just using the Cisco's you have in place. Simply place a GRE tunnel between the two sites and just IPSec UDP port 5060 (SIP), and leave all other traffic alone (your phones are on separate subnets right???????). This will encrypt the signalling (SIP is the assumption here) but leave the RTP alone so that you dont have the jitter issues (as much at least). If you are really serious about doing VoIP then look into the products from InGate and NetRake, and others. The InGate supports NAT/PAT (which is useful since some phones basically require a public IP address UGH), but more importantly it supports TLS. This encrypts the packets, but doesn't suffer from the keying issues of IPSec nor the overhead, so tiny little SIP packets can be encrypted without wait, but I am not clear on the RTP packets (they aren't encrypted as far as I know). Plus you get a registrar, proxy, etc, etc etc server along with it. They are relatively cheap. Netrake is for carriers, but is kinda cool to look at. As far as QoS, don't worry about it unless you are short on bandwidth, and even then it doesn't seem to make much difference (in my experience YMMV). Hope this helps I speak for me and me alone. Do not hold my employer liable for my rantings.

1 0

RE: VoIP over IPsec
by Ejay Hire 17 Feb '03

17 Feb '03

More specifically, dynamic routing protocols like ospf and rip. -----Original Message----- From: Petri Helenius [mailto:pete@he.iki.fi] Sent: Monday, February 17, 2003 5:21 PM To: Iljitsch van Beijnum; Steve Feldman Cc: nanog(a)nanog.org Subject: Re: VoIP over IPsec > On Mon, 17 Feb 2003, Steve Feldman wrote: > > > 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? > Probably because a major router vendor, despite of repeated customer requests, declined to implement routing across such tunnel mode. Pete

2 1

RE: VoIP over IPsec
by Charles Youse 17 Feb '03

17 Feb '03

Because you need to use GRE to create a virtual interface on the router and thus enable the use of routing protocols. At least, that's the only way I know how to do it. C. -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Monday, February 17, 2003 6:19 PM To: Steve Feldman Cc: nanog(a)nanog.org Subject: Re: VoIP over IPsec On Mon, 17 Feb 2003, Steve Feldman wrote: > 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?

1 0

RE: VoIP over IPsec
by Ejay Hire 17 Feb '03

17 Feb '03

There is some work on the SRTP protocol, but finding a cpe that will work with it is unlikely in the near future. If you had a gateway server at each site then you might be able to use a back-to-back ua and srtp between the sites. (That sounds kludgey. -----Original Message----- From: Charles Youse [mailto:cyouse@register.com] Sent: Monday, February 17, 2003 12:34 PM To: Stephen Sprunk; Charlie Clemmer Cc: nanog(a)merit.edu Subject: RE: VoIP over IPsec 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? I'm worried about the security implications, not because I feel there is a huge security risk but because I'm sure the topic will be brought up. (Communicating over one provider's backbone provides little opportunity for third parties to snoop packets between points, of course.) Has the issue of VoIP security ever been addressed? I suppose I should really do my homework. C. -----Original Message----- From: Stephen Sprunk [mailto:stephen@sprunk.org] Sent: Monday, February 17, 2003 1:22 PM To: Charlie Clemmer Cc: nanog(a)merit.edu Subject: Re: VoIP over IPsec Thus spake "Charlie Clemmer" <cclemmer(a)nexgennetworks.com> > Stephen, I know this is outside of Charles' original inquiry, but I'm not > familiar with this "qos pre-classify" feature. Since we would be encrypting > voice traffic ... at what point would you classify it? If I classify it > before it goes into the tunnel and gets encrypted, would that > classification last once it's encrypted? If we try to classify after it's > been encrypted, how can we tell it's voice traffic? It seems to me that > jitter from both the actual encryption process as well as that associated > with basic serialization would be the potential death of VoIP in this > scenario, but I'm not sure mechanisms available to help resolve that risk. In the default IOS code path, encryption happens before QOS (and after GRE). Modern IOS versions copy the DSCP when encapsulating/ encrypting packets, so DSCP-based QOS will still work, but IP- and port-based QOS will not. More importantly, encryption is slow; even hardware encryption is significantly slower than the rest of the forwarding process. It's also FIFO by default, meaning that large data packets can get stuck ahead of your VoIP packets, causing jitter. 'qos pre-classify' adds a second QOS stage before encryption, which allows you to classify packets in their unencrypted state and, more importantly, adds PQ capability to the encryption stage. For more information: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos _c/fqcprt1/qcfvpn.htm S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking

1 0

RE: VoIP over IPsec
by Charles Youse 17 Feb '03

17 Feb '03

Using hardware encryption with the qos pre-classify feature, I imagine that jitter will no longer be an issue - (that is, the jitter you mention previously is introduced by the lack of prioritization into the encryption queue). Or am I missing something? C. -----Original Message----- From: Stephen Sprunk [mailto:stephen@sprunk.org] Sent: Monday, February 17, 2003 2:24 AM To: Charles Youse Cc: nanog(a)merit.edu Subject: Re: VoIP over IPsec Thus spake "Charles Youse" <cyouse(a)register.com> > In order to cut costs in our telecom budget I'm toying with the idea > of replacing a lot of our inter-office leased lines with VPN > connections over the public Internet. [...] > Assume for the moment that latency and bandwidth are not an issue; > e.g., any two points that will be exchanging voice data will both have > transit from the same provider with an aggressive SLA. Latency, bandwidth, and packet loss are moot. Jitter is VoIP's enemy. > Does anyone have any experience running VoIP over such tunnels? > Is there a technical reason why this solution is not feasible? Are > Cisco routers not happy doing VoIP/IPsec/GRE in concert? IPsec itself will not cause you problems; there's no theoretical conflict. Unfortunately, IOS can introduce jitter when encrypting packets. To mitigate this, you can apply QOS, with a strict priotiy queue for the VoIP packets and the "qos pre-classify" feature. Your mileage will vary depending on the CPU power of the router, the traffic levels, and whether you're using hardware encryption. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking

1 0