Subject: FW: Message Header w/Version

From: Fernando Cuervo <[email-masked]>
Date: Fri, 13 Aug 1999 08:29:28 -0500

> ----------
> From:         Cuervo, Fernando [CAR:5N10-I:EXCH]
> Sent:         August 13, 1999 9:23 AM
> To:   'Brian Rosen'
> Subject:      RE: Message Header w/Version
>
> I disagree with Brian's position. I believe the smaller amount of
> contextual info you have to manage in general, and deal with in a message
> by message basis the better. Additionally, I believe  any structure in the
> header that is being proven useful should be adopted. Why do we want to
> introduce yet a new and more complicate style of doing simple things?
>
> Fernando
> ----------
> From:         Brian Rosen[SMTP:[email-masked]]
> Sent:         August 12, 1999 7:29 PM
> To:   [email-masked]
> Subject:      Re: Message Header w/Version
>
> I disagree
>
> It's not much different to look up the version having parsed the mId
> then it is to parse the version.  It's almost certainly faster to
> look it up (you need do a lookup for lots of other contextual state
> information), than to parse it, but the difference is pretty small.
>
> It does make messages longer unnecessarily.
>
> The
>
> > -----Original Message-----
> > From: Nancy-M Greene [mailto:[email-masked]]
> > Sent: Thursday, August 12, 1999 1:34 PM
> > To: [email-masked]
> > Subject: Re: Message Header w/Version
> >
> >
> > The issue is to allow a parser to find out quickly which
> > version tree it
> > should go down to parse the rest of the message. If the
> > protocol version is
> > on every message, then it can decide immediately. If the
> > parser has to parse
> > and understand who the sender of the message is, and then
> > find out which
> > version of the protocol that sender has said in ServiceChange
> > that it will
> > be using, the parser wastes time.
> >
> > This seems to be a good argument for putting the protocol
> > version back on
> > each Megaco message. Note that all commands in a message
> > would be assumed to
> > be of the same version of the protocol.
> >
> > Nancy
> > --------------------------------------------------------------
> > ------------
> > Nancy M. Greene
> > Internet & Service Provider Networks, Nortel Networks
> > T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
> >
> > > ----------
> > > From:         Christopher Ross[SMTP:[email-masked]]
> > > Sent:         Wednesday, August 04, 1999 4:51 PM
> > > To:   [email-masked]
> > > Subject:      Re: Message Header w/Version
> > >
> > > I definitely agree.
> > >
> > > In the first version of MEGACO the space is pretty much
> > wasted, I agree.
> > > In
> > > future versions tho, there would be no way to understand
> > the message if
> > > the new
> > > version was substantially different from the first.  HTTP
> > and SIP (to
> > > mention a
> > > few) place version at the front to allow for future
> > expansion.  I think
> > > that it
> > > would be wise to add it now... while we still can.
> > >
> > > This is a snippet of a real HTTP interaction... just to
> > show how HTTP does
> > > it.
> > > (My typing is in bold, for those with HTML browsers)
> > >
> > > A valid transaction
> > >
> > >      [cross@lotus]> telnet www.yahoo.com 80
> > >      Trying 204.71.200.68...
> > >      Connected to www.yahoo.com.
> > >      Escape character is '^]'.
> > >      GET /index.html HTTP/1.0
> > >
> > >      HTTP/1.0 200 OK
> > >      Content-Length: 9989
> > >      Content-Type: text/html
> > >
> > >      <html><head><title>Yahoo!</title>
> > >
> > > An error transaction...
> > >
> > >      [cross@lotus]> telnet www.yahoo.com 80
> > >      Trying 204.71.200.68...
> > >      Connected to www.yahoo.com.
> > >      Escape character is '^]'.
> > >      GET x.html HTTP/1.0
> > >
> > >      HTTP/1.0 404 Not Found
> > >      Content-Type: text/html
> > >
> > >      <head><title>Yahoo - Document Not Found</title>
> > >
> > > I think that we should follow this method as closely as
> > possible...  (even
> > > for
> > > the status and error messages)  it is clean and extensible.
> > >
> > > -Chris Ross
> > >
> > >
> > > Abdallah Rayhan wrote:
> > >
> > > > I know this has been raised before and there has been alot of
> > > > discussion about ServiceChange. However, I feel that I need
> > > > to raise the Version issue again but not to repeat the discussion
> > > > about ServiceChange.
> > > >
> > > > Version is important for backward compatibility between the
> > > > current version of megaco and future ones. When you parse
> > > > you dont want to be half the way in the message before
> > > > realizing that it is a different version than what you thought.
> > > >
> > >
> >
>
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 16 Aug 1999 10:09:19 -0400

Good summary

>  - If the version is announced only in the ServiceChange
> message, does this
> mean that the MG always controls the version to be used and
> that there is no
> way for the MGC to negotiate it?  This has an implication for network
> upgrade procedures which people may want to consider.
The ServiceChange message has a response.  The MG puts it's
version in the request, the MGC puts it's in the response.

