Subject: RE: [AAA-WG]: issue: real-time duplicate detection andproposedchange.

From: <[email-masked]>
Date: Wed, 16 Oct 2002 10:04:02 +0300

Hi,

> I think that the CMS application, when ready, should include 
> the command
> code and other stuff from the header (otherwise you'll see 
> attacks where
> you have the same protected AVPs, but replace resource 
> allocation request with
> accounting request etc). As this text in the CMS application is being
> developed, we could take care of not including the D bit there.

I think what Jari say should be possible, it could be that D bit is not
included.

> Duplicates can happen end-to-end and middle-to-end. For the 
> D-bit to be
> useful, it has to be set in all places that can generate 
> duplicates. So,
> we really need to handle it even in proxies (if at all)!

I also agree with this, D flag to be useful need to be handled even
in Diameter agents (proxy, relay..).

Br
Marco

> -----Original Message-----
> From: ext Jari Arkko [mailto:[email-masked]]
> Sent: 16. October 2002 7:48
> To: Bernard Aboba
> Cc: Loughney John (NRC/Helsinki); [email-masked];
> [email-masked]
> Subject: Re: [AAA-WG]: issue: real-time duplicate detection
> andproposedchange.
> 
> 
> Bernard Aboba wrote:
> >>>However, your point on end-to-end made me think that if an
> >>>intermediate agent retransmits the packet, it must set the
> >>>'D' bit, and this could break e2e packet hash/signature.
> >>
> >>So it needs to be done end-to-end or not at all?
> > 
> > 
> > I think Pat's point was that the "D" but would need to be considered
> > mutable in any MICs calculated E2E. Transmission layer 
> security is not an
> > issue since this doesn't prevent an agent from setting the "D" bit.
> > 
> > My reading of the CMS Security application (correct me if 
> I'm wrong) is
> > that none of the MICs would cover the "D" bit, so it seems 
> to me that this
> > is not an issue.
> > 
> > Or am I missing something? If so, can someone point out the specific
> > section and page # (and draft) that describes what would be 
> broken by
> > setting the "D" bit in an intermediate agent?
> 
> That page doesn't exist.
> 
> I think that the CMS application, when ready, should include 
> the command
> code and other stuff from the header (otherwise you'll see 
> attacks where
> you have the same protected AVPs, but replace resource 
> allocation request with
> accounting request etc). As this text in the CMS application is being
> developed, we could take care of not including the D bit there.
> 
> John wrote:
> 
>  > So it needs to be done end-to-end or not at all?
> 
> Duplicates can happen end-to-end and middle-to-end. For the 
> D-bit to be
> useful, it has to be set in all places that can generate 
> duplicates. So,
> we really need to handle it even in proxies (if at all)!
> 
> Jari
> 
> 
>

---

From: <[email-masked]>
Date: Wed, 16 Oct 2002 11:29:22 +0300

Hi Bernard,

> So does that mean that no existing functionality if broken by 
> the "D" bit?

That is my understanding - no existing function is broken by the
D bit.

John

---

From: <[email-masked]>
Date: Wed, 16 Oct 2002 14:00:06 +0300

Hi Bernard,

> So does that mean that no existing functionality if broken by 

My understanding is that no existing functinality is broken unless
I'm missing something, can someone correct me if I'm wrong?

Also I have to admit that I never mentioned how the server may use
this D flag, and that the title of the issue is somehow misleading
as well as better explanation "why D-bit" is missed.
Probably a better title would have been "duplicate detection for
real-time accounting application" and I try a better explanation 
in a sperate mail, which follows this mail.

thanks,
Marco

> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 16. October 2002 7:06
> To: Jari Arkko
> OK. I thought I was missing something.
> 
> > I think that the CMS application, when ready, should 
> include the command
> Sure, because it's mutable.
>