Re: [pcp] PCP-base 02: Section 7.7

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Monday, January 10, 2011 10:55 PM
> To: Dan Wing; 'Francis Dupont'; 'Simon Perreault'
> Cc: [e-mail]
> Subject: RE: [pcp] PCP-base 02: Section 7.7
> 
> Hi Dan,
> 
> As a reminder, I have enumerated a set of advantages of implementing
> what was called option 2 (http://www.ietf.org/mail-
> archive/web/pcp/current/msg00483.html).
> 
> In http://www.ietf.org/mail-archive/web/pcp/current/msg00487.html, I
> tried to explain that implementing option 1 may not reduce keepalives
> in some contexts since the refresh interval is forced by the server and
> not by the client (see SIP example for instance).

Thanks for the pointers.

The first URL says:

    > I don't know how we can forbid applications to use option 2
    > which is the obvious one to avoid overloading service
    > elements with keepalive messages!
    >
    > As a concrete example: In the current VoIP deployments SBC
    > or P-CSCF forces the SIP User Agent to send frequent
    > REGISTER messages (setting a small value of expire timer);
    > these messages are not forwarded to the core service
    > elements. The main purpose is to maintain the NAT binding
    > in case a NAT is traversed alive. Both the NAT and SBC are
    > overloaded with these keepalive messages. For the NAT side
    > this may not be an issue when the NAT is embedded in the
    > CPE but this may be become sensitive for the CGN case.
    >
    > If PCP is used to instruct a mapping before issuing the
    > REGISTER message: (1) the CGN is not overloaded, (2)
    > service contact point is not overloaded, (3) the client can
    > use the external IP address/port to build its application
    > messages (e.g., SIP) and thus no need to implement extra
    > function in the service side (e.g., SBC) or in the CGN
    > (e.g., SIP ALG), (4) the service elements can detect the
    > present of non-transparent NAT by comparing the content of
    > the message with the source IP/port information, (5) the
    > client is aware of the lifetime of the mapping in the CGN
    > which important to avoid sending aggressive keeplines
    > (e.g., 20s for Ipsec clients), etc.

and the second URL reinforces that connect-then-lifetime does not
have property (3).

Here is how I see property (3) implemented when doing connect-then-lifetime,
following the REGISTER
procedure described at
http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios-13#page-16

  SIP UA                          PCP server    SIP proxy
    |                                 |             |
    |--SIP REGISTER, rport------------------------->|
    |<-Ok, port=12345-------------------------------|
    |                                 |             |
    |-PIN44, REMOTE_PEER=<sip proxy>->|             |
    |<--lifetime=3600, ext-port=12345-|             |
    |                                 |             |

What is the disadvantage of reducing SIP keepalives that way?


For RTP, message flow would be like this, again doing connect-then-lifetime.
The difference is we don't get anything like an "rport=NNN" from the remote
peer.  But, we don't need it anyway except to detect a rogue NAT on the path
between the PCP-controlled NAT and the RTP peer.  If the SIP UA wanted to
detect such a rogue NAT, it would need to send ICE (STUN) messages to the
RTP peer.

  SIP UA                          PCP server     RTP peer
    |                                 |             |
    |--RTP message--------------------------------->|
    |--RTP message--------------------------------->|
    |--... more RTP messages ...------------------->|
    |--RTP message--------------------------------->|
    |                                 |             |
    |-PIN44, REMOTE_PEER=<rtp peer>=->|             |
    |<--lifetime=3600, ext-port=12345-|             |
    |                                 |             |

As with SIP, the SIP UA does not need to be in a hurry to communicate with
the PCP server.

-d


> Cheers,
> Med
> 
> -----Message d'origine-----
> De : Dan Wing [mailto:[e-mail]]
> Envoyé : mardi 11 janvier 2011 01:03
> À : 'Francis Dupont'; 'Simon Perreault'; BOUCADAIR Mohamed OLNC/NAD/TIP
> Cc : [e-mail]
> Objet : RE: [pcp] PCP-base 02: Section 7.7
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Francis Dupont
> > Sent: Monday, January 10, 2011 3:02 PM
> > To: Simon Perreault
> > Cc: [e-mail]
> > Subject: Re: [pcp] PCP-base 02: Section 7.7
> >
> >
> >  In your previous mail you wrote:
> >
> >    Note that this was discussed in the virtual interim meeting. I
> seem
> > to
> >    recall the consensus being that the advantage of easy deployment
> >    outweighed the disadvantages.
> >
> > => I am afraid this argument would not close the subject...
> > and there was no consensus, just a 'go to next point'.
> >
> >   (Were the minutes of the meeting posted?)
> >
> > => +1!
> >
> > [e-mail]
> >
> > PS: BTW the 'ease of deployment' is not a good argument as it applied
> > only on hosts, not on NATs, when IMHO at least 50% of the deployed
> > base won't support it.
> 
> For reference, this is Issue #17,
> http://trac.tools.ietf.org/wg/pcp/trac/ticket/17
> 
> In the post http://www.ietf.org/mail-
> archive/web/pcp/current/msg00474.html,
> Simon described the host implementation difficulty.  This got agreement
> from
> Dave Thaler, http://www.ietf.org/mail-
> archive/web/pcp/current/msg00475.html
> and Lars Eggert,
> http://www.ietf.org/mail-archive/web/pcp/current/msg00480.html.
> 
> I do not find a post that describes the NAT implementation difficulty.
> 
> I found posts that suggest NATs want to have different port ranges for
> PCP-controlled ports than for dynamically-created connections.  That's
> makes
> some sense when the user is operating a server.  But I don't understand
> how
> separate NAT port ranges are helpful/necessary for the application
> keepalives case.
> 
> If this does help the NAT, it seems we will need to force (MUST) the
> hosts
> to allocate a source port in the non-ephemeral port range and follow
> the
> other steps described in
> http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html.
> 
> -d
> 
> 
> 
> 
> *********************************
> This message and any attachments (the "message") are confidential and
> intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered,
> changed or falsified.
> If you are not the intended addressee of this message, please cancel it
> immediately and inform the sender.
> ********************************