Subject: Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS

From: <[email-masked]>
Date: Tue, 3 Jan 2012 18:24:42 +0100

OK with the direction of the proposal.
Just too questions for clarification:
- do we keep a priority order between 1/(D)TLS and 2/IPsec as currently documented in draft or is it also challenged by the Stephen's comment?
- Is it clear that mandating the possible use of IPsec to secure the connection does not mandate the peers to support of Diameter by the peers (e.g. use of IPsec GWs btw peers)?

Regards,

Lionel 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Tina TSOU
Envoyé : lundi 21 novembre 2011 09:49
À : jouni korhonen; [email-masked]
Objet : Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS

This solution works for me, though I think TLS is closer to what most of the vendors currently implement.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of jouni korhonen
Sent: Monday, November 21, 2011 12:38 AM
To: [email-masked]
Subject: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS

Folks,

During the meeting we had a discussion on Stephen Farrell's discuss: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ballot/#stephen-farrell

Glen had a solution proposal that we follow what Stephen suggested i.e. mandate use of either IPsec or (D)TLS within the spec and leave out the "some security mechanism". This of course has some impact on product & deployment level as from now on either IPsec or (D)TLS must be used..

Any feedback?

- Jouni
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Tue, 3 Jan 2012 21:32:17 +0100

Within 3GPP, the NDS relies on the use of IPsec GWs to secure IP connections between nodes. And I was actually referring to that point in my mail.

Lionel

-----Message d'origine-----
De : Avi Lior [mailto:[email-masked]] 
Envoyé : mardi 3 janvier 2012 21:16
À : MORAND Lionel RD-CORE-ISS; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Dime] On RFC3588bis security.. Stephen Farrell's DISCUSS

Leaving out "some other security mechanism" is a problem for example to
3GPP where they rely on Network Domain Security - (a closed secure
environment).

I think we can address the concern by stating that other security
mechanisms can be used where they provide the same or better security
mechanisms such as those provided by DTLS, TLS, or Ipsec.

As we can see we can by the email thread we can debate about TLS vs Ipsec
vs. DTLS and in some cases neither of those would work or be desirable.

For interoperability purposes we need to mandate that Diameter
implementation SHALL support DTLS and TLS or DTLS and IPSEC or DTLS and
IPSEC and TLS but we should also allow for the case where something else
can be used.

On 12-01-03 12:24 , "[email-masked]" wrote:

>- do we keep a priority order between 1/(D)TLS and 2/IPsec as currently
>documented in draft or is it also challenged by the Stephen's comment?
>- Is it clear that mandating the possible use of IPsec to secure the
>connection does not mandate the peers to support of Diameter by the peers
>(e.g. use of IPsec GWs btw peers)?
>
>Regards,
>
>Lionel 
>
>During the meeting we had a discussion on Stephen Farrell's discuss:
>https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ballot/#stephe
>n-farrell
>
>Glen had a solution proposal that we follow what Stephen suggested i.e.
>mandate use of either IPsec or (D)TLS within the spec and leave out the
>"some security mechanism". This of course has some impact on product &
>deployment level as from now on either IPsec or (D)TLS must be used..
>
>Any feedback?
>
>- Jouni

This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

---

From: jouni korhonen <[email-masked]>
Date: Wed, 4 Jan 2012 10:27:57 +0200

Hi,

> - do we keep a priority order between 1/(D)TLS and 2/IPsec as currently documented in draft or is it also challenged by the Stephen's comment?

Stephen does not challenge the priority order. I would personally have a slight preference for IPsec as it is already there for other purposes but I am definitely OK having the current priority order the WG came up with.

> - Is it clear that mandating the possible use of IPsec to secure the connection does not mandate the peers to support of Diameter by the peers (e.g. use of IPsec GWs btw peers)?

This is a good point to emphasize. One known deployment that will rely on IPsec is 3GPP Rel-8. For example, GSMA recently put references to NDS into LTE roaming guideline IR.88 for securing Diameter connections.

In addition to Stephen's Section 13 change proposal also Section 2.2 sentence "If desired, alternative security mechanisms that are independent of Diameter, such as IPsec [RFC4301], can be deployed to secure connections between peers." needs to be changed to make it explicit that the alternative security mechanism is IPsec based.

- Jouni

---

From: Avi Lior <[email-masked]>
Date: Thu, 5 Jan 2012 14:51:45 +0000

Hi

On 12-01-04 3:27 , "jouni korhonen" wrote:

>This is a good point to emphasize. One known deployment that will rely on
>IPsec is 3GPP Rel-8. For example, GSMA recently put references to NDS
>into LTE roaming guideline IR.88 for securing Diameter connections.
>
>In addition to Stephen's Section 13 change proposal also Section 2.2
>sentence "If desired, alternative security mechanisms that are
>independent of Diameter, such as IPsec [RFC4301], can be deployed to
>secure connections between peers." needs to be changed to make it
>explicit that the alternative security mechanism is IPsec based.

I agree with this sort of.  Alternative security mechanism is IPSec based
really should be: as good as or better then the mechanisms provided by
Ipsec/DTLS/TLS etcŠ  This will allow some future proofing in the case
where we have better schemes.  But also why Ipsec?

---

From: Avi Lior <[email-masked]>
Date: Thu, 5 Jan 2012 14:47:54 +0000

On 12-01-03 15:32 , "[email-masked]" wrote:

>Within 3GPP, the NDS relies on the use of IPsec GWs to secure IP
>connections between nodes. And I was actually referring to that point in
>my mail.

Yes indeed.  The point I am trying to make is that Ipsec is outside the
scope of the Diameter Implementation.  We have to be clear about that.
The Diameter box/blade does not have to implement any security mechanisms
but it has to operate within a secure environment that provides the same
or better security as Ipsec/DTLS/TLS etcŠ.