Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)
draft-ietf-sigtran-m2pa-13

[Ballot discuss]
Please remove the following paragraph:

When M2PA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network
includes an appropriate security policy framework. The "Site Security
Handbook" [RFC2196] SHOULD be consulted for guidance.

[Ballot discuss]
There are a number of places (4.1.2 stands out) where there are SHOULDs that seem like they should be MUSTs.  There is no guidance on when one might not want to follow the advice.  For example, the draft says:

  It is necessary for at least one of the endpoints to be listening on
  the port on which the other endpoint is trying to establish the
  association. Therefore, at least one of the port numbers SHOULD be the
  M2PA registered port.

But that's the normal procedure for any client-server protocol.  Why is that specified explicitly here?  I agree that implementations can do things differently if they wish -- is there something more that I'm missing here?

4.1.2 says "it is RECOMMENDED that each endpoint know the IP address (or IP addresses, if multi-homing is used) and port number of both endpoints."  This needs to be clarified somewhat, in light of the text in [Security] -- each party MUST know the cryptographic identity of its authorized peers. This may or may not be an IP address.

The assertion about professionally managed networks is, in fact, quite an assumption, and one that probably doesn't belong in this document.  What could be said, instead, is a list of conditions that, if true, could justify not turning on m2pa security.

[Ballot discuss]
For that matter, I'm wondering if there's enough detail on SCTP.  How many streams should be created?  (I see an implicit requirement for at least two.  Is that enough?  Are more supported?)  Can unordered delivery be used?  There are several statements about SCTP providing reliable delivery, so I'd guess not -- but it never says so.  How are SCTP exceptional conditions dealt with, such as an unexpected shutdown or an ABORT or any of the odder things listed in Section 10.2 of RFC 2960?  Section 4.1.2 of this document shows multiple SCTP connections between multiple pairs of IP addresses; can SCTP's multihoming be used as well?  Again, I think that the information is there, but hard to find. I suggest that a section on SCTP interfacing be added.  (There's currently a subsection, but it only discusses slow start issues.)

There are a number of places (4.1.2 stands out) where there are SHOULDs that seem like they should be MUSTs.  But no alternatives are given, or is there any guidance on when one might not want to follow the advice.  For example, 4.1.2 says "it is RECOMMENDED that each endpoint know the IP address (or IP addresses, if multi-homing is used) and port number of both endpoints."  It's rather hard to see how the two ends can communicate if they don't know each other's IP address.  (Knowing the remote end's IP address -- or certificate, or *some* sort of IPsec identity -- is also a security issue.)  Is this intended to suggest that the DNS not be used?  I'm puzzled.  The assertion about professionally managed networks is, in fact, quite an assumption, and one that probably doesn't belong in this document.  What could be said, instead, is a list of conditions that, if true, could justify not turning on m2pa security.

[Ballot comment]
Except for this sentence:

        The description of how to use IPsec is inadequate.

my DISCUSS issues have not been addressed at all.  My DISCUSS stands.

[Ballot comment]
Reviewed by John Loughney, Gen-ART (both at -11 and -12).

His comment (excerpted):
I worked with the author to resolve the DISCUSSes on this.
I don't see any reason to hold this draft up any longer.

[Ballot comment]
Reviewed by John Loughney, Gen-ART

His comment (excerpted):
I worked with the author to resolve the DISCUSSes on this.
I don't see any reason to hold this draft up any longer.

[Ballot comment]
Missing IPR statements:
$ idnits <drafts/draft-ietf-sigtran-m2pa-11.txt
idnits 1.26, (21 Apr 2004)

The document seems to use RFC 2026 boilerplate...
The document seems to lack an 2026 Section 10.4(C) Copyright Notice
The document seems to lack an RFC 2026 Section 10.4(C) Permission Grants Notice
The document seems to lack an RFC 2026 Section 10.4(C) Disclaimer

[Ballot comment]
Reviewed by John Loughney, Gen-ART

Some points from his review:

2) Security section seems a bit off.  I don't know about
  the M2PA usage scenarios - if it is interoperator or
  intraoperator.  If it is solely within an operator,
  perhaps "Site Security Handbook" is enough.  However,
  in general, I guess some text talking more about threats
  & how the protocol is used would be more helpful.  My
  guess is that this kind of signaling is high-value,
  so that if it gets knocked-out, there will be problems.

