SBC impact on RFC 4474

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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

________________________________

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



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 sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip


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

> -----Original Message-----
> From: sip-bouncesietf.org [mailto:sip-bouncesietf.org]
On Behalf Of
> Elwell, John
>
> 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.

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.


> I would like to hear views on the following:
> - 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.


> - Existing solution proposals:
>     o draft-wing-sip-identity-media-02
>     o draft-fischer-sip-e2e-sec-media-00
> - 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
_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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 

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbergericsson.com] 
> Sent: 14 March 2008 01:29
> To: Elwell, John; IETF SIP List
> Subject: VS: [Sip] SBC impact on RFC 4474
> 
> Hi,
>  
> SBCs may modify SDP even if ICE is used.
>  
> Regards,
>  
> Christer
> 
> ________________________________
> 
> Lähettäjä: sip-bouncesietf.org puolesta: Elwell,
John
> Lähetetty: to 13.3.2008 22:27
> Vastaanottaja: IETF SIP List
> Aihe: [Sip] SBC impact on RFC 4474
> 
> 
> 
> 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 sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 
> 
> 
_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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:john.elwellsiemens.com] 
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 

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbergericsson.com]
> Sent: 14 March 2008 01:29
> To: Elwell, John; IETF SIP List
> Subject: VS: [Sip] SBC impact on RFC 4474
> 
> Hi,
>  
> SBCs may modify SDP even if ICE is used.
>  
> Regards,
>  
> Christer
> 
> ________________________________
> 
> Lähettäjä: sip-bouncesietf.org puolesta: Elwell,
John
> Lähetetty: to 13.3.2008 22:27
> Vastaanottaja: IETF SIP List
> Aihe: [Sip] SBC impact on RFC 4474
> 
> 
> 
> 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 
> sip-implementorscs.columbia.edu for questions on current
sip Use 
> sippingietf.org for new developments on the application of
sip
> 
> 
> 
_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbergericsson.com] 
> Sent: 17 March 2008 13:42
> To: Elwell, John; IETF SIP List
> Subject: RE: [Sip] SBC impact on RFC 4474
> 
> 
> 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:john.elwellsiemens.com] 
> 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 
> 
> > -----Original Message-----
> > From: Christer Holmberg
[mailto:christer.holmbergericsson.com]
> > Sent: 14 March 2008 01:29
> > To: Elwell, John; IETF SIP List
> > Subject: VS: [Sip] SBC impact on RFC 4474
> > 
> > Hi,
> >  
> > SBCs may modify SDP even if ICE is used.
> >  
> > Regards,
> >  
> > Christer
> > 
> > ________________________________
> > 
> > Lähettäjä: sip-bouncesietf.org puolesta: Elwell,
John
> > Lähetetty: to 13.3.2008 22:27
> > Vastaanottaja: IETF SIP List
> > Aihe: [Sip] SBC impact on RFC 4474
> > 
> > 
> > 
> > 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 
> > sip-implementorscs.columbia.edu for
questions on current sip Use 
> > sippingietf.org for new developments on the
application of sip
> > 
> > 
> > 
> 
_______________________________________________
Sip mailing list  https://www
.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip