Re: [stir] draft-kaplan-stir-ikes-out

["Anton Tveretin" <[e-mail]>]

I think we should discuss scenarios involving different networks first.
Consider a SIP-> PSTN call. The gateway IMO should perform validation, and 
transcode IKES information. But caller might have only SIP AoR 
(e-mail-style) and no telephony-style number. So the caller becomes unknown. 
Also, it is unlikely that anyone will do validation on PSTN side.

PSTN -> SIP. Probably IKES is not deployed on PSTN side. So the gateway 
should supply it.

SIP -> PSTN -> SIP. The second gateway must recognize IKES even though it 
does no validation. Remember that caller might be unknown?

I do not know whether SIP<->H.323 gateways exist.

SIP->PSTN->H.323? IKES would be available to the callee, but not to 
gatekeepers, unless it is delivered with RAS. But it is GK that admits or 
not. So "do not admit unvalidated calls" policy implies that IKES is passed 
with RAS.

Of course, scenarios as SIP->PSTN->H.323->PSTN->SIP->PSTN->H.323 are also 
possible, esp. if consider private networks.

I think it is nothing wrong with covering other protocols. Or, should say 
RFC 2225 (IPOA) be approved by ITU?

Everything in this message is under question  (?).

----- Original Message ----- 
From: "Hadriel Kaplan" <[e-mail]>
To: "Anton Tveretin" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, August 05, 2013 1:27 AM
Subject: Re: [stir] draft-kaplan-stir-ikes-out



On Aug 4, 2013, at 2:26 PM, "Anton Tveretin" <[e-mail]> wrote:

> Why should addresses be included into IKES? IMO that adds nothing but 
> extra work
> for each validator.

By "included" you mean included in the IKES-IF string encoded in the message 
itself, e.g. the LIKES-IF SIP header?  It's only included that way in SIP 
and XMPP.  It's included in them for two reasons:
1) To provide a quick match mechanism that can be performed before having to 
retrieve a cert/pub-key and performing public key crypto.  If the canonical 
identities the verifier generates from the received To/From URIs don't match 
the ones in the LIKES-IF header, it knows it's a failure and not to bother 
checking the signature.  If they match, then it goes and checks the 
signature.  It's an optimization, but a useful optimization, especially for 
call-forwarding cases to figure out which destination identity to check the 
signature for.

2) To provide troubleshooting help.  There's a concern that the 
"canonicalization" process performed by the signer and verifier domains 
might lead to different identities, resulting in a IKES verification failure 
when it should instead succeed.  By having the signer insert its values into 
the new header, the admin of the receiving domain can figure out if his 
canonicalization policies are wrong or not.


> Chapter 11 (error): in DSS1, call termination is done with 3 messages
> (DISCONNECT/RELEASE/RELEASE COMPLETE). In H.225.0 call control, just one
> (RELEASE COMPLETE). This error must be corrected.

Yup, good catch - will do on next revision.


> H.225.0 call control contains h323-uu-pdu, which coexists with 
> user-information, and thus it actually does not count to 131 bytes of ISDN 
> User-to-User IE. So I think it is possible to combine all ISDN (ISUP, 
> DSS1, H.225.0 CC).

Yeah I knew H.225 could have its own - in fact one could just define new ASN 
definitions for real/defined fields for the IKES information.  See below for 
more on that...


> But, for H.323 it would be more critical to supply IKES in RAS (e.g. ARQ) 
> and H.501 messages IMO.

Why is it critically important for RAS?


> Yes, H.323 Forum might have a different opinion about H.323 dying. Anyway, 
> H.323 users deserve new features, practice shows that.

Huh.  I was under the impression is was on its last legs, even in video 
conferencing. (but then I don't personally focus on the video conferencing 
market, so I could be way off there)  Regardless, I can certainly update the 
draft for H.323 usage, and I will remove the incorrect claim that its dead.

Do you think it would be better to just remove H.323 from this draft 
completely, and let the relevant parts for H.323 be worked out in H-series 
docs by the ITU/whomever?  That way we don't have to have any new ASN 
definitions for the IKES information in this IKES draft, for example.


> And what about other networks, e.g. GSM?

Right now the draft just says: "Other protocols wishing to support IKES need 
to define their own mapping to the values defined in this document."

I didn't want to go and document one for every possible protocol in this one 
IKES document - I figure if IKES gets deployed and used then other protocol 
groups will do so in their own documentation, if they want to.  Like for 
example BICC, IAX, etc.  All I wanted to do was prove it could be done for 
other protocols, and in particular define how it could work for SIP and 
SS7/ISUP.  Even the XMPP usage might be better off in a separate doc, in the 
IETF STOX working group or in an XSF XEP.

-hadriel