parties ID handling under ISAKMP-OAKLEY

["Alexei V. Vopilov" <alx@xxxxxxxxxxxx>]

One of observations on the latest IPsec drafts
is the handling of the parties ID information
during a SA phase two negotiation.
I trust that a serious discussion had preceded the
discussion to put the scope of negotiating SA in
the ID payload, I mean TCP/UDP protocol, and ports.
However, it is not clear in documents how to negotiated
a SA, say from an initiator TCP port X to responder TCP
port Y.
Probably, I missed some point, but ...

1. A DOI reserves 'proto' an 'port' for the ID payload,
but does not say exactly whether these values belong
to initiator (data sender) or responder side.
I guess it should describe the destination point of SA even
been included in the initiator ID payload.

2. The only way to include _both_ IDs in the proposal
as per ISAKMP-OAKLEY is to use Quick Mode with full context.
If an initiator did not include _both_ IDs in the
proposal, the responder cannot predict the missing part and thus
respond with own ID, which include other than 0 port information.
Do you feel the serious security problem due to that?
I do, especially for multi-user IPsec environment running number of
client applications.

3. Since there can be only one pair of IDs in the proposal, multiple
SAs cannot be negotiated at the same time or they will be just
identical by scope, i.e. will protect the same connection streams.

4. Q: Can I negotiate two ICMP SAs of
different ICMP types which will have different SPIs?
If it can be done using the Id payload 'port' field for the ICMP
'type' one, that should be stated in the DOI draft.

5. Q: There cannot be a 'ports range' negotiated according to
   the current DOI-06, right?

6. Q: If an initiator needs to negotiate a SA been stuck to
      specific IP address+key_ID values, how it can be done with
      current ISAKMP-OAKLEY, DOI drafts.
      Another word, is it possible for a party to provide
      more than one ID payload for itself?

If I'm completely wrong, just give me the right hint.
thanx.
---
Alexei V. Vopilov (alx@elnet.msk.ru),  +7(095)5367694
Software Architecture&Development Consultant.
---
-----Original Message-----
From: Theodore Y. Ts'o <tytso@MIT.EDU>
To: ipsec@tis.com <ipsec@tis.com>
Date: 5 декабря 1997 г. 8:54
Subject: IPSEC document reading party!


:
:Hi,
:
: Bob and I are very concerned that few people are actually
:reading all of the IPSEC drafts, and so there may be internal
:inconsistency and other problems across the various drafts, that perhaps
:won't be discovered until after they are published as RFC's.  That, as
:they say, would be Bad.
:
: In order to try to avoid this, we are planning an IPSEC document
:reading party, to be held Monday evening at the IETF meeting.  The
:logistical details are still be being finalized, but it will probably
:start at either 6:00 or 7:30.  (If it starts at 6:00, food will be
:provided.)
:
: We are looking for a people who are willing to put in a couple
:of hours of real work, by reading over the documents, with a particular
:attention towards finding consistency problems and other problems with
:the drafts.  Please come only if you are prepared to work!  Also, please
:bring your own copies of the documents to read.
:
: In the interests of getting work done, we're not looking for
:quality, not quantity, in terms of the number of people we have
:participating.  Document editors are especially asked to come so that
:they will be available for questions should they arise from the readers.
:
: If you are interested in particpating, please RSVP to Bob and I.
:Information about the location, etc. will be announced later (probably
:at the IETF meeting itself; check the announcements board.)
:
: If you have any questions, please let either Bob or I know.
:
: - Ted
:
:
:
: