Subject: [midcom] Fail over mechanism in midcom

From: "Abdallah Rayhan" <[email-masked]>
Date: Wed, 17 Jan 2001 14:14:10 -0500

Fail over mechanisms, IMHO, should be addressed as part of the
midcom architecture. By fail over I mean two things:
    1- external agent going out of service and handing the
       service off to another agent.
       
       Should the middle box trust the new agent and
       impose security challenges on it?
       
       Should state-transfer be assumed between the old agent
       and the new one?
       
       There are issues related to provisioning, such as
       should the middle box be pre-provisioned to authorize
       the new agent to engage in signaling? etc...

    2- middle box going out of service and handing the service
       off to another middle box.
       
       In addition to the issues in 1, we probably need to
       identify how to handle existing pinholes when service
       change occurs.   

Obviously there are issues that needs to be addressed in each
case to make such handing over seamless to the apps/users
that is if we decided to support this feature.

regards
Abdallah

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: "Melinda Shore" <[email-masked]>
Date: Wed, 17 Jan 2001 17:19:24 -0500

>        impose security challenges on it?

I think you're missing something here but raising
a related question that does need to be addressed.
We're already assuming that more than one agent
can talk to a middlebox.  What we haven't discussed,
however, is the question of ownership of transactions.
If agent A can request a pinhole, will it be possible
to authorize agent B to dink with that pinhole (close
it, extend its lifetime, etc.).  This strikes me as an
authorization/policy question rather than having much
to do directly with failover.

>        off to another middle box.

This really is a very hard problem for a bunch of 
reasons and I cannot imagine how to do it reliably
for NAT unless the whole box is being failed over.
And if that's the case, then it's already being handled 
elsewhere.  You may want to look at the reliable
server pooling documents, although I think that
rserpool is quite unsuitable for applications 
maintaining a lot of state, which a middlebox
(firewall, NAT, etc.) almost inarguably is.  At
any rate, this is clearly out of scope for midcom.

Melinda