Subject: IPS-ALL: Draft IPS Meeting minutes from IETF-52

From: "Elizabeth G. Rodriguez" <[email-masked]>
Date: Fri, 21 Dec 2001 12:49:43 -0600

All, 

Following are the DRAFT IPS meeting minutes from IETF-52 

Please send clarifications/additions/corrections, etc to the list, David
and I, no later than Jan 3.

Thanks,

Elizabeth & David

IETF IPS Meeting Minutes

December 10, 2001

Reference section in all documents must be split into two sections -
normative and non-normative.

Interim meeting in Feb. Announcement on IPS mailing list & IETF
announce. Need RSVPs.

Information at www.ietf.org/IESG/IPS-Interim.txt

-- FC Encapsulation draft (Ralph Weber)

Basically done.

SOFc4 will be going in, other minor (editorial) fixes.  

Rev 5 will be candidate for last call.

Last call will be in conjunction with FCIP and/or iFCP

-- Security draft (Bernard Aboba)

Security documetn will go standards track, but all protocol docs will be
self contained.

Protocol documents will govern, in case of any discrepancies.

Note to this effect will be added to security draft.

Cannot require sequence space extension is in ESPv3, since will not be
available for some time.

NAT traversal language will be non-normative due to IPR issues

            and problems encountered in testing IPsec NAT traversal.

Dependencies

            - Protocol specs, need SLPv2 security update (2608bis), but
may be

                        able to finesse needing a normative reference

            - IPsec transforms are in progress.

                        See IPsec WG for more, for the AES drafts, MAC
is in good shape,

                        CTR requires some attention in ipsec WG

            - SRP (RFC 2945)

            - DHCP-ipsec drafts.

Transforms

Currently specified 

            Must: 3DES-CBC; HMAC-SHA1

            Should NOT: DES

            Should: AES-CTR and CBC-MAC w/ XCBC

Q: (William Dixon) - Why not AES-128CBC instead of AES-CTR?  Much
further along; 

interoperable implementations are available.  Will be discussed in ipsec
wg.  

            Resolving issues off of the mailing list.

            Demoting 3DES will cause interoperability problems.

Transport vs. Tunnel mode

            Specified: iFCP, FCIP Tunnel mode MUST; transport MAY

            iSCSI, under discussion. 

            Summary of pros/cons

            Transport mode:

                        Pros: End to end security, Lower overhead,
Larger MTU, 

                              Negotiation of connection specific
selectors is common practice

                        Cons: Requires ipsec to be implemented on the
IPS entities

                              Greater difficulties with NAT traversal

            Tunnel mode:

            Pros: More compatible with existing VPN gateways, 

                  Don't have to implement ipsec on IPS entity

                  Easier to traverse NATs

            Cons: More overhead, Smaller MTU

            Tunnel problems - connection-specific selectors and
dynamically assigned

                        addresses (problem is use of mode config which
is non-standard -

                        standards track documents exist, but not clear
whether they will

                        be widely implemented).

            Tunnel mode + connection-specific selectors are very
difficult to do.

            Many gateways do not do connection-specific selectors well.

            Need to look at these issues in more detail.  Implementors
please look

                        into the security gateways you're planning to
use.

IKE identifiers

            Both Main and Aggressive are MUST, Aggressive mode is there
to deal with

                        dynamic addresses.

            Open issues in use of specific ID types.

Policy Distribution

            - Constraining IKE is a good first step.

            - Security policy gets tricky when

                        - Not all nodes in an iSCSI network support
security

                        - IKE times out when trying to reach a non-IPsec
entity

                                    (e.g., 60 sec).  Initiator needs to
know whether to

                                    try IPsec or not to avoid this.

            Responder-controlled security [TCP SYN in clear, target sets
up

                        an SA if it supports IPsec] is an alternative.
Currently

                        a MUST NOT to avoid denial of service issues
because TCP

                        SYN causes IKE work (much worse than TCP SYN
flood case).

                        This limits need for security policy to target.

            Doesn't work well for target initiating IKE to initiator
behind

                        a firewall or NAT.

            May use iSNS security policy distribution.

            Existing IPsec policy distribution mechanisms have been
problematic.

                        iSNS could be better.

Certificates

            SHOULD: use IKE certificates

            SHOULD: check certificate revocation list

            MAY: use certificates to determine authorization

            Easiest enrollment solution is to have HBAs get/use host
