[OASIS Issue Tracker] (AMQP-126) Sole Connection Detection Policy needs clarification

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/AMQP-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=66295#comment-66295 ] 

Lorenz Quack commented on AMQP-126:
-----------------------------------

I wonder whether this could be considered a DoS attack vector.
Imagine an application connecting/disconnecting using popular container-ids to a container implementing this spec and requesting the close-existing policy.
This would then disconnect all existing connections regardless of whether the existing connections support this spec.
This would work regardless of the detection policy implemented by the enforcing container.
The spec requires compliant implementations to support the close-existing policy guaranteeing a compliant implementation would be susceptible to this.

> Sole Connection Detection Policy needs clarification
> ----------------------------------------------------
>
>                 Key: AMQP-126
>                 URL: https://issues.oasis-open.org/browse/AMQP-126
>             Project: OASIS Advanced Message Queuing Protocol (AMQP) TC
>          Issue Type: Bug
>          Components: Sole Connection
>    Affects Versions: soleconn-WD2
>            Reporter: Lorenz Quack
>
> I find Section 3.2.2 of the specification unclear.
> To wrap my brain around the rules and when a certain detection policy would trigger the enforement policy I consider 4 cases: an existing connection does/doesn't have sole connction enforement (SCE) permutated with the new connection having/not having SCE.
> Then my reading of the spec gives me this table:
>   | old conn |  new conn ||  "strong" | "weak"
> 1 | NO SCE   |  NO SCE   ||    no     |   no
> 2 | NO SCE   |     SCE   ||    no     |  yes
> 3 |    SCE   |  NO SCE   ||    yes    |   no
> 4 |    SCE   |     SCE   ||    yes    |  yes
> Do people agree with my reading of the spec?
> Was it intended this way?
> In the "strong" case I find the asymmetry between case 2 and 3 surprising.
> I find it surprising that the weak policy should trigger in case 2 where the "strong" policy does not.
> My guess is that the intention was that the strong policy also triggers in case 2.
> Overall, I find it hard to see a clear intention behind the two detectoin policies.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)