Re: [pcp] PCP Extensions for Footprint Discovery

["Bertz, Lyle T [CTO]" <[e-mail]>]

Comments below.


-----Original Message-----
From: 🔓Dan Wing [mailto:[e-mail]]
Sent: Wednesday, September 03, 2014 11:26 AM
To: Bertz, Lyle T [CTO]
Cc: Alper Yegin; [e-mail]
Subject: Re: [pcp] PCP Extensions for Footprint Discovery


On Sep 3, 2014, at 7:56 AM, Bertz, Lyle T [CTO] <[e-mail]> wrote:

> Dan,
>
> This is pulled from nroff so hopefully it stays intact :)
>
> The following Figure shows a common deployment scenario.  For illustrative purpose we will use IPv4 Mobility Home Agents.
>
> +------------+
> | Home Agent |
> +------------+
>   | A/24  |
>   |       | C
>   |   +----------+    +----------+
>   |   | Service  |    | Services |
>   |   | Node     |--->| Firewall |
>   |   | (Server) |    +----------+
>   |   +----------+
>   |
>   |
> +-------------------+
> |      Hosts        |
> |     Firewall      |
> |                   |
> |   R1         R2   |
> | A/25      A.128/25|
> | Forward     NAPT  |
> | (No NAT)   (B/27) |
> +-------------------+
>          |
>       Internet
>
> Here the Home Subnet of A/24 when forwarded to the Hosts Firewall has two distinct rules applied.  Rule 1 (R1) merely forwards the traffic from the first half of subnet A without any form of address translation.  Rule 2 (R2) affects the upper half of subnet A (addresses ending with 128-255) sent through a NAPT function which externally maps them to the subnet B/27. In this case the Service Node will serve a site footprint of A/25 and B/27 for any requests received by corresponding nodes on the Internet (past the firewall).  This is referred to as the public or external footprint of the Node.   Any node at the site would view the internal footprint of the Service Node as A/24.  The endpoint of the Service is the Host address C.


So the problem is determining if packets, sent by a handset to a certain IP address, are routed directly or go through a NAT?

>>>> 3 issues.  A. What subnets are hosted at the site?  B. Are they going through a NAT if destined to a uCDN?  C. If so (yes to Answer B), what are the addresses used in the NAT?

> In the case of an ALTO based service, e.g. CDNI which notes ALTO is one option of accomplishing the Endpoint determination, any request sent from the site to an upstream CDN (uCDN) that resides on the Internet would ultimately need to be identified with the downstream CDN (dCDN) that the Service Node is a part of.   The Endpoint must then resolve to C for correct routing in this example.
>
> ALTO provides the structure of the network map and cost map for a network.  How the footprint, i.e. a collection of CIDRs in IPv4, is acquired through what the protocol [draft-ietf-alto-protocol] describes as "Dynamic Network Information" (see Figure 1 of [draft-ietf-alto-protocol]). "Routing Protocols" are also described as an option to determine topology but the internal rules of the Firewall are not discoverable via routing protocols nor is it obvious from routing protocols that a firewall is present in the network.  Such detection would require routing protocol participation on both sides of the firewall which often involves participation in multiple types of routing protocols.
>
> The footprint for the Service Node can only be determined through two steps.
> 1. The acquisition of the addresses allocated to local hosts at the site.  In the case of IP Mobility these are the Home Networks at the site.
> 2. The determine of the application of any address translation that may occur by downstream elements, e.g. carrier NATs / firewalls.
>
> The internal routing of the site further complicates the discovery of the correct egress firewall to the Internet.  In the example distinct firewalls exist and no direct route between the Service Node and the Hosts Firewall is present.  This separation of concerns provides more security and is common in operator networks.
>
> PCP [ref] has resolved how to determine if some form of translation occurs along a path from a Host regardless of a site's internal routing configuration. If PCP is to be used a some matters must be resolved:
>
> 1. As a third party, the Service Node cannot use PCP as a traditional client - a Host that has been assigned an address that is part of the subnet it needs to learn more about.  This is especially true in IP Mobility where the Service Node is likely to not support IP Mobility and, therefore, could not be assigned an address from the subnet by the Home Agent.  A proposal for 3rd Party Authorization [ref] can provide security if the Service Node can act as an PCP Client to a PCP Server in an indirect manner.

