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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
