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
yshastry@iol.unh.edu.
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.