Yeah, PCP isn't intended to be used as a network configuration protocol between network elements; PCP is designed and deployed as an end-host (PC, tablet, smartphone) to firewall/NAT protocol.

>>>> Understood.  That is why we mentioned this is not ideal.

But SNMP is pretty ideal for an SDN function.  Does the NAT MIB (draft-ietf-behave-nat-mib) provide the mapping information you need?  Afterall, you're trying to see what the mapping rules are, not information about a dynamic connection itself.  If draft-ietf-behave-nat-mib doesn't provide the information you need, perhaps it can be changed to provide that information.

>>>> This isn't SDN.  The MIB has what looks to be ideal data but SNMP is not considered a viable protocol to form call control decisions (like routes and route table updates).  Any update to the MIB would require the 'discovery element' to rescan the entire MIB, parse for changes and then inject ALTO updates.   Constant SNMP polling would be required.   Forget about using Informs for updates.   Regardless of this the discovery of the allocated pool, discovery of the SNMP agent, surety that the routing occurs between the gateway and the pool and participation in the internal routing protocol for any updates along with SNMP to read the MIB with constant polling are all still challenges.    For example, using OSPF as the internal routing protocol the 'discovery service' would need at least SNMP, OSPF, some way of discovering the pools on the gateways and constant polling to figure out if a rout changed.  That only works if a routing protocol is in the LAN.  If these are hard coded links in the switches then we would require SNMP access to all elements, assuming the support it, at the site to reverse the network map to get a subnet and a NAT pool.

> 2. For IP Mobility, the anchor gateways can be augmented to become PCP servers and support new Allocation opcodes to note the subnets allocated on the Server.
>
> 3. For DHCP allocated subnets there is a possibility to query the DHCP server but how to determine downstream firewalls and routing for a specific subnet becomes quite problematic.

Could you elaborate on the concern around firewalls, which you have brought up several times in this email?  I don't understand how they could get in the way of solving the problem.  One thing mentioned earlier is a firewall is between separate routing domains, but of course separate routing domains often exist without a firewall between them, too -- the problem (in that case) isn't the presence of the firewall but rather the presence of separate routing domains, likely because of separate administrative domains.

>>>> Sure.  At the boundary of a network the firewall may participate in different routing protocols on the interior (trusted/semi-trusted) vs. exterior (untrusted).  To get both sides you need some way to participate in the routing on both sides of the firewall.  From a security perspective that is problematic (read 'not permitted' to have another server span 2 different zones of trust by security policy).  On the inside of the site just because a firewall has a mapping for an IP address group it does not imply the packets for a particular subnet use only that firewall - it could be part of a load balanced group, a backup, etc.   You really can't get that information from a single MIB or listening to just the interior routing protocol - you would need to constantly listen, poll and scan more MIBs in hopes you can construct a decent site wide picture.

> 4. A gateway can use PCP server discovery process(es) to determine PCP Servers.

I don't know where the 'gateway' (router?) is located in the network topology.

>>>> IP Mobility anchor from the example - a Home Agent or in LTE a P-GW.

> Alternatively it could allocate itself an address on a specific subnet and act as a traditional client.   Otherwise, Server (firewall) discovery will need to be rethought in terms of broadcasts and how a PCP server may respond when the requesting PCP client is not from the subnet it is querying about - this can be mitigated by use of locally broadcast and 3rd party authorization.  Alternatively placing a PCP server in a routing element and sending this new kind of discovery to a subnet broadcast address may provide a method by which 'discovery' of the PCP server (allocating gateway) may take place.

-d


>
>
>
> -----Original Message-----
> From: 🔓Dan Wing [mailto:[e-mail]]
> Sent: Tuesday, September 02, 2014 10:35 PM
> To: Bertz, Lyle T [CTO]
> Cc: Alper Yegin; [e-mail]
> Subject: Re: [pcp] PCP Extensions for Footprint Discovery
>
>
> On Sep 1, 2014, at 4:59 PM, Bertz, Lyle T [CTO] <[e-mail]> wrote:
>
>> Not for IP Mobility.  In that case the pools are allocated by the mobility (anchor) points, or Diameter/Radius protocols and there is one option for DHCP but it is not used often in production for other reasons.  Diameter is also used for LTE but I would not worry too much about this matter if it were only a 3GPP issue.
>>
>> In both cases (IP Mobility/LTE) as well as DHCP you get gratuitous ARPs in some implementations - that helps some but then participation in the interior routing protocol is required to be sure about pool size used in a footprint.  There is still one more step though.
>>
>> The next step is to interrogate any NAT functions regarding how the pools are translated.  For instance, an IPv4 /24 subnet/pool could have the lower half ran through a NAT and the upper sent through a firewall without translation.  It is not always obvious how the pools are exposed to another network.
>>
>> Manual provisioning is out of the question for large operators.
>>
>> Rather than trying to determine the route between a mobility gateway and the NAT / firewall via internal routing participation (which can be a number of protocols or worst case a series of statically defined routes in which case I have no immediate idea of how to solve it) it seems more realistic to ask the gateway about the allocations (pools) it owns and let it forward requests regarding how peer mappings occur to carrier grade NATs in the network.  The pools that have no NAT function assigned to them are public if they are known public publics, e.g. not a 10.x.x.x..  Otherwise they are translated and the public pools are what should be advertised as footprints.
>>
>> A typical operator is looking at several /8 networks that are divided over tens to hundreds of sites that may have multiple functions that could use ALTO.  In that case they also contain firewalls and probably have a NAT function in place as well.
>>
>> I hope that clarifies the challenge a bit more.
>
> I asked one of our CDNI experts and I admit that after reading your draft, talking with him, and reading your email, that I do not understand the 'footprint' problem well enough so I can't evaluate if PCP is the best solution.  Is there an explanation of the CDN footprint problem?  That is, where is the pain, and what needs to be known to which endpoint (client, server, some Javascript running in the browser to choose a certain server, or whatever -- I honestly don't know).
>
> -d
>
>
>
>>
>> From: Alper Yegin <[e-mail]>
>> Sent: Monday, September 1, 2014 3:42 AM
>> To: Bertz, Lyle T [CTO]
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [pcp] PCP Extensions for Footprint Discovery
>>
>> Hello Lyle,
>>
>>
>> Couldn't DHCP be used for that purpose?
>>
>>
>> Alper
>>
>>
>>
>> On Aug 25, 2014, at 11:32 PM, Bertz, Lyle T [CTO] wrote:
>>
>>> I wanted to forward this on Brent’s behalf. It is on the agenda tomorrow.
>>>
>>> Thanks!
>>>
>>> Lyle
>>>
>>> From: Hirschman, Brent B [CTO]
>>> Sent: Monday, August 25, 2014 8:36 AM
>>> To: '[e-mail]'; '[e-mail]'
>>> Subject: PCP Extensions for Footprint Discovery
>>>
>>> Here are the slides for a quick discussion on how we feel PCP can be easily extended to aid footprint discovery, e.g., internal network CDNI endpoints.  This is meant as an introductory discussion to hopefully generate more interest in this idea.
>>>
>>> Brent Hirschman
>>> Tech Dev Strategist III
>>> Sprint Corporation
>>> 6220 Sprint Parkway
>>> Overland Park, KS 66251
>>> Office – 913-762-6736
>>> Mobile – 913-593-6221
>>>
>>>
>>>
>>> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
>>> <IETF 90 - PCP Extensions For Footprint Discovery.pptx>_______________________________________________
>>> pcp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pcp
>>
>>
>>
>> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
>> _______________________________________________
>> pcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pcp
>
>
> ________________________________
>
> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.


________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.