Subject: Re: [Dime] diameter overload control requirements review

From: Ben Campbell <[email-masked]>
Date: Tue, 4 Dec 2012 15:41:01 -0600

Hi,

Sorry for the late response--I just got back from holiday. I've removed sections that I don't think need further comment:

On Nov 27, 2012, at 5:32 AM, jouni korhonen <[email-masked]> wrote:

> Eric,
> 
> See responses inline.
> 
> On Nov 27, 2012, at 3:17 AM, Eric McMurry wrote:
>>> 

[...]

>>> o Explain IPX and provide appropriate references so that the reader
>>> can get the context.
>> 
>> Is that level of detail necessary to get the use case across?  Perhaps you have some text you would like to include here?
> 
> I would only say something along the lines:
> 
>   IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that provides
>   roaming interconnection network between mobile operators and service
>   providers. The IPX is also used to transport Diameter signaling between
>   operators [IR.88].
> 
> Feel free to modify & shorten.
> 

Are we assuming that the IPX is operating at the Diameter layer, rather than just providing IP transport? I know there may be instances of both, but we should be explicit what we are considering in the draft.

[...]

>>> Section 7. Solution Requirements
>>> 
>>> o Req 2: I would also add here that the solution MUST NOT have assumptions
>>> on how some applications are _implemented_ today compared how they are
>>> specified.
>> 
>> sounds reasonable.  Are you thinking about relays here? I think it is still relevant question wether a pure relay is an element that will ever be used.
> 
> Actually I was not thinking about relays. Just in general. It is so
> easy to draw conclusions with the few implementations one is familiar
> with.
> 

I think I must be missing something here. I don't see how we can avoid assuming that implementations actually implement the specs in general. I can see calling out specific exceptions where there may be known problems.

So I think I would suggest stating the opposite: Something to the effect of "We assume implementations fully comply with RFC 6733 except where otherwise noted."

[...]

>>> o Req18: How do you prevent other from benefiting? Say, the others do the
>>> work and the ones that do not still get the benefit network not being
>>> overloaded in general.. and they do not need to move a limb.
>> 
>> this one is tricky.  It comes straight from the SIP overload control requirements (RFC 5390) so perhaps someone from that group can better answer this (Janet, Eric?).  I believe that the goal is not to prevent benefit to elements that do not support the mechanism.  Rather, it is to require the mechanism attempt to treat those elements fairly with respect to the elements that do support the mechanism.
>> 
>> One hopes that having some elements in a network that do support an overload control mechanism will benefit all of the network.
> 
> Right. Maybe someone who contributed to SIP overload can shift their
> ideas & reasoning on this requirement into this document?

I'm not sure I see the problem with the existing language--it's pretty clear that non-supporting nodes should not benefit _more_ than supporting ones.  Maybe we should say "MUST NOT _unfairly_ benefit"?

>>> o Req28: The lack of e2e security makes this requirement hard to meet. 
>>> Also, would this mean we need a way to prove the authenticity of the
>>> provided overload information? What would be the cost of that?
>> 
>> perhaps someone should work on e2e security ;-)
>> 
>> I agree this would be difficult for e2e overload signaling.  It's important though because the potential harm from attacks goes up substantially with an overload control mechanism in place.  A single malicious message could deny large amounts of service.
> 
> Maybe we just need to point out the lack of e2e security and its implications
> regarding this requirement? That's like one sentence or so.

Also, keep in mind the requirement is to not make things worse (i.e. no _new_ issues.). This is not the same as a requirement to have no issues at all.

This does seem to have implications on the e2e vs hbh question. I think we can authenticate information hbh, since we should have a protected transport between peers.

> 
>>> Section 9. Security Considerations
>>> 
>>> o Quite a few of these vulnerabilities boil down to the fact that we
>>> cannot prove the ownership & authenticity of the provided overload
>>> control information. I would state that there..
>> 
>> okay, I will add some text to that effect in the summary.
> 

It's also worth mentioning the differing impacts on the hbh vs e2e approaches. 

Thanks!

Ben.

---

From: "THIEBAUT, LAURENT (LAURENT)" <[email-masked]>
Date: Wed, 5 Dec 2012 09:18:27 +0100

Hello all

about

LTH : What about following text

IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that provides roaming interconnection network between mobile operators and service providers. The IPX *may also be* used to transport *and relay/proxy* Diameter signaling between operators [IR.88].

Best regards

Laurent

ALCATEL-LUCENT

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : mardi 4 décembre 2012 22:41
À : jouni korhonen; Eric McMurry; ERIC C NOEL
Cc : [email-masked]
Objet : Re: [Dime] diameter overload control requirements review

Hi,

[...]

[...]

[...]

Thanks!

Ben.

_______________________________________________

DiME mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/dime

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Dec 2012 11:23:19 -0600

On Dec 5, 2012, at 2:18 AM, "THIEBAUT, LAURENT (LAURENT)" <[email-masked]> wrote:

> IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that provides roaming interconnection network between mobile operators and service providers. The IPX *may also be*used to transport *and relay/proxy* Diameter signaling between operators [IR.88].

I think the language is close to right, although we might want to be more explicit in what we mean by "used to transport...Diameter". I _think_ we are talking about transporting IP traffic, where Diameter might be one of the application layer protocols carried (possibly among others).

More importantly, does the working group wish to consider both use cases? They are fairly different, as in the "transport" case, the carriers have have a direct peering relationship at the _Diameter_ layer, regardless of the route taken by IP packets. In the "relay/proxy" case, the carriers have a (trusted or otherwise) third party between them.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 5 Dec 2012 22:06:37 +0200

Hi Ben,

I think WG (and I) should be more interested in the Diameter layer. Lets not get too much into detail what IPX really is, since it has a tendency to cause headache.

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Dec 2012 14:23:31 -0600

> I think WG (and I) should be more interested in the Diameter layer. Lets not get too much into detail what IPX really is, since it has a tendency to cause headache.

Hi Jouni,

While we might not care too much about the IPX details, we do need to document the use case we are considering, since it drives some of the requirements. I infer from your comment that, for the sake of requirements,  we should assume the presence of a third-party agent for the interconnect case?  If so, we can probably model that as a third-party agent without worrying about the rest of IPX.

OTOH, the transport-only model really doesn't add requirements beyond the base, other than perhaps a security consideration comment about stronger need to use a protected transport since one cannot assume a trusted network. But people should be doing that anyway ;-)

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 6 Dec 2012 09:28:02 +0200

Hi,

On Dec 5, 2012, at 10:23 PM, Ben Campbell <[email-masked]> wrote:

> While we might not care too much about the IPX details, we do need to document the use case we are considering, since it drives some of the requirements. I infer from your comment that, for the

Sure. An there intermediating proxies & relays that are run by 3rd parties come into picture.

> sake of requirements,  we should assume the presence of a third-party agent for the interconnect case?  If so, we can probably model that as a third-party agent without worrying about the rest of IPX.

More or less. However, as the IPX is the current interconnection network of choice for many mobile operators, we should have references in place and the text that such network is used for interconnection. I would not go deeper than this myself.

> OTOH, the transport-only model really doesn't add requirements beyond the base, other than perhaps a security consideration comment about stronger need to use a protected transport since one cannot…

Righty.

- Jouni