Subject: [Gen-art] Gen-art LC review of draft-ietf-mmusic-latching-05

From: Elwyn Davies <[email-masked]>
Date: Tue, 27 May 2014 17:35:03 +0100

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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

Document: draft-ietf-mmusic-latching-05.txt
Reviewer: Elwyn Davies
Review Date: 27 May 2014
IETF LC End Date: 28 May 2014
IESG Telechat date: 29 May 2014

Summary: Ready with nits.  Generally a well argued document.  In the
light of the comment that the IETF advises the use of ICE or STUN rather
than HNT, I wondered if it might be helpful to explain how these
mechanisms mitigate or resolve the security issues in s5.   

Major issues:
None

Minor issues:
s5: Section 4 talks about problems with XMPP but the security concerns
in s5 are all discussed in the context of SIP/SBC.  I think some words
about the corresponding security issues in XMPP (or just a statement
that all - or a subset - of these apply to XMPP) ought to be added.

s8: <Heresy Starts> Barry Leiba in his comments in the tracker suggests
that the references would be usefully split into Normative and
Informative subsets.  Given the number of references, splitting them up
seems like a good idea.  I am going to suggest something highly
heretical:  Split them up but call them "Key References" and "Additional
References".  "Normative" has become such a loaded word in the standards
community that, despite its underlying English meaning, it is probably
better to confine its usage to Standards Track documents.  I feel that
we usefully adopt this alternative classification for non-standards
track documents as a general technique to avoid the ongoing discussions
about split refetrence sections. <Heresy Ends> 

Nits/editorial comments:
General:  Would probably be useful to explain the "address:port"
terminology;  Also both the terms "couple" and "set" are used for the
tuple - better to stick with one and use "address:port sets/couples"
instead of "address:ports".

General: s/e.g./e.g.,/g

s1:  Need to expand SDP

s3, last sentence:
OLD:
the SBC may decide not to send media to that customer UA until a SIP 200
response for policy reasons, to prevent toll-fraud.
NEW:
the SBC may decide, for policy reasons, not to send media to that
customer UA until a SIP 200 response has been received, [e.g., ???] to
prevent toll-fraud.

s4, para 1: s/ address:port set that once packets cross the NAT, will be
mapped/address:port set that, once packets cross the NAT, will be
mapped/

s4, Figure 2:  The figure doesn't reflect the address mapping done in
the NATs.  the clients Alice and Bob are shown with public
(documentation) addresses whereas they should presumably have private
addresses that are mapped to these public addresses by the NAT.

s4, Figure 3: The previous comment doesn't apply to this figure which
shows the NAT mapping.  Arguably it would be nice to use private address
space addresses on the private side of the NAT, but I notice we never
managed to allocate a specific private address for documentation - I
suppose since they are private it doesn't matter!

s4, Figure 3, title: Cut and paste error... this figure is about XMPP
not SBC!

s5, para 2: s/In all/All/

---

From: Barry Leiba <[email-masked]>
Date: Tue, 27 May 2014 13:07:52 -0400

> about split refetrence sections. <Heresy Ends>

That would address the spirit of my concern, and I'd be happy if we
went in that direction.

I think the RFC Editor would push back, as their Style Guide has an
effect on this as well... so if we do want to go in this direction, we
should head to rfc-interest and pose it as input to the updated RFC
Style Guide that they're working on.

Barry

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 May 2014 15:19:13 +0300

Elwyn: many thanks for your review. Authors, do you have any responses or corrections, based on the s5 minor issue and nits listed below?

Jari

