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

From: "Anton Tveretin" <[email-masked]>
Date: Mon, 5 Aug 2013 00:26:03 +0600

Hello,
First, I thank you, Hadriel, for the work done.
See my notes, though.
Why should addresses be included into IKES? IMO that adds nothing but extra 
work
for each validator.
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.
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).
But, for H.323 it would be more critical to supply IKES in RAS (e.g. ARQ) 
and H.501 messages IMO.
Yes, H.323 Forum might have a different opinion about H.323 dying. Anyway, 
H.323 users deserve new features, practice shows that.
And what about other networks, e.g. GSM?
Sincerely yours,
Anton.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 4 Aug 2013 15:27:33 -0400

On Aug 4, 2013, at 2:26 PM, "Anton Tveretin" <[email-masked]> 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.

> (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

---

From: "Anton Tveretin" <[email-masked]>
Date: Tue, 13 Aug 2013 22:02:39 +0600

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" <[email-masked]>
To: "Anton Tveretin" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 05, 2013 1:27 AM
Subject: Re: [stir] draft-kaplan-stir-ikes-out

> Why should addresses be included into IKES? IMO that adds nothing but 

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.

> 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...

> 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

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Aug 2013 16:14:53 -0400

On Aug 13, 2013, at 12:02 PM, Anton Tveretin <[email-masked]> wrote:

> 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.

I'm not following you.  If a SIP user only has an email-style source identity with no corresponding telephone number, there's not much we can do about that.  The user will either get a generic domain-wide or gateway telephone number (as Skype users do, for example), or they'll be anonymous (or 'unknown' as you mentioned in another email).

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

Sorry I don't understand in what way you mean that.  Supply what?

If the call comes in from the PSTN without IKES, there are 3 things the PSTN-SIP gateway can do:
1) it can copy the CgPN into the SIP From, but can't generate an IKEs thing for it since it's not authoritative for the CgPN and doesn't have a private key to sign it with. (nor should it)
2) it can generate a From using some generic telephone number assigned to the gateway, which it can theoretically generate an IKES signature for but probably shouldn't.
3) it can generate an anonymous (or 'unknown') From, which obviously means no IKES signature.

Are you saying it should do (1) but with an IKES signature, or are you saying it should do (2) but with an IKES signature?

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

I don't follow what you're asking/pointing-out above.

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

Yup, plenty do.

> 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.

Hmmm... yeah I can see that, but not sure if it makes more sense to just have the GW perform the IKES verification, and then send the GK a flag in the RAS indicating it's been successful or failed to validate.  

ISTM this type of thing is better decided in ETSI or ITU or someplace that makes H.323 standards decisions... so I think it makes more sense to pull H.323 out of the IEKS draft and leave it up to another SDO to decide how to handle.

> 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?

We do cover other SDO protocols in the IETF, and even multiple SDO protocols in one RFC - but my impression is we only do that when there's sufficient expertise in the IETF to do so, or when we get contributions from the other SDO.  Afaik, there are very few people in the IETF who are active in H.323 anymore - there are some in the video side, and a couple in other places, but I wouldn't be comfortable deciding anything about it without reaching out to the other SDOs.

-hadriel