Subject: [ppsp] comments to I-D.li-ppsp-nat-traversal-02

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Fri, 08 Jul 2011 17:50:40 +0800

Hi lichun,

I read your draft describing NAT Traversal for PPSP.

It's a good collection of potential solutions for NAT Traversal.

Some of my comments in below.

If RELOAD-ICE or STUN/TURN server is chosen, we don't need to make revision
to Tracker and peer protocol.

If other methods are chosen, different optional proposals are required for
each methods. Do you propose to add all these optional revision to Tracker
protocol in order to support all potential NAT Traversal methods?

In section 7.2.1, why not using Peer IP Add. ? 

You mentioned PPSP authentication. Currently, we introduced an
authentication method by issuing a certificate to identify peers along with
TLS. Any suggestions on authentication?

And if Peers have been authenticated, could we reuse ICE without
authentication? If yes, we don't need 7.5.

 

  _____  

Best Regards
Gu Yingjie

---

From: [email-masked]
Date: Thu, 14 Jul 2011 09:06:58 +0800

Hi, Yingjie

Please see inline.

BR
Lichun

"Yingjie Gu(yingjie)" <[email-masked]> 写于 2011-07-08 17:50:40:

> It’s a good collection of potential solutions for NAT Traversal.
> If RELOAD-ICE or STUN/TURN server is chosen, we don’t need to make 
> revision to Tracker and peer protocol.
> If other methods are chosen, different optional proposals are 
> required for each methods. Do you propose to add all these optional 
> revision to Tracker protocol in order to support all potential NAT 
> Traversal methods?

These revisions are either mandatory or optional for PPSP-ICE.
The decision of supporting NAT traversal or not and choosing which NAT 
traversal 
solution should be left to implementation. 
If PPSP-ICE is chosen, implementing/using optional revisions or not should 
also be left to implementation.

> In section 7.2.1, why not using Peer IP Add. ? 

Source peer doesn't know and doesn't need to know the destination peer's 
address that can be reached by proxy peer.

> authentication method by issuing a certificate to identify peers 
> along with TLS. Any suggestions on authentication?

I think TLS is good. HTTPS is widely deployed.

> authentication? If yes, we don’t need 7.5.

ICE connectivity checks use STUN/TURN protocol, which can not be protected 
by PPSP protocol's authentication.
ICE parameters also include host/reflexive/relayed address. Even ICE is 
not used, MediaAttach still need to exchange SDP without ICE parameters.

> Gu Yingjie

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Thu, 14 Jul 2011 17:10:26 +0800

Hi Lichun,

See inline please.

  _____  

Best Regards
Gu Yingjie

发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2011年7月14日 乐乐9:07
收件人: Yingjie Gu(yingjie)
抄送: [email-masked]
主题: re: comments to I-D.li-ppsp-nat-traversal-02

Hi, Yingjie 

Please see inline.

BR 
Lichun

I can’t understand. If all is left to implementation, then I guess your
draft is just informal. And we don’t need to make any revision to current
protocol to support NAT traversal. 

Source peer can know the IP address by peerlist. Because we can carry both
IP add and peer ID in peerlist, right?

ICE connectivity checks use STUN/TURN protocol, which can not be protected
by PPSP protocol's authentication. 
ICE parameters also include host/reflexive/relayed address. Even ICE is not
used, MediaAttach still need to exchange SDP without ICE parameters. 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is
solely property of the sender's organization. This mail communication is
confidential. Recipients named above are obligated to maintain secrecy and
are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the originator of the
message. Any views expressed in this message are those of the individual
sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: [email-masked]
Date: Mon, 18 Jul 2011 09:21:34 +0800

Hi, Yingjie

Please see inline.

BR
Lichun

"Yingjie Gu(yingjie)" <[email-masked]> 写于 2011-07-14 17:10:26:

> The decision of supporting NAT traversal or not and choosing which 
> NAT traversal 
> If PPSP-ICE is chosen, implementing/using optional revisions or not 
> should also be left to implementation. 

> I can’t understand. If all is left to implementation, then I guess 
> your draft is just informal. And we don’t need to make any revision 
> to current protocol to support NAT traversal. 
> 

NAT traversal is not required in all scenarios, and there are multiple 
good ways to do it. 
So I think NAT traversal related extensions should be left to 
implementation.
But we must standardize PPSP to support all NAT traversal methods accepted 
by the WG even these methods can not be used all together or can not be 
used in all scenarios. 
Otherwise, PPSP nodes can not interoperate properly if they wish to use a 
NAT traversal method.

> Source peer doesn't know and doesn't need to know the destination 
> peer's address that can be reached by proxy peer. 
> Source peer can know the IP address by peerlist. Because we can 
> carry both IP add and peer ID in peerlist, right?
> 
Source peer does know the IP address of destination peer. But proxy peer 
may contact other address of destination peer 
because the destination peer is behind NAT. 
Source peer may obtain destination peer's host address, reflexive address 
and proxy address from peer list.
However, source peer can not reach host address and reflexive address. So 
source peer has to use proxy address to contact destination peer.
Proxy peer may not use the host address and reflexive address in peer list 
to contact destination peer.

About carrying IP and peer ID in peer list, I think peer list should 
contain peer ID and IP by default.
Peer ID is required to allow multi-homed peer, mobile peer and NATed peer. 
Peer ID is used for authentication.
IP address is required if using PPSP-ICE or not using NAT traversal 
methods. I think PPSP protocol should consider not using NAT traversal as 
default.

> ICE connectivity checks use STUN/TURN protocol, which can not be 
> protected by PPSP protocol's authentication. 
> ICE parameters also include host/reflexive/relayed address. Even ICE
> is not used, MediaAttach still need to exchange SDP without ICE 
parameters. 
> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.
> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 
> notify the originator of the message. Any views expressed in this 
> message are those of the individual sender.