Subject: [pcp] DNS Indirection

From: <[email-masked]>
Date: Fri, 18 Feb 2011 08:43:14 +0100

Dear all,

We would like to have a feedback about an open question we have in http://tools.ietf.org/html/draft-bpw-pcp-dhcp-02 (Section 5.2):

      [Ed.  Is there a value to consider a level of indirection (e.g.,
      SRV)? (1) to use an arbitrary port number for PCP Server instead
      of the default port, (2) detect whether a security channel is in
      use (using the transport protocol)]
The current text assumes there is no indirection.

Cheers,
Med

********************************************************************************

IMPORTANT. 
Les informations contenues dans ce message électronique y compris les fichiers attachés sont strictement confidentielles et peuvent être protégées par la loi.
Ce message électronique est destiné exclusivement au(x) destinataire(s) mentionné(s) ci-dessus. 
Si vous avez reçu ce message par erreur ou s'il ne vous est pas destiné, veuillez immédiatement le signaler à l'expéditeur et effacer ce message et tous les fichiers éventuellement attachés.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. 
Tout message électronique est susceptible d'altération.
A ce titre, le Groupe France Télécom décline toute responsabilité notamment s'il a été altéré, déformé ou falsifié.
De même, il appartient au destinataire de s'assurer de l'absence de tout virus.
  
IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure of this message is prohibited. 
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.

********************************************************************************

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Feb 2011 10:57:29 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, February 17, 2011 11:43 PM
> To: [email-masked]
> Subject: [pcp] DNS Indirection
> 
> Dear all,
> 
> We would like to have a feedback about an open question we have in
> http://tools.ietf.org/html/draft-bpw-pcp-dhcp-02 (Section 5.2):
> 

There is value in SRV.  But there is additional complexity and additional
failure modes.  To my knowledge the only (relatively) widely deployed
application that uses SRV in real life is XMPP.  Just last year, Cisco 
bumped into a bug where our devices borked SRV responses that were 
longer than expected.  (1) would be neat to have, but I am not convinced
we necessarily need it.  (2) can be done without SRV; lots of protocols
without SRV already negotiate or force upgrading to a secure channel.

I vote for K.I.S.S.  That is, don't do SRV.

-d

---

From: Benson Schliesser <[email-masked]>
Date: Fri, 18 Feb 2011 14:00:20 -0600

On 2/18/11 12:57 PM, "Dan Wing" <[email-masked]> wrote:

> application that uses SRV in real life is XMPP.

Microsoft Active Directory leverages SRV fairly extensively.  But I
understand your point.

> I vote for K.I.S.S.  That is, don't do SRV.

I agree.  If discovery isn't needed, e.g. because the server is naturally in
the data path (like a NAT or Firewall), then I'm not sure the benefits
(flexibility?) offset the risks of adding another layer that might fail.

Cheers,
-Benson

---

From: <[email-masked]>
Date: Tue, 22 Feb 2011 15:19:03 +0800

|THIRD_PARTY makes a normal PCP client easier, because the PCP 
|client doesn't need any code to cause its PCP request to 
|egress the proper interface.  This is important because after 
|using MAP and receiving a TCP SYN, the host will send a TCP 
|SYNACK and that needs to use the correct interface.  Using the 
|host's address preferences, rather than doing it in a PCP 
|library which hopes to mimic the host's address preference, is 
|far safer.

==>Agreed.

|A proxy would need to copy the source IP address of the PCP 
|request into the THIRD_PARTY option.  I admit that is a change 
|to proxy behavior.  But I don't understand how that makes the 
|proxy "far more complex".  Can you elaborate?

==> I don't see it makes the proxy far more complex, the PCP
 proxy can simply copy the source address of the received
 packet into the  THIRD_PARTY option.  But due to the deeper header
decoding, it may impact the PCP header decoding speed of the PCP
 server when the internal address is  in the optional header instead of 
in the fixed Opcode specified area. Therefore  the PCP server,
especially 
those who are embeded in the CGN, may need hardware to accelerate 
packet decoding.

Hence, THIRD_PARTY option might be benificial in future, but I wonder 
if it's too eairly to move internal ip address into this option.

|
|-d

---

From: <[email-masked]>
Date: Tue, 22 Feb 2011 18:04:14 +0100

Hi Dan,

I fully agree with your analysis. 

I will remove that note from the I-D and add a sentence to record this. 

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : vendredi 18 février 2011 19:57
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Objet : RE: [pcp] DNS Indirection

-d

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************