certs.

            Long cert chains cause IP fragmentation in IKE, which can
cause problems.

            Allow any IKE certificate - use these for identity only,
avoid adding

                        new OIDs to do iSCSI authorization.

            General, but inconclusive transport vs. tunnel mode
discussion.

            Pros and Cons for making each the MUST implement brought up.

            Neither mode will be prohibited.  Can make both MUST, but
decision has not been made.

            John Hufferd asks about transport vs. tunnel mode resolution

            Needs to go to mailing list

            David Black will write something up.

-- iFCP (Charles Monia)

- iFCP N_Port address definition

            Currently IP address of gateway + N port ID behind it. Issue
with NAPTs.

            As of -08, adding TCP port to IP address (gateway address is
the pair).  

            No iSNS change required.

- FC Broadcast

            FC Broadcast is best-effort, IPFC and FC-VI use this to do
discovery.

            Not performance-critical.  Currently uses UDP/IP, may not be
as reliable

            as FC broadcast over fabric, and relying on IP fragmentation
may be a big

            problem.  Changing to a server-based TCP implementation of
broadcast -

            send broadcast frame to broadcast server who then sends it
to all gateways.

            Use 0xFF-FF-FF well known address as port ID for all of the
iFCP entities

            involved in this.  Discovery based on iSNS - need iSNS
changes for this.

            Need to look at issue of two broadcast servers in the same
domain.

- Stale Frame detection

            Currently optional.  Will change to MUST implement and MUST
use.

-- iFCP MIB (Charles Monia)

Minor changes, cleanup from review by Keith.  Fairly stable, close to
done.

-- iSNS (Josh Tseng)

- Change to support iFCP transparent mode.

- Security Issues.  Use IPsec to protect iSNS messages.

            MUST implement IPsec w/ESP in tunnel mode for iFCP and
appropriate mode for

                        iSCSI.

            Use unicast for query and response message

            Use multicast for iSNS heartbeat used to discover iSNS
server

            iFCP gateways and iSCSI devices using iSNS SHOULD
authenticate to the iSNS server.

- Use of iSNS to distribute security policy

            This is about centralization of security administration.

            Security bitmap to hold things not already negotiated by
ISAKMP.

            Parameters to be stored and distributed by iSNS -
Use/non-use of:

                        IPsec, IKE, Main Mode, Aggressive Mode, Perfect
forward secrecy, 

                        preshared key, tunnel & transport mode.

            Need to review this for what's necessary - work with
security draft

            authors (e.g., Bernard Aboba).

- DHCP option - make absolutely sure that a new one is needed before
asking for

            one.  DHCP name server option may not be appropriate (RFC
2937).

-- iSNS MIB 

No serious content changes - minor cleanups (similar to iFCP MIB),
stable, close

            to done.

-- FCIP (Ralph Weber)

At -07 draft.  Major open issue is WWN short frame security.  A few
other

minor changes will be made (e.g., add SOF and EOF for class 4 FC
service).

WWN Short Frame Security

- Prior to Irvine, FCIP endpoint was IP address.  NAT/NAPT support makes
this

            problematic.  Sending WWN across as identity.

Discussion of how to go about solving this problem - authors would like
to

            do this as part of FC-BB-2 rather than FCIP.  IETF IPS
oversight/check

            of this will be necessary.  FC-BB-2 - specific solution
seems to

            be preferred to a generic FC solution.  Expect to see
proposal on list

            soon, discussion at FC-BB-2 in Feb. and IPS interim that
week.

-- FCIP SLP

No known issues aside from coordination with security draft updates.
Will

revise to match those and be ready for WG Last Call.  FCIP-SLP draft
tracks

security draft which tracks 2608bis.

-- SCSI, FC Mgmt, and FCIP MIBs (Keith McCloghrie)

FC Mgmt MIB has been transferred to IPS from IPFC.  Keith is
rearchitecting

            (e.g., consistency with IF and Entity MIBs, remove non-FC
objects),

            expect first ietf-ips-fcmgmt-mib draft soon.

SCSI MIB - design team nearing completion of UML model.  Internet-Draft
will

            be forthcoming shortly.  T10 working session on SCSI MIB on
Monday, 

            Jan 14 in Houston. Details available at
www.t10.org/meeting.htm.

FCIP MIB - There are a bunch of work items - NAT, BB-2 changes,
dependent on

            rework of FC Mgmt MIB.

            Yaron: SCSI and iSCSI MIBs use "instance" abstraction so
that one

                        MIB can represent multiple entities, FCIP should
do likewise.

            Security - SNMPv3 has security.  Get security boilerplate
from IETF

            OPS MIB site, and expand on it to add specific information
about

            risks involved in specific writable elements.  DO NOT say
"MUST

            use SNMPv3".

            Next draft will be coming in January.

End discussion of transport/tunnel mode and related issues.

            Dynamic address support for tunnel mode is an
interoperability issue that

            weighs against use of tunnel mode.

---------- Tuesday Dec 11---------

-- Agenda rebashing

Framing requirements agenda item pulled due to Transport AD/tsvwg issue.
Resolution

will be posted to the list, soon, we hope.

-- SRP IPR requirements (David Black)

            Note Well statement displayed.

            Key points -

                        If know about IP, need to disclose. Further, if
you should know about IP, 

                        need to disclose (e.g. Company cannot keep you
in the dark in order to 

                        avoid disclosure). But, no patent search is
required (e.g. if no way you 

                        should know, don't need to go out of your way to
find out if there are claims).

            Should company own IP directly material to standard, IETF
will ask Company to publish statement, 

            and request fair, reasonable and non-discriminatory terms
for licensing of IP.  

            Company is not obligated to comply.

            IETF does not judge fairness

            Claims (rumors) against SRP

            1)         Stanford.  Royalty free license available.

            2)         Lucent.  May have IP that may be essential.  

                        If essential, will be licensed under standard
Lucent IP licensing practices.

            3)         Speke patent.  No statement. May be owned by
Phoenix Technologies.

            MUST/SHOULD/MAY requirements discussion for SRP at February
interim meeting.

Closing warning from AD and WG chair about results of Dell and Rambus
situations

            in which hiding patents resulted in patents being
unenforceable (FTC consent

            decree for Dell, actual court decisions in Rambus).

-- UNH Plugfest report (Yamini Shastry)

Held Oct 28 - Nov 3

Based on -08 draft

15 participated.  4 initiators, 1 initiator, 9 both initiator & target.
1 neither initiator/target.

Reserved bits test did not match with "MUST be zero on transmit/MUST be
ignored

            on receive"

Summary of changes made to draft as a result of plugfest - most are
minor, see

            slides.

OOO issue is number 5 on this list - will come up in main iSCSI section.

Areas not tested include

            - digests

            - multiple connections/session

            - discovery sessions

            - unsolicited and/or immediate data

            - command windows greater than 1

            - Security

            - No implementations of markers

            - No real error recovery

            - No serious parameter negotiation beyond defaults

Next plugfest [Feb 11-15] will look at these areas.  Based on -09 draft.

Information from www.iol.unh.edu or from Yamini at [email-masked].

New scripts will be available 2 weeks prior to plugfest.

Request for minimum conformance of participate products made.

Markers - determining whether they're in/out has to wait for resolution
of

            status of tsvwg ULP Framing draft.  

-- iSCSI (Julian Satran)

Open issues

            - Security (tunnel vs. transport, and transforms)

            - Framing (tsvwg status)?

                        - Constant overhead word stuffing (version of
Constant Overhead Byte

                                    Stuffing) as a possible alternative

            - Abort Task Set/Clear Task Set

            - OOO PDU handling

            - Serious issue: are NOPs allowed in a discovery session.

* Abort and Clear Task set

            - Remove ordering discussion for Clear Task Set

            - Abort Task Set currently requires a SCSI response for
every

                        aborted command.  Alternate - hold Abort Task
Set response

                        until all outstanding responses are ACKed by the
initiator.

                        Avoids any need to create "fake" SCSI responses,
significantly

                        reduces burden on Initiator.  This is slower,
but much simpler.

                        Most of section 9.4 will vanish.

Sense of the room - follow this approach, modulo working out details

            on the list.

* Out of Order Operation

            - This is a within-connection issue.  No ordering
requirements across

                        connections.

            - Within-connection issue turned up on list in context of
allowing a

                        DMA engine to reorder commands at its
convenience.  Could use

                        multiple connections to do this.

Eddy Q: DMA flow-through to wire is a plausible adapter design that
increases

            the desireability of doing ordering.

Mallikarjun: Unsolicited non-immediate data provides additional ordering

            flexibility.

Sense of the room - this is the right approach.

* NOP in Discovery Sessions

Underlying problem is whether to keep discovery session around for

            detection/notification of configuration changes.

Mark Bakke: Want to know when new targets become available.  Multiple
ways

            to do this.  Discovery session is an in-band way of doing
this, allows

            an async message to be sent to do this (won't need to poll).
Wants

            both NOPs and async messages on on discovery session to keep
it alive

            long-term.

Resolution - N&D team to generate text describing applicability and use
of

            the various mechanisms, along with requirements on
implementations to

            yield interoperability.  Will ship to list and use that to
drive closure

            on need for long-lived discovery sessions which in turn will
drive

            closure of NOP issues.

* Framing

            Word-stuffing version of COBS is an alternative to markers.
Has to touch

                        every byte of message.  CRC and ESP also have
to, so this might be

                        a good alternative when those techniques are in
use.

            COBS/COWS is the same class of mechanism as markers, similar
considerations.

                        Comment that something is needed that doesn't
require TCP modifications

                        - that would be either markers or COBS/COWS.
Hardware targets talking

                                    to software initiators is the
scenario of interest.

                        Comment that TCP modification for framing is
acceptable, hence no

                        need for COBS/COWS or markers.

            Discussion is not conclusive - Need to get tsvwg ULP issue
resolved, write

                        COBS/COWS up in detail (sense of room is no
serious objection to doing

                        so), and take this up on list, resolve at Feb.
interim.

The -10 version will appear sufficiently prior to interim meeting.  

-- iSCSI Boot draft

iSCSI usage of DHCP option is fine.  Will go into next draft.

(DHC WG consulted, no need for DHC draft).

-- iSCSI Naming and Discovery

            Will be informational.

            IQN format will use date codes

            New ISID format

            New username and Initiator name usage guidelines

            Stringprep approach to character normalization

ISID format change - ISID will contain vendor ID.  Will now be 48 bits,
use

            IEEE OUI or IANA OUI.  02 should be "Local Usage" rather
than "Random".

            Note that this can be coped with at install time.

3 forms now acceptable

1) IEEE OUI

2) IANA Enterprise Number

3) Vendor unique -- locally unique; not globally unique.

Recommendation: Double size to 128, so that you can have a WW unique
value

Response:  Not needed -- ISID is relative to iSCSI node name, which is
WW unique.

Three people support embedding the MAC into the ISID.  Will take this to
the

            list.  

John Hufferd: Embedding the MAC in this ISID binds the session to a
single HBA.

Conservative Reuse description.  Reuse ISIDs across all targets.  Needed
to

            deal with T10 changes in progress to persistent
reservations.

-- Stringprep (Mark Bakke)

IDN is close to done on the stringprep/nameprep drafts.  This draft is
about how

            to use this for iSCSI names.

Q: What about unassigned codepoints.

A: Whatever underlying stringprep draft does.

Sense of room: adopted as WG draft.

-- SLP for iSCSI

Document is stable, unicast SLP usage is ok.

Will coordinate security w/IPS Security draft.

Will work with SLP authors on suitable notification support.

-- iSCSI MIB status (Mark Bakke)

Fitting into family of MIBs below SCSI MIB that is being developed -

            FCP MIB may be developed, no plans for parallel SCSI MIB.
Details

            of how these fit together being worked out in SCSI MIB team.

Will be looking at how to add usernames/cert identities to access
control

            area of iSCSI MIB w/o large complexity.

-- iSNS for iSSI status  (Josh Tseng)

See iSNS session on Monday.  New informational material on how iSNS can

            be used to map iSCSI and FC devices in a hybrid
installation.

Final comments

- Request to look at applying ISID-like structure to portal group tags

            for consistency and autoconfiguration reasons.

---

From: Ralph Weber <[email-masked]>
Date: Wed, 26 Dec 2001 08:09:42 -0600

Regarding the following sentence in the FCIP report.

>   ... FC-BB-2 - specific solution seems to be preferred to 
>   a generic FC solution. ...

I think it would be more correct to say:

  Since FC does not have the concept of multiple switch-to-
  switch links between the same pair of switches over a single
  cable, an FC-BB-2 solution is more appropriate than a generic
  FC solution.

Thanks.

Ralph...