Subject: RE: [Sip] SIP Identity using Media Path

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Jul 2007 14:43:09 -0700

I wrote:

> > >>The CSeq (at least the digit portion) may also be modified,
> > >>for example if there has been some "dialog piggybacked" requests
> > >>sent between the SBC and another entity, but not end-to-end. In
> > >>that case the the SBC may have to increase the CSeq before
> > >>forwarding the request, if the digit portion value has already
> > >>been used in a request sent by the SBC in the same direction.
> > >
> > >That seems like a good opportunity, within that trust domain
> > >between the SBC and the other entity, to use
> > >P-Asserted-Identity.
> > 
> > I am not sure I understand. How could the P-A-I header be 
> > used instead of the CSeq?
> 
> The SBC that wants to interfere with the CSeq when doing 'dialog
> piggybacking' can go ahead and do that.  Doing that will destroy 
> the validity of the SIP-Identity-Media signature for the 'dialog 
> piggybacked' request.  Because the SBC and the 'other entity' 
> (which is receiving the 'dialog piggybacked' message) are both
> in the same trust domain, they can use P-A-I between themselves.

I sketched out what you had said, and I now understand what you
were saying.  The case is like this:

              +----+
              |    +------CSeq=2--(dialog piggybacked request-->
  -CSeq=1---->+ SBC|
              |    +------CSeq=1--(request)-->
              +----+

What I had suggested was that the piggybacked request (the one
with CSeq=2) could be sent with P-A-I (created by the SBC), as 
it was being sent to another entity within the same trust domain
as the SBC.

The difficulty you were describing was that when the next request
arrives, it may be using CSeq=2:

              +----+
              |    +-->
  -CSeq=2---->+ SBC|
              |    +-->
              +----+

the SBC would need to disambiguate the newly-arrived CSeq from
the piggybacked (spoofed) request the SBC created from the
previous request.

The easy solution to this is to not sign the CSeq's sequence
number, but just the method.  For replay protection we would
rely on the nonce created by the signing service (which I
described in
http://www1.ietf.org/mail-archive/web/sip/current/msg19883.html).

I can't read the tea leaves of RFC4474 to understand why RFC4474
signs CSeq's sequence number.

Let me know if removing CSeq's sequence number from the signature
would resolve the problem you brought up.

-d

_______________________________________________
Sip mailing list  https://www1.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 (JO/LMF)" <[email-masked]>
Date: Tue, 17 Jul 2007 08:06:10 +0200

Hi Dan,

I was planning to provide an example myself, but you seem to have done
the work for me :)

>>>>>The CSeq (at least the digit portion) may also be modified, for
example if there has been some "dialog piggybacked" 
>>>>>requests sent between the SBC and another entity, but not
end-to-end. In that case the the SBC may have to increase the CSeq
before 
>>>>>forwarding the request, if the digit portion value has already been
used in a request sent by the SBC in the same direction.
>>>>between the SBC and the other entity, to use P-Asserted-Identity.
>>> 
>>>I am not sure I understand. How could the P-A-I header be used
instead of the CSeq?
>>piggybacking' can go ahead and do that.  Doing that will destroy the 
>>validity of the SIP-Identity-Media signature for the 'dialog 
>>(which is receiving the 'dialog piggybacked' message) are both in the 
>>same trust domain, they can use P-A-I between themselves.
> 
>I sketched out what you had said, and I now understand what 
>you were saying.  The case is like this:
> 
>               +----+
>What I had suggested was that the piggybacked request (the 
>one with CSeq=2) could be sent with P-A-I (created by the 
>SBC), as it was being sent to another entity within the same 
>trust domain as the SBC.
> 
>The difficulty you were describing was that when the next 
>request arrives, it may be using CSeq=2:
> 
>               +----+
>               |    +-->
>   -CSeq=2---->+ SBC|
>               |    +-->
>               +----+
> 
>the SBC would need to disambiguate the newly-arrived CSeq 
>from the piggybacked (spoofed) request the SBC created from 
>the previous request.

Yes. The SBC would need for forward the request with an increased CSeq
value, e.g. Cseq=3.

Having said that, I think it's quite unlikely that the SBC would
piggyback anything before it receives the initial INVITE, so for that
request it is maybe possible to assume that the CSeq will stay
unchanged.

But, during the dialog the SBC may have to change the Cseq digit value,
and I've also seen use-cases where the method is changed.

Regards,

Christer