On 27 May 2014, at 19:35, Elwyn Davies <[email-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Emil Ivov <[email-masked]>
Date: Wed, 28 May 2014 16:06:57 +0200

Hey Jari, all,

On Wed, May 28, 2014 at 2:19 PM, Jari Arkko <[email-masked]> wrote:
> Elwyn: many thanks for your review. Authors, do you have any responses or corrections,
> based on the s5 minor issue and nits listed below?

I was thinking of addressing them all in bulk once all the IESG
comments were in. Apologies if that's considered a poor practice. I'll
try to respond to all of them today.

As for the S5 one: yes the concerns and solutions apply for XMPP the
same way as they do for SIP. We will clarify that in the next
revision.

Emil

-- 
https://jitsi.org

---

From: Barry Leiba <[email-masked]>
Date: Wed, 28 May 2014 10:19:36 -0400

> try to respond to all of them today.

We generally hold document updates and batch them (though that varies
too), but individual responses, sooner, is usually best.

Barry

---

From: Emil Ivov <[email-masked]>
Date: Thu, 29 May 2014 18:17:25 +0200

Hey Elwyin,

Thanks for reviewing! Comments inline:

> mechanisms mitigate or resolve the security issues in s5.

Good point. How about this:

-  A common concern is that an SBC that implements HNT may latch to
-  incorrect and possibly malicious sources.  A malicious source could,
===
+  A common concern is that an SBC that implements HNT may latch to
+  incorrect and possibly malicious sources.  The ICE [RFC5245] protocol
+  for example, provides authentication tokens (conveyed in the ice-
+  ufrag and ice-pwd attributes) that allow confirming the identity of a
+  peer before engaging in media exchange with her.  Without such
+  authentication, a malicious source could,

> that all - or a subset - of these apply to XMPP) ought to be added.

How about:

-   A common concern is that an SBC that implements HNT may latch to
===
+   A common concern is that an SBC (or an XMPP server, all security
+   considerations apply to both) that implements HNT may latch to

> about split refetrence sections. <Heresy Ends>

Sounds good to me. Fixed.

> terminology;

OK, how about:

-  An UA behind a NAT streams media from a private address:port set that
-  once packets cross the NAT, will be mapped to a public set.
===
+  An UA that is behind a NAT would stream media from an address and a
+  port number (an address:port couple) that are only valid in its local
+  network.  Once packets cross the NAT, that address:port couple will
+  be mapped to a public one.

> Also both the terms "couple" and "set" are used for the

Agreed. Fixed.

> General: s/e.g./e.g.,/g

OK

> s1:  Need to expand SDP

Done

> customer UA until a SIP 200 response has been received, [e.g., ???] to

OK

> mapped/address:port set that, once packets cross the NAT, will be

This one disappeared with one of my other changes.

> addresses that are mapped to these public addresses by the NAT.

We used to have private addresses there but were asked (I think by a 
previous chair) to replace them with documentation ones because they 
would be more appropriate. Could you please confirm that using typical 
NATed addreses wouldn't break any policy?

For the sake of completeness, nothing would prevent any address from 
appearing behind a NAT (even public-looking ones) so this is only about 
increasing the clarity of the example.

> suppose since they are private it doesn't matter!

I am fine either way.

> s4, Figure 3, title: Cut and paste error... this figure is about XMPP

Thanks

> s5, para 2: s/In all/All/

Fixed

Thanks again for your review!

Emil
-- 
https://jitsi.org

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 30 May 2014 17:03:21 +0100

Hi, Emil.

A couple of points below - I have deleted the agreed ones.

I had a quick look through -06 and it looks fine to me except for a
couple of mnor points noted below (and a s/i.e./i.e.,/ in the new text
in s2, para 2). If I was being *really* pedantic I could argue that
"(i.e. the SIP SBC and media relay are co-located on the same host)" 
needs to have "and using the same subnet" but that's probably a nit too
far. ;-)

> +  authentication, a malicious source could,

That looks good.  Suggest: s/that allow confirming the identity of a
peer/that allow the identity of a peer to be confirmed/
> Sounds good to me. Fixed.
WE'll see what the RFc Editor has to say about this!

> +  be mapped to a public one.
Looks good.

<<snip>>

> > suppose since they are private it doesn't matter!

Ultimately it doesn't really matter whether private or documentation
addresses are used... we are just more used to seeing private addresses
on the non-public side of NATs.  I don't know what general policy is
supposed to be so I have asked my fellow gen-arters for a view.  I
haven't heard back yet.

What I think would be useful would be to show the NAT address mapping in
Figure 2 as you have done in the XMPP Figure 3.

<<snip>>

> Thanks again for your review!

Thanks for the reponse.

Regards,
Elwyn