Subject: New Version of Megaco/H.248 Protocol Document Available

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 14 Jan 2000 12:34:15 -0500

We have posted a new version of the protocol document on the web site.

Files are at
ftp://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v13.doc
and
ftp://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v13.pdf

This version will, we hope, be superceded VERY soon by another one,
and that one will be issued as an Internet Draft.  This version has
almost all of the text changes that have been discussed, an updated ABNF and
updated examples.  The ASN.1 is NOT updated.

I would personally view the Signals text as not updated, and the
Local/Remote descriptor text as still a work in progress.  While there
are some minor points still in debate, I believe most other issues
are settled, and the text reflects the decisions made.

Please review this text as soon as possible.  If you believe that the
text does not reflect consensus as determined in meetings and on the
list, please raise the issues NOW.  At this time, we are discouraging
new ideas.

Brian

---

From: Pekka Pessi <[email-masked]>
Date: Mon, 17 Jan 2000 21:34:59 +0200

The authentication mechanism described in section 10.2 is still
        incomplete. It is not clear what "UDP" is (source port, destination
        port or protocol number).  Also, the current text refers to
        "transaction" instead of "message". There is error in the number of
        the hex digits for pseudo header, too.

        The text does not address ASN.1 at all. I think that the easiest way
        to defined the AH procedure for ASN.1 is to use algorithm defined in
        RFC2402, i.e., include an authHeader with zero AuthData when the
        data is encoded, compute ICV, then use some heuristics to find
        AuthData and patch the BER encoding result.

        In order to avoid issues with different canonic encodings, I'd like
        to encode pseudoheader with PER, especially because in this case the
        PER encodings means just putting the values in a C structure like
        this:

struct PseudoHeader {
  struct in_addr src_ip;
  struct in_addr dst_ip;
  unsigned short src_port; /* in network byte order */
  unsigned short src_port; /* in network byte order */
  unsigned char  protocol;
};

        So, I propose following text to the end of second paragraph:

-----8<-------------8<-------------8<-------------8<-------------8<-----
... This prevents spoofing of the IP addresses.  To retain the same
functionality, the ICV calculation should be performed across the entire
message prepended by a synthesized IP header consisting of an 8-bit protocol
number, a 32-bit source IP address, a 32-bit destination address, a 16-bit
source port, and a 16-bit desctination port. In the case of text encoding,
the pseudo header is encoded as 26 hex digits.

In the case of ASN.1 encodings, the pseudo header is encoded using the
packed encoding rules (PER) [X.691]. The pseudo header has abstract syntax
as follows:

PseudoHeader ::= SEQUENCE
{
   src-ip   OCTET STRING (SIZE(4)),
   dst-ip   OCTET STRING (SIZE(4)),
   src-port INTEGER (0 .. 65535),
   dst-port INTEGER (0 .. 65535),
   protocol INTEGER (0 .. 255)
}
-----8<-------------8<-------------8<-------------8<-------------8<-----

        Best regards,
                                        Pekka Pessi

---

From: Michael Thomas <[email-masked]>
Date: Mon, 17 Jan 2000 13:05:31 -0800

A *much* better option is to not require AH at
all, but instead use ESP. ESP has the ability to
have an authentication header in it, and with NULL
encryption you get the same functionality. ESP
does not try to authenticate the IP header either,
which in this particular case neatly avoids the
problem of not knowing which interface will be
picked, etc, etc.

AH should be deprecated, IMO, and I just read this
morning that Bruce Schneier is in favor of nuking
it too.

             Mike