Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis

[<[e-mail]>]

Hi Christoph,

For this to work, ADD_ADDR should convey the external IP address/port not the internal ones.  

FWIW, the steps to be followed are listed in draft-boucadair-mptcp-symmetric:

===
   o  Each endpoint proceeds to the discovery of upstream flow-aware
      devices (e.g., NAT, Firewall).

      This can be achieved by various means, e.g., using UPnP IGD
      [IGD1][IGD2], PCP server discovery [RFC6887], PCP DHCP option
      [RFC7291], DS-Lite AFTR [RFC6334], etc.

      A NAT/firewall can be embedded in a CPE (Customer Premises
      Equipment) and/or hosted in the network provider's side.

   o  Appropriate mappings are instantiated in those discovered flow-
      aware devices.  In particular, external IP address(es) and port
      numbers are retrieved.

      This can be achieved using PCP [RFC6887].  Note, mappings created
      by PCP MAP requests are, by definition, endpoint-independent
      mappings (EIMs) with endpoint-independent filtering (EIF).
      Filters can be associated with the PCP MAP request to restrict a
      mapping to be bound to specific remote peer(s).

      PCP allows to dynamically control both NATs and firewalls.
      Furthermore, PCP allows to retrieve the lifetime associated with
      an external IP address and external port number.

      If the host is a UPnP IGD Control Point, [RFC6970] allows to relay
      UPnP IGD primitives into PCP messages.  PCP can also be used to
      control multi-layered NATs/firewall owing to the activation of
      [I-D.ietf-pcp-proxy] in intermediate NATs/firewalls.

   o  When initiating an MPTCP connection, external IP addresses and
      port numbers are communicated to the remote peer.
=====

Cheers,
Med

> -----Message d'origine-----
> De : Christoph Paasch [mailto:[e-mail]]
> Envoyé : mercredi 15 juillet 2015 18:08
> À : Olivier Bonaventure
> Cc : BOUCADAIR Mohamed IMT/OLN; [e-mail];
> [e-mail]
> Objet : Re: [multipathtcp] Preparing for Prague meeting - things to delete
> or add to MPTCP protocol bis
> 
> On 15/07/15 - 17:49:24, Olivier Bonaventure wrote:
> > Christoph,
> > >
> > >On 15/07/15 - 16:48:40, Olivier Bonaventure wrote:
> > >>>>>                                          +-+-+-+-+
> > >>>>>
> > >>>>>        Flags is a set of 4 flags:        |C|r|r|r|
> > >>>>>
> > >>>>>                                          +-+-+-+-+
> > >>>>>
> > >>>>>        C flag MUST be set to 1 when the address/port are checked.
> > >>>>>
> > >>>>>        "rrr" are for future assignment as additional flag bits.
> > >>>>>
> > >>>>>        r bits MUST each be sent as zero and MUST be ignored on
> receipt.
> > >>>>>
> > >>>>
> > >>>>However, I'm stil not convinced by the usefulness of using the C bit
> > >>>>that you propose. If a host knows that it cannot receive a SYN over
> a
> > >>>>given address, then the best solution is to not advertise this
> address.
> > >>>
> > >>>[Med] Agree. An implementation that supports the "C" flag is likely
> to advertise addresses/ports for which pinholes have been created in
> NATs/FWs and address/ports that can be used to receive incoming packets
> successfully.
> > >>
> > >>
> > >>>The issue with the implicit approach (i.e., no C-flag) is at the
> server side: should the server interpret the advertisement of an
> address/port as an indication that packets can be sent without
> experiencing reachability issues or not?
> > >>
> > >>This is what RFC6824 assumes today. ADD_ADDR is only a hint about the
> > >>possibility of trying to reach this address. Anyway it will be a SYN
> and the
> > >>host will wait for a SYN+ACK to confirm the reachability
> > >
> > >I think, concerning the reachability, what is rather interesting is to
> > >advertise the secondary address without wanting the peer to even try
> > >establishing a new subflow to this address. This advertisement is done
> in
> > >case the "primary" subflow becomes unreachable. If it becomes
> unreachable,
> > >then the peer can use the advertised address to create a new subflow.
> >
> > You would then propose a kind of "Backup" flag in the ADD_ADDR option
> > meaning that this address should only be used to create a subflow if the
> > primary subflow fails ?
> 
> Yes, something along those lines.
> When all other addresses are failing, then this "backup"-address can be
> used
> for a new subflow.
> 
> 
> Cheers,
> Christoph