Subject: Re: When to use AH-within-MEGACO

From: Brian Rosen <[email-masked]>
Date: Tue, 17 Aug 1999 14:01:49 -0400

I agree that operational results determine what actually
happens.  What we want is that IPsec is used if it's available.
What we are asked to do is write the spec in terms of
mandatory-to-implement (in the language, we can't police it).
So if we really want to maximize interoperability, we would have
to mandate that both sides implement the interim scheme,
and state that IPsec is used in preference to the interim
scheme if available.  That is what the current wording states.
If you want to wordsmith it to make your point clearer, I'll see
what I can do.

The real thread, I thought, was the issue of requiring BOTH
ends to implement the interim scheme.

If we are willing to accept some possible interoperability,
you could back off on the MG; saying that the MGC has to do
both, but the MG can do either.  The problem is that there are
at least some people who claim they will not be able to
implement IPsec on an MGC.

To further back off, we could say you implement IPsec if you
can, and the interim scheme if you can't on both sides.  There
we will have many more problems with MGCs that don't implement
the interim scheme, with MGs that don't have IPsec.

> -----Original Message-----
> From: Fernando Cuervo [mailto:[email-masked]]
> Sent: Tuesday, August 17, 1999 12:31 PM
> To: [email-masked]; 'Brian Rosen'
> Subject: RE: When to use AH-within-MEGACO
>
>
> Specifying interoperability in terms of the system
> capabilities does not
> seem appropriate, operational results should be used. In this
> case I would
> simply say that if an MGC and an MG cannot establish a
> Security Association
> then the AH-within-MEGACO/H.248 scheme must be used. So there is a
> requirement that both MGC and MG (if IPSEC capable) be able
> the identify the
> supplied mId with that of a system that failed to establish
> an SA, at this
> point the MGC or MG may decide to proceed or decline an
> association with the
> AH-within-MEGACO/H.248 scheme.
>
> what do you think?
>
> Fernando
> > ----------
> > From:       Brian Rosen[SMTP:[email-masked]]
> > Sent:       August 17, 1999 11:08 AM
> > To:         [email-masked]
> > Subject:    Re: When to use AH-within-MEGACO
> >
> > Sure, we can't enforce anything.  The question is what the
> > document says.  At the moment, it says:
> >
> > "Implementations of this protocol using IPv4 MUST support
> the interim
> > AH-within-MEGACO/H.248 scheme.  Implementations MUST
> support IPsec AH
> > header
> > if the underlying operating systems supports it; if the
> operating systems
> > support IPSEC AH-headers, the AH-within-MEGACO/H.248 MUST
> NOT be used.
> > Implementations may support the ESP header.  IPSEC and
> > AH-within-MEGACO/H.248 must not be used at the same time."
> >
> > This way is fully interoperable, although the phrase
> > "if the operating systems support IPSEC AH-headers, the
> > AH-within-MEGACO/H.248 MUST NOT be used" has to be reworded
> to say "if the
> > operating systems of both MG and MGC support IPSEC AH-headers, the
> > AH-within-MEGACO/H.248 MUST NOT be used".  Another way which is not
> > interoperable is:
> >
> > "MG implementations MUST support the IPSEC AH header if the
> underlying
> > operating systems supports it.  If the MG's underlying
> operating system
> > does
> > not support IPSEC AH,
> > then MG implementations MUST implement the interim AH-within-
> > MEGACO/H.248 scheme.
> >
> > MGC implementations of this protocol using IPv4 MUST
> support the interim
> > AH-within-MEGACO/H.248 scheme.  MGC implementations MUST
> support the IPSEC
> > AH header if the underlying operating systems supports it
> >
> > If the operating systems of both MG and MGC support IPSEC
> AH-headers, the
> > AH-within-MEGACO/H.248 MUST NOT be used. Implementations
> may support the
> > IPSEC ESP header.  IPSEC and AH-within-MEGACO/H.248 must
> not be used at
> > the
> > same time.  IPv6 Implementations are assumed to have IPSEC
> implementations
> > and MUST NOT use the AH-within-MEGACO/H.248 scheme."
> >
> > This wording is more consistent with the rest of the document,
> > which gives the MG implementations options, but requires both
> > on the MGC.  It will not be interoperable where the MG has
> > IPSEC, but the MGC does not.
> >
> > The third choice is even less interoperable:
> > "Implementations of this protocol MUST support the IPSEC AH
> header if the
> > underlying operating systems supports it.  If the
> underlying operating
> > system does not support IPSEC AH,
> > then the interim AH-within-MEGACO/H.248 scheme MUST be
> supported.  MGC
> > implementations SHOULD support the interim scheme even if
> it's underlying
> > operating system supports IPSEC.
> >
> > If the operating systems of both MG and MGC support IPSEC
> AH-headers, the
> > AH-within-MEGACO/H.248 MUST NOT be used. Implementations
> may support the
> > IPSEC ESP header.  IPSEC and AH-within-MEGACO/H.248 must
> not be used at
> > the
> > same time.  IPv6 Implementations are assumed to have IPSEC
> implementations
> > and MUST NOT use the AH-within-MEGACO/H.248 scheme."
> >
> > Choices?
> >
> > Brian
> > ------------
> > Brian Rosen, Principal Engineer
> > FORE Systems, 1000 FORE Drive, Warrendale, PA 15086
> > (724) 742-6826  mailto:[email-masked]
> >
> >
> > > -----Original Message-----
> > > From: Matt Holdrege [mailto:[email-masked]]
> > > Sent: Monday, August 16, 1999 11:20 AM
> > > To: Brian Rosen
> > > Cc: [email-masked]
> > > Subject: Re: When to use AH-within-MEGACO
> > >
> > >
> > > We aren't the protocol police. All you can do is spell it out
> > > that some
> > > MG's may have the alternate AH scheme and some may have true
> > > IPsec. MGC's
> > > should have both IPsec and the alternate scheme or they risk
> > > non-interoperability.
> > >
> > >
> > > At 09:23 AM 8/16/99 -0400, Brian Rosen wrote:
> > > >Security is mandatory to implement, optional to use.
> > > >The question is do we require all MGCs to implement AH-under-
> > > >Megaco even if it can implement IPSEC in order to interoperate
> > > >with any MG that does not have IPSEC, or do we allow it
> > > >to be optional-to-implement if IPSEC is implemented.
> > > >
> > > >Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Natarajan Kalpathy
> [mailto:[email-masked]]
> > > > > Sent: Friday, August 13, 1999 3:35 PM
> > > > > To: [email-masked]
> > > > > Subject: Re: When to use AH-within-MEGACO
> > > > >
> > > > >
> > > > > Well  first  of  all  secutrity  is  a   optional  item  if
> > > > > you   look  at
> > > > > ABNF  grammer , i dont  know  why  is  it  complusory for MGC
> > > > >  to  implement
> > > > > MGC . The current  draft clearly states that if   some  one
> > > > > have  IPSEC
> > > > > implemented  then  it  is  the  first  choice  other wise
> > > > > one  can  go  for
> > > > > MEGACO  AH  header  if  he  wants  security
> > > > >
> > > > > Natarajan
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Brian Rosen <[email-masked]> on 08/13/99 02:03:27 PM
> > > > >
> > > > > Please respond to Brian Rosen <[email-masked]>
> > > > >
> > > > > Sent by:  Brian Rosen <[email-masked]>
> > > > >
> > > > >
> > > > > To:   [email-masked]
> > > > > cc:    (Natarajan Kalpathy/MW/US/3Com)
> > > > > Subject:  When to use AH-within-MEGACO
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > The Berlin draft changed the wording for AH-under-MEGACO to
> > > > > read:
> > > > >
> > > > > Implementations MUST implement IPsec AH header if the
> underlying
> > > > > operating systems supports it; if the operating
> systems support
> > > > > IPsec AH-headers, the AH-within-MEGACO/H.248 MUST NOT be
> > > > > used.Implementations may support the ESP header.
> IPSEC and AH-
> > > > > within-MEGACO/H.248 must not be used at the same time.
> > > > >
> > > > > Other than the obvious editing typos,
> > > > > I don't think this captures what we want to do.
> > > > >
> > > > > I believe we can assert that MGCs must implement IPSEC.  If
> > > > > anyone objects, please yell now.  I then propose that the
> > > > > words say, if an MG can do IPSEC, that is what it must do.
> > > > > If you can't then MGs must implement AH-in-MEGACO.
> > > > > MGCs must implement both.
> > > > >
> > > > > Brian
> > > > >
> > >
> >
>

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 17 Aug 1999 13:51:52 -0700

We agreed in Oslo that the MGC must support both if it wants to
interoperate. The argument that cheap, dumb IP phones can't do IPsec was
taken into consideration. But MGC's, no matter what the OS is, are not
cheap and dumb. Or if they are, they will only be used in cheap, dumb
networks. :)

So what's the problem again?

---

From: Christian Huitema <[email-masked]>
Date: Tue, 17 Aug 1999 17:22:57 -0400

> cheap and dumb. Or if they are, they will only be used in cheap, dumb

This is also what I recall from Oslo. That MG will do either, since IPSEC
is preferred but may not be always available on small real-time OS used in
gateways, and that MGC will do both, since classic MGC platforms do indeed
support IPSEC.

--
Christian Huitema
------------------------------
Please note my new address: [email-masked]
http://www.telcordia.com/

---

From: Shyamal Prasad <[email-masked]>
Date: Tue, 17 Aug 1999 17:06:44 -0500

"Matt" == Matt Holdrege <[email-masked]> writes:

    Matt> We agreed in Oslo that the MGC must support both if it wants
    Matt> to interoperate. The argument that cheap, dumb IP phones
    Matt> can't do IPsec was taken into consideration. But MGC's, no
    Matt> matter what the OS is, are not cheap and dumb. Or if they
    Matt> are, they will only be used in cheap, dumb networks. :)

    Matt> So what's the problem again?

The "dumb and cheap" arugment is an oversimplification.

Why is everyone assuming the lack of IP Sec has to do with "dumb and
cheap"? It is simply a decision related to the lack of IP Sec on some
commerically available RTOS implementations. But if you can do
application level AH, you can certainly build an IP Sec stack (or your
IP stack vendor can) on the same hardware. Besides, (correct me if I
am wrong), if you did the AH header you'd still have to build some
sort of key management into your application, would you not? It's a
lot of work anyway you look at it.

The option of using an application level AH header is a hack, and a
pretty dirty one at that too, to allow the market time to adjust to
the lack of IP Sec implementations. Ideally it should not even be an
option: if your MG OS vendor does not support IP Sec, well, sit on
them and make sure they do, soon.

However, if you can allow MG vendors time to go out and get an IPSec
stack, I think you should give MGC vendors the same flexibility. Also,
I don't understand why people are expecting all MGCs to be built on
Solaris/Windows 2000, and all MG's to be "cheap and dumb." Software
and markets are never that simple.

Yes, interoperability is a pain. But if you hack things, you can hack
it so "all MG/MGC's that implement IP Sec must also support the use of
the application level AH header" (I can hear you go "ugh", but how
much dirtier is that?). If you do that, everything interworks.

Why are people asking "does anyone have a problem with MGC's being
required to support IP Sec?" when no one has ever publicly asked for a
similar statement for MGs? What MG's can do AH at the application
level and not be capable of doing IP Sec, and why?

I believe that the asymmetric view for MG/MGC capabilities that is
being proposed right now is very short sighted.

Cheers!
Shyamal
--
Shyamal Prasad   +1 972 583-5499
The views expressed above are mine, not that of Ericsson.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 17 Aug 1999 15:06:21 -0700

> gateways, and that MGC will do both, since classic MGC platforms do indeed

   That was also my understanding, but I do recall
that there was some concern voiced that this
asymmetric arrangement might not go over well with
the powers that be. Or was that optional TCP for
the MG? I might be confusing the two, though I
thought I heard the same concern for both.

   What I'd like to bring up here is that,
although I appreciate Brian's concern about small
MG's that don't own their stack, I'm not
especially convinced that putting the AH or ESP at
application level is going to significantly help
the speed of deployment of people in that
unfortunate situation.
   ESP is likely to be mandatory for MEGACO/H.248
implementations, not just AH since signaling which
traverses untrusted parts of the network will not
afford the privacy that is commonly assummed in
the current PSTN.  Also, although I can live with
IKE being informative rather than normative in the
recommendation, the reality of the situation is
that for mass deployment of residential CPE,
pre-shared-key IPSec is not a viable option.
Either IKE or something that does a lot of the
same things as IKE is going to be mandatory to
deploy the MG.
   Although I can see in theory how you could
successfully decouple AH and ESP from the IP
layer, I have a great deal of doubt as to how much
faster it will be to get that unfortunate vendor
from point A to point B. In fact, my hunch is that
it will in fact be *slower* since there is bound
to be all the usual lack of implementations and
interoperability issues with
wheel-reinvention. Worse is that the MEGACO text
as it stands right now does not do an adequate job
of addressing how to resolve any of these
interoperability problems; referring to the
relevant RFC's is not adequate because they are
normative for IP layer IPSec and need to be
interpreted for application layer (unless the
IPSec WG is working on that problem too).
   In sum, if I were a vendor in the unenviable
situation of not having IPSec and I were faced
with this burden, I still think that my best
course of action would be to expend my energy to
get real IPSec into my box. App layer IPSec is a
very iffy proposition and I'm not sure how prudent
it is to take a chance on an untried, under
speciefed, and potentially under supported
(ex-cathedra MUST's not withstanding) option just
for MEGACO.
   My suggestion: junk the entire concept and
concentrate our efforts on standards based
solutions.

                Mike

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 17 Aug 1999 15:28:51 -0700

It was an oversimplification, but one that I think everyone understands.
Your further arguments are the same that I've been making all along. I
can't understand why anyone would want to built AH into the application
layer when the better standard alternative exists.

I also can't understand why any service provider would ever use it?