Interesting.....thanks for the explanation. Never know when someone else will run into the same thing and the fix being documented will help them resolve it!

MARY LOU CAREY
BackUP Telecom Consulting
Office: 615-791-9969
Cell: 615-796-1111

On 2021-07-02 11:55 AM, Matthew Yaklin wrote:
Just to wrap this up and to thank those who responded…

IQNT's sonus (ribbon) do not support the DATE header. Ribbon plans to
fix it soon. It is being stripped out.

Meta already loaded an efix for us. I think I typed out the issue
wrong.

On verification the IAT has the time. The INVITE did not have the
DATE. Meta's perimeta json schema choked due to that.

They will now use the SBC's date/time to do a comparison if the DATE
is not there. Probably check to see if it is within a certain time
frame. After all the DATE and iat may not match when the INVITE comes
in when everything is there to process.

This should solve the problem and allow us to keep moving along with
this.

Matt

From: VoiceOps <voiceops-boun...@voiceops.org> On Behalf Of John S.
Robinson
Sent: Thursday, July 1, 2021 3:31 PM
To: voiceops@voiceops.org
Subject: Re: [VoiceOps] question about stir/shaken - iat and DATE
header

Date header has been part of  RFC-3261 SIP [1] for 19 years now, but
was not used all that much.    IAT and Date are both part of the specs
and more recent RFC's that define stir-shaken.   So the seldom-used
but long time defined Date: header is now required.    Furthermore,
IAT is part of the formal JSON in the Identity header and must be
present, or the claims are not valid.

Normally, IAT would restate the Date with Unix Epoch date.   IAT is
signed, but the Date header is not signed.

When a call is received and Verified, the the plain-text signed JSON
is validated.   If verified IAT is stale, the call is rejected.
True, someone could mess with Date header along the route or SIP From
header or PAI.   And for that matter, someone could mess with the JSON
attributes that are signed.   But then the verification would fail,
and the call should not be delivered.   That's part of the beauty of
the system.

Best regards,

John

On 7/1/2021 12:29, Joseph Jackson wrote:

I've heard that TNSi also counts on the date header being present.

So far we don't see a lot of people passing tokens with the date
header.

From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of
Matthew Yaklin
Sent: Thursday, July 01, 2021 12:25 PM
To: voiceops@voiceops.org
Subject: [VoiceOps] question about stir/shaken - iat and DATE header


All,

Pretty simple question here. When you do a verify request are you
filling in the iat with your sbc's current date/time or using the
DATE information from the invite?

With Neustar the iat is currently optional. IQNT is basically
removing the DATE header in a test we are doing by sending them a
call and getting it back in a different region.

It really does not make sense to me to use the DATE header because
it could be messed with by anyone in the path. It is untrusted. The
iat is trusted so when you verify it makes more sense to use the
current date/time of your SBC because the limitation is 60 seconds
from AS to VS.

I imagine Neustar made it optional because their own system has some
intelligence when it comes to this expiration of the AS.

On top of that Metaswitch is not prepared for this situation. They
are basically counting on that DATE header to be there in their
recommended perimeta SBC config. They plan to fix it by using the
current date/time.

Just looking for how others are handling this. Just leaving it blank
for now?

Matt

_______________________________________________

VoiceOps mailing list

VoiceOps@voiceops.org

https://puck.nether.net/mailman/listinfo/voiceops



Links:
------
[1] https://datatracker.ietf.org/doc/html/rfc3261.html
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Reply via email to