[Sipping] Gen-ART review of draft-ietf-sipping-sbc-funcs-04.txt

[[e-mail]]

Authors,

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html)

Please resolve these comments along with any other Last Call
comments you may receive.

Document: draft-ietf-sipping-sbc-funcs-04.txt
Reviewer: David L. Black
Review Date: 7 January 2008
IETF LC End Date: 16 January 2008

Summary:

This draft is on the right track, but has open issues,
described in the review.

Comments:

This draft is generally in good shape and well-written.  Most
of these comments are nits, but I consider the following
three to be minor open issues:
	a) NAT problem not explained (3.4.1)
	b) Scope of Protocol Repair needs to be broadened (3.6)
	c) Recommendations need to cross-reference problems (4)
These are marked with *** in the comments below.

End of Section 2: the intuition behind the terms "inner
network" and "outer network" should be explained.  It
appears that the SBC is logically associated with the inner
network and provides functions such as controlling and
protecting access to the inner network from the outer
network.

Section 2.2:

   Some endpoints may be behind enterprise or residential NATs.
   In cases where the access network is a private network, the
   SBC is the NAT for all traffic.

"the NAT" --> "a NAT" and add a sentence calling attention to
the possibility that SIP traffic may get NAT'ed more than once
(e.g., in Figure 3, traffic to/from UA3 may get NAT'ed at both
the NAT and the SBC if the Access Network is a private network).

The last paragraph of section 3.1.3 rapidly switches from
topology hiding to identity hiding.  The relationship
between these two should be explained.

Section 3.2.1:

   Some operators do not want to manage the traffic (e.g.,
   allowing only certain codecs), but only to monitor it ...

The parenthetical example "(e.g., ..." is very poorly placed.
It should be moved into the previous paragraph.

Section 3.2.2 - Add "requirements of Authenticated Identity
Management" just before the citation of [3] for clarity.

"o=mhandley" - while I realize this came from RFC 2327, please
use an example other than Mark Handley's username.  "caller"
or "callee" would be fine.

*** Section 3.4.1 doesn't completely explain the NAT problem
before it describes the solution.  It looks like the primary
NAT problem is keeping the NAT binding for the control
connection active, hence the decreased validity time to force
an earlier REGISTER to refresh the binding state.  That needs
to be explained in the first paragraph, and it needs to be
clear that this is about a NAT outside the SBC (e.g., the NAT
in Figure 3, not the NAT that may be in the SBC), as an SBC
presumably does not need to resort to this sort of subterfuge
to keep a NAT binding active in a NAT that's part of the SBC
itself.

I presume that media traffic is sufficiently continuous that
its NAT bindings are self-sustaining, right?  That should
also be stated.

The fourth paragraph in Section 3.4.1 ("Operators implement
...") is about a lot more than NATs (e.g., it applies in the
complete absence of NATs).  It probably belongs somewhere
else; at a minimum, it's also related to access control (3.5).

Section 3.4.2 - please provide examples and citations for
end-to-end confidentiality and integrity mechanisms used
in practice.

Section 3.4.2, last sentence - surely there are rules of
thumb that work for choosing NAT binding refresh periods
that usually work.  Section 3.5 of
draft-ietf-tsvwg-udp-guidelines-04.txt is one place to
look, and this should probably be referenced.

Section 3.4.3:

   Naturally also other measures need to be taken in
   order to enable the NAT traversal, but this example
   illustrates only one mechanism for preserving the
   SIP related NAT bindings.

That's somewhat cryptic - a brief explanation of the
"other measures" would be an improvement.

Section 3.6.1, end of first paragraph - explain what is
meant by "protocol conversion": conversion of which
protocol between what and what?

*** Section 3.6.1 describes repairing messages "generated
by not-fully-standard clients" but the example in Section
3.6.3 involves a correct message sent to a client that
doesn't implement the entire standard.  Section 3.6.1
needs to be rewritten to encompass the example.

Section 3.7.1 - provide an example of the encryption
techniques used.

*** Section 4 should cross-reference the requirements back
to subsections of Section 3.  I think the cross references
are:
- Req-1 (topology hiding): 3.1
- Req-2 (redirect via intermediary): 3.2, 3.4, 3.5, others?
- Req-3 (capability mismatch): 3.3
Section 4 should also list items not completely addressed,
i.e., those for which SBC "hacks" and/or not-completely
standard SBC interposition will continue to be needed.

The Security considerations section should point out the
security motivations for some SBC functionality. This
arises in a number of subsections of Section 3.

idnits 2.05.03 ran clean (no errors or warnings).

----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------



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