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

[Hadriel Kaplan <[e-mail]>]

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