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

[Hadriel Kaplan <[e-mail]>]

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

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

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