Subject: [Speermint] Review of architecture-09

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 20 Jan 2010 16:36:01 +0100

In the light of the LC, i have reviewed
draft-ietf-speermint-architecture-09. Here are my comments:

Generally, i think that some of the issues i have listed below require
an additional revision before we progress the draft. I've found content
as well as editorial issues, and i suggest solving those before we
proceed the draft.

More details:

- The draft has a number of idnits - those should be solved:
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-speermint-architecture-09.txt

Most obvious are the over-long lines, and the outdated references.

- nit: 3.1 is the only sub-secion of 3. - this is sometimes considered
misuse of sections...

- Acronyms are not expanded on first use - i've spotted "UA", "ENUM",
"SIP", "URI", "NAPTR", "SRV", "EvRC" (??)

- "Figure 2" is referenced a few times, eg. on page 4, even though
there's just "figure 1".

- Content: Page 5, first line: "intra-SSP" should probably be clarified
as "resource within the originating SSP"

- Typo: Page 5, bullet 4: "tec" is probably supposed to be "text"?

- Content: Page 5, "In case the target SSP changes..." What does that
mean? I thought the that "target SSP" would be the ultimate destination,
and hence the "target SSP" cannot "change" (except in cases like
porting...) If this is about a "transit" case, then we have a
terminology problem - that would then be the "next hop SSP"? The only
exception might be when a session gets redirected to a different SSP -
is that case meant here? Also, the reference to "figure 2" is pointing
nowhere..

- Typo: Page 5: "communicator" -> "communicate" in section 3.1

- Content: Section 3.1: there seems to be a confusion between "network
elements" and "functions". If i understand it correctly, then "elements"
implement "functions", hence "elements" can only communicate with other
"elements", but not with "functions", because the "functions" are
something abstract?

- Content: Section 4.4.1: The definition of "LUF" in RFC 5486 is
different from what is stated here. RFC 5486 says the LUF returns the
"target domain", and not the address of the SF or the target SSP...
Again, a terminology problem around the famous "no-man's land" between
LUF and LRF..

The draft itself says in 4.1.2 that the *LR* discovers the "next hop SF"
(page 6, bottom)

An option would be to state in 4.1.1 that "the LUF identifies the target
 SSP for a given request"?

- Content: Section 4.1.1.1 "performs a Lookup Function (LUF) to
determing the target address" should probably also be "... to determine
the target SSP"?

- Nit: page 7, line 3 "may be used" should read "need to be used"?

- Nit: "originating SSP" and other terminology should be written as
"Originating SSP", so that those terms are easier distinguished from
other "non-terminology" text. (for example, first line of 4.1.2.1 - in
4.1.2.2, "Originating SSP" is already capitalized)

- Content: 4.1.2.1 - What is an "receiving SSP"? Is that the "Target
SSP", or some intermediate SSP?

- Content: 4.1.2.1 says "when communicating with another SSP" might be
redundant, because intra-SSP communication is out of scope anyway?

- Nit: 4.1.2.3: "communicationS" -> "communication"

- Content: Page 8, first line: "a SF may perform"... I think that should
be "a SBE may perform", or "a SF of an SBE" (like a few lines down) -
not sure if this is intentional, though.

- Content: 4.1.3.1.1 - The sentence is a) completely broken and b)
contradicts the recommendation (?) to select TLS in 4.1.2.1

- Content: Section 5 "Peering must occur in a common IP address space" -
what is meant by this? The whole internet is a "common IP address space"
(or, actually two spaces, if you consider v4 and v6). I *think* i
understand what is meant here ("a broadcast domain"?), but the
definition is extremely vague...

- Content: Section 4.2.1.1, last sentence: My local SIP guru here says
that checking the "From" header against the client TLS certificate might
be dangerous in transit scenarios, because it might contain the domain
of the originating SSP, while the client certificate would be from the
intermediate SSP. Also, he notes that verifying both the Identity
headers *and* the From header might be too much of verification...

- Content: Section 6, Security Considerations are weak: An "optional
requirement" is somehow a contradiction, and not really convincing,
particularly in the field of Security.. Maybe change that to
"cryptography should be required unless physical security..." Also, i
don't see the work requested in the second paragraph happening anywhere...

- Nit: RFC2119 is referenced, but i don't see a single RFC2119-style
MAY, MUST etc. in the draft. It might be safe to remove the reference to
RFC2119.

tia,

Alex

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Thu, 21 Jan 2010 16:13:37 -0500

I have a problem with Section 4.1.1.2 which implies that an ENUM look up
is necessarily of a public End User ENUM record. This was not originally
the case and I'm not sure what the rationale is for eliminating other
options. This is particularly so since the Public End User tree is
pretty sparse at this point (to say the least) while various parties are
already using private trees and several efforts are underway to
construct potentially wide ranging infrastructure ENUM trees. 

I suggest rewriting the first sentence to read

If an external E.164 address is the target, the originating SSP consults
an ENUM registry, which could be the
   public "User ENUM" rooted at e164.arpa, according to the procedures
described
   in RFC 3761. Alternatively, the originating SSP may consult an
infrastructure ENUM registry (see RFC 5067) or a private registry to
identify to the 
   carrier of record.

Penn Pfautz
AT&T Access Management
+1-732-420-4962