Subject: [Sip] SBC impact on RFC 4474

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 Mar 2008 21:27:10 +0000

One of the questions raised at the end of the SIP session today was the
following:

"Are there any useful steps for dealing with SDP modification by SBCs?"

SBCs modify SDP (and perhaps other signed information in SIP requests).
One of the reasons is NAT traversal (should not be applicable with ICE,
but I don't think we can always assume that ICE is used). Other reasons
are topology hiding, media shaping, etc.. Such modification breaks RFC
4474 signatures.

SBCs also sometimes change From URIs in SIP requests, as discussed in
draft-kaplan-sip-uris-change-00. We have taken this into account during
our various discussions (in the WG and off-line) on the telephone number
problem, so I want to keep that separate. For this thread, assume an
"email-style" (or non-phone-number-based) From URI that is not modified
by an SBC. Focus instead on modification of other signed information.

I would like to hear views on the following:
- The degree to which this is a problem.
- Existing solution proposals:
    o draft-wing-sip-identity-media-02
    o draft-fischer-sip-e2e-sec-media-00
- Other solution proposals.

John

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 14 Mar 2008 02:28:31 +0100

Hi,
 
SBCs may modify SDP even if ICE is used.
 
Regards,
 
Christer

________________________________

Lähettäjä: [email-masked] puolesta: Elwell, John
Lähetetty: to 13.3.2008 22:27
Vastaanottaja: IETF SIP List
Aihe: [Sip] SBC impact on RFC 4474

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Mar 2008 01:30:55 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Elwell, John
>

Not that it's germane to the issue, but SBC's don't change SDP due to NAT traversal, or rather that is not the primary or even secondary reason they do so typically. (and you don't have to take my word for it - SBCs were first deployed in peering interconnects, before NAT traversal was even a feature, and yet they modified SDP back then too)  It is a common misconception in the IETF, for some reason.  I believe our marketing group categorizes NAT traversal as #4 or 5 on the list in terms of popular reasons for media relay, but other vendors may have different views. (and obviously this could be due to the kind of customers we sell to, vs. other SBCs)

The SBCs change SDP to make media flow a certain direction, based on the call signaling path and certain policies.  The common reasons are, in no specific order: VPN interconnection/crossing (where even the provider core itself is one or more "VPNs"), traffic engineering, topology hiding, privacy, QoS measurement, QoS marking, transcoding, transrating, NAT traversal, Firewall traversal (which is not the same as NAT traversal, btw), policing/fraud-prevention, rfc2833 interworking, lawful interception, unlawful interception, media format/content inspection, IPv4/v6 conversion, SRTP termination, IPSEC tunnel termination relay, and I'm sure I'm forgetting a couple.  Thus ICE removing the need for the SBC to modify SDP is highly improbable.  Even if the SBC were the TURN server itself it wouldn't work, because the address it has to give out depends on where the SIP call goes, and is not knowable before-hand except in the simplest of cases.

> - The degree to which this is a problem.

Well, that depends.  For calls within a service provider or domain, or between two service providers directly peering, SBCs should pose no problem, since the rfc4474 signing/verifying can be done by the last/first SBCs of the two domains.  Unfortunately, that is a use case rfc4474 provides virtually no benefit for, imho.  The primary motivation for using rfc4474 would be when it crosses transit providers/domains - when there's an actual chain of trust greater than 1.  So personally I think rfc4474 not working in those scenarios is a problem.

> - Other solution proposals.

[tongue-in-cheek] Have the originating UAC generate an INVITE without SDP (i.e., a delayed offer).  Therefore there will be no SDP to sign and become invalidated.  The SDP offer comes in the 2xx, which luckily is unsignable, and the ACK would presumably rarely be signed.  Or make the authenticator a 3PCC box, so that the SDP removal happens without the UAC even knowing it.
;)

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 14 Mar 2008 11:40:50 +0000

Christer,

I think I already captured that in the statement "Other reasons
are topology hiding, media shaping, etc.. Such modification breaks RFC
4474 signatures."
If you think that is insufficient, please elaborate reasons, so we get a better understanding of the scope of the problem.

John 

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 14 March 2008 01:29
> To: Elwell, John; IETF SIP List
> Subject: VS: [Sip] SBC impact on RFC 4474
> 
> Hi,
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 17 Mar 2008 14:42:14 +0100

Hi John,

My comment was based on your "should not be applicable with ICE" statement, and they way I understood it was that SDP would not be modified if ICE is used.

Maybe I missunderstood what you were trying to say.

Regards,

Christer

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 14. maaliskuuta 2008 13:41
To: Christer Holmberg; IETF SIP List
Subject: RE: [Sip] SBC impact on RFC 4474

Christer,

I think I already captured that in the statement "Other reasons are topology hiding, media shaping, etc.. Such modification breaks RFC
4474 signatures."
If you think that is insufficient, please elaborate reasons, so we get a better understanding of the scope of the problem.

John 

> One of the reasons is NAT traversal (should not be applicable with 
> ICE, but I don't think we can always assume that ICE is used).
> Other reasons
> draft-kaplan-sip-uris-change-00. We have taken this into account 
> during our various discussions (in the WG and off-line) on the 
> telephone number problem, so I want to keep that separate. For this 
> thread, assume an "email-style" (or non-phone-number-based) From URI 
> that is not modified by an SBC. Focus instead on modification of other 
> signed information.
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
> 
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 18 Mar 2008 11:12:27 +0000

Christer,

No, I meant SDP should not be modified for the purpose of NAT traversal if ICE is used. It seems it can still be changed for other purposes.

John

> Sent: 17 March 2008 13:42
> My comment was based on your "should not be applicable with 
> ICE" statement, and they way I understood it was that SDP 
> would not be modified if ICE is used.
> 
> I think I already captured that in the statement "Other 
> reasons are topology hiding, media shaping, etc.. Such 
> modification breaks RFC
> 4474 signatures."
> If you think that is insufficient, please elaborate reasons, 
> so we get a better understanding of the scope of the problem.
> 
> John 
>