Subject: [Sipping] Review of draft-schwartz-sipping-spit-saml-01

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 19 Jul 2006 17:39:27 -0500

Hannes, David:

I have reviewd draft-schwartz-sipping-spit-saml-01.  While the
intent of the draft becomes clear on a detailed reading, I believe
that you may have to substantively clarify the text in several
places.  Here are the comments that I hope will aid in this.

1/ In the Introduction (Section 1), it is mentioned that, "All
  that is needed using SIP is a User Agent Client (UAC) that
  initiates, in parallel, a large number of calls."

  I think that a UAC initiating in sequence a large number of
  calls suffices as well; or better yet, a bank of zombie'd
  UACs that serially attempt a call.  In other words, I don't
  think the characteristic of being parallel is a pre-requisite
  to spit.

2/ In Section 3.2, it is stated that "The approach described in
  this document works in a number of different environments..."
  Yet, three bullet lists down, it is stated that P2P trust
  model is in sufficient churn that the approach described in
  this document is for further study in such networks.

  The most expedient thing would be to simply take out the third
  bullet item.  If you do so, then excise all parts of the
  text that use "P2P and "Super Node".

3/ There are two static attributes (Type attributes) defined:
  IdentityStrength and CostOfCall.

  There is one simplying assumption that is made when defining
  IdentityStrength: Calls originating on the PSTN will have a
  high value since the Caller ID associated with a PSTN call
  has a perceived higher degree of trust.  This seems fuzzy:
  what about a telemarketer who uses the PSTN to spit?  At
  some point, the telemarketed call will break out of the PSTN
  into the Internet.  I don't think that call origination on
  the PSTN is a good enough criteria to accord this call a
  higher trust metric.

  For this reason, I think you may need to break the value of
  3 into its discrete components.  In fact, I almost think that
  the fact that the call came from a PSTN or an enterprise is
  really a flow attribute, and not a type attribute.  So you
  ought to have "3 - Physical premise verified", and move
  "Enterprise / PSTN based" to flow attributes.

  Also, I don't understand the purported value of 4 (User had
  to present a passport.  When is the passport presented?  To who
  is the passport presented?)

  Regarding CostOfCall, I will note that in the PSTN this has
  dubious value.  Telemarketers call regardless of the cost
  of the call.  Cost of the call will be less of an issue on
  the (big-I) Internet (we don't do billing, right?); even
  for those Internet Telephony architectures that bill, if the
  practice of telemarketing in the PSTN is any indication,
  the cost will not stop spit.

4/ The XML snippet in Section 4.3 appears out of place.  I
  would have expected to see an XML schema definition somewhere
  in the draft, but could not find any.

5/ Regarding Figure 2, what are intermediaries D and F for?
  They are not used in the text describing the figure, and as
  such, I would suggest removing them to reduce clutter.

6/ I am trying to correlate the flow attributes under node B
  in Figure 2...I cannot tell what callsPMin corresponds to.
  Is it CallRate (Section 4.2.1)?  CallCompletionSuccessRate
  (Section 4.2.2)?  CallDurationConsistency (Section 4.2.3)?
  Likewise, what does ASR correspond to?  What does
  sameLngth correspond to?  It is not clear.  SSuspect
  corresponds to SpitSuspect, that one is clear.

7/ In the text below Figure 3, s/(3c)/(2c).  There isn't any
  3c in the figure.

8/ In Figure 3, as C, E, and G add their flow attributes, I
  would expect these to be additive (as Section 3.2.1 says).
  However, looking at the figure, it appears that C, E, and G
  are not adding anything; simply forwarding the flow attributes
  added by B.  Is this the intent?

9/ In Figure 4, there is a CRLF problem: headers such as
  To, From, Call-ID and others are all munged on one line.  The
  same goes for the SDP body as well.

10/ In Figure 4, I wish the SAML assertions were more
  descriptive.  Also I note that the assertions are carried in a
  header (Assertion).  Where is this header defined?  What are
  the semantics of this header?

11/ Nit: Section 2, when defining an Administrative Domain,
  you use an abbreviation: EU.  I believe that this is a stand-in
  for "End User", but this is not clarified.

12/ Nit: Same section, when defining Security Attributes:
  s/ASecurity information/Security information

13/ Nit: Same section, when defining Policy:
  s/to the receipt Security/to the receipt of Security

14/ Nit: In Section 4.2, define OAD (I think you mean Originating
  Administrative Domain).

15/ In Section 4.2.1:
  s/relative to the monthly average/relative to the average of
  a predefined time period.

16/ In Section 4.2.2, what is a successful call?  Only 200?
  Is 3xx response considered successful?  4xx-6xx clearly are not.

17/ In Section 4.2.3:
  s/the monthly average/average of a predefined time period

18/ Nit: Section 4.3, define TAD (Terminating Administrative Domain?)

19/ Section 5, second paragraph: define ASR.

That's it.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP