[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=66297#comment-66297 ] 

Rob Godfrey commented on AMQP-126:
----------------------------------

{quote}
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.
{quote}
Note, as per my prior comment, that there are potentially severe consequences to "sharing" a container id ... the consequences of "stealing" a link are potentially much worse than cleanly closing connections.
Note that establishing a container id happens *after* authentication, so that any such "attacks" would be traceable to an identity.  Having said that, implementations might wish to allow for tying container-id to authenticated identity in some way (so that a client which authenticates with identity A and the claims to be container B will fill fail if A does not have permission to connect as B). 


> 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)