Re: [Dime] Silly doubt on InbandSecurity handling in CER
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dime] Silly doubt on InbandSecurity handling in CER



Hi Srinivas,

According to RFC3588, Inband-Security-Id may support other security Ids
apart from 0 and 1 (ref page 80), and thus value 2 may not be invalid
AVP value for  Inband-Security-Id AVP, so  DIAMETER_INVALID_AVP_VALUE
may not be appropriate.

Kind Regards,
Nilanjan


-----Original Message-----
From: dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] On Behalf Of
srinivas
Sent: Tuesday, September 16, 2008 3:41 PM
To: dime-request at ietf.org; dime at ietf.org
Subject: [Dime] Silly doubt on InbandSecurity handling in CER

Hi,
Silly doubt.Suppose a Diameter node has received the CER with
inband-security value as 2 then does the node has to respond with
DIAMETER_NO_COMMON_SECURITY (5017) or DIAMETER_INVALID_AVP_VALUE (5004)
or
any one is fine.
>From my understanding if the node sends DIAMETER_INVALID_AVP_VALUE
(5004)
then the receiver will easily come to know that AVP value is wrong.
Please give your thoughts/comments on the same.

Thanks & Regards, 
Srinivas CH,
Huawei Technologis India Pvt Ltd, 
1st Floor DIamond District, 
Airport Road, Bangalore-8, 
Contact: (Off) 080-41117676 ext: 3008               (Mob) +919731316362.
 
This e-mail and attachments contain confidential information from
HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way
(including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the
sender by
phone or email immediately and delete it!

-----Original Message-----
From: dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] On Behalf Of
Ankit Kumar Sharma
Sent: Monday, September 15, 2008 10:50 AM
To: Sarkar, Biplab; Jacob Martin; jouni.korhonen at iki.fi
Cc: dime at ietf.org
Subject: Re: [Dime] Application-id reuse

Hi Biplab,
-----Original Message-----
From: dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] On Behalf Of
Sarkar, Biplab
Sent: Monday, September 15, 2008 10:27 AM
To: Jacob Martin; jouni.korhonen at iki.fi
Cc: dime at ietf.org
Subject: Re: [Dime] Application-id reuse

Hi all,

I was thinking of the consequences of allowing AVP's to have the liberty
to
either set or un-set the M-bit.
The sender may decide to set it depending upon its judgement about the
version of the peer.

< I hope you are referring to section 4.1 of RFC 3588.
" A configuration option may be provided on a system wide, per
         peer, or per realm basis that would allow/prevent particular
         Mandatory AVPs to be sent.  Thus an administrator could change
         the configuration to avoid interoperability problem ">

- Will this give added help for extendability?
<Yes it would add to the extendibility/flexibility>
- Is it really required to mandate the presence of M-bit for AVPs? Won't
it
be better to allow the sender to decide?

< To define any specification, there should be mandate on some of the
basic
AVPs which helps in core functioning. For proprietary extensions,
vendors
are allowed to define custom AVPs to meet their requirements>

Some comments on this please.

Thanks & Regards,
Biplab


-----Original Message-----
From: dime-bounces at ietf.org on behalf of Jacob Martin
Sent: Mon 9/15/2008 10:17 AM
To: jouni.korhonen at iki.fi
Cc: dime at ietf.org
Subject: Re: [Dime] Application-id reuse

On 9/15/08, Jouni <ron.kehno at kolumbus.fi> wrote:
> Jacob Martin kirjoitti:
>>
>>> Now that M-bit settings are wrong is just n error in TS29.234
>>>
>> I did not get you on this. could you please explain this again?
> Wm has some new AVPs with M-bit set, as you also pointed out. This
goes
> against the rule for "when to create a new application" as no new
> application is
> created. These are just errors in the current TS 29.234.
ok... Thanks for the clarification.
>
> Jouni
>
>
>
>
_______________________________________________
DiME mailing list
DiME at ietf.org
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME at ietf.org
https://www.ietf.org/mailman/listinfo/dime

Thanks,
Ankit

"DISCLAIMER: This message is proprietary to Aricent and is intended
solely
for the use of the individual to whom it is addressed. It may contain
privileged or confidential information and should not be circulated or
used
for any purpose other than for what it is intended. If you have received
this message in error,please notify the originator immediately. If you
are
not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of
this
message. Aricent accepts no responsibility for loss or damage arising
from
the use of the information transmitted by this email including damage
from
virus."
_______________________________________________
DiME mailing list
DiME at ietf.org
https://www.ietf.org/mailman/listinfo/dime


_______________________________________________
DiME mailing list
DiME at ietf.org
https://www.ietf.org/mailman/listinfo/dime
No virus found in this incoming message.
Checked by AVG - http://www.avg.com 
Version: 8.0.169 / Virus Database: 270.6.21/1673 - Release Date:
9/15/2008 6:49 PM


_______________________________________________
DiME mailing list
DiME at ietf.org
https://www.ietf.org/mailman/listinfo/dime



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.