Subject: [P2PSIP] Establish D/TLS after AppAttach?

From: "Michael Chen" <[email-masked]>
Date: Tue, 25 Oct 2011 16:04:43 -0700

Hi,

We had some discussions at the [email-masked] list, and I like
to post this question here. The base draft makes no mention of whether
the link between two peers from an AppAttach may/should/must also
establish D/TLS connection. Without an agreement, two peer will not be
able to forward the actual SIP dialog traffics.

This could be a big inter-op issue, so I would like the principles of
this draft address it.

Thank you

--Michael

---

From: Frederic-Philippe Metz <[email-masked]>
Date: Wed, 26 Oct 2011 21:20:39 +0200

Hi all,

I definitely support Michaels question into the P2P group. The draft
doesn't clearly figure out how the connection "description" is
presented to the upper layers. In short terms, the reference point of
a usage using AppAttach is not defined which connection it should
expect. It may cause incompatibility if the same usage (i.e. SIP)
would expect different connection type "formats" from RELOAD.
Best Regards >>> Frédéric

On Wed, Oct 26, 2011 at 1:04 AM, Michael Chen <[email-masked]> wrote:
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>

---

From: Bruce Lowekamp <[email-masked]>
Date: Sat, 29 Oct 2011 16:40:31 -0400

The OverlayLinkTypes that reload includes are all message-oriented
protocols.  It's up to the usage defining the application-id to
indicate what is actually passed in these messages.  e.g. the sip
usage specifies SIP messages for application-id 5060.

Beyond the application-id, I don't think it's the role of an IETF
draft to specify how that is presented to the upper layers, though a
usage has to specify what is on the wire clearly enough that
compatible implementations can be written, obviously.

Bruce

---

From: Frederic-Philippe Metz <[email-masked]>
Date: Sun, 30 Oct 2011 10:36:39 +0100

Hi Bruce, thanks for the reply, I agree with you.
I think I missed the point.

For the implementors, it is not clear (please correct me if I am wrong Michael):

The draft says:
"For example, if a P2PSIP node wishes to
   establish a SIP dialog with another P2PSIP node, it will use
   AppAttach to establish a direct connection with the other node.  This
   new connection is separate from the peer protocol connection.  It is
   a dedicated UDP or TCP flow used only for the SIP dialog."

and

"   AppAttach:    used to form application layer connections between
      nodes."

and the paragraph 5.5.2:

This could mean two things at least (the third is for completeness):

1. An application issues an AppAttach to RELOAD and receives the
candidates. The application then have to form the connection itself.

2. An application issues a command to RELOAD that does the AppAttach
stuff ( AppAttach -> ICE -> TLS/D/TLS) and RELOAD provides an
application connection to the application (an "OverlayLinkType
connection")

(3. For completeness: Same as 2, but RELOAD provides a pure TCP or UDP
connection to the application (AppAttach -> ICE -> TCP/UDP). The
application then has to perform TLS/DTLS itself.)

I assume, with respect to your answer, you mean point 2. applies. Am I
right ? That means An application somehow tells RELOAD to make a
connection and RELOAD provides a application connection the
application then uses to exchange the application messages.

Best Regards,
Frédéric

---

From: Bruce Lowekamp <[email-masked]>
Date: Sun, 30 Oct 2011 11:32:47 -0400

I would personally implement it essentially as #2, with the
application implementing an interface with a receiveMessage(Message)
function and invoking an interface provided by the reload
implementation that has a sendMessage(Message) function.  Reality
needs to be a bit more complicated as, for example, the SIP usage
specifies requirements about the certificate of the other side.

I'm happy to provide a clarification in the draft if we can find some
helpful text.  But I don't see this as needing to be specified in the
draft---any of the approaches could produce a valid implementation.
It might be a good discussion in an implementers' wiki page, though.

Bruce

---

From: Frederic-Philippe Metz <[email-masked]>
Date: Sun, 30 Oct 2011 21:35:47 +0100

Hi Bruce,
great that we can discussed this point. I guess "helpful text" means
that I should suggest one :-) I will think about it if so. On the
implementation side, I would assume that there doesn't exist any
assumptions what the connection should look like to the usage and as a
consequence, it would be configurable in an implementation.

There's one question open: The problem came from an implementation
design where one implementor thought that the application with the SIP
usage expects a pure TLS/DTLS connection from RELOAD (#2) to send raw
SIP stuff and the other implementation would expect a TCP/UDP
connection (#3) where the usage (I mean application) would do the
TLS/DTLS stuff on its own. They would not be compatible to each other.
Shouldn't that be standardized that (when using RELOAD) an application
has to expect a special kind of connection (maybe in the usage draft
for every usage) ?

If not, if the connection coming from RELOAD should be assumed as a
raw connection (even if TLS/DTLS is already done in RELOAD) and the
usage (i.e.SIP) i.e. wants to use TLS then the usage (application)
should do TLS on top of the RELOAD connection ?

Cheers,
Frédéric

---

From: [email-masked]
Date: Mon, 31 Oct 2011 14:13:41 +0800

Hi,
I think it isn't enough beneficial that RELOAD provides connection for 
application. 
Firstly, it is difficult that RELOAD understand the link type of all kinds 
of applications. The Link type defined in RELOAD doesn't necessarily 
suitable for all applications. 
Secondly, it is difficult that RELOAD maintains the connection of 
application. Different application have different connection maintainence 
mechanism, for example, some applications need long connection, but other 
applications need short connection.
Even though RELOAD provides raw connection for application, it isn't more 
beneficial than application providing connection itself. But its 
shortcoming is obvious, and it increases the coupling between RELOAD and 
application and increases implementation complexity.

So I think it is suitable that applicatin forms connection ifself. Then we 
need think about the definition of the link type of AppAttach. It is 
different from the link type of Attach, and it should be compatible for 
all kinds of application. Maybe the specific options of link type of 
AppAttach should be leaved to application.

***************************************
Email：        [email-masked]
TEL：          025-52871543
Mobile：       13776637274
Fax：          025-52872187
***************************************

Frederic-Philippe Metz <[email-masked]> 
发件人:  [email-masked]
2011-10-31 04:35

收件人
p2psip WG <[email-masked]>
抄送

主题
Re: [P2PSIP] Establish D/TLS after AppAttach?

Hi Bruce,

Cheers,
Frédéric

--------------------------------------------------------
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: Bruce Lowekamp <[email-masked]>
Date: Mon, 31 Oct 2011 09:21:54 -0400

2011/10/31 <[email-masked]>
>
> Hi,
> I think it isn't enough beneficial that RELOAD provides connection for application.
> Firstly, it is difficult that RELOAD understand the link type of all kinds of applications. The Link type defined in RELOAD doesn't necessarily suitable for all applications.

OverlayLinkType is extensible.  If your draft needs something else,
please define it.

>
> Secondly, it is difficult that RELOAD maintains the connection of application. Different application have different connection maintainence mechanism, for example, some applications need long connection, but other applications need short connection.

>From 5.5.2.1:

The application using connection set up with this request is
   responsible for providing sufficiently frequent keep traffic for NAT
   and Firewall keep alive and for deciding when to close the
   connection.

Bruce

>
> Even though RELOAD provides raw connection for application, it isn't more beneficial than application providing connection itself. But its shortcoming is obvious, and it increases the coupling between RELOAD and application and increases implementation complexity.
>
> So I think it is suitable that applicatin forms connection ifself. Then we need think about the definition of the link type of AppAttach. It is different from the link type of Attach, and it should be compatible for all kinds of application. Maybe the specific options of link type of AppAttach should be leaved to application.
>
>