Subject: RE: [Dime]: A Potential Issue with the New Text for RFC 3558bis

From: "Dan Warren" <[email-masked]>
Date: Mon, 5 Nov 2007 18:29:48 -0000

Just an observation...

Doesn't all of the below not countenance for the possibility of a
Diameter implementation within a single domain (ie where security is
actually not an issue)?  So if I were take an example of an Accounting
application between a device a charging system within a single network,
do I need any form of security at all?

Perhaps what is needed is a description of the context within which
security is required - Diameter interactions without underlying or
inherent security.  I certainly see no need for a security mechanism for
something like Diameter-SIP-Application when deployed in a single
network, as an example.

Dan

> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]] 
> Sent: 05 November 2007 17:29
> To: Thomas Lindgren
> Cc: [email-masked]
> Subject: Re: [Dime]: A Potential Issue with the New Text for 
> RFC 3558bis
> 
> Hi Thomas,
> 
> > While I certainly didn't write it, it does seem reasonable to me. 
> > First, requiring support for IPSec doesn't seem like an issue that 
> > needs to be addressed in the diameter protocol. Second, 
> since diameter 
> > is a peer-to-peer protocol, the distinction of requiring 
> TLS support 
> > in 'servers' but permitting its absence in other elements 
> seems odd, 
> > or perhaps outdated. Third, perhaps we will want other 
> solutions than 
> > IPSec or the base spec TLS usage. (How about an alternative simpler 
> > stunnel-style TLS, anyone?) So the MUST/MAY requirements in 
> the first 
> > paragraph seem too strong and inflexible. Regarding the MUST NOT, I 
> > have in practice seen little demand for either IPSec or TLS 
> so far, so 
> > requiring it seems like overkill (or an invitation to ignore full 
> > compliance). Thus, the second formulation seems fine to me.
> 
> I generally agree with this assessment. This was also the 
> general feeling among implementors during past interops. 
> That's why the current text is the way it is. Regarding 
> 'servers' requiring TLS support, that can probably needs 
> cleaning up as well.
> 
> >
> > (Ideally, I'd instead prefer to see the detailed transport layer 
> > security issues moved into new RFCs instead.)
> 
> regards,
> victor
> 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
> 
> 

Forthcoming GSMA Events:
 
GSMA Mobile Asia Congress
Macau
12 - 15 November 2007
www.mobileasiacongress.com
 
GSMA Mobile World Congress
Barcelona
11 - 14 February 2008
www.mobileworldcongress.com

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 759 2300 and highlight the error

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

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 5 Nov 2007 12:58:26 -0800

Just an observation...

Doesn't all of the below not countenance for the possibility of a
Diameter implementation within a single domain (ie where security is
actually not an issue)?  So if I were take an example of an Accounting
application between a device a charging system within a single network,
do I need any form of security at all?
[gwz] 
Of course not!  The service providers are our friends, totally dedicated
only to supplying the highest possible quality of service & all of their
employees are utterly trustworthy & incorruptible.
[/gwz]

[gwz] 
See above; repeat as necessary until delusion is complete.
[/gwz]
...