Subject: [Megaco] Abrogation of Error Code 504

From: "Sean Leahy" <[email-masked]>
Date: Fri, 5 Oct 2001 11:57:24 +0100

Error Code 504 ('Command from Unauthorised Entity') appears to have been
abrogated.

This error is useful when an MGC may want to receive a kick from the MG
that it (the MGC) should now start the process of re-registration with that
MG by requesting it to restart.

For example: The MG had gone down when the MGC last attempted to perform
this operation with all it's MGs after a re-assignment process. Now the MGC
detects that the MG is up again via the (anticipated) error response to an
audit .

We are left with Error Code 402 as an alternative for this situation but
that seems poorer as it implies the unauthorised action is termination
(rather than Gateway) specific.

Can we have Error Code 504 back please ?

Sean Leahy

_______________________________________________
Megaco mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/megaco

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 5 Oct 2001 10:10:18 -0400

The MG shouldn't even reply to an MGC with which it has no control
relationship.  Otherwise it is subject to DOS attacks where formulation of
such replies consumes resources.  I tried to find words on the subject in
RFC 3015, but no luck so far.

-----Original Message-----
From: Sean Leahy [mailto:[email-masked]]
Sent: Friday, October 05, 2001 6:57 AM
To: [email-masked]
Cc: Andrew Russell-laing; Richard Saffrey; Richard Watts
Subject: [Megaco] Abrogation of Error Code 504

Sean Leahy

---

From: "Sean Leahy" <[email-masked]>
Date: Fri, 5 Oct 2001 16:28:57 +0100

Tom,
     Re: The MG shouldn't even reply to an MGC with which it has no control relationship.

     What if the MGC has different entities with different addresses, the MG is known to all these entities as a part of the enclosed system
     but the MG does not know that the entity assigned to control it has changed ?

     The MG also knows the identities of all possible controlling entities, but simply believes an out of date entity is the current controlling
entity.

     The MG thinks it still has a control relationship with entity X but the MGC has moved the control to entity Y and entity Y has started to audit
it,
waiting for it to come back up.

     In this case, protection can be provided by checking the register of known MGs and MGC Entities whilst using Error 504 for when the changeover
of controlling entities WITHIN THE SYSTEM gets lost at the MG.

     Regards,
     Sean Leahy

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 5 Oct 2001 11:46:59 -0400

I'm sorry, this violates the Megaco model which has the MG in control of the
control session except when the MGC sends down a ServiceChange request on
ROOT.  I have colleagues who are unhappy with this model, but consensus has
stood behind it.  

Do I have the sequence right?

 1) The MG goes out of service temporarily.
 2) When it comes back, it thinks it still has a control session with MGC A.
 3) MGC B is auditing it because it has taken over.

What seems to be missing here is the following behaviour required by the
standard:
 2a) The MG should have sent a ServiceChange to MGC A indicating that it is
back in service.
 2b) If MGC A failed to reply, the MG should have tried another.
 3) MGC B really can't take over until the MG has acknowledged a handoff.

-----Original Message-----
From: Sean Leahy [mailto:[email-masked]]
Sent: Friday, October 05, 2001 11:29 AM
To: Taylor, Tom-PT [CAR:B881:EXCH]
Cc: [email-masked]; Richard Saffrey
Subject: RE: [Megaco] Abrogation of Error Code 504

Tom,
     Re: The MG shouldn't even reply to an MGC with which it has no control
relationship.

     What if the MGC has different entities with different addresses, the MG
is known to all these entities as a part of the enclosed system
     but the MG does not know that the entity assigned to control it has
changed ?

     The MG also knows the identities of all possible controlling entities,
but simply believes an out of date entity is the current controlling
entity.

     The MG thinks it still has a control relationship with entity X but the
MGC has moved the control to entity Y and entity Y has started to audit
it,
waiting for it to come back up.

     In this case, protection can be provided by checking the register of
known MGs and MGC Entities whilst using Error 504 for when the changeover
of controlling entities WITHIN THE SYSTEM gets lost at the MG.

     Regards,
     Sean Leahy

---

From: "Sean Leahy" <[email-masked]>
Date: Mon, 8 Oct 2001 10:10:16 +0100

Tom,
     You wrote :

"Do I have the sequence right?

What seems to be missing here is the following behaviour required by the standard:
 2a) The MG should have sent a ServiceChange to MGC A indicating that it is back in service.
 2b) If MGC A failed to reply, the MG should have tried another.
 3) MGC B really can't take over until the MG has acknowledged a handoff. "

Basically, the sequence you suggest is what we were considering except that the MG did not
really go OOS, communication with it was just temporarily lost - hence the MG never restarted and
thus never saw any need to send a Service Change.

Instead the MG carries on and when communication is restored, a new MGC sub-entity (different address)
is auditing it. Whan the new MGC Entity receives Error 504, it then sends a Service Change (Root).

Regards,
Sean

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 8 Oct 2001 22:26:14 -0400

Are you saying the MG didn't detect the loss of communication but the MGC
did?  I have a feeling we've heard about this problem before, and the
proposed answer was polls from the MG.  The response to that was that the
MGC had better be able to control the frequency of polling.

-----Original Message-----
From: Sean Leahy [mailto:[email-masked]]
Sent: Monday, October 08, 2001 5:10 AM
To: Taylor, Tom-PT [CAR:B881:EXCH]
Cc: [email-masked]; Richard Saffrey
Subject: RE: [Megaco] Abrogation of Error Code 504

Tom,
     You wrote :

Basically, the sequence you suggest is what we were considering except that
the MG did not
really go OOS, communication with it was just temporarily lost - hence the
MG never restarted and
thus never saw any need to send a Service Change.

Instead the MG carries on and when communication is restored, a new MGC
sub-entity (different address)
is auditing it. Whan the new MGC Entity receives Error 504, it then sends a
Service Change (Root).

Regards,
Sean

---

From: "Sean Leahy" <[email-masked]>
Date: Tue, 9 Oct 2001 08:58:38 +0100

Tom,
     Re: Your Question:

     "Are you saying the MG didn't detect the loss of communication but the
MGC did?  I have a feeling we've heard about this problem before, and the
proposed answer was polls from the MG.  The response to that was that the
MGC had better be able to control the frequency of polling."

     Yes, the MG does not poll but the MGC polls via an audit request sent
at a frequency determined by its view of the service state of the MG.

     Since protection of abuse is prevented by registers held at the MG and
MGC of entities allowed to enter the control relationship, I cannot see why
the MG cannot return an error 504 to the MGC if a part of the MGC ends up
polling it that is different from the original MGC sub-entity that was
controlling it. This then kicks off the MGC Entity to request the MG
restarts and re-registers.

     Sean

---

From: "Sean Leahy" <[email-masked]>
Date: Wed, 10 Oct 2001 15:59:07 +0100

Tom,
     I was hoping you would reconsider abrogating Error Code 504 on the
basis of this discussion, since I think I have provided a solution to the
DOS attack problem that was previously used to justify not allowing it i.e.
the Error Code Reply is only returned when the sender is on a known list of
entities allowed to enter the control relationship.

     Sean
---------------------- Forwarded by Sean Leahy/MAIN/MC1 on 10/10/2001 15:30
---------------------------

(Embedded image moved to file: pic22758.pcx)
From: Sean Leahy On: 09/10/2001 08:58:38

To:   "Tom-PT Taylor" <[email-masked]> @ MCEXT
cc:   [email-masked], Richard Saffrey/MAIN/MC1@MCMAIN

Subject:  RE: [Megaco] Abrogation of Error Code 504  (Document link: Sean
      Leahy)

Tom,
     Re: Your Question:

     Sean

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 10 Oct 2001 14:22:02 -0400

OK, let's generalize your requirement slightly.  You want a means for an MG
to indicate to an MGC with which it has a trust relationship that no control
association exists between them.  Why not simply 401 Protocol Error, since
the problem is a protocol violation?  There is also 402 Unauthorized.

I have to confess that I have been unable to find language in H.248
forbidding responses to MGCs not in an active association with the MG.  It
was certainly a consideration in our definition of error codes.

-----Original Message-----
From: Sean Leahy [mailto:[email-masked]]
Sent: Wednesday, October 10, 2001 10:59 AM
To: Taylor, Tom-PT [CAR:B881:EXCH]
Cc: [email-masked]; Richard Saffrey
Subject: RE: [Megaco] Abrogation of Error Code 504

Tom,

     Sean

Tom,
     Re: Your Question:

     Sean

---

From: "Sean Leahy" <[email-masked]>
Date: Thu, 11 Oct 2001 09:10:09 +0100

---------------------- Forwarded by Sean Leahy/MAIN/MC1 on 11/10/2001 09:07
---------------------------

(Embedded image moved to file: pic17086.pcx)
From: Sean Leahy On: 11/10/2001 09:09:38

cc:

Tom,
     Re: Your comments:

     Comment: "OK, let's generalize your requirement slightly.  You want a
means for an MG to indicate to an MGC with
which it has a trust relationship that no control association exists
between them.  Why not simply 401 Protocol Error,
since the problem is a protocol violation?  There is also 402 Unauthorized
."

     Reply : Well we do not think it is a 401 protocol error and we want
the specific information that the reason for the error is
that the MG does not have the control association with the particular
(known) sub-entity of the MGC. The definition for Error
402 in Annex L seems to suggest that the error is specific to the
conjunction of a particular termination with a particular
command rather than a general problem to do with the relationship between
the MGC and MG.

     Comment: "I have to confess that I have been unable to find language in H.248 forbidding responses to MGCs not in an active
association with the MG.  It was certainly a consideration in our definition of error codes."

     Reply: Error 504 'Command Received from unauthorised entity' seemed to us to fit the bill (if you assume 'authorised'
includes the concept of 'within a control relationship') but it is currently defined as 'not used'.

     Regards,
     Sean Leahy

---

From: "Sean Leahy" <[email-masked]>
Date: Fri, 12 Oct 2001 09:17:54 +0100

Richard/Dave,
     Have you any further views on this ?

     I was concerned that :

a. Error 402 in Annex L seems to suggest that the error is specific to the
conjunction of a particular termination with a particular command rather
than a general problem to
do with the relationship between the MGC and MG.

b. Originally, it was argued that we should not use an error for the
purposes we wanted.

     However, I also find it unlikely that an error would be caused due to
an 'authorisation' problem
that was so specific !  I guess I would have abrogated Error 402 rather
than Error 504 or changed the
description of Error 402.

     However, I think we could live with using Error 402 so long as no-one
else wants to interpret it
as specifically as the spec' suggests ?

     Regards,
     Sean
---------------------- Forwarded by Sean Leahy/MAIN/MC1 on 12/10/2001 09:05
---------------------------

Christian Groves <[email-masked]>@ietf.org on 12/10/2001
05:20:53

Sent by:  [email-masked]

To:   Tom-PT Taylor <[email-masked]>
cc:   "[email-masked]'" <[email-masked]>

Subject:  Re: FW: [Megaco] Abrogation of Error Code 504

G'Day Tom,

You wanted other opinions so I must agree with you I think 402 is
sufficient. The reason 504 was abrogated was that it overlapped with
402.

402 Unauthorized
The command is not executed due to the originator of a command is not
authorised to execute that command for the termination(s) affected by
it.
504 Command Received from unauthorized entity

I fail to see the difference between the codes. ie.
o Originator = entity
o not authorised = unauthorised
o termination(s) - every H.248 command references termination(s)

If 402 wasn't for this case can someone give me an example of a
completely difference case where it would be used.

Regards, Christian

Tom-PT Taylor wrote:
> From: Taylor, Tom-PT [CAR:B881:EXCH]
> Sent: Thursday, October 11, 2001 10:35 AM
> To: Sean Leahy
> OK, I've carried the argument far enough.  What are other people's
> views?  If there are no objections, I'll give the action to Sean to
> draft a very short I-D documenting the error code for purposes of IANA
> registration.  The ITU will have to figure out their process for
> amending Annex L.
>
> Sent: Thursday, October 11, 2001 4:10 AM
>      Comment: "I have to confess that I have been unable to find
> language in H.248 forbidding responses to MGCs not in an active
>
>      Reply: Error 504 'Command Received from unauthorised entity'
> seemed to us to fit the bill (if you assume 'authorised'
>