RE: [Sipping] Question Regarding Contact Header Topology Hiding

["Rayees Khan" <[e-mail]>]

 
In absence of any standards, SBCs have been subject of lot of
speculations. This might be main reason why there are so many different
opinions about the behaviour of SBCs. The configuration that I
havedescribed is the best option for THIG functionality, nevertheless,
SBC has to perform other functionalities as well, which might be
hampered by this configuration. However, I belive that things can be
resolved with this configuration.
 
regards
Rayees
 

________________________________

From: Gilad Shaham [mailto:[e-mail]] 
Sent: Sunday, June 17, 2007 9:22 AM
To: Rayees Khan; Vinay Pande (vipande)
Cc: [e-mail]
Subject: RE: [Sipping] Question Regarding Contact Header Topology Hiding



So do you mean that if the SBC monitors the FQDN example.com, the DNS
servers outside example.com would always resolve it to the SBC IP? That
would mean that all traffic, including non SIP will reach the SBC.

If this is the case, however, it would mean that the SBC is also aware
of the FQDN it protects and therefore it can leave the contact with the
FQDN (or change it to the FQDN if it's an IP address).

 

I think it's a possible configuration, I'm not sure it covers all SBCs.

 

Cheers,

Gilad

 

________________________________

From: Rayees Khan [mailto:[e-mail]] 
Sent: Friday, June 15, 2007 10:57 AM
To: Vinay Pande (vipande); Gilad Shaham; [e-mail]
Subject: RE: [Sipping] Question Regarding Contact Header Topology Hiding

 

My understanding is that the two networks on either side of SBC (public
and private) are different address spaces. By that I mean that in Public
network the FQDN would be resolved to the Public interface of SBC so all
the traffic actually hits SBC. The SBC subsequently re-resolves this
FQDN in internal network and routes the messages to the end-point. 

 

regards

Rayees

 

 

________________________________

From: Vinay Pande (vipande) [mailto:[e-mail]] 
Sent: Thursday, June 14, 2007 6:06 PM
To: Gilad Shaham; [e-mail]
Subject: RE: [Sipping] Question Regarding Contact Header Topology Hiding

Hi Gilad,

 

Just a thought -- Assume this traffic hits an SBC which is transiting
VoIP traffic from provider 1 to provider 2 and it does not hide the
Contact details in INVITE etc.

Wouldnt it amount to disclosing whose traffic you are transiting? That
could open up door for "guessing" the topology behind this SBC and
possibly some targetted DoS attacks to that inside FQDN whose traffic
this SBC was transiting. If the SBC overrides Contact headers with its
own FQDN/IP, that possibility is reduced.

 

My 2 cents.

 

Thanks,

Vinay

 

________________________________

From: Gilad Shaham [mailto:[e-mail]] 
Sent: Thursday, June 14, 2007 8:20 AM
To: [e-mail]
Subject: [Sipping] Question Regarding Contact Header Topology Hiding

draft-ietf-sipping-sbc-funcs-03 mentions the Contact header as one of
the possible options for topology hiding.

My question is -  what would count as a contact header that requires
topology hiding?

 

A contact that contains an IP address is probably such a contact.

What if the contact is an AOR obtained from the registration such as:

sip:[e-mail];gr=h4f6d2yggk4

 

It sounds to me as the later example does not expose the underlying
topology. So is this true, topology hiding should only hide contact
headers with IP addresses? Any other cases?

 

Thanks,

Gilad


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


------------------------------------------------------------------------
----------
IMPORTANT The information contained in this e-mail any
attachments is intended only for the named recipient and may be
privileged or confidential.

If you are not the intended recipient, please notify us immediately 
on [phone] and do not disclose, copy, distribute 
or take any action based on the contents of this e-mail. 

You should understand and accept that, when communicating with us
by e-mail, it is not a totally secure communication medium.

We accept no liability for any direct, indirect or consequential loss
arising from any action taken in reliance on the information contained
in this e-mail and give no warranty or representation as to its accuracy
or reliability.

DIGITALK has the facility to monitor and read both incoming
and outgoing communications by e-mail. In line with industry efforts
to reduce the proliferation of Un-Solicited SPAM messages, 
DIGITALK uses various methods including Reverse-DNS 
lookups and ban-lists to prevent malicious content reaching our users.

This message and any attachments has been scanned for known
viruses. However, we would advise you to ensure the content is
indeed virus free. We do not, to the extent permitted by law, accept
any liability (whether in contract, negligence or otherwise) for any
virus
infection and/or external compromise of security and/or breach of
confidentiality in relation to transmissions sent by e-mail.

VAT No: GB 876 3287 81. Reg No: 3080801
Place of Registration: England
Registered Office Address: 2 Radian Court, Knowlhill, Milton Keynes
------------------------------------------------------------------------
----------"


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP