Re: [asterisk-users] Why Nat=yes Nat=no Option?
Actually I would nat=yes always, even if clients are not behind NAT os otherwise the clietn can put some garbage into the contact header (e.g. IP address of an upstream provider) and influence routing. The only thing were nat=yes is bad is if you have an asymmetric client. I do not know any RTP asymmetric client, but there are still SIp asymmetric clients, e.g. some Cisco phones and Cisco Gateways klaus Steve Totaro schrieb: I have done some large installs where people are going to be in the office, sometimes out, work from home, it always changes sorta thing.. I have found that setting all device profiles to Nat=yes Just Works whether they are on the LAN or not and this is even on larger scale systems with hundreds of phones. Is there any reason why this would be frowned upon as a default? Even to the point of, if nat= is not specified, it would default to yes? Is there a performance hit somewhere, or some other downside? If not, I suggest making it the default. -- Thanks, Steve Totaro +18887771888 (Toll Free) +12409381212 (Cell) +12024369784 (Skype) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
Klaus Darilion wrote: Actually I would nat=yes always, even if clients are not behind NAT os otherwise the clietn can put some garbage into the contact header (e.g. IP address of an upstream provider) and influence routing. No. There is a specific reason RFC 3261 says: Registration creates bindings in a location service for a particular domain that associates an address-of-record URI with one or more contact addresses. Thus, when a proxy for that domain receives a request whose Request-URI matches the address-of-record, the proxy will forward the request to the contact addresses registered to that address-of-record. This gives the UAC the necessary level of control to determine how it is to be contacted. Imagine, for a example, a scenario in which incoming registrations are proxied further upstream for whatever reason - load balancer/distributor perhaps? - by an intermediate element. Do you really want to use that proximate hop's received IP address in place of the ultimate sending UAC's domain? -- Alex -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
Alex Balashov wrote: Klaus Darilion wrote: Actually I would nat=yes always, even if clients are not behind NAT os otherwise the clietn can put some garbage into the contact header (e.g. IP address of an upstream provider) and influence routing. No. There is a specific reason RFC 3261 says: Registration creates bindings in a location service for a particular domain that associates an address-of-record URI with one or more contact addresses. Thus, when a proxy for that domain receives a request whose Request-URI matches the address-of-record, the proxy will forward the request to the contact addresses registered to that address-of-record. This gives the UAC the necessary level of control to determine how it is to be contacted. Imagine, for a example, a scenario in which incoming registrations are proxied further upstream for whatever reason - load balancer/distributor perhaps? - by an intermediate element. Do you really want to use that proximate hop's received IP address in place of the ultimate sending UAC's domain? In other words, there is a very specific reason why UACs are given the power to determine where and how to be contacted by the locator, depending on the application. If the UAS wishes to restrict the ability of registrants to specify a contact URI domain that does not match their received IP, or to overwrite it with something else, it can do that. Those are configuration options that can be created with Asterisk. But to enable standards-breaking behaviour by default (let alone always) is absurd; there very point of specifying a contact binding in registrations is to provide the very control and flexibility you are suggesting should be taken away. -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
On Thu, Nov 13, 2008 at 10:19 AM, Alex Balashov [EMAIL PROTECTED]wrote: Alex Balashov wrote: Klaus Darilion wrote: Actually I would nat=yes always, even if clients are not behind NAT os otherwise the clietn can put some garbage into the contact header (e.g. IP address of an upstream provider) and influence routing. No. There is a specific reason RFC 3261 says: Registration creates bindings in a location service for a particular domain that associates an address-of-record URI with one or more contact addresses. Thus, when a proxy for that domain receives a request whose Request-URI matches the address-of-record, the proxy will forward the request to the contact addresses registered to that address-of-record. This gives the UAC the necessary level of control to determine how it is to be contacted. Imagine, for a example, a scenario in which incoming registrations are proxied further upstream for whatever reason - load balancer/distributor perhaps? - by an intermediate element. Do you really want to use that proximate hop's received IP address in place of the ultimate sending UAC's domain? In other words, there is a very specific reason why UACs are given the power to determine where and how to be contacted by the locator, depending on the application. If the UAS wishes to restrict the ability of registrants to specify a contact URI domain that does not match their received IP, or to overwrite it with something else, it can do that. Those are configuration options that can be created with Asterisk. But to enable standards-breaking behaviour by default (let alone always) is absurd; there very point of specifying a contact binding in registrations is to provide the very control and flexibility you are suggesting should be taken away. -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 Alex is going to cling to to the RFC as if it were the gospel, and not look at what would essentially be a good thing. Making many NAT questions drop off IRC and and the list. Making administration and system deployments Just Work. An RFC means Request for Comment, it is not the Gospel or the Law. Here, read this link http://www.legalzoom.com/legal-articles//article13758.html Good stuff. -- Thanks, Steve Totaro +18887771888 (Toll Free) +12409381212 (Cell) +12024369784 (Skype) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
Steve Totaro wrote: Alex is going to cling to to the RFC as if it were the gospel, and not look at what would essentially be a good thing. The RFC is not the gospel, but nor is it just a request for comment, historical nomenclature aside. It is the de facto standard for the implementation of the protocol, the product of IETF working groups, various standards bodies, and private and academic industry consortia. It is essential for interoperability and is the source of the justification for the appeal to sameness in the claim that two elements or services speak the same protocol. Inconsistencies, omissions, or deviations from the standard in implementations do not materially undermine this point. Nothing is perfect, including the RFC itself, which is replete with ambiguities open to interpretation and disagreements about those interpretations. However, it does provide the anchor for essential adherence, especially when it comes to points that are spelled out clearly (i.e. the basic purpose and function of registration and contact bindings) as opposed to more marginal scenarios. Do I really have to explain why it is important to follow the RFC when implementing an IETF protocol? One thing you need to appreciate is that when you are recommending changes to default settings, you are engaging in a kind of standards work. That's because the potential implications apply to everyone. In light of that, I find it bizarre that you solicit input on your suggestion but then proceed to personally attack those who disagree, especially with arguments proceeding from standards. Making many NAT questions drop off IRC and and the list. Making administration and system deployments Just Work. More precisely, make administration and system deployments that are readily conceptualised in _your_ imagination and experience just work. The behaviour you are suggesting would break any number of other scenarios common in the engineering of VoIP service delivery platforms. You are making a claim from the standpoint of someone who goes around installing phones that transact directly with an Asterisk PBX, and you are attempting to universalise your use case as though it were cosmologically significant. That is just one of the many scenarios in which SIP is used, and certainly only one of the manifold applications of Asterisk's SIP stack, in theory and in practice. What is important to phone installers isn't what matters to others. When recommending changes to standard behaviour, you have to argue in reasonable terms and contend with valid arguments rather than just dismissing them. I suppose we should be grateful that standards bodies for the most part consist of people considerably more judicious and insightful than that. The RFC provides an architectural model for how SIP works, and if you're going to suggest changes to an implementation of that model, it's important to understand what the model actually is on a level of abstraction that may considerably surpass your narrowminded assumptions based on your own use. The world of SIP entails considerably more complexity than phones and PBXs. -- Alex -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
On Thu, Nov 13, 2008 at 12:19 PM, Alex Balashov [EMAIL PROTECTED]wrote: Steve Totaro wrote: Alex is going to cling to to the RFC as if it were the gospel, and not look at what would essentially be a good thing. The RFC is not the gospel, but nor is it just a request for comment, historical nomenclature aside. It is the de facto standard for the implementation of the protocol, the product of IETF working groups, various standards bodies, and private and academic industry consortia. It is essential for interoperability and is the source of the justification for the appeal to sameness in the claim that two elements or services speak the same protocol. Inconsistencies, omissions, or deviations from the standard in implementations do not materially undermine this point. Nothing is perfect, including the RFC itself, which is replete with ambiguities open to interpretation and disagreements about those interpretations. However, it does provide the anchor for essential adherence, especially when it comes to points that are spelled out clearly (i.e. the basic purpose and function of registration and contact bindings) as opposed to more marginal scenarios. Do I really have to explain why it is important to follow the RFC when implementing an IETF protocol? One thing you need to appreciate is that when you are recommending changes to default settings, you are engaging in a kind of standards work. That's because the potential implications apply to everyone. In light of that, I find it bizarre that you solicit input on your suggestion but then proceed to personally attack those who disagree, especially with arguments proceeding from standards. Making many NAT questions drop off IRC and and the list. Making administration and system deployments Just Work. More precisely, make administration and system deployments that are readily conceptualised in _your_ imagination and experience just work. The behaviour you are suggesting would break any number of other scenarios common in the engineering of VoIP service delivery platforms. You are making a claim from the standpoint of someone who goes around installing phones that transact directly with an Asterisk PBX, and you are attempting to universalise your use case as though it were cosmologically significant. That is just one of the many scenarios in which SIP is used, and certainly only one of the manifold applications of Asterisk's SIP stack, in theory and in practice. What is important to phone installers isn't what matters to others. When recommending changes to standard behaviour, you have to argue in reasonable terms and contend with valid arguments rather than just dismissing them. I suppose we should be grateful that standards bodies for the most part consist of people considerably more judicious and insightful than that. The RFC provides an architectural model for how SIP works, and if you're going to suggest changes to an implementation of that model, it's important to understand what the model actually is on a level of abstraction that may considerably surpass your narrowminded assumptions based on your own use. The world of SIP entails considerably more complexity than phones and PBXs. What is Asterisk designed to be? A PBX. (yes that is a period) -- Alex -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 Yes, if I want to read a book, I do, this is a mailing list so I really didn't read much of what you said above, if you cannot get to the point in a few lines within a few paragraphs, you are wasting my time Not sure why you feel like you need to correct me so badly or Who I have attacked? I take exception to this statement. That is the only clarification I request from you, no book needed. Sounds personal, let it go, it failed, but I washed my hands of it long ago. -- Thanks, Steve Totaro +18887771888 (Toll Free) +12409381212 (Cell) +12024369784 (Skype) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
You're right, all that verbose book-learnin' and complex protocol implementations definitely don't belong together. Steve Totaro wrote: What is Asterisk designed to be? A PBX. (yes that is a period) That question will fetch many answers depending on who you're talking to. It is used for a great many things in larger systems. I think you know that. But, even assuming a straightforward PBX application is all it's good for, it still participates in the model outlined by the RFC. So, once again, it's important to understand the model holistically before you change how and when it's followed. I have a customer who uses Asterisk as a PBX but with an outboard registrar. Your recommended behaviour would break the platform unless they took the time to school themselves on the 'nat' option, why Asterisk does funky and nonstandard things with peer reachability by default, and changed all their peers to nat=no. People use Asterisk's SIP stack because it's a SIP stack out of the box, not a convenient-for-Steve-out-of-the-box or tailored-to-Alex-out-of-the-box stack. -- Alex -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
Alex Balashov schrieb: Klaus Darilion wrote: Actually I would nat=yes always, even if clients are not behind NAT os otherwise the clietn can put some garbage into the contact header (e.g. IP address of an upstream provider) and influence routing. No. There is a specific reason RFC 3261 says: Registration creates bindings in a location service for a particular domain that associates an address-of-record URI with one or more contact addresses. Thus, when a proxy for that domain receives a request whose Request-URI matches the address-of-record, the proxy will forward the request to the contact addresses registered to that address-of-record. This gives the UAC the necessary level of control to determine how it is to be contacted. Imagine, for a example, a scenario in which incoming registrations are proxied further upstream for whatever reason - load balancer/distributor perhaps? - by an intermediate element. Do you really want to use that proximate hop's received IP address in place of the ultimate sending UAC's domain? This is a different scenario. In this case of course I want the public IP of the client, not of the load balancer. So, yes - in this case nat=no is useful for Asterisk. Nevertheless I ignore the IP provided by the client in the contact header completely - I always use the public IP of the client. Thus, in a loadbalancer setup I would configure the load balancer to ignore the advertised IP but use the received IP (implementation depends on the actual setup and used components). But as a basic rule - never ever trust the client. Storing and using the Contact provided by the client without any screening is dangerous. klaus ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
Alex Balashov schrieb: Steve Totaro wrote: Alex is going to cling to to the RFC as if it were the gospel, and not look at what would essentially be a good thing. The RFC is not the gospel, but nor is it just a request for comment, historical nomenclature aside. It is the de facto standard for the implementation of the protocol, the product of IETF working groups, various standards bodies, and private and academic industry consortia. It is essential for interoperability and is the source of the justification for the appeal to sameness in the claim that two elements or services speak the same protocol. Inconsistencies, omissions, or deviations from the standard in implementations do not materially undermine this point. Nothing is perfect, including the RFC itself, which is replete with ambiguities open to interpretation and disagreements about those interpretations. However, it does provide the anchor for essential adherence, especially when it comes to points that are spelled out clearly (i.e. the basic purpose and function of registration and contact bindings) as opposed to more marginal scenarios. Do I really have to explain why it is important to follow the RFC when implementing an IETF protocol? Of course we know that we should implement RFC conform. But RFC 3261 has ignored the fact that the Internet is full of NATs and standard conform implementations can not work. This in the case of SIP it necessary to break the RFC. regards klaus ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
Klaus Darilion wrote: Of course we know that we should implement RFC conform. But RFC 3261 has ignored the fact that the Internet is full of NATs and standard conform implementations can not work. This in the case of SIP it necessary to break the RFC. By default? NAT itself is a hack; therefore, I would think that NAT traversal assistance should be enabled when NAT is used. Why would we presume NAT and implement behaviour that is only desirable under NAT as a default? -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
Klaus Darilion wrote: This is a different scenario. In this case of course I want the public IP of the client, not of the load balancer. So, yes - in this case nat=no is useful for Asterisk. Nevertheless I ignore the IP provided by the client in the contact header completely - I always use the public IP of the client. Thus, in a loadbalancer setup I would configure the load balancer to ignore the advertised IP but use the received IP (implementation depends on the actual setup and used components). But as a basic rule - never ever trust the client. Storing and using the Contact provided by the client without any screening is dangerous. Hm. Interesting. I am curious: I agree that validation should be in place, but why do you think that distrust of the client's contact URI should be elevated to a basic rule? What incentive do UACs have to provide an illegitimate contact URI? So the UAS will send responses somewhere else, to another UAC that will reject the request because it the dialog/transaction parameters do not match? Man-in-the-middle attacks from spoofed requests containing bogus contact domains? That can also be carried out with IP spoofing and other more traditional means on the IP layer itself. But there is a difference between screening and distrusting by default, particularly in scenarios where it may be explicitly undesirable for the received IP to be used as the contact, such as in switch assemblies where the signaling agents are partitioned somehow. I think the question here really is about good default behaviours and assumptions, not whether validation for security is a good idea, though. In the scenario in the last paragraph, I may wish to allow contact addresses from other hosts on the same originating subnet but not on foreign networks (validation), but not to use the received IP (assumption of NAT). -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
Alex Balashov schrieb: Klaus Darilion wrote: This is a different scenario. In this case of course I want the public IP of the client, not of the load balancer. So, yes - in this case nat=no is useful for Asterisk. Nevertheless I ignore the IP provided by the client in the contact header completely - I always use the public IP of the client. Thus, in a loadbalancer setup I would configure the load balancer to ignore the advertised IP but use the received IP (implementation depends on the actual setup and used components). But as a basic rule - never ever trust the client. Storing and using the Contact provided by the client without any screening is dangerous. Hm. Interesting. I am curious: I agree that validation should be in place, but why do you think that distrust of the client's contact URI should be elevated to a basic rule? What incentive do UACs have to provide an illegitimate contact URI? So the UAS will send responses somewhere else, to another UAC that will reject the request because it the dialog/transaction parameters do not match? Man-in-the-middle attacks from spoofed requests containing bogus contact domains? That can also be carried out with IP spoofing and other more traditional means on the IP layer itself. Nono - it is not about replies. it is about how incoming calls will be routed. Consider the following scenario, which is general for SIP proxies/PBXs: Proxy (Asterisk, Openser ...) on IP 1.1.1.1 This proxy uses a gateway for PSTN located at 2.2.2.2 (either belongs to the proxy operator or is a gateway from a termination provider). Very often the authentication between gateway and proxy is done based on IP address. Now, the customers SIP client at 3.3.3.3 REGISTERs to the proxy with Contact: sip:[EMAIL PROTECTED] If now there is an incoming call to the customer, the Proxy/Asterisk will send the INVITE to 2.2.2.2 = the gateway. The gateway happily accepts the call - as you see there is lots of fraud possibilities. I did several security audits and many ITSPs were vulnerably for this kind of attack. There are some methods to prevent this (like e.g. blacklists in openser) but a simple workaround which works fine in most ITSP setups is to ignore the user provided contact. But there is a difference between screening and distrusting by default, yes it is. But if the service is a POTS replacement and call forwarding will be done using a web interface it is easier to use the source IP:port instead of screening. particularly in scenarios where it may be explicitly undesirable for the received IP to be used as the contact, such as in switch assemblies where the signaling agents are partitioned somehow. yes, yes. true. of course my example is for a very simple setup. But in such complex scenarios there is still fraud potential and screening/replacing the contact will not be done by the registrar, but by the ingress point into the SIP network (e.g. load balancer, outbound proxy, SBC, P-CSCF ... - call it what you want) I think the question here really is about good default behaviours and assumptions, not whether validation for security is a good idea, though. I think the default value is ok. I works for 99% and it increases security. If someone has a big complex setup he probably has the knowledge of the nat= setting and knows the impacts of changing the value. In the scenario in the last paragraph, I may wish to allow contact addresses from other hosts on the same originating subnet but not on foreign networks (validation), but not to use the received IP (assumption of NAT). If you have such requirements then change the nat= setting, screen the contact values and you are fine. But IMO nat=yes is a good default setting. klaus ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
Alex Balashov schrieb: Klaus Darilion wrote: Of course we know that we should implement RFC conform. But RFC 3261 has ignored the fact that the Internet is full of NATs and standard conform implementations can not work. This in the case of SIP it necessary to break the RFC. By default? NAT itself is a hack; therefore, I would think that NAT traversal assistance should be enabled when NAT is used. Why would we presume NAT and implement behaviour that is only desirable under NAT as a default? Because NAT is the default. At least in Austria - most customers get a NAT router with their DSL Account. klaus ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
Klaus Darilion wrote: Very often the authentication between gateway and proxy is done based on IP address. Now, the customers SIP client at 3.3.3.3 REGISTERs to the proxy with Contact: sip:[EMAIL PROTECTED] If now there is an incoming call to the customer, the Proxy/Asterisk will send the INVITE to 2.2.2.2 = the gateway. The gateway happily accepts the call - as you see there is lots of fraud possibilities. This is true and a very good observation! This kind of tomfoolery seems to be among the numerous pitfalls that come with trusted-IP SIP trunks. I am persuaded by your suggestion that in a typical ITSP scenario it may be wise to restrict the contact domain provided that the end-users are understood to be end-user phone devices/CPE. If, however, there are wholesale / multichannel operations where the far-side equipment and network topology can operate according to various principles, that may not be wise. And in any case, to go back to the original question, I am not sure that the most practical thing to do is to simply ignore the contact domain; it is better to restrict it to ensure that the user does not attempt to route calls over your trusted IP trunks, if you have them. It seems to me that there are far too many possible IP telephony applications where the contact address may differ from the proximate sender of the request on the IP level. It would not work in almost any multilateral peering/clearing/settlement setup. No, as you and Steve rightly point out, IP phones on simple home LANs fronted by consumer broadband routers in a many-to-one NAT scenario do not fall into that category. But we're talking about what is reasonable to assume here for every single installation by default. It was said recently in this thread that Asterisk is designed to be a PBX, but asterisk.org says Asterisk is the world's leading open source PBX, telephony engine, and telephony applications toolkit. That should give a lot of pause and be carefully reflected on. There are some methods to prevent this (like e.g. blacklists in openser) but a simple workaround which works fine in most ITSP setups is to ignore the user provided contact. I would insist it is more parsimonious and even-handed to restrict than to ignore. I think the question here really is about good default behaviours and assumptions, not whether validation for security is a good idea, though. I think the default value is ok. I works for 99% and it increases security. If someone has a big complex setup he probably has the knowledge of the nat= setting and knows the impacts of changing the value. The question is one of principle: whether they should have to deal with nonstandard behaviour by default. or enable it explicitly. I am also not sure it works for 99%. Perhaps in the restricted context you specified - ITSPs providing POTS replacement services to end users, or companies using Asterisk as an internal PBX open to the outside with mobile users. But I don't think that's anywhere near 99%. Just about any scenario inside an ITSP where Asterisk would be used as a feature server, voicemail server, or other application element and receive calls via a proxy would not invite this behaviour. Perhaps a reasonable compromise would be to follow the general logic that seems to be behind OpenSER's nathelper module's nat_uac_test() or nat_traversal's client_nat_test() function parameters and enable NAT behaviour by default for RFC 1918 contact addresses, but not others. I could get behind that. -- Alex -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
Steve Totaro wrote: I have done some large installs where people are going to be in the office, sometimes out, work from home, it always changes sorta thing.. I have found that setting all device profiles to Nat=yes Just Works whether they are on the LAN or not and this is even on larger scale systems with hundreds of phones. Is there any reason why this would be frowned upon as a default? Even to the point of, if nat= is not specified, it would default to yes? Is there a performance hit somewhere, or some other downside? If not, I suggest making it the default. The premise of nat=yes is that the domain portion of the Contact URI is overridden with the real, received source IP of the request and that the default expectation of port 5060 (if not specified in the Contact URI) is dropped in favour of the actually received source UDP port. Similarly for SDP (without SIP-aware ALG). I think the reason this would be frowned upon as a default is philosophical in essence; by default, per the RFC, a SIP UAC is expected to behave such and such way, i.e. use the Contact URI that arrives in a REGISTER request and/or INVITE. Overriding that with the received IP:port is a hack around prescribed behaviour, and enabling hacks as default behaviour is generally considered a bad idea. -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
On Wed, Nov 12, 2008 at 4:47 PM, Alex Balashov [EMAIL PROTECTED]wrote: Steve Totaro wrote: I have done some large installs where people are going to be in the office, sometimes out, work from home, it always changes sorta thing.. I have found that setting all device profiles to Nat=yes Just Works whether they are on the LAN or not and this is even on larger scale systems with hundreds of phones. Is there any reason why this would be frowned upon as a default? Even to the point of, if nat= is not specified, it would default to yes? Is there a performance hit somewhere, or some other downside? If not, I suggest making it the default. The premise of nat=yes is that the domain portion of the Contact URI is overridden with the real, received source IP of the request and that the default expectation of port 5060 (if not specified in the Contact URI) is dropped in favour of the actually received source UDP port. Similarly for SDP (without SIP-aware ALG). I think the reason this would be frowned upon as a default is philosophical in essence; by default, per the RFC, a SIP UAC is expected to behave such and such way, i.e. use the Contact URI that arrives in a REGISTER request and/or INVITE. Overriding that with the received IP:port is a hack around prescribed behaviour, and enabling hacks as default behaviour is generally considered a bad idea. -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 While not taking the time to look, and if memory serves me correctly, LAN devices appear on the correct ports even with nat=yes. I may be wrong I will have to double check this when I have a moment. So if a hack overwrites something with the same something then did you really break the RFC? -- Thanks, Steve Totaro +18887771888 (Toll Free) +12409381212 (Cell) +12024369784 (Skype) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
Steve Totaro wrote: While not taking the time to look, and if memory serves me correctly, LAN devices appear on the correct ports even with nat=yes. I may be wrong I will have to double check this when I have a moment. That is not my understanding from the code. Also, I am curious - what is the definition of LAN device as you are using it here? Is it a network with 1) an RFC1918 address and 2) a network on which the system running Asterisk has a physical interface binding? If so, what about other routed subnets also on a LAN? -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
On Wed, Nov 12, 2008 at 5:25 PM, Alex Balashov [EMAIL PROTECTED]wrote: Steve Totaro wrote: While not taking the time to look, and if memory serves me correctly, LAN devices appear on the correct ports even with nat=yes. I may be wrong I will have to double check this when I have a moment. That is not my understanding from the code. I believe that if you are speaking of code and Asterisk's implementation of the SIP RFC it is already very borked in many many ways. I speak from what I see in userspace, real-world, although, as I said, I am going from memory and could be wrong. Also, I am curious - what is the definition of LAN device as you are using it here? Is it a network with 1) an RFC1918 address and 2) a network on which the system running Asterisk has a physical interface binding? If so, what about other routed subnets also on a LAN? I define a LAN based on layer 2 and more recently layer 3 (layer 3 aware switches) of the OSI reference model. Call me old school but I got my CCNA in the nineties. If so, what about other routed subnets also on a LAN?, sorry, I do not understand what you are asking.. -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 -- Thanks, Steve Totaro +18887771888 (Toll Free) +12409381212 (Cell) +12024369784 (Skype) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
Steve Totaro wrote: I believe that if you are speaking of code and Asterisk's implementation of the SIP RFC it is already very borked in many many ways. I speak from what I see in userspace, real-world, although, as I said, I am going from memory and could be wrong. Yeah, I know. But deciding whether to elevate a hack to default behaviour status is a question that cannot be governed purely by someone's perceived real-world use cases, because not all use cases are universal. That's typically not how questions of standards compliance (alleged existing noncompliance therewith by Asterisk notwithstanding) are settled. If we did things this way, we would constantly be arguing about whose real-world is more real or more importantly real than the others'. For instance, there are a variety of setups that your suggested approach would break, uncommon as they may be. What if the requests come from an internal subnet fronted by a NAT device but to which the Asterisk host also has a direct route that the return path or the media path should take? Or what if the user agents are configured for near-end NAT traversal fixups (sort of like Asterisk's 'externip' option) for which overriding them to the received IP information would present problems? I realise that's probably not the sort of thing you see in the deployments you are leveraging as part of the claim to real world insight, but the point is that many people reside in many different kinds of real world. Default configuration options should implement standard behaviour as much as possible. If I am a new user of Asterisk unfamiliar with the 'nat' option, I shouldn't have to explicitly set it to 'no' (because the default behaviour is 'yes') in order to get Asterisk to behave in a more standards-compliant way; it should be the other way around. The package shouldn't come with a hack enabled out-of-the-box. The standards are the reasonable, pragmatic departure point for the common denominator, and the standards say that Contact URIs and SDP endpoint attributes are to be believed and mandatorily used. Also, I am curious - what is the definition of LAN device as you are using it here? Is it a network with 1) an RFC1918 address and 2) a network on which the system running Asterisk has a physical interface binding? If so, what about other routed subnets also on a LAN? I define a LAN based on layer 2 and more recently layer 3 (layer 3 aware switches) of the OSI reference model. Call me old school but I got my CCNA in the nineties. I know how you define a LAN; it's how I'd define a LAN too. Asterisk, however, is not Layer 2-aware, so the question is how IT defines a LAN. If, hypothetically, the behaviour you suggested (nat=yes behaviour is not applied to requests originating from LAN endpoints), then Asterisk would have to know that the source address is a LAN address. How? What are the criteria? If so, what about other routed subnets also on a LAN?, sorry, I do not understand what you are asking.. It's related to the above. In other words, perhaps Asterisk can conceivably know if a request originated from a LAN address if it comes from the subnet of one of the host's IP interfaces and is off a private range, but what if the address is off a private range but not on a subnet to which the Asterisk host is directly connected. Is it a LAN endpoint then? -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
On Wed, Nov 12, 2008 at 6:57 PM, Alex Balashov [EMAIL PROTECTED]wrote: Steve Totaro wrote: I believe that if you are speaking of code and Asterisk's implementation of the SIP RFC it is already very borked in many many ways. I speak from what I see in userspace, real-world, although, as I said, I am going from memory and could be wrong. Yeah, I know. But deciding whether to elevate a hack to default behaviour status is a question that cannot be governed purely by someone's perceived real-world use cases, because not all use cases are universal. That's typically not how questions of standards compliance (alleged existing noncompliance therewith by Asterisk notwithstanding) are settled. If we did things this way, we would constantly be arguing about whose real-world is more real or more importantly real than the others'. For instance, there are a variety of setups that your suggested approach would break, uncommon as they may be. What if the requests come from an internal subnet fronted by a NAT device but to which the Asterisk host also has a direct route that the return path or the media path should take? Or what if the user agents are configured for near-end NAT traversal fixups (sort of like Asterisk's 'externip' option) for which overriding them to the received IP information would present problems? I realise that's probably not the sort of thing you see in the deployments you are leveraging as part of the claim to real world insight, but the point is that many people reside in many different kinds of real world. Default configuration options should implement standard behaviour as much as possible. If I am a new user of Asterisk unfamiliar with the 'nat' option, I shouldn't have to explicitly set it to 'no' (because the default behaviour is 'yes') in order to get Asterisk to behave in a more standards-compliant way; it should be the other way around. The package shouldn't come with a hack enabled out-of-the-box. The standards are the reasonable, pragmatic departure point for the common denominator, and the standards say that Contact URIs and SDP endpoint attributes are to be believed and mandatorily used. Also, I am curious - what is the definition of LAN device as you are using it here? Is it a network with 1) an RFC1918 address and 2) a network on which the system running Asterisk has a physical interface binding? If so, what about other routed subnets also on a LAN? I define a LAN based on layer 2 and more recently layer 3 (layer 3 aware switches) of the OSI reference model. Call me old school but I got my CCNA in the nineties. I know how you define a LAN; it's how I'd define a LAN too. Asterisk, however, is not Layer 2-aware, so the question is how IT defines a LAN. If, hypothetically, the behaviour you suggested (nat=yes behaviour is not applied to requests originating from LAN endpoints), then Asterisk would have to know that the source address is a LAN address. How? What are the criteria? If so, what about other routed subnets also on a LAN?, sorry, I do not understand what you are asking.. It's related to the above. In other words, perhaps Asterisk can conceivably know if a request originated from a LAN address if it comes from the subnet of one of the host's IP interfaces and is off a private range, but what if the address is off a private range but not on a subnet to which the Asterisk host is directly connected. Is it a LAN endpoint then? -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 Anyone more senior than Alex care to weigh in? -- Thanks, Steve Totaro +18887771888 (Toll Free) +12409381212 (Cell) +12024369784 (Skype) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
On Wednesday 12 November 2008 18:34:45 Steve Totaro wrote: On Wed, Nov 12, 2008 at 6:57 PM, Alex Balashov [EMAIL PROTECTED]wrote: Steve Totaro wrote: I believe that if you are speaking of code and Asterisk's implementation of the SIP RFC it is already very borked in many many ways. I speak from what I see in userspace, real-world, although, as I said, I am going from memory and could be wrong. Yeah, I know. But deciding whether to elevate a hack to default behaviour status is a question that cannot be governed purely by someone's perceived real-world use cases, because not all use cases are universal. That's typically not how questions of standards compliance (alleged existing noncompliance therewith by Asterisk notwithstanding) are settled. If we did things this way, we would constantly be arguing about whose real-world is more real or more importantly real than the others'. For instance, there are a variety of setups that your suggested approach would break, uncommon as they may be. What if the requests come from an internal subnet fronted by a NAT device but to which the Asterisk host also has a direct route that the return path or the media path should take? Or what if the user agents are configured for near-end NAT traversal fixups (sort of like Asterisk's 'externip' option) for which overriding them to the received IP information would present problems? I realise that's probably not the sort of thing you see in the deployments you are leveraging as part of the claim to real world insight, but the point is that many people reside in many different kinds of real world. Default configuration options should implement standard behaviour as much as possible. If I am a new user of Asterisk unfamiliar with the 'nat' option, I shouldn't have to explicitly set it to 'no' (because the default behaviour is 'yes') in order to get Asterisk to behave in a more standards-compliant way; it should be the other way around. The package shouldn't come with a hack enabled out-of-the-box. The standards are the reasonable, pragmatic departure point for the common denominator, and the standards say that Contact URIs and SDP endpoint attributes are to be believed and mandatorily used. Also, I am curious - what is the definition of LAN device as you are using it here? Is it a network with 1) an RFC1918 address and 2) a network on which the system running Asterisk has a physical interface binding? If so, what about other routed subnets also on a LAN? I define a LAN based on layer 2 and more recently layer 3 (layer 3 aware switches) of the OSI reference model. Call me old school but I got my CCNA in the nineties. I know how you define a LAN; it's how I'd define a LAN too. Asterisk, however, is not Layer 2-aware, so the question is how IT defines a LAN. If, hypothetically, the behaviour you suggested (nat=yes behaviour is not applied to requests originating from LAN endpoints), then Asterisk would have to know that the source address is a LAN address. How? What are the criteria? If so, what about other routed subnets also on a LAN?, sorry, I do not understand what you are asking.. It's related to the above. In other words, perhaps Asterisk can conceivably know if a request originated from a LAN address if it comes from the subnet of one of the host's IP interfaces and is off a private range, but what if the address is off a private range but not on a subnet to which the Asterisk host is directly connected. Is it a LAN endpoint then? Anyone more senior than Alex care to weigh in? I don't really see a need to. He was right on the money, when he said that nat=yes breaks the SIP specification, although it generally works to your advantage to have it set. While Asterisk's SIP implementation may be buggy, broken, or various other words that you can dream up to describe that it's not strictly compliant, it is, in fact, one of the most interoperable SIP stacks currently available. Due to this distinction, it is by far the tool of choice for other SIP implementers to use to distinguish just how interoperable their own products are. That says oodles about just how bad other implementations are and just how good Asterisk's is, by comparison. That may still not mean much in terms of overall compliance, but it means a whole lot in terms of market position. You should remember that next time you pooh-pooh Asterisk's SIP stack. -- Tilghman ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Why Nat=yes Nat=no Option?
On Wed, Nov 12, 2008 at 7:58 PM, Tilghman Lesher [EMAIL PROTECTED] wrote: On Wednesday 12 November 2008 18:34:45 Steve Totaro wrote: On Wed, Nov 12, 2008 at 6:57 PM, Alex Balashov [EMAIL PROTECTED]wrote: Steve Totaro wrote: I believe that if you are speaking of code and Asterisk's implementation of the SIP RFC it is already very borked in many many ways. I speak from what I see in userspace, real-world, although, as I said, I am going from memory and could be wrong. Yeah, I know. But deciding whether to elevate a hack to default behaviour status is a question that cannot be governed purely by someone's perceived real-world use cases, because not all use cases are universal. That's typically not how questions of standards compliance (alleged existing noncompliance therewith by Asterisk notwithstanding) are settled. If we did things this way, we would constantly be arguing about whose real-world is more real or more importantly real than the others'. For instance, there are a variety of setups that your suggested approach would break, uncommon as they may be. What if the requests come from an internal subnet fronted by a NAT device but to which the Asterisk host also has a direct route that the return path or the media path should take? Or what if the user agents are configured for near-end NAT traversal fixups (sort of like Asterisk's 'externip' option) for which overriding them to the received IP information would present problems? I realise that's probably not the sort of thing you see in the deployments you are leveraging as part of the claim to real world insight, but the point is that many people reside in many different kinds of real world. Default configuration options should implement standard behaviour as much as possible. If I am a new user of Asterisk unfamiliar with the 'nat' option, I shouldn't have to explicitly set it to 'no' (because the default behaviour is 'yes') in order to get Asterisk to behave in a more standards-compliant way; it should be the other way around. The package shouldn't come with a hack enabled out-of-the-box. The standards are the reasonable, pragmatic departure point for the common denominator, and the standards say that Contact URIs and SDP endpoint attributes are to be believed and mandatorily used. Also, I am curious - what is the definition of LAN device as you are using it here? Is it a network with 1) an RFC1918 address and 2) a network on which the system running Asterisk has a physical interface binding? If so, what about other routed subnets also on a LAN? I define a LAN based on layer 2 and more recently layer 3 (layer 3 aware switches) of the OSI reference model. Call me old school but I got my CCNA in the nineties. I know how you define a LAN; it's how I'd define a LAN too. Asterisk, however, is not Layer 2-aware, so the question is how IT defines a LAN. If, hypothetically, the behaviour you suggested (nat=yes behaviour is not applied to requests originating from LAN endpoints), then Asterisk would have to know that the source address is a LAN address. How? What are the criteria? If so, what about other routed subnets also on a LAN?, sorry, I do not understand what you are asking.. It's related to the above. In other words, perhaps Asterisk can conceivably know if a request originated from a LAN address if it comes from the subnet of one of the host's IP interfaces and is off a private range, but what if the address is off a private range but not on a subnet to which the Asterisk host is directly connected. Is it a LAN endpoint then? Anyone more senior than Alex care to weigh in? I don't really see a need to. He was right on the money, when he said that nat=yes breaks the SIP specification, although it generally works to your advantage to have it set. When does it not was the original question? While Asterisk's SIP implementation may be buggy, broken, or various other words that you can dream up to describe that it's not strictly compliant, it is, in fact, one of the most interoperable SIP stacks currently available. Due to this distinction, it is by far the tool of choice for other SIP implementers to use to distinguish just how interoperable their own products are. Citation needed. That says oodles about just how bad other implementations are and just how good Asterisk's is, by comparison. That may still not mean much in terms of overall compliance, but it means a whole lot in terms of market position. Citation needed. You should remember that next time you pooh-pooh Asterisk's SIP stack. Stating it is not compliant is not pooh-poohing Asterisk's SIP stack, it is stating a fact. Taking a bit personal aren't you? I have no issue with it for the most
Re: [asterisk-users] Why Nat=yes Nat=no Option?
Alex Balashov wrote: Steve Totaro wrote: I have done some large installs where people are going to be in the office, sometimes out, work from home, it always changes sorta thing.. I have found that setting all device profiles to Nat=yes Just Works whether they are on the LAN or not and this is even on larger scale systems with hundreds of phones. Is there any reason why this would be frowned upon as a default? Even to the point of, if nat= is not specified, it would default to yes? Is there a performance hit somewhere, or some other downside? If not, I suggest making it the default. The premise of nat=yes is that the domain portion of the Contact URI is overridden with the real, received source IP of the request and that the default expectation of port 5060 (if not specified in the Contact URI) is dropped in favour of the actually received source UDP port. Similarly for SDP (without SIP-aware ALG). I think the reason this would be frowned upon as a default is philosophical in essence; by default, per the RFC, a SIP UAC is expected to behave such and such way, i.e. use the Contact URI that arrives in a REGISTER request and/or INVITE. Overriding that with the received IP:port is a hack around prescribed behaviour, and enabling hacks as default behaviour is generally considered a bad idea. IIRC Uniden phones do not (or did not at one time) work with nat=yes if they were not NAT'd. -- Consulting and design services for LAN, WAN, voice and data. Based near Birmingham, AL. Now accepting clients worldwide. Contact me for Tellabs echo canceling systems. Also see http://www.fnords.org/skillslist.html ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