3) The folloing  section could probably be removed, I am unsure how it relates
  to this protocol.

  6.2 Protecting Confidentiality

  Particularly for wireless users, the requirement for confidentiality
  MAY include the masking of IP addresses and ports. In this case
  application-level encryption is not sufficient. IPSec ESP SHOULD be
  used instead [RFC2401].  Regardless of which level performs the
  encryption, the IPSec ISAKMP service SHOULD be used for key
  management.

4) The (and TCP) should probably be removed, as there is no mention
  of TCP usage elsewhere. Or better, it could say "TCP port 3565 is
  reserved for this protocol in case a definition for TCP is created later".

  7.1 SCTP Payload Protocol Identifier

  The SCTP (and TCP) Registered User Port Number Assignment for M2PA
  is 3565.

6) "SS7 MTP2" should be spelled out in the document title.

[Ballot discuss]
The description of how to use IPsec is inadequate.

For that matter, I'm wondering if there's enough detail on SCTP.  How many streams should be created?  (I see an implicit requirement for at least two.  Is that enough?  Are more supported?)  Can unordered delivery be used?  There are several statements about SCTP providing reliable delivery, so I'd guess not -- but it never says so.  How are SCTP exceptional conditions dealt with, such as an unexpected shutdown or an ABORT or any of the odder things listed in Section 10.2 of RFC 2960?  Section 4.1.2 of this document shows multiple SCTP connections between multiple pairs of IP addresses; can SCTP's multihoming be used as well?  Again, I think that the information is there, but hard to find. I suggest that a section on SCTP interfacing be added.  (There's currently a subsection, but it only discusses slow start issues.)

There are a number of places (4.1.2 stands out) where there are SHOULDs that seem like they should be MUSTs.  But no alternatives are given, or is there any guidance on when one might not want to follow the advice.  For example, 4.1.2 says "it is RECOMMENDED that each endpoint know the IP address (or IP addresses, if multi-homing is used) and port number of both endpoints."  It's rather hard to see how the two ends can communicate if they don't know each other's IP address.  (Knowing the remote end's IP address -- or certificate, or *some* sort of IPsec identity -- is also a security issue.)  Is this intended to suggest that the DNS not be used?  I'm puzzled.  Similarly, the statement in 6.2 that "the IPSec ISAKMP service SHOULD be used" is quite vague.  (The assertion about professionally managed networks is, in fact, quite an assumption, and one that probably doesn't belong in this document.  What could be said, instead, is a list of conditions that, if true, could justify not turning on m2pa security.)

[Ballot discuss]
The description of how to use IPsec is inadequate.

For that matter, I'm wondering if there's enough detail on SCTP.  How many streams should be created?  (I see an implicit requirement for at least two.  Is that enough?  Are more supported?)  Can unordered delivery be used?  There are several statements about SCTP providing reliable delivery, so I'd guess not -- but it never says so.  How are SCTP exceptional conditions dealt with, such as an unexpected shutdown or an ABORT or any of the odder things listed in Section 10.2 of RFC 2960?  Section 4.1.2 of this document shows multiple SCTP connections between multiple pairs of IP addresses; can SCTP's multihoming be used as well?  Again, I think that the information is there, but hard to find.
I suggest that a section on SCTP interfacing be added.  (There's currently a subsection, but it only discusses slow start issues.)

There are a number of places (4.1.2 stands out) where there are SHOULDs that seem like they should be MUSTs.  But no alternatives are given, or is there any guidance on when one might not want to follow the advice.  For example, 4.1.2 says "it is RECOMMENDED that each endpoint know the IP address (or IP addresses, if multi-homing is used) and port number of both endpoints."  It's rather hard to see how the two ends can communicate if they don't know each other's IP address.  (Knowing the remote end's IP address -- or certificate, or *some* sort of IPsec identity -- is also a security issue.)  Is this intended to suggest that the DNS not be used?  I'm puzzled.  Similarly, the statement in 6.2 that "the IPSec ISAKMP service SHOULD be used" is quite vague.  (The assertion about professionally managed networks is, in fact, quite an assumption, and one that probably doesn't belong in this document.  What could be said, instead, is a list of conditions that, if true, could justify not turning on m2pa security.)