Subject: [pcp] base #30 (new): GetExternalIP capability?

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 14 Dec 2010 20:27:23 -0000

#30: GetExternalIP capability?

 From http://www.ietf.org/mail-archive/web/pcp/current/msg00167.html

    Moreover, I'm in favour of having explicit OpCodes such as the
    following:
 [...]
    5.  Get External IP Address: get the external IP address assigned by
        the PCP-controlled device. This is useful in various scenarios (in
 particular stateless NAT)
 [...]

-- 
--------------------------------------------------+-------------------------
 Reporter:  mohamed.boucadair@…                   |       Owner:     
     Type:  enhancement                           |      Status:  new
 Priority:  minor                                 |   Milestone:     
Component:  base                                  |     Version:     
 Severity:  Active WG Document                    |    Keywords:     
--------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/30>
pcp <http://tools.ietf.org/pcp/>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Dec 2010 13:10:54 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> pcp issue tracker
> Sent: Tuesday, December 14, 2010 12:27 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [pcp] base #30 (new): GetExternalIP capability?
> 

What would a PCP client do with that information?  I fear the
information will be be mis-used by misguided developers -- the 
same sort of developers that feel NAPTs shouldn't change port 
numbers.

That said, I agree on a home NAT with only one IP address (such as 
a residential NAT), this could be implemented pretty easily.
But on a NAT with many public IP addresses (that is, a "pool" of
addresses as it is called in various documents), this is troublesome
to implement as it requires the NAT retain state about which IP address
it returned to the PCP client -- even though there is no port 
forwarding.  

-d

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Dec 2010 23:22:56 +0100

There is an easy way to address your concern: define an error code
which allows a NAT to refuse a GetExternalIP from a client without
state.

Regards

[email-masked]

PS: BTW what happens with a 'delete all' request from a client which
has nothing to delete?

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Dec 2010 16:44:23 -0800

> which allows a NAT to refuse a GetExternalIP from a client without

That does not address my concern.

Today, we have hundreds of applications which insist on getting
a specific port number from the subscriber's NAT.  Those application
developers, if they see a "get external address" opcode, will 
simply use it and think they are done.  And when they do testing
on a quiescent NAT, their use of PCP might work fine if their
application sends a packet first.  They will think they have
succeeded.

But their application will fail when deployed on a network with
a busy NAT.

I don't want that sore eye for PCP.

So -- what is the purpose of a PCP message to learn the public 
address?
 
> PS: BTW what happens with a 'delete all' request from a client which

It needs to returns a positive answer.  I don't recall if -01 says
that or not.

-d

---

From: <[email-masked]>
Date: Tue, 21 Dec 2010 07:39:50 +0100

Hi Dan,

The main use case is for the stateless NATxy scenario. 

Stateful scenario: For handling the GetExternalIPAddress request when there is no state, it can be handled like any PINxy when there is no dynamic/static/PCP-instructed mapping.

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : lundi 20 décembre 2010 22:11
À : 'pcp issue tracker'; BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : RE: [pcp] base #30 (new): GetExternalIP capability?

-d

>  Reporter:  mohamed.boucadair@.                   |       Owner:

*********************************
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.
********************************

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Dec 2010 09:31:23 +0100

Today, we have hundreds of applications which insist on getting
   a specific port number from the subscriber's NAT.  Those application
   developers, if they see a "get external address" opcode, will 
   simply use it and think they are done.

=> do you mean they just get the external address then believe
the specific port number will be reserved to them?

   And when they do testing

   
    
=> BTW any PCP message can be used to learn the public address,
and there are other ways to get it. So IMHO the idea is to get it
without side-effects.

   
=> I agree about the positive answer but my question is about the
external address included in it. Is it reliable?
BTW a 'delete all' is the first action I propose for a booting IWF
until we have a GET mechanism: it is important to go in a known state...

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 21 Dec 2010 18:01:54 -0800

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, December 20, 2010 10:40 PM
> To: Dan Wing; 'pcp issue tracker'
> Cc: [email-masked]
> Subject: RE: [pcp] base #30 (new): GetExternalIP capability?
> 
> Hi Dan,
> 

A firewall also does not change ports, so a firewall could
also use this.

I think we need to ask the PCP server questions like:

  1. is my source ports going to be changed?  This indicates
     if the PCP-controlled device is a NAT or a NAPT 
     (network address and port translator).  

     We can achieve that by requesting a mapping, but the
     answer will not always indicate (1) clearly.  That is
     I could request port 80 and be given port 80 (if it
     is available).  How might we improve that?  I have
     an idea:  send a request for requested-external-port=0,
     and if the PCP-controlled device:

        o  changes port numbers (that is, is a NAPT or
           stateful NAT64), it picks an available port 
           and returns it.

        o  does not change port numbers (that is, is a 
           stateless NAT or is a firewall), it refuses
           with a new error code for 'port numbers are
           not modified; port 0 illegal'.

           The PCP client then knows its port numbers
           are never changed.

     Thoughts?

  2. is my source IP address going to be changed?  This 
     indicates if the PCP-controlled device is a (stateless) 
     NAT or a firewall.

     Requesting a mapping will indicate (2) clearly.

I wonder about A+P and similar ideas/implementions floating
around, and how they would work with the ideas above or
with GetExternalIPAddress?  Specifically, could they use
PCP to learn their allowed ports?  I would like PCP to
support this just enough that anyone interested can write
an informational-track document to explain how it might
be done.

-d

> Stateful scenario: For handling the GetExternalIPAddress request when
> there is no state, it can be handled like any PINxy when there is no
> dynamic/static/PCP-instructed mapping.
>
> Cheers,
> Med
> 
> 
> >         the PCP-controlled device. This is useful in various
> scenarios
> > (in
> > --------------------------------------------------+------------------
> --
> > -----
> > --------------------------------------------------+------------------
> --
> > -----
> >

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 21 Dec 2010 18:27:02 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, December 21, 2010 12:31 AM
> To: Dan Wing
> Cc: 'pcp issue tracker'; [email-masked];
> [email-masked]
> Subject: Re: [pcp] base #30 (new): GetExternalIP capability?
> 
> 

They get an external address, "X".  They assume that, because 
they are sending traffic from port 12345, they will be assigned 
port 12345 on external address "X".  This does work, very well,
on a vast majority of NATs when there is no other traffic 
originating from port 12345.  The fact it works leads many a
developer into thinking it always works.  Pity the developer
of a successful application that is running on two hosts 
behind the same NAT.

> => BTW any PCP message can be used to learn the public address,

Yes, of course.

> and there are other ways to get it. So IMHO the idea is to get it

It was only earlier today that Mohamed explained a reason for
the request -- stateless NAT.

With a stateless NAT, PCP will never create state in the NAT,
because the NAT is stateless.  So what is the side-effect that
we're avoiding?

> until we have a GET mechanism: it is important to go in a known

But what if there are PCP clients *behind* the IWF, doing their
own PCP mappings with the PCP server?  You'll break them if the 
IWF does that.  Or are you expecting PCP clients will never exist
on PCs, or that the IWF will break PCP messaging from the
PCP clients to the ISP's PCP server, or what?  Let's figure out
the model for the IWF and how an IWF can support PCP clients
before having the IWF nuke mappings.

I want to also point out that, today, when a subscriber issues
a DHCP request and gets a publicly-routable IPv4 address, that
IPv4 address could have been assigned to another subscriber
only a few seconds/minutes earlier -- and could be receiving
all sorts of annoying traffic (such as connection attempts
from BitTorrent clients).  So, today, we do not "start at a
known state".  Which makes me question the need to "start at
a known state" with PCP.  

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Dec 2010 09:12:41 +0100

=> IMHO it is a case of 'bad format' error (interesting
case as the sub-code/offset carries the information).

Regards

PS: about A+P a traditional resource allocation protocol
like DHCP is IMHO far better.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Dec 2010 09:33:03 +0100

=> this is clearly a buggy behavior but I don't understand how
to not provide GetExternalIP() will be enough to avoid it.

   
   
=> with a stateless NAT there cannot be by definition a side-effect.
BTW how a stateless NAT can be controlled by PCP? There is nothing
to control, in particular no way to create a port forwarding,
something which makes no sense for a stateless NAT.
So IMHO we don't know a GetExternalIP() request for stateless NATs,
but a GetExternalIP() response.

   But what if there are PCP clients *behind* the IWF, doing their
   own PCP mappings with the PCP server?

=> this must be forbidden, i.e., the IWF must be a proxy for PCP
so these clients can see the IWF as the PCP server.
And remember I prefer a GET mechanism (aka state on the server)
than Epoch/nuke (aka state on clients).

=> "start at a known state" is a philosophical school (:-).

Regards

---

From: Simon Perreault <[email-masked]>
Date: Wed, 22 Dec 2010 10:19:27 -0500

> but a GetExternalIP() response.

I can see the usual pinhole requests working with stateless NATs without
the need for an additional opcode.

When a PCP server associated with a stateless NAT receives a pinhole
request, it transforms the internal address into the external address
using the stateless mapping algorithm and returns that. There is no
communication with the stateless NAT, and no side-effect.

(Maybe this use-case could be added to the text.)

I do not yet see the need for an additional opcode.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Dec 2010 18:31:37 +0100

> So IMHO we don't know a GetExternalIP() request for stateless NATs,

=> oops, s/know/need/

   
=> I agree but we need a clean and easy way to recognize
this condition (stateless NAT) in the response.

IMHO an error code is the best, the only drawback the error character
but one can consider to try PCP on a stateless NAT is already an error
condition, so if nothing better is proposed...

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 22 Dec 2010 18:28:44 -0800

... 
> condition, so if nothing better is proposed...

A stateless NAT might also have a firewall integrated into it, and
that firewall might need port forwarding state to allow incoming
packets.  

How shall we distinguish that, in a simple manner?

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 23 Dec 2010 09:24:15 +0100

=> this is a generic question for embedded NAT+firewall.
IMHO the first step is to understand the structure of
such a beast:
 - on which side of the NAT is the firewall?
 - what are implicit pinholes?
 - etc.
i.e., architecture and requirements.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 23 Dec 2010 09:47:03 -0800

> Sent: Thursday, December 23, 2010 12:24 AM
> To: Dan Wing
> Cc: 'Simon Perreault'; [email-masked]

It is a question for a firewall-only device (without NAT), too, such 
as draft-ietf-v6ops-cpe-simple-security.

>  - on which side of the NAT is the firewall?

We have to declare that the PCP server knows.  If the PCP server
knows, does it affect the protocol?

>  - what are implicit pinholes?

Everything on the table:  NATs, NAPTs, and 
draft-ietf-v6ops-cpe-simple-security all assume outgoing dynamic
connections are allowed.  PCP's job is to (a) allow incoming
unsolicited connections and (b) query/control lifetime of dynamic
connections. 

-d