Subject: [straw] draft-ietf-straw-b2bua-stun-00 review

From: Ari Keränen <[email-masked]>
Date: Mon, 19 Jan 2015 10:23:43 +0200

Hi,

Here's my review of the "STUN Message Handling for SIP B2BUAs" draft.

In general I think the draft is well written, but it would be good if 
the goals of the document were more clearly articulated. I assume the 
point is to make sure that NAT traversal with ICE works also when there 
are B2BUAs in place, but that seemed now only implicit. Or are there 
other/additional goals? It would be good to articulate the goals in the 
abstract and/or intro and show how these goals are achieved in the 
normative part.

There is also detailed discussion for media-place B2BUAs but hardly 
anything for other B2BUAs. Should something normative be discussed for 
those too?

Also the draft is missing security considerations section.

Some more detailed comments below.

1.  Introduction

    [RFC7362]
    describes how B2BUAs can perform Hosted NAT Traversal (HNT) to solve
    the NAT traversal problem.

"solve" is a bit strong word here. RFC 7362 itself advises against the 
mechanisms described there, so perhaps say, for example: "[RFC7362] 
describes how B2BUAs can perform Hosted NAT Traversal (HNT) in certain 
environments."

3.1.  Overview

    When one or both of the endpoints are behind a NAT, and there is a
    B2BUA between the endpoints, the B2BUAs MUST support ICE

Does this apply to all B2BUAs, e.g. plain Proxy-B2BUA? That would not 
necessarily need to do, nor support, ICE at all?

3.2.  ICE Termination with B2BUA

       If the B2BUA is in ICE lite mode as described in section 2.7 of

When would the B2BUA be in lite and when in full mode? Should the B2BUA 
just follow the recommendation of 5245 for the agents or is there 
something more to take into consideration?

3.3.  ICE Passthrough with B2BUAs

       The B2BUAs candidates will have lower-priority than the candidates
       provided by the endpoint, this way endpoint and remote peer

This sentence seems to imply that the B2BUA candidates would 
automatically have lower priority. Is that the case (if so, where is it 
defined)? Or should there be some RFC2119 language about that?

4.  Security Considerations

This obviously still needs to be done.

At least issues regarding B2BUA being able to see all (intended 
end-to-end?) secure traffic when terminating secure connections should 
be discussed or if this is already discussed in another document, that 
could be referenced.

Cheers,
Ari

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 19 Jan 2015 17:06:24 +0000

Hi Ari,

Thanks a lot for your review and comments. See inline

-----Original Message-----
From: Ari Keränen <[email-masked]>
Date: Monday, 19 January 2015 8:23 am
To: "[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>
Subject: [straw] draft-ietf-straw-b2bua-stun-00 review

>abstract and/or intro and show how these goals are achieved in the

I will add below text for the same.

"The goal of this draft is to ensure that NAT(Firewall) traversal with ICE
works also when there
are B2BUAs in place and the B2BUAs handle ICE messages properly²

>anything for other B2BUAs. Should something normative be discussed for

Other types of B2BUA as defined in RFC 7092 (like signaling plane only,
proxy e.t.c) does not handle media /come in the media path.  This drafts
picks up the B2BUA types that come in media path. I am not sure if we need
any text for other types.  Perhaps some text to just say that other types
of B2BUA would have no considerations as they don¹t come in media path
should be enough.

>Also the draft is missing security considerations section.

Yes we will add the same.

>describes how B2BUAs can perform Hosted NAT Traversal (HNT) in certain

Agree. Will re-word it

>necessarily need to do, nor support, ICE at all?

Right. I think I will set the expectation at the beginning of the draft
this is applicable for only B2BUAs that are in media path, not the other
ones.

>something more to take into consideration?

As I can see the recommendations of 5245 is enough. We don¹t need any
thing else. 

>defined)? Or should there be some RFC2119 language about that?

Good point. This is needed for only those cases where B2BUA prefers not to
be in media path(the decision to be in or not is not in the scope of this
draft) if endpoints can reach directly. Only if endpoint fails to reach
and you don¹t have a TURN server and rather wants to use B2BUA then ICE
checks will try B2BUA candidates (as it has lower priority) to see if it
can reach by relaying via B2BUA.
>be discussed or if this is already discussed in another document, that

Yes. We will add some text here for sure

Ram
>
>
>Cheers,
>Ari
>
>_______________________________________________
>straw mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/straw

---

From: Ari Keränen <[email-masked]>
Date: Tue, 20 Jan 2015 15:44:44 +0200

Hi Ram,

Your suggestions look good to me. One additional comment below.

> As I can see the recommendations of 5245 is enough. We don¹t need any

In that case maybe you want to be a bit more clear on that. For example 
say that the recommendations for ICE agents set forth by 5245 also apply 
to B2BUAs. See especially https://tools.ietf.org/html/rfc5245#appendix-A

Cheers,
Ari

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 20 Jan 2015 14:05:26 +0000

Sure. Will do that.

Thanks,
Ram