Re: [PATCH net-next v3 1/8] gtp: add documentation

[Andreas Schultz]

Hi Harald,

- On Feb 22, 2017, at 9:36 AM, laforge lafo...@gnumonks.org wrote:

> Hi Andreas,
> 
> thanks for your feedback.
> 
> On Mon, Feb 20, 2017 at 06:28:07PM +0100, Andreas Schultz wrote:
>> > Are you absolutely sure about this?
>> 
>> Yes. It took me a while to realize this. The crux is this statement in TS
>> 29.060,
>> Section 7.3.1:
>> 
>> > The SGSN shall include an SGSN Address for control plane and an SGSN 
>> > address for
>> > user traffic, which may differ from that provided by the underlying network
>> > service
>> > (e.g. IP). The GGSN shall store these SGSN Addresses and use them when 
>> > sending
>> > control plane on this GTP tunnel or G-PDUs to the SGSN for the MS.
>> 
>> IMHO, this implies that the source IP of GTP-U and GTP-C frames does not 
>> have to
>> match the GSN address specified by a Create PDP Context Request.
> 
> Yes, I follow that reasoning for GTP-C (i.e. the transport-layer S-GW
> source IP of the CREATE PDP CTX REQ may differ from the one signalled
> inside GTP-C.
> 
> For GTP-U however, this just means that GTP-U in general can use
> different IP addresses from GTP-C.  This is well-known and I also have
> no doubts about this.
> 
> But what I still doubt is whether within an ongoing GTP-U tunnel, the
> source IP address can change at any time without any signaling
> announcing that change.
> 
>> TS 29.274, Section 4.2.2.1, Initial Messages:
>> 
>> > During the establishment of the GTP tunnel, the GTPv2 entity selects and
>> > communicates to the peer GTPv2 entity the IP Destination Address at which
>> > it expects to receive subsequent control plane Initial messages related
>> > to that GTP tunnel via .
>> 
>> TS 23.401, Annex D, Sect. D.3.3. makes is clear beyond doubt that we have to
>> accept packet for a valid TEID from virtually any IP. If you look at figure
>> D.3.3-1, step 16, you will see that only the new SGSN is contacting the P-GW.
>> There is no prior advertisement of the change from the old SGSN.
> 
> Yes, but that is again GTP-C, and not GTP-U.
> 
>> Step 16 would therefor not work if we limited the tunnel to a specific source
>> IP.
> 
> correct. But it is a GTP-C transaction.
> 
>> > I so far always assumed that you use GTP-C "MODIFY PDP CONTEXT" in case
>> > of such mobility situations, i.e. the control plane explicitly notifies
>> > the GTP-U entity of a change in the SGSN/S-GW address.
>> 
>> Yes, it does. But that notification only applies to the tunnel endpoint at
>> the SGSN/S-GW in the GGSN/P-GW to SGSN/S-GW direction.
>> 
>> > At least for 3G this seems to be the case, and my assumption appears to
>> > be confirmed with sources such as e.g. page 15 of
>> > http://www.nwadmin.de/presentation_mobility_manag ement_in_UMTS.pdf
>> > 
>> > Also, for LTE, it seems that there's a GTPv2-C "Modify Bearer
>> > Request/Response" involved in relocation from one S-GW to another S-GW:
>> > http://www.lteandbeyond.com/2012/03/x2-based-handover-with-sgw-relocation.html
>> 
>> I think this affirms my argument, Step 3a is sending GTP packets from a
>> source IP that is know to the P-GW before. The fact that this is only
>> used for GTP-C does IMHO not mean that the same should not apply to
>> GTP-U.
>> 
>> >> Step 3. The target Serving GW assigns addresses and TEIDs (one per
>> >> bearer) for downlink traffic from the PDN GW. The Serving GW allocates
>> >> DL TEIDs on S5/S8 even for non-accepted bearers. It sends a Modify
>> >> Bearer Request (Serving GW addresses for user plane and TEID(s))
>> >> message per PDN connection to the PDN GW(s). The SGW also includes
>> >> User Location Information IE and/or UE Time Zone IE if it is present
>> >> in step 2. The PDN GW updates its context field and returns a Modify
>> >> Bearer Response (Charging Id, MSISDN, etc.) message to the Serving GW.
>> >> The MSISDN is included if the PDN GW has it stored in its UE context.
>> >> The PDN GW starts sending downlink packets to the target GW using the
>> >> newly received address and TEIDs. These downlink packets will use the
>> >> new downlink path via the target Serving GW to the target eNodeB. The
>> >> Serving GW shall allocate TEIDs for the failed bearers and inform to
>> >> the MME.
>> > 
>> > Section 5.5.1.1.3 of TS 23.401 agrees with the GTPv2C signalling during
>> > relocation, AFAICT.
>> 
>> Again, there is nothing in there that defines a IP *source*, a F-TEID is
>> a tunnel ENDPOINT id not a tunnel SOURCE id.
>> 
>> >> +Therefor the receiving side only identifies tunnels based on TEID's, not 
>> >> based
>> >> +on the source IP.
>> > 
>> > I'm wondering if this really is neccesary. Do you have actual protocol
>> > traces, specs or any other literature confirming this?
>> 
>> So far I have only seen symmetric GTP-U tunnels. However I believe there
>> is nothing that would stop a SGSN/S-GW from switching GPT-U tunnel source
>> transparently across IP's (for example a system with multiple shelves might
>> use different shelve in DL/UL direction and have 

Re: [PATCH net-next v3 1/8] gtp: add documentation

[Harald Welte]

Hi Andreas,

thanks for your feedback.

On Mon, Feb 20, 2017 at 06:28:07PM +0100, Andreas Schultz wrote:
> > Are you absolutely sure about this?
> 
> Yes. It took me a while to realize this. The crux is this statement in TS 
> 29.060,
> Section 7.3.1:
> 
> > The SGSN shall include an SGSN Address for control plane and an SGSN 
> > address for
> > user traffic, which may differ from that provided by the underlying network 
> > service
> > (e.g. IP). The GGSN shall store these SGSN Addresses and use them when 
> > sending
> > control plane on this GTP tunnel or G-PDUs to the SGSN for the MS.
> 
> IMHO, this implies that the source IP of GTP-U and GTP-C frames does not have 
> to
> match the GSN address specified by a Create PDP Context Request.

Yes, I follow that reasoning for GTP-C (i.e. the transport-layer S-GW
source IP of the CREATE PDP CTX REQ may differ from the one signalled
inside GTP-C.

For GTP-U however, this just means that GTP-U in general can use
different IP addresses from GTP-C.  This is well-known and I also have
no doubts about this.

But what I still doubt is whether within an ongoing GTP-U tunnel, the
source IP address can change at any time without any signaling
announcing that change.

> TS 29.274, Section 4.2.2.1, Initial Messages:
> 
> > During the establishment of the GTP tunnel, the GTPv2 entity selects and
> > communicates to the peer GTPv2 entity the IP Destination Address at which
> > it expects to receive subsequent control plane Initial messages related
> > to that GTP tunnel via .
> 
> TS 23.401, Annex D, Sect. D.3.3. makes is clear beyond doubt that we have to
> accept packet for a valid TEID from virtually any IP. If you look at figure
> D.3.3-1, step 16, you will see that only the new SGSN is contacting the P-GW.
> There is no prior advertisement of the change from the old SGSN.

Yes, but that is again GTP-C, and not GTP-U.

> Step 16 would therefor not work if we limited the tunnel to a specific source
> IP.

correct. But it is a GTP-C transaction.

> > I so far always assumed that you use GTP-C "MODIFY PDP CONTEXT" in case
> > of such mobility situations, i.e. the control plane explicitly notifies
> > the GTP-U entity of a change in the SGSN/S-GW address.
> 
> Yes, it does. But that notification only applies to the tunnel endpoint at
> the SGSN/S-GW in the GGSN/P-GW to SGSN/S-GW direction.
> 
> > At least for 3G this seems to be the case, and my assumption appears to
> > be confirmed with sources such as e.g. page 15 of
> > http://www.nwadmin.de/presentation_mobility_manag ement_in_UMTS.pdf
> > 
> > Also, for LTE, it seems that there's a GTPv2-C "Modify Bearer
> > Request/Response" involved in relocation from one S-GW to another S-GW:
> > http://www.lteandbeyond.com/2012/03/x2-based-handover-with-sgw-relocation.html
> 
> I think this affirms my argument, Step 3a is sending GTP packets from a
> source IP that is know to the P-GW before. The fact that this is only
> used for GTP-C does IMHO not mean that the same should not apply to
> GTP-U.
> 
> >> Step 3. The target Serving GW assigns addresses and TEIDs (one per
> >> bearer) for downlink traffic from the PDN GW. The Serving GW allocates
> >> DL TEIDs on S5/S8 even for non-accepted bearers. It sends a Modify
> >> Bearer Request (Serving GW addresses for user plane and TEID(s))
> >> message per PDN connection to the PDN GW(s). The SGW also includes
> >> User Location Information IE and/or UE Time Zone IE if it is present
> >> in step 2. The PDN GW updates its context field and returns a Modify
> >> Bearer Response (Charging Id, MSISDN, etc.) message to the Serving GW.
> >> The MSISDN is included if the PDN GW has it stored in its UE context.
> >> The PDN GW starts sending downlink packets to the target GW using the
> >> newly received address and TEIDs. These downlink packets will use the
> >> new downlink path via the target Serving GW to the target eNodeB. The
> >> Serving GW shall allocate TEIDs for the failed bearers and inform to
> >> the MME.
> > 
> > Section 5.5.1.1.3 of TS 23.401 agrees with the GTPv2C signalling during
> > relocation, AFAICT.
> 
> Again, there is nothing in there that defines a IP *source*, a F-TEID is
> a tunnel ENDPOINT id not a tunnel SOURCE id.
> 
> >> +Therefor the receiving side only identifies tunnels based on TEID's, not 
> >> based
> >> +on the source IP.
> > 
> > I'm wondering if this really is neccesary. Do you have actual protocol
> > traces, specs or any other literature confirming this?
> 
> So far I have only seen symmetric GTP-U tunnels. However I believe there
> is nothing that would stop a SGSN/S-GW from switching GPT-U tunnel source
> transparently across IP's (for example a system with multiple shelves might
> use different shelve in DL/UL direction and have therefore multiple IP's.

yes, it might.  But then, on the other hand - at least for what I know
about 2G/3G - it is typically very cumbersome to announce IP addresses
to roaming partners.  It involves manual updating 

Re: [PATCH net-next v3 1/8] gtp: add documentation

[Neels Hofmeyr]

On Mon, Feb 20, 2017 at 06:28:07PM +0100, Andreas Schultz wrote:
> >> +A specific tunnel is only defined by the destination entity. Since the
> >> +destination port is constant, only the destination IP and TEID define
> >> +a tunnel. The source IP and Port have no meaning for the tunnel.
> > 
> > Are you absolutely sure about this?
> 
> Yes. It took me a while to realize this. The crux is this statement in TS 
> 29.060,
> Section 7.3.1:

Also sounds right to me. When the tunnel is established, each side of a GTP
tunnel stores the other side's IP and TEID; port number is constant
(unfortunately, which is one of the ideas/reasons behind gtphub).

~N



signature.asc
Description: Digital signature

Re: [PATCH net-next v3 1/8] gtp: add documentation

[Andreas Schultz]

Hi,

- On Feb 20, 2017, at 5:15 PM, laforge lafo...@gnumonks.org wrote:

> Hi Andreas,
> 
> this is not really about the documentation, but it still makes sense to
> discuss here as the issue is best described:
> 
> On Mon, Feb 13, 2017 at 04:36:17PM +0100, Andreas Schultz wrote:
>> +Local GTP-U entity and tunnel identification
>> +
>> +
>> +GTP-U uses UDP for transporting PDU's. The receiving UDP port is 2152 for
>> +GTPv1-U and 3386 for GTPv0-U.
>> +
>> +There is only one GTP-U entity (and therefor SGSN/GGSN/S-GW/PDN-GW instance)
>> +per IP address. Tunnel Endpoint Identifier (TEID) are unique per GTP-U 
>> entity.
>> +
>> +A specific tunnel is only defined by the destination entity. Since the
>> +destination port is constant, only the destination IP and TEID define
>> +a tunnel. The source IP and Port have no meaning for the tunnel.
> 
> Are you absolutely sure about this?

Yes. It took me a while to realize this. The crux is this statement in TS 
29.060,
Section 7.3.1:

> The SGSN shall include an SGSN Address for control plane and an SGSN address 
> for
> user traffic, which may differ from that provided by the underlying network 
> service
> (e.g. IP). The GGSN shall store these SGSN Addresses and use them when sending
> control plane on this GTP tunnel or G-PDUs to the SGSN for the MS.

IMHO, this implies that the source IP of GTP-U and GTP-C frames does not have to
match the GSN address specified by a Create PDP Context Request.

For GTPv2-C there is no such clear statement. However, GTPv2-C makes it clear
that a TEID describes the local tunnel ENDPOINT, there nothing that defines
the tunnel *source* (the same is true for GTPv1-C, except that is not so
explicit).

TS 29.274, Section 4.2.2.1, Initial Messages:

> During the establishment of the GTP tunnel, the GTPv2 entity selects and
> communicates to the peer GTPv2 entity the IP Destination Address at which
> it expects to receive subsequent control plane Initial messages related
> to that GTP tunnel via .

TS 23.401, Annex D, Sect. D.3.3. makes is clear beyond doubt that we have to
accept packet for a valid TEID from virtually any IP. If you look at figure
D.3.3-1, step 16, you will see that only the new SGSN is contacting the P-GW.
There is no prior advertisement of the change from the old SGSN.

Step 16 would therefor not work if we limited the tunnel to a specific source
IP.

The same applies to figure D.3.4-1, step 18.

>> +[3GPP TS 29.281] Section 4.3.0 defines this so:
>> +
>> +> The TEID in the GTP-U header is used to de-multiplex traffic incoming from
>> +> remote tunnel endpoints so that it is delivered to the User plane entities
>> +> in a way that allows multiplexing of different users, different packet
>> +> protocols and different QoS levels. Therefore no two remote GTP-U 
>> endpoints
>> +> shall send traffic to a GTP-U protocol entity using the same TEID value
>> except
>> +> for data forwarding as part of mobility procedures.
>> +
>> +The definition above only defines that two remote GTP-U endpoints *should 
>> not*
>> +send to the same TEID, it *does not* forbid or exclude such a scenario. In
>> +fact, the mentioned mobility procedures make it necessary that the GTP-U 
>> entity
>> +accepts traffic for TEID's from multiple or unknown peers.
> 
> I so far always assumed that you use GTP-C "MODIFY PDP CONTEXT" in case
> of such mobility situations, i.e. the control plane explicitly notifies
> the GTP-U entity of a change in the SGSN/S-GW address.

Yes, it does. But that notification only applies to the tunnel endpoint at
the SGSN/S-GW in the GGSN/P-GW to SGSN/S-GW direction.

> At least for 3G this seems to be the case, and my assumption appears to
> be confirmed with sources such as e.g. page 15 of
> http://www.nwadmin.de/presentation_mobility_manag ement_in_UMTS.pdf
> 
> Also, for LTE, it seems that there's a GTPv2-C "Modify Bearer
> Request/Response" involved in relocation from one S-GW to another S-GW:
> http://www.lteandbeyond.com/2012/03/x2-based-handover-with-sgw-relocation.html

I think this affirms my argument, Step 3a is sending GTP packets from a
source IP that is know to the P-GW before. The fact that this is only
used for GTP-C does IMHO not mean that the same should not apply to
GTP-U.

>> Step 3. The target Serving GW assigns addresses and TEIDs (one per
>> bearer) for downlink traffic from the PDN GW. The Serving GW allocates
>> DL TEIDs on S5/S8 even for non-accepted bearers. It sends a Modify
>> Bearer Request (Serving GW addresses for user plane and TEID(s))
>> message per PDN connection to the PDN GW(s). The SGW also includes
>> User Location Information IE and/or UE Time Zone IE if it is present
>> in step 2. The PDN GW updates its context field and returns a Modify
>> Bearer Response (Charging Id, MSISDN, etc.) message to the Serving GW.
>> The MSISDN is included if the PDN GW has it stored in its UE context.
>> The PDN GW starts sending downlink packets to 

Re: [PATCH net-next v3 1/8] gtp: add documentation

[Harald Welte]

Hi Andreas,

this is not really about the documentation, but it still makes sense to
discuss here as the issue is best described:

On Mon, Feb 13, 2017 at 04:36:17PM +0100, Andreas Schultz wrote:
> +Local GTP-U entity and tunnel identification
> +
> +
> +GTP-U uses UDP for transporting PDU's. The receiving UDP port is 2152 for
> +GTPv1-U and 3386 for GTPv0-U.
> +
> +There is only one GTP-U entity (and therefor SGSN/GGSN/S-GW/PDN-GW instance)
> +per IP address. Tunnel Endpoint Identifier (TEID) are unique per GTP-U 
> entity.
> +
> +A specific tunnel is only defined by the destination entity. Since the
> +destination port is constant, only the destination IP and TEID define
> +a tunnel. The source IP and Port have no meaning for the tunnel.

Are you absolutely sure about this?

> +[3GPP TS 29.281] Section 4.3.0 defines this so:
> +
> +> The TEID in the GTP-U header is used to de-multiplex traffic incoming from
> +> remote tunnel endpoints so that it is delivered to the User plane entities
> +> in a way that allows multiplexing of different users, different packet
> +> protocols and different QoS levels. Therefore no two remote GTP-U endpoints
> +> shall send traffic to a GTP-U protocol entity using the same TEID value 
> except
> +> for data forwarding as part of mobility procedures.
> +
> +The definition above only defines that two remote GTP-U endpoints *should 
> not*
> +send to the same TEID, it *does not* forbid or exclude such a scenario. In
> +fact, the mentioned mobility procedures make it necessary that the GTP-U 
> entity
> +accepts traffic for TEID's from multiple or unknown peers.

I so far always assumed that you use GTP-C "MODIFY PDP CONTEXT" in case
of such mobility situations, i.e. the control plane explicitly notifies
the GTP-U entity of a change in the SGSN/S-GW address.

At least for 3G this seems to be the case, and my assumption appears to
be confirmed with sources such as e.g. page 15 of
http://www.nwadmin.de/presentation_mobility_manag ement_in_UMTS.pdf

Also, for LTE, it seems that there's a GTPv2-C "Modify Bearer
Request/Response" involved in relocation from one S-GW to another S-GW:
http://www.lteandbeyond.com/2012/03/x2-based-handover-with-sgw-relocation.html

> Step 3. The target Serving GW assigns addresses and TEIDs (one per
> bearer) for downlink traffic from the PDN GW. The Serving GW allocates
> DL TEIDs on S5/S8 even for non-accepted bearers. It sends a Modify
> Bearer Request (Serving GW addresses for user plane and TEID(s))
> message per PDN connection to the PDN GW(s). The SGW also includes
> User Location Information IE and/or UE Time Zone IE if it is present
> in step 2. The PDN GW updates its context field and returns a Modify
> Bearer Response (Charging Id, MSISDN, etc.) message to the Serving GW.
> The MSISDN is included if the PDN GW has it stored in its UE context.
> The PDN GW starts sending downlink packets to the target GW using the
> newly received address and TEIDs. These downlink packets will use the
> new downlink path via the target Serving GW to the target eNodeB. The
> Serving GW shall allocate TEIDs for the failed bearers and inform to
> the MME.

Section 5.5.1.1.3 of TS 23.401 agrees with the GTPv2C signalling during
relocation, AFAICT.

> +Therefor the receiving side only identifies tunnels based on TEID's, not 
> based
> +on the source IP.

I'm wondering if this really is neccesary. Do you have actual protocol
traces, specs or any other literature confirming this?  

I find it somewhat surprising, given how much this opens the door for
arbitrary spoofing from anyone (with access to the respective private
network such as GRX).

So in which situations specifically will thre be a S-GW side Address
change without associated GTP-C signaling informing the P-GW about the
new S-GW side Address + TEID?

Regards,
Harald
-- 
- Harald Welte    http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)