> One final point: there has been no discussion of the profile
> ID issue.  The
> word "profile" brings to my mind the idea of restrictions on
> the available
> possibilities, rather than new forms which would be unknown
> to parsers.  As
> such, it would be informatioin the receiver of a message
> would want the
> sender to know, not vice versa.  Thus if we should have it at
> all, it should
> be in the ServiceChange message and possibly its response.
Agreed, probably both request and response as in the version

Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 16 Aug 1999 10:21:18 -0500

What you say in these paragraphs raises an obvious point I considered
putting into my summary but didn't: message parsing MUST be able to proceed
successfully independently of version, up to the point where version is
identified.  This holds regardless of whether version is specified in every
message or just in serviceChange, and is a constraint on how we evolve the
protocol.

You make a good point about the undesirability of optionality for the
version field.

> From: Rayhan, Abdallah [CAR:5N00:EXCH]
> Sent: Monday, August 16, 1999 10:16 AM
> By having Version optional, there is no gain other than
> being optional. Look at this scenario, you have MGC that
> controls 1000 MGs V2 and 1000 MGs V1. Hence each
> time you want to hash the mId part to know which version
> to proceed with and before that you want to check to see
> if Version is there at all. In other words, MGCs and MGs
> have to implement two different ways of doing things while
> if it is a standard, you will always know what to look for
> in one clean and straight forward way.
>
        [[TomT]]
What you say in the following paragraphs raises an obvious point I
considered putting into my summary but didn't: message parsing MUST be able
to proceed successfully independently of version, up to the point where
version is identified.  This holds regardless of whether version is
specified in every message or just in serviceChange, and is a constraint on
how we evolve the protocol.

> In addition to that you create semantic rules for serviceChange,
> and all those what ifs, what if serviceChange does not have
> a Version, what if the new version has different syntax than
> the current one...what if you are not be able to reach to the
> command to know that it is serviceChange,  and you have to
> know the semantics of the transaction before figuring out
> that it is a serviceChange.
>
>
> The other issue of Version is the AH. Since AH is an
> interim solution, the next version of MEGACO might not
> include AH, implement different authentication algorithm,
> use different AH length, or it might change the message
> header format. RFC2402 states that AuthData of AH is
> of variable length. What if we decided to follow that.
>
> Having Version as the first thing tells exactly what
> syntax to look for in the message.
>
> I strongly believe that Version should be present in
> every message and should be the first thing even
> before  authenticatedMessage. You figure out the
> version then decide how to proceed with AH and
> mId, and parsing. Simple and efficient.
>
> SIP uses Version and HTTP had to have RFC2145
> to clarify the ambiguities and interpretability
> issues of Version interpretation.
>
> Most of the IETF protocols have a single token to
> represent Version as part of the header,
> like IPv4,IPv6, RSVP, SIP, HTTP, even the new ones
> like MDTP/SCTP, ...I dont think that is considered a
> waste of bandwidth or  inefficient way of doing things.
>
> regards
> Abdallah Rayhan
>
>
> Brian Rosen wrote:
>
> > The reason why all the tokens have 2/3 character alternates
> > is to address that, which is why that is what you would use
> > when performance is an issue.
> >
> > How about a compromise?
> >
> > Make the version optional on each message.  Make it required in
> > the serviceChange.  Then you can say
> >
> > "MEGACO V1.0/PacketCableV7.2Profile xmgc.abc.com Transaction=....."
> >
> > or
> > "! xmgc.abc.com T=..."
> > Your choice.
> >
> > Brian

---

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

What about profiles?  I believe they are required.

Do vendors get to signal extension capability?

You can't have your cake and eat it too.  I don't think you can get "short
messages" and "easy parsing to determine what to expect" at the same time.

One advantage of the serviceChange method is that it can be
arbitrarily long (and informative).

Brian

> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Wednesday, August 18, 1999 9:56 AM
> I've seen Christian Grove's later message on this point, but
> I think based
> primarily on David Oran's arguments I will make a call on
> this one.  We
> should have a version number in each message.  However, I see
> no particular
> need to have minor version and double digits for both major
> and minor, as
> Abdallah illustrates below, so we can cut the overhead down
> to one digit
> plus the separator character.
>
> > Sent: Tuesday, August 17, 1999 1:04 PM
> > Question: What are the pros and cons of Version ?
> >
> > pros:
> > 1- Ability to change syntax and semantics of new versions of MEGACO
> > with the possibility of maintaining backward compatibility.
> > 2- Less semantic/syntax constraints on how to process  messages.
> > 3- Ability to differentiate between unsupported versions and
> > syntax/semantic
> > errors
> >
> > cons:
> > 1- Few extra bytes( MEGACO/xx.xx)
> >
> > It is obvious that pros of having Version in every message outweighs
> > the cons.
> >
> > regards
> > Abdallah Rayhan
> >
> >
> > David Oran wrote:
> >
> > > A perhaps silly question:
> > >
> > > If the version number is only in the service change
> message, then if the
> > MG
> > > and MGC ever get mis-synchronized (perhaps due to an
> earlier parsing or
> > > protocol error), how does a parser reasonably figure out
> when it gets
> > > confused by a message whether its confusion is due to a
> version mismatch
> > or
> > > something else. It strikes me that there's at least the
> potential for
> > better
> > > debugging and error reporting if every message is entirely
> > self-describing.
> > >
> > > Some (possibly debatable) philosophy:
> > >
> > > Some things about a protocol need to be "held fixed"
> across evolutionary
> > > changes or you lose backward compatibility. Putting the
> version number
> > in
> > > every message effectively "fixes" the format of the
> protocol up to the
> > > version-number field for all time. Conversely, depending
> on the version
> > > number in the service-change message fixes some aspects
> of the protocol
> > > state machine for all time (i.e. must see a service change message
> > before
> > > you can interpret any other message). Which of these two
> things do we
> > feel
> > > more comfortable keeping constant for the life of the
> protocol? I have
> > my
> > > personal preference; maybe you can guess?
> > >
> > > Dave.
>

---

From: Fernando Cuervo <[email-masked]>
Date: Wed, 18 Aug 1999 13:40:34 -0400

If we are going to have a Version field let's make it useful, no sense in
having a Version that is so constrained, major/minor and profiles are
required.

> Sent:         August 18, 1999 10:32 AM

---

From: Pete Cordell <[email-masked]>
Date: Wed, 18 Aug 1999 21:17:31 +0100

Exercising my limited knowledge of security...

Is there a security issue with having known plain text at the start of each
message?  Or is there a randomisation vector at the start of the message
already?  Even if there isn't, the risk probably isn't that high, or is it?

Pete

=============================================
Pete Cordell
[email-masked]
=============================================

-----Original Message-----
From: Abdallah Rayhan <[email-masked]>
To: [email-masked]
<[email-masked]>
Date: 18 August 1999 20:33
Subject: Re: Message Header w/Version

>We could borrow the Version specs from RFC2145 which
>explains version ordering, compliance requirements, and
>upgrading of version numbers for HTTP.  SIP borrows
>the same specs from HTTP.
>
>RFC2145 explains the differences between minor and major
>releases of the protocol and how that affects Version. Also,
>Version does not have leading zeros. So 01.10 should be written
>as 1.1, two digits would be the max allowed width per each.
>In addition to that it specifics the order of releases.
>
>regards
>Abdallah
>
>Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B901-I:BNR] wrote:
>
>> I've seen Christian Grove's later message on this point, but I think
based
>> primarily on David Oran's arguments I will make a call on this one.  We
>> should have a version number in each message.  However, I see no
particular
>> need to have minor version and double digits for both major and minor, as
>> Abdallah illustrates below, so we can cut the overhead down to one digit

---

From: Brian Rosen <[email-masked]>
Date: Wed, 18 Aug 1999 17:00:57 -0400

Actually, there is.  I wouldn't worry too much about it.
It occurs any time you know some plaintext, and where it
occurs in the message.  It gives you the basis for the
"try a key and see if it works" attack.  That is why the
"try every possible key until you find it" engine is
a realistic cracker - lots of messages have known (or highly
predictable) plaintext.

If you are concerned, use the ESP header, and specify triple
DES (yes, I know we can't export it from the U.S.).  There
are no known ways to break triple DES, even if you have
a piece of plaintext and its matching ciphertext.

Brian

> From: Pete Cordell [mailto:[email-masked]]
> Sent: Wednesday, August 18, 1999 4:18 PM

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 18 Aug 1999 15:55:31 -0500

My understanding of the requirement was that we are talking about AH, where
the goal is to authenticate the message. Known plain text won't make coming
up with a different payload that transforms to the same AH header any
easier, so this shouldn't be a problem.

Spencer

> From: Pete Cordell [SMTP:[email-masked]]
> Sent: Wednesday, August 18, 1999 3:18 PM

---

From: Brian Rosen <[email-masked]>
Date: Wed, 18 Aug 1999 17:22:50 -0400

Well the discussion started on the interim AH-under-megaco.
That is the AH header which provides authentication and
integrity check, but not encryption.  Pete's issue does
not occur, as Spencer points out, as the text is cleartext,
and the header provides an MD-5 (for example) keyed hash.

The protocol also specifies the (optional) ESP header, which
has no interim version.  ESP is the part of IPSEC that
provides encryption services.

Brian

> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: Wednesday, August 18, 1999 4:56 PM
> > Is there a security issue with having known plain text at
> the start of
> > each
> > already?  Even if there isn't, the risk probably isn't that
> high, or is
> > it?
> >
> > Pete
> >
> > >> need to have minor version and double digits for both
> major and minor,
> > as
> > >> Abdallah illustrates below, so we can cut the overhead
> down to one
> > digit