response code mapping to upstream peers

Hi, Does anyone do any response code mapping on the peer side? You can deny information to attackers by changing you codes from the default (turn a BUSY HERE into a BAD GATEWAY, at the SBC, for instance), and I'm wondering if anyone has found a good reason to do so. Thanks, David

I actually do quite a bit of this. Metaswitch has a tendency to return 502 messages when what people actually want to see is a 503, 486, or 480 (depending on the case and direction of the call and if route advancing is desired or not). I also use this to sanitize things a tad on my access side. On 04/09/2012 01:33 PM, David Hiers wrote:
Hi, Does anyone do any response code mapping on the peer side? You can deny information to attackers by changing you codes from the default (turn a BUSY HERE into a BAD GATEWAY, at the SBC, for instance), and I'm wondering if anyone has found a good reason to do so.
Thanks,
David _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

We do this quite a bit, as well. We map many 4xx and 6xx responses to 503, which seems to be the code most switches want to see to route advance. Otherwise, they often just give up, instead of moving on to the next egress. On 04/10/2012 03:50 PM, Ryan Delgrosso wrote:
I actually do quite a bit of this.
Metaswitch has a tendency to return 502 messages when what people actually want to see is a 503, 486, or 480 (depending on the case and direction of the call and if route advancing is desired or not). I also use this to sanitize things a tad on my access side.
On 04/09/2012 01:33 PM, David Hiers wrote:
Hi, Does anyone do any response code mapping on the peer side? You can deny information to attackers by changing you codes from the default (turn a BUSY HERE into a BAD GATEWAY, at the SBC, for instance), and I'm wondering if anyone has found a good reason to do so.
Thanks,
David _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

Interesting! 502s are a bit of a pain for us. Every so often, one of the peers of our peer will use a 502 as a reason to retry the call as fast as they can, forever. The current hypothesis is that the remote peer has a couple of connections to our adjacent peer, and cycles between a small number of routes, all which come back to us, so all generate another round of 502s, so we get flooded with INVITEs. Thinking about a 6xx as an "abandon all hope" response... David On Tue, Apr 10, 2012 at 4:06 PM, Tim Thompson <timthompson at nicodem.us> wrote:
We do this quite a bit, as well. We map many 4xx and 6xx responses to 503, which seems to be the code most switches want to see to route advance. Otherwise, they often just give up, instead of moving on to the next egress.
On 04/10/2012 03:50 PM, Ryan Delgrosso wrote:
I actually do quite a bit of this.
Metaswitch has a tendency to return 502 messages when what people actually want to see is a 503, 486, or 480 (depending on the case and direction of the call and if route advancing is desired or not). I also use this to sanitize things a tad on my access side.
On 04/09/2012 01:33 PM, David Hiers wrote:
Hi, Does anyone do any response code mapping on the peer side? You can deny information to attackers by changing you codes from the default (turn a BUSY HERE into a BAD GATEWAY, at the SBC, for instance), and I'm wondering if anyone has found a good reason to do so.
Thanks,
David _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

You can try that, but that's also assuming the peer in the middle isn't manipulating it, themselves (and will also stop recursing on a 6xx). We run into that same scenario quite a bit, ourselves; it can add up to some insane PDD. Our solution was to add a level of loop detection in our LCR, and 503 them. So far that seems to be working in the majority of cases. On 04/11/2012 01:13 PM, David Hiers wrote:
Interesting!
502s are a bit of a pain for us. Every so often, one of the peers of our peer will use a 502 as a reason to retry the call as fast as they can, forever. The current hypothesis is that the remote peer has a couple of connections to our adjacent peer, and cycles between a small number of routes, all which come back to us, so all generate another round of 502s, so we get flooded with INVITEs.
Thinking about a 6xx as an "abandon all hope" response...
David
On Tue, Apr 10, 2012 at 4:06 PM, Tim Thompson<timthompson at nicodem.us> wrote:
We do this quite a bit, as well. We map many 4xx and 6xx responses to 503, which seems to be the code most switches want to see to route advance. Otherwise, they often just give up, instead of moving on to the next egress.
On 04/10/2012 03:50 PM, Ryan Delgrosso wrote:
I actually do quite a bit of this.
Metaswitch has a tendency to return 502 messages when what people actually want to see is a 503, 486, or 480 (depending on the case and direction of the call and if route advancing is desired or not). I also use this to sanitize things a tad on my access side.
On 04/09/2012 01:33 PM, David Hiers wrote:
Hi, Does anyone do any response code mapping on the peer side? You can deny information to attackers by changing you codes from the default (turn a BUSY HERE into a BAD GATEWAY, at the SBC, for instance), and I'm wondering if anyone has found a good reason to do so.
Thanks,
David _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

On 04/11/2012 04:13 PM, David Hiers wrote:
Thinking about a 6xx as an "abandon all hope" response...
Beware that many UAs and forking proxies ignore the RFC-mandated "abandon all hope" aspect of 6xx and roll over on it anyway, much as they do with 5xx-class replies. The reason is that 503 and 603 are both so mis/over-used as catch-all epithets for "didn't work for some reason". -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
participants (4)
-
abalashov@evaristesys.com
-
hiersd@gmail.com
-
ryandelgrosso@gmail.com
-
timthompson@nicodem.us