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

From: Natarajan Kalpathy <[email-masked]>
Date: Fri, 13 Aug 1999 14:35:29 -0500

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: Natarajan Kalpathy <[email-masked]>
Date: Fri, 13 Aug 1999 14:39:12 -0500

Sorry for  typo in previous mail , here i  go  again

  secutrity  is  a   optional  item  if  you   look  at  ABNF  grammer , i dont
      know  why  is  it  complusory for MGC  to  implement  IPSEC  . 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/she   wants  security

Natarajan

---

From: Brian Rosen <[email-masked]>
Date: Mon, 16 Aug 1999 14:17:12 -0400

If you have real IPSEC, you can use AH and/or ESP to protect
the MEGACO protocol flows.

If you don't have IPSEC, we have provided an AH equivalent,
but not an ESP equivalent with the MEGACO protocol.

For the bearer, you use the security the bearer supports.

Matt's interoperability issues are between MG and MGC, and
have nothing to do with RTP or other bearers going between
MG and MG.

Brian

> -----Original Message-----
> From: Bob Bell [mailto:[email-masked]]
> Sent: Monday, August 16, 1999 12:50 PM
> To: [email-masked]
> Subject: Re: When to use AH-within-MEGACO
>
>
> I am a little confused. IPSec defines both the use of the AH for
> authentication and an Encapsulating Security Payload for
> opaque tunnelling
> of the IP Stream. IPSec may be used for the MEGACO signalling
> packages, but
> there are serious questions about its use on the RTP stream.
> Bob Bell
>
> At 09:20 AM  8/16/99 , Matt Holdrege wrote:
> >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
> >> >
> >> >
> Bob Bell
> Cisco Systems Inc.
> 801-294-3034(v)
> 801-294-3023(f)

---

From: Brian Rosen <[email-masked]>
Date: Tue, 17 Aug 1999 11:08:58 -0400

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]

> From: Matt Holdrege [mailto:[email-masked]]
> Sent: Monday, August 16, 1999 11:20 AM
> To: Brian Rosen
> Cc: [email-masked]
> We aren't the protocol police. All you can do is spell it out
> that some

---

From: Fernando Cuervo <[email-masked]>
Date: Tue, 17 Aug 1999 11:31:12 -0500

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]

---

From: Brian Rosen <[email-masked]>
Date: Wed, 18 Aug 1999 10:54:41 -0400

Sorry, but when you use IPsec, you either provision an SPI,
with the keys you need, or you use IKE to negate the SPI.
In either case, if you have IPSEC, and the other side doesn't,
you will know definitively whether you have a secure transport.

If you don't, you can try using the AH-under-megaco scheme.
If the other side supports it, you will get the Auth header
back, otherwise, you get an error.

So, if both sides implement the interim scheme, or if all MGCs
implement it, the user will always have the option of having
a secure (meaning, his choice of authenticated, integrity
checked, and possibly encoded) transport of megaco messages.
In all cases, the user will know if his connection is secure,
and his local security policy can determine if he proceeds if
the connection is not secure.

The issue on the table is not whether the interim scheme is
in the protocol; it was decided in Oslo that it is, and
Berlin did not change it.  The issue is whether it is mandatory
in the MGC and/or the MG.  The sentiment as I see it is that
it is like all the other options mandatory in the MG, optional
in the MGC.  We have a dissenting voice, who states that
MGCs may be built on the kinds of embedded operating systems
that don't yet offer IPsec.  It is up to our WG chair to
determine consensus on this issue.

Brian

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, August 18, 1999 10:30 AM
> Hi,
> I don't think IPsec has anything to do with H.248, or any other
> same-layer protocol. IPsec is a method for encryption IP packets -
> period - no matter what is on the layers above. If IPsec is mandatory
> for H.248, is MUST be implemented on all the different MGC/MG
> platforms.
> Ok, today it probably isn't, and that IS a big problem, but I still
> don't think adding IPsec stuff, like AH and/or ESP, in the protocol is
> the right answer.
>
> Consider this case:
>
> Example 1: If the MGC platform supports IPsec, it will change the
> next-protocol field in the IP header to the one used by AH or ESP
> (sorry, I don't remember the values by hand). Then, if the MG platform
> does not support IPsec (it will be taken care of by the H.248
> protocol),
> where will the IP stack forward the packet? It does not see it as a
> TCP/UDP/whatever-transport-H.248-will-use packet, but as IPsec packet,
> and since IPsec is not implemented on the platform, there is
> no place to
> send the packet.
>
> Example 2: If the MG platform does not support IPsec, the
> protocol will
> add the AH header, but will not be able to change the next-protocol
> field in the IP header. Thus, the MGC platform, that DOES
> support IPsec,
> will not see it as an IPsec packet, but as a normal
> TCP/UDP/whatever-transport-H.248-will-use packet. H.248 will
> then get a
> packet with an AH header, which it has to deal with itself,
> which means
> there is no use to have IPsec on the platform itself in the
> first place.
>
> The second example is probably easier to deal with than the
> first, but I
> still think it makes things quite complicated.
>
> Maybe I've missed something, so please correct me if I'm wrong.
>
> Christer
>
>
> [email-masked] wrote:
>

---

From: Fernando Cuervo <[email-masked]>
Date: Thu, 19 Aug 1999 13:05:30 -0500

Brian,
I decided to wordsmith and reorganise a bit the security section ,
I believe it does a better job of explaining the IPsec preference over the
interim scheme. We also corrected a couple of the references to IPsec docs.
here it goes...

7.9 Security Considerations

  A security mechanism is clearly needed to prevent unauthorized entities
from using the
MEGACO/H.248 protocol for setting up unauthorized calls or interfering with
authorized calls.

  The security mechanism for the MEGACO/H.248 protocol is IPsec [RFC2401 to
RFC2411].
The AH header [RFC2402] affords data origin authentication, connectionless
integrity and
optional anti-replay protection of messages passed between the MG and the
MGC. The
ESP header[RFC2406] provides all the above security services plus
confidentiality of
messages, if desired. For instance, the ESP encryption service should be
requested if the
session descriptions are used to carry session keys, as defined in SDP.

  MEGACO/H.248 implementations employing the ESP header MUST comply with
section
5 of [RFC2406], which defines a minimum set of algorithms for integrity
checking and encryption.
Similarly, MEGACO/H.248 implementations employing the AH header MUST comply
with
section 5 of [RFC2402], which defines a minimum set of algorithms for
integrity checking.

  MEGACO/H.248 implementations SHOULD use IKE [RFC2409] to permit more
robust
keying options. MEGACO/H.248 implementations employing IKE SHOULD support
authentication with RSA signatures and RSA public key encryption.

7.9.1 Interim AH-within-MEGACO/H.248 scheme

  Implementation of IPsec requires that the AH or ESP header be inserted
immediately after
the IP header. This cannot be easily done at the application level.
Therefore, this presents a
deployment problem for the MEGACO/H.248 protocol where the underlying
network
implementation does not support IPsec.

  As an interim solution, the MEGACO/H.248 protocol defines an optional AH
header within
the MEGACO/H.248 protocol header. The header fields are exactly those of the
SPI,
SEQUENCE NUMBER and DATA fields as defined in [RFC2402]. The semantics of
the
header fields are the same as the "transport mode" of [RFC2402], except for
the calculation
of the Integrity Check Value (ICV). In IPsec, the ICV is calculated over the
entire IP
packet including the IP header. This prevents spoofing of the IP addresses.
To retain the
same functionality, the ICV calculation should be performed across the
entire transaction
prepended by a synthesized IP header consisting of a 32 bit source IP
address, a 32 bit
destination address and an 16 bit UDP port in the MSBs of a 32 bit word. The
Authentication
Data is assumed to be zero as in [RFC2402]. When the AH-within-MEGACO/H.248
mechanism is employed when TCP is the transport Layer, the UDP Port above
becomes
the TCP port, and all other operations are the same.

  Implementations of the MEGACO/H.248 protocol using IPv4 MUST implement the
interim
AH-within-MEGACO/H.248 scheme. However, this interim scheme MUST NOT be used

when the underlying network layer supports IPsec. IPv6 Implementations are
assumed to
support IPsec and MUST NOT use the AH-within-MEGACO/H.248 interim scheme.

  All implementations of the AH-within-MEGACO/H.248 interim mechanism MUST
comply
with section 5 of [RFC2402] which defines a minimum set of algorithms for
integrity checking
using manual keys.

  The AH-within-MEGACO/H.248 interim scheme does not provide protection
against
eavesdropping; thus forbidding third parties from monitoring the connections
set up by a given
termination. Also, it does not provide protection against replay attacks.

  These procedures do not necessarily protect against denial of service
attacks by misbehaving
MGs or misbehaving MGCs. However, they will provide an identification of
these misbehaving
entities, which should then be deprived of their authorization through
maintenance procedures.

> Sent:         August 17, 1999 2:01 PM
> 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.
>
> > 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
> >
> >
> > > AH-within-MEGACO/H.248 scheme.  Implementations MUST
> > support IPsec AH
> > > header
> > > operating systems supports it.  If the MG's underlying
> > operating system
> > > does
> > > not support IPSEC AH,
> > > IPSEC ESP header.  IPSEC and AH-within-MEGACO/H.248 must
> > not be used at
> > > the
> > > IPSEC ESP header.  IPSEC and AH-within-MEGACO/H.248 must
> > not be used at
> > > the