[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] SIP Identity using Media Path
> > I just submitted a draft, "SIP Identity using Media Path", which
> > describes a mechanism that allows RFC4474-like signatures and also
> > allows SBCs and B2BUAs to modify the message's SDP. Links to HTML
> > and plain text versions of the Internet Draft are below.
>
> It's nice to see work like this that tries to handle the reality of
> installed networks instead of pretending that SBCs don't exist.
Thanks.
> I'm not sure that I grasp this completely yet, but I'll let it simmer
> for a while and give it another read later.
>
>
> === Comments ===
>
> Section 3, figure 1:
>
> This figure is a simplification, since many enterprises will
> have their
> own SBCs on their borders:
>
> <--- Enterprise-A ---->
> clients --- PBX --- SBC --- SP1-SBC-1 --- SP1-SBC2 ----+
> |
> +------------------------------------------------------+
> |
> | <--- Enterprise-B ---->
> +--- SP2-SBC1 --- SP2-SBC2 --- SBC --- PBX --- clients
True. I'll figure out a clearer way to diagram that.
> Section 3, "mailto URLs" para:
>
> sp1.net and sp2.net (and, later in the document, sp3.net) are (or at
> least could be) real domains that shouldn't be used.
Agreed; I may go with "sp1.example.net" and "sp2.example.net",
although this is less clear than using unique top-level domain
names.
> Section 4.1, item about Contact:
>
> How can the Contact header usefully be used in the signing process? An
> SBC along the message path will happily replace it.
I have removed that in -01 (which isn't yet published, of course). There
was some thought it was necessary, but I agree it should be removed
from the signature.
On a similar note, I am considering removing CallId from the signature.
Oftentimes the Call Id value contains an IP address (in dotted decimal
or hex), and an SBC or B2BUA may also want to rewrite such a CallId. I
have made a note of that in -01 so this can be discussed.
> === Editorial nits ===
Thanks for the list of nits - I'll get those cleaned up in -01.
-d
> In the text, RFC references are sometimes written "RFCxxxx" and
> sometimes "RFC xxxx". Decide on one alternative.
>
>
> Section 3, figure 1:
>
> > +----[SP1-SBC1]-[SP1-SBC1]---[SP2-SBC1]-[SP2-SBC2]----+
>
> SP1 has two SBC1. One of them should be SBC2.
>
> Section 3, first para after figure 1:
>
> > using a mailto URL (e.g., 'sip:john.doe@xxxxxxxxxxx')
>
> Both here and a couple of paragraphs below (under "Mailto
> URLs:"), sip:
> URLs are refered to as mailto URLs which sounds very strange.
>
> Section 3, "mailto URLs" para:
>
> > SP1 would validate the RFC4474 signature modify the SDP.
>
> I can't make sense of this sentence. What should it mean?
>
> > So that a
> > new RFC4474 signature can be created using its own
> public/private
> > key pair, SP1 needs to modify the From: field.
>
> Rewrite this sentence to
>
> >> SP1 needs to modify the From: field so that a new RFC4474 signature
> >> can be created using its own public/private key pair.
>
> > Unlike with E.164
> > numbers which are globally unique, the SP1 isn't able to
>
> Remove the "the" in front of "SP1".
>
>
> Section 4, second list item:
>
> > o This new header is signed in addition to the same set of SIP
> > headers signed by RFC4474 (detailed in )
>
> Detailed in what?
>
>
> Section 4, para before figure 2:
>
> > In practice, if the
>
> The rest of this sentence has gotten lost somewhere. Please
> contact the
> information desk.
>
>
> Section 4, step 1:
>
> > Step 1: Originating endpoint prepares to send an Invite and chooses
>
> "INVITE"
>
> > then sends the Invite to its local SIP proxy.
>
> "INVITE"
>
>
> Section 4, step 2:
>
> > into the new Identity-Media header. The invite is forwarded
>
> "INVITE"
>
>
> Section 4, step 4:
>
> > the Invite. It validates the Identity-Media signature is
> > valid and was validates it was generated by the
> originating
>
> "INVITE"
>
> Insert "that" after "It validates". Change "was validates" to
> "validates
> that".
>
>
> Section 4, step 5:
>
> > authentication service forwards the Invite to the endpoint.
>
> "INVITE"
>
>
> Section 4, step 6:
>
> > challenge technique from the Invite, and performs that
>
> "INVITE"
>
>
> Section 4, step 7:
>
> > public key. The terminating endpoint validates the
>
> Insert "that" after "validates".
>
>
> Section 4, step 8:
>
> > Step 8: You can reliably and honestly indicate calling party
> > information ("caller-id") to the terminating
> endpoint, and
> > ring their phone.
>
> Rewrite to
>
> >> Step 8: The terminating endpoint can reliably and
> honestly indicate
> >> calling party information ("caller-id") and ring
> the phone.
>
>
> Section 4.1, first para:
>
> > "fingerprint"). The specific SDP attribute that are signed depends
>
> "attributes"
>
>
> Section 4.1, second para:
>
> > The SIP headers that are signed are signed the same as done by
>
> Remove the second "signed".
>
> > the body is not signed. They signed headers are:
>
> "They" -> "The"
>
>
> Section 4.1, item about Date:
>
> > the weekday and month items case set as shown in BNF in RFC 3261.
>
> Insert "the" before "BNF".
>
>
> Section 4.2:
>
> > The authentication service examines the SIP message body for the
> > application/sdp Content-Type. For all such content-types
> found, the
>
> "all such content-types" -> "all such message bodies"
>
>
> Section 5, para 3:
>
> > or HIP session and validates the certificate fingerprint
> presented in
> > SIP signaling matches the certificate presented in the TLS, DTLS,
>
> Insert "that" after "validates" and insert "the" before "SIP".
>
>
> Section 5.2:
>
> Newline missing after SDP example.
>
>
> Section 5.3.1:
>
> > subsequent PK-CHALLANGE and PK-RESPONSE, in its SDP. The
> syntax is a
>
> "CHALLENGE"
>
>
> Section 5.3.2.1:
>
> > 5.3.2.1. PK-CHALLANGE
>
> "CHALLENGE"
>
>
> Section 7.1:
>
> Write the list items as complete sentences, i.e. start with
> capitals and
> remove ", or" from the end of the first item.
>
> > the device to manufacture a new self-signed certificate (or public
>
> Insert "needs" after "the device".
>
>
> Section 10.1:
>
> > This example shows how two a=fingerprint lines in SDP would populate
> > a the Media-Fingerprints SIP header field. The following is an
> > example of an Invite created by the endpoint.
>
> "a the" -> "the"
>
> "INVITE"
>
>
> Hans
>
> --
> Hans Persson <hasse@xxxxxxxxxx> Ingate - Firewalls with SIP & NAT
> Ingate Systems AB +46 13 210857 http://www.ingate.com/
>
> Private: <unicorn@xxxxxxxxxxxxxx>
> http://www.lysator.liu.se/~unicorn/