[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DRAFT Agenda and Package for January 9, 2003 Telechat
- To: iesg@ietf.org
- Subject: DRAFT Agenda and Package for January 9, 2003 Telechat
- From: Jacqueline Hargest <jhargest@ietf.org>
- Date: Fri, 03 Jan 2003 20:54:49 -0800
- Cc: Alex Zinin <alex.zinin@alcatel.com>
- Delivery-date: Sat, 04 Jan 2003 07:51:55 -0800
- Envelope-to: iesg-hack@psg.com
- Resent-date: Sat, 04 Jan 2003 07:50:22 -0800
- Resent-from: randy@psg.com
- Resent-message-id: <E18UqZ4-0003th-00@rip.psg.com>
- Resent-to: iesg-hack@psg.com
* DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the January 9, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
- December 27, 2002
o Review of Action Items
OUTSTANDING TASKS
Last updated: January 3, 2002
o <draft-dfncis-netnews-admin-sys-04.txt> in Expert Review; Ned to
evaluate.
DONE o Thomas Narten to send text to Scott Bradner re: kre's ipv6 appeal.
Scott to incorporate.
IP o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG. If OK, Steve/Secretariat to announce.
IP o Ned to write MIME and MEDIA TYPES Roadmap document
IP o Jeff to compare and contrast identity vs. identifier
IP o Erik to document process of how the IESG goes about asking
architectural questions of the IAB
IP o Thomas to write (or cause to be written) a draft on "how to
get to Draft".
IP o Patrik to take action on elevating RFC2279 to Standard.
IP o Thomas to contact Cablelabs to discuss formal relationship
with IAB
DONE o Thomas to send in suggestions for Extensions Statement.
Scott to incorporate
o Patrik to re-evaluate state of draft-irtf-idrm-handle-system (Informational)
o Patrik to re-evaluate state of draft-jaffer-metric-interchange-format (None)
o Erik to re-evaluate state of draft-jl-pcdp (Informational)
DONE o Steve B. to re-evaluate state of draft-khan-gaur-secure-mpeg-syntax (Request)
IP o Allison to re-evaluate state of draft-malis-sonet-ces-mpls (Request)
o Patrik to re-evaluate state of draft-new-apex-server (Informational)
IP o Ned to re-evaluate state of draft-tegen-smqp (Informational)
IP o Ned to re-evaluate state of draft-tiwari-appl-wxxx-forms (Informational)
DONE o Allison and Thomas to draft note for draft-stoica-diffserv-dps
2. Protocol Actions
o Intrusion Detection Message Exchange Format Data Model and
Extensible Markup Language (XML) Document Type Definition
(Proposed Standard)
<draft-ietf-idwg-idmef-xml-09.txt>
Token: Bellovin, Steve
o A Presence Event Package for the Session Initiation Protocol (SIP)
(Proposed Standard)
<draft-ietf-simple-presence-09.txt>
Token: Faltstrom, Patrik
o An Extensible Markup Language (XML) Based Format for Watcher
Information (Proposed Standard)
<draft-ietf-simple-winfo-format-03.txt>
o A Watcher Information Event Template-Package for the Session
Initiation Protocol (SIP) (Proposed Standard)
<draft-ietf-simple-winfo-package-04.txt>
o iSCSI (Proposed Standard)
<draft-ietf-ips-iscsi-19.txt>
Token: Mankin, Allison
o Bootstrapping Clients using the iSCSI Protocol (Proposed Standard)
<draft-ietf-ips-iscsi-boot-08.txt>
Token: Mankin, Allison
o iSCSI Naming and Discovery (Informational)
<draft-ietf-ips-iscsi-name-disc-08.txt>
Token: Mankin, Allison
o RTP Payload Format for SMPTE 292M Video (Proposed Standard)
<draft-ietf-avt-smpte292-video-08.txt>
Token: Bradner, Scott
3. Individual via RFC Editor
o Basic MGCP Packages (Informational)
<draft-foster-mgcp-basic-packages-09.txt>
Token: Bradner, Scott
4. Working Group Submissions
o Requirements for Resource Priority Mechanisms for the Session
Initiation Protocol (Informational)
<draft-ietf-ieprep-sip-reqs-03.txt>
Token: Mankin, Allison
5. Proposed Working Groups
o License to Enhance Messaging Oriented Network Access for Diverse
Endpoints
Token:Ned
6. Working Group News We Can Use
7. IAB News we can use
8. Management Issues
o Revised IDR (Inter-Domain Routing) Charter
DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
December 27, 2002
Reported by: Jacqueline Hargest, IETF Assistant Director
ATTENDEES
---------
Alvestrand, Harald / Cisco
Austein, Rob / IAB Liaison
Bellovin, Steve / AT&T Labs
Bradner, Scott / Harvard
Bush, Randy / IIJ
Cotton, Michelle / ICANN
Faltstrom, Patrik / Cisco
Fenner, Bill / AT&T
Freed, Ned / Innosoft
Hargest, Jacqueline / IETF
Narten, Thomas / IBM
Schiller, Jeff / MIT
Wijnen, Bert / Lucent
Zinin, Alex / Alcatel
REGRETS
-------
Coya, Steve / IETF
Daigle, Leslie / Verisign (IAB)
Mankin, Allison / ISI
Nordmark, Erik / Sun
Reynolds, Joyce K. / ISI (RFC Editor)
Minutes
-------
1. The minutes of the December 12 Teleconference were approved.
Secretariat to place in public archives.
2. Prior to the December 27 teleconference, the following
document was APPROVED:
o 'STUN - Simple Traversal of UDP Through Network Address Translators'
(Proposed Standard) <draft-ietf-midcom-stun-05.txt>
3. Protocol Action APPROVED:
The IESG approved publication of 'RTP Payload Format for Enhanced
Variable Rate Codecs (EVRC) and Selectable Mode Vocoders SMV'
<draft-ietf-avt-evrc-smv-03.txt> as a Proposed Standard. Secretariat
to send announcement.
4. Working Group Documents APPROVED:
The IESG had no problem with the publication of the following
document 'Impairments And Other Constraints On Optical Layer Routing'
<draft-ietf-ipo-impairments-04.txt> as an Informational RFC.
Secretariat to convey to RFC Editor.
The IESG had no problem with the publication of the following document
'Middlebox Communications (MIDCOM) Protocol Evaluation'
<draft-ietf-midcom-protocol-eval-06.txt> as an Informational RFC.
Secretariat to convey to RFC Editor.
5. Working Group Documents TENTATIVELY APPROVED:
The IESG tentatively approved publication of 'Netlink as an IP Services
Protocol' <draft-ietf-forces-netlink-04.txt> as an Informational RFC.
Once Alex clears Thomas's objections concerning the title and abstract,
Secretariat will announce.
The IESG tentatively approved publication of 'Framework for Policy
Usage Feedback for Common Open Policy Service with Policy Provisioning
(COPS-PR)' <draft-ietf-rap-feedback-frwk-04.txt> as an Informational
RFC. Bert will cover Steve's nit with an RFC Editor Note. If ok,
Secretariat to send announcement.
6. Document Actions APPROVED:
The IESG has approved the Internet-Draft 'H.323 URL Scheme
Registration with IANA' <draft-levin-iptel-h323-url-scheme-05.txt>
as an Informational RFC. Secretariat to send announcement.
The IESG has approved the Internet-Draft 'Basic Socket Interface
Extensions for IPv6' <draft-ietf-ipngwg-rfc2553bis-10.txt> as an
Informational RFC. Secretariat to send announcement.
7. Protocol Actions DEFERRED:
o Intrusion Detection Message Exchange Format Data Model and
Extensible Markup Language (XML) Document Type Definition
(Proposed Standard)
<draft-ietf-idwg-idmef-xml-09.txt>
o 'iSCSI' (Proposed) <draft-ietf-ips-iscsi-19.txt>
o 'Bootstrapping Clients using the iSCSI Protocol' (Proposed)
<draft-ietf-ips-iscsi-boot-08.txt>
o 'iSCSI Naming and Discovery' (Informational)
<draft-ietf-ips-iscsi-name-disc-08.txt>
Note: Randy Bush moved to separate the Boostrapping document
(draft-ietf-ips-iscsi-boot) from the other two. The first two documents
will pass if Steve Bellovin and Allison Mankin resolve Bellovin's
issues. Steve will then notify the Secretariat to update his position
to "no-ob". The third document will be held for Allison and Randy to
clean up.
8. Document Actions TENTATIVELY APPROVED:
o 'CR-LDP Extensions for ASON' (Informational)
<draft-aboulmagd-ccamp-crldp-ason-ext-02.txt>
Note: Michelle and Bert will check assignments issues. If ok,
Secretariat will announce.
9. The following documents are still under DISCUSSION:
o 'Session Initiation Protocol Basic Call Flow Examples' (BCP)
<draft-ietf-sipping-basic-call-flows-01.txt>
o 'DHCP Option for CableLabs Client Configuration' (Proposed)
<draft-ietf-dhc-packetcable-04.txt>
o 'Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol
(L2TP)' (Proposed)
<draft-ietf-l2tpext-v92-moh-03.txt>
Note: Scott will send a message with his desired changes, which Thomas
will take to the author(s).
o 'Known CN Request-Routing Mechanisms' (Informational)
<draft-ietf-cdi-known-request-routing-02.txt>
Note: Randy Bush registered a substantial issue.
o 'An Architecture for Open Pluggable Edge Services (OPES)'
(Informational)
<draft-ietf-opes-architecture-04.txt>
o 'Requirements for OPES Callout Protocols' (Informational)
<draft-ietf-opes-protocol-reqs-03.txt>
Note: Ned will draft a note to the WG re: security concerns for both of
these documents, and run it by the IESG.
o 'Basic MGCP Packages' (Informational)
<draft-foster-mgcp-basic-packages-09.txt>
Note: Allison has some concerns and was not on the call to discuss.
10. Working Group Action:
o License to Enhance Messaging Oriented Network Access for
Diverse Endpoints (LEMONADE)
Token: Ned
Note: Remaining issue concerning the charter. Allison needs to give
input. Bill recommended a wording change because of "unified
messaging"; and the acronym doesn't indicate what they do. Ned to
send new version of charter; Secretariat to post and send
announcement to new-work.
11. NEW Action Items:
o Harald will send final text for kre appeal, to be sent to kre
and ietf-announce, and to be posted on appeals web page
o Bill and Jacqueline to work out a system to ensure proper
assignment of individual submissions
12. Outstanding Action Items:
o <draft-dfncis-netnews-admin-sys-04.txt> in Expert Review; Ned to
evaluate.
DONE o Thomas Narten to send text to Scott Bradner re: kre's ipv6 appeal.
Scott to incorporate.
IP o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG. If OK, Steve/Secretariat to announce.
IP o Ned to write MIME and MEDIA TYPES Roadmap document
IP o Jeff to compare and contrast identity vs. identifier
IP o Erik to document process of how the IESG goes about asking
architectural questions of the IAB
IP o Thomas to write (or cause to be written) a draft on "how to
get to Draft".
IP o Patrik to take action on elevating RFC2279 to Standard.
IP o Thomas to contact Cablelabs to discuss formal relationship
with IAB
DONE o Thomas to send in suggestions for Extensions Statement.
Scott to incorporate
o Patrik to re-evaluate state of draft-irtf-idrm-handle-system (Informational)
o Patrik to re-evaluate state of draft-jaffer-metric-interchange-format (None)
o Erik to re-evaluate state of draft-jl-pcdp (Informational)
DONE o Steve B. to re-evaluate state of draft-khan-gaur-secure-mpeg-syntax (Request)
IP o Allison to re-evaluate state of draft-malis-sonet-ces-mpls (Request)
o Patrik to re-evaluate state of draft-new-apex-server (Informational)
IP o Ned to re-evaluate state of draft-tegen-smqp (Informational)
IP o Ned to re-evaluate state of draft-tiwari-appl-wxxx-forms (Informational)
DONE o Allison and Thomas to draft note for draft-stoica-diffserv-dps
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-idwg-idmef-xml - Intrusion Detection
Message Exchange Format Data Model and Extensible Markup
Language (XML) Document Type Definition to Proposed Standard
--------
Last Call to expire on: July 3, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ X ] [ ] [ ] [ ]
Scott Bradner [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ X ] [ ]
Patrik Faltstrom [ ] [ XX] [ D ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ XX] [ D ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Scott: note:
I would have thought that there should eb an IANA considerations
section that at least points to sec 5 on how extensions
can get made but also, I would have thought that sec 5 would
have included what IETF proocesses (see RFC 2434) should
be used to extend teh protocol
I'm sensitive to this because we are getting a pile of
requests to extend IETF protools (MPLS, RSVP etc) of
late and we did not have any -must be extened within the
ietf only- IANA mesage so we are being asked to OK
some messy extensions - it woudl be good to cut this off at the
pass and include such restrictions in new docs
Patrik:
Yes, I should have discovered this earlier, but this last week has been
too much. I just passed the document to the xml-directorate for review.
I will send in a new ballot as soon as I get a response.
This imply I hope this only have to wait until say monday, and not next
telechat before it can pass.
So, please, do the rest of the ballot!
Randy:
needs to separate into at least two docs, the xml and transport model
and the particular application
xml-dir review comment
1) There is too much description and teaching about XML and UML. The
document should merely reference the XML and UML standards and explain
the restrictions and/or extensions to those specs in the definition of
IDMEF.
2) Section 3.3.4 mentions XML Schema and how they would one day use it.
Well, it has been out for awhile, so why aren't they? If they
switched from DTD's to XML Schema, they could probably get rid of half
of the data type sections (3.4.1 to 3.4.6) and their entire need for UML.
Bert:
I think I had a Defer (after initially thought I would be noObj.
But I need to rais a Discuss.
Section: 4.2.7.4.2 The SNMPService Class
The description of this Class shows only how to deal with SNMPv1/v2c
where authentication is done by (very weak) communitty String.
WWWWWe just made SNMPv1/v2c Historic. Of course they are still in
wide use, but SNMPv3 (which we just publsihed as STD 62) is already
deployed at many places and will get more and more deployment.
I think this document should recognize that and also address SNMPv3
where we no longer have a community String.
I also wonder if in the many examples on Pages 76 and folloing, if
it is OK to use domain names and IP addresses as they do. In other
words, do they violate one of our NITS:
Addresses used in examples should prefer use of fully
qualified domain names to literal IP addresses, and prefer use
of example fqdn's such as foo.example.com to real-world fqdn's
See RFC 2606 for example domain names that can be used
There is also a range of IP addresses set aside for this
purpose. These are 192.0.2.0/24 (see RFC 3330). Private
addressess that would be used in the real world should be
avoided in examples.
Let me add that the IPR section is also missing for this doc
that is targeted for STDs track.
COMMMENTS:
==========
Ned:
>To: Randy Bush <randy@psg.com>
> discuss
> ...
> 2) Section 3.3.4 mentions XML Schema and how they would one day use it.
> Well, it has been out for awhile, so why aren't they? If they
> switched from DTD's to XML Schema, they could probably get rid of half
> of the data type sections (3.4.1 to 3.4.6) and their entire need for UML.
This isssue is discussed in section 4.7 of
draft-hollenbeck-ietf-xml-guidelines-07.txt, recently approved as a BCP.
This section makes it clear that either a DTD or a Schema based approach
is permissible; neither one is inherently better than the other:
The choice of tool depends on the needs for extensibility or for a
formal language and mechanism for constraining permissible values
and validating adherence to the constraints.
I read this as saying that unless a case can be made that these needs
aren't met by the chosen mechanism we should not be insisting they make a
different choice.
Ned
Randy:
i think the point is
both water and air are allowed. one may be better for washing your
car.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, idwg-public@zurich.ibm.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Intrusion Detection Message Exchange Format
Data Model and Extensible Markup Language (XML) Document Type
Definition to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Intrusion Detection Message
Exchange Format Data Model and Extensible Markup Language (XML) Document
Type Definition' <draft-ietf-idwg-idmef-xml-09.txt> as a Proposed
Standard. This document is the product of the Intrusion Detection
Exchange Format Working Group. The IESG contact persons are Jeffrey
Schiller and Steve Bellovin.
Technical Summary
Different elements of intrusion detection systems (IDS) need to
communicate with each other. This document defines a standard
data model, and implements it as an XML DTD.
Working Group Summary
There were no major issues with the document.
Protocol Quality
This document was reviewed for the IESG by Steve Bellovin.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-simple-winfo-package - A Session
Initiation Protocol (SIP)Event Template-Package for Watcher
Information to Proposed Standard
--------
Last Call to expire on: 2002-10-3
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Scott Bradner [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Patrik Faltstrom [ X ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, simple@mailman.dynamicsoft.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: A Session Initiation Protocol (SIP)Event
Template-Package for Watcher Information to Proposed Standard
-------------
The IESG has approved the Internet-Drafts 'A Presence Event Package for
the Session Initiation Protocol (SIP)' <draft-ietf-simple-presence-09.txt>,
'A Session Initiation Protocol (SIP) Event Template-Package for Watcher
Information' <draft-ietf-simple-winfo-package-04.txt> and 'An Extensible
Markup Language (XML) Based Format for Watcher Information'
<draft-ietf-simple-winfo-format-03.txt> as Proposed Standards.
These documents are products of the SIP for Instant Messaging and
Presence Leveraging Extensions Working Group. The IESG contact persons
are Ned Freed and Patrik Faltstrom.
Technical Summary
The main document describes the usage of the Session Initiation
Protocol (SIP) for subscriptions and notifications of presence.
Subscriptions and notifications of presence are supported by defining
an event package within the general SIP event notification framework.
The supporting documents define the watcher information
template-package, and an XML document format for the state of watchers
on a resource.
Working Group Summary
There was consensus for these documents in the working group.
Protocol Quality
The documents were reviewed for the IESG by Patrik Faltstrom and
Allison Mankin.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-ips-iscsi - iSCSI to Proposed Standard
--------
Last Call to expire on: 2002-12-16
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ XX] [ D ]
Scott Bradner [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ X ] [ ]
Patrik Faltstrom [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jeff Schiller [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
Discuss:
========
Randy:
Boot security has traditionally been a problematic area,
so an alternative secure boot mechanism is very welcome.
iSCSI boot has substantial potential, and some of the
products coming on the market have impressive security
features (such as IKE/IPsec support on the HBA), so that
I'd expect a draft on isCSI Boot to demonstrate
particular attention to security issues.
This document falls short in this regard,
though it can be easily fixed with a little work.
Section 3
Some mention of PXE should probably be provided here. This is
important because of the major security vulnerabilites that it
exposed (see the PXE Postscript below)
Section 4
Obtaining the iSCSI boot load from somewhere else presumably means
that the host may also lack other basic facilities, such as support
for security mechanisms. So how do we verify the authenticity of the
initial boot load?
Section 5
Hmm. Why is DHCPv6 being recommended as the way to obtain an IPV6
address? Shouldn't this document just reference the existing
documents on IPv6 address assignment? For this purpose, all that really
matters is that the host use DHCPv6 "lite" for configuring the required
parameters.
If "servername" is a domain name, shouldn't there be some text
describing the vulnerabilities if DNS security is not used?
Section 8
"The software stage can be secured by using public key encryption and
digitial signatures. This is the approach taken by the popular
PXE boot framework."
PXE and security should not be mentioned in the same paragraph --
without at least describing the limitations. For example, are we
requiring that the iSCSI HBA be able to store certificates? If so, this
is not very credible at the moment, since this would require the iSCSI
HBA to implement an enrollment protocol as well as IKE certificate
handling code. I'm not aware of any HBAs that can actually handle this.
Some discussion of the limitations of DHCP Authentication would be
appropriate here. For example, DHCP authentication uses the
client-identifier as the claim of Identity. This means is fine for
cases where the NIC/HBA is on the motherboard, and therefore the
machine can be pre-provisioned by the OEM or IT staff.
However, if the NIC/HBA is removable, then the admins will need to
re-provision it if it fails or is switched out. That's one reason why
DHCP server auth via public key might be more easily deployed.
Some limitations of current boot image verification technology should
be included here. In practice, I can't name an example of where this
has been successfully deployed on a large scale, due to the lack of
revocation support.
Interesting that this section doesn't mention transmission level
security schemes at all, including IPS security. Are we to assume that
securing iSCSI boot using these mechanisms is too difficult? Is so,
then iSCSI boot will not be much more secure than PXE (see Postscript).
I'd expect some discussion of the vulnerabilities and issues.
Also, I'd like to see some reference to discovery security (DNS or
SLPv2), or if this isn't used, some advice on what other security
measures need to be put in place instead.
PXE Postscript
PXE is a DHCP-based boot approach that represents a small extension
to the traditional DHCP/BOOTP/TFTP approach. PXE extends this by
enabling additional commands to be executed (such as a request that
the booting machine reformat its hard disk), as well as enabling
verification of boot file's authenticity. However, PXE did not
satisfactorily address the security problems in DHCP/BOOTP/TFTP. Some
of the issues included:
a. PXE is often enabled by default and potentially high in the boot
order as delivered by some OEMs. That means that customer could have
PXE installed in their networks without asking for it. The iSCSI boot
draft should say something about iSCSI boot not being enabled by
default, or put high in the boot order without an explicit request.
b. PXE did not utilize DHCP authentication. This is true not only
because it wasn't required by PXE, but also because of the difficulty
of configuring machines fresh from the factory with the appropriate
shared secrets (or certs and root trusts, if a cert-based DHCP auth
method were to become available). The iSCSI boot draft could say more
about the practical issues in configuring DHCP securely, such as the
administrative issues and alternatives, such as public-key based
server signing.
c. DHCP options were believed without subsequent verification (TFTP
server options, etc.) Some of this remains in the iSCSI boot draft, so
a word of warning is appropriate. For example, even if DHCP or
alternative discovery mechanism is not secured, I'd expect that iSCSI
security would be used.
d. A rogue PXE server could provide a client with a PXE
option (60) and then reformat the machine's hard disk, without the
client having the ability to verify whether this was a smart thing to
do. We've seen this happen by accident in our test lab when a tester
brought in a copy of ghost and reformatted one of the lab machines when
it rebooted. So some warning words about rogue servers is appropriate --
particularly if IPsec/IKE is not supported in iSCSI boot, and only CHAP
authentication is used (nightmare scenario).
e. PXE security was restricted to boot image verification, but the
hosts could typically only store one root trust cert, and revocation
checking and cert chains are typically not supported. Without
revocation and chain support, if the boot image server cert was ever
compromised, you'd have to touch every machine to reconfigure it. So
some statement about credentialing requirements would be appropriate.
This could just be a pre-shared key for IPsec and a CHAP secret, or
something more elaborate (a cert for IKE + a CHAP secret) might be
required. In the latter case, there are some PC NVRAM storage
requirements that might be articulated. Given the headroom restrictions
of BIOS code, squeezing all this in is quite challenging.
Because of vulnerabilities a-e, PXE security is rarely enabled in
practice, and this makes it possible for a rogue PXE server to reformat
the hard disks of machines booting within an enterprise network. Note
that gaining control of that many machines would ordinarily require a
well written virus, which presumably could be counter-acted by
anti-virus software or appropriate OS or application upgrades.
However, because boot software often runs in the BIOS, it's much
trickier to address security flaws here than in an OS or application --
you've got to flash the BIOS, and this may not be remotely accessible
on many hosts.
The combination of the level of vulnerability and difficulty of
applying BIOS fixes has made boot security potentially one of the most
lethal security vulnerabilities existing today -- serious enough that
I'm told by Bill Arbaugh that PXE security was the topic of a briefing
to the National Security Coucil, headed by Condolezza Rice.
So it would be really great if iSCSI boot can provide a better
solution, and if the security issues were better articulated in this
document.
[ and more -- rb ]
This draft *does* talk about some security mechanisms -- it mentions
DHCP authentication, SLPv2 security, and IPsec. But provisioning all
of these mechanisms together is tricky and the draft doesn't even take
a stab at it. For example, IPsec is cited only for denial of service
prevention -- there is no comparison about the certificate facilities
in IKE (which supports cert request payloads and chaining) versus PXE
(only a single cert, no revocation, no chains).
You get the feeling that security is just an afterthought in this
draft -- which is a shame really, because it could do so much more.
For example, the draft *could* advocate use of IPsec for securing DHCP
(this is supported in DHCPv6), SLPv2 (IPsec security is supported in
the IPS security draft), and iSCSI. That would enable a machine to
boot securely, potentially from a set of consistent credentials (such
as a single cert used for all three purposes). In a situation like
this, minmizing the required provisioning is very important -- since
OEMs don't even support the minimal provisioning required by PXE.
Steve:
*'d items are my "must fix" items to clear the discuss.
draft-ietf-ips-iscsi-19.txt:
3.2.6.2:
Would it hurt to permit '_'? That's been an annoyance
in host names per RFC 810.
3.2.6.3.1:
Why the reversed domain name? These don't seem to be
hierarchical.
5:
Is "key" a SCSI term? It's a bit disconcerting to see
it used in a login/security discussion when it doesn't
mean cryptographic key. (5.3.2 speaks of "security
keys"...)
5.2:
In this string:
Acceptor-> <key>=<valuey>|NotUnderstood|Irrelevant|Reject
it isn't clear that <key>= must always appear.
Does the implementation-specific key issue cause
problems with our extensions policy?
7.1.3, etc.:
The state diagram is a work of art, of its kind (see
the Star Warms "ASCIImation" (http://www.asciimation.co.nz/)
for another example), but it's very difficult to read.
I can't quite tell what states T16 is between, just
from that diagram. State that the tables are
authoritative.
*8.2.1:
CHAP supports the use of different secrets for each
challenger. That should be mandated here. (Without
that, an attacker could use a second, parallel login
session to mount the equivalent of a reflection attack.)
I might settle for some other way to prevent this
attack, but I'd really prefer different secrets.
8.3.1:
They should mandate ESP sequence number extension, but
that's still an I-D. Can we/should we delay this spec
while waiting for it?
(In general, there's too much redundancy here about
IPsec with the iSCSI security document. I don't know
that that's bad, but I haven't checked to ensure that
they're completely consistent. That will make it harder
to revise the security specs for, say, IKEv2.)
9.3:
Are these timeouts too short? Might we see congestion
by too-rapid recovery attempts causing TCP teardown/startup?
(I *wish* these folks had used SCTP. Yes, I know why they
didn't, but...)
*11.1:
"None" is not acceptable as the only alternative to a
proprietary scheme.
draft-ietf-ips-iscsi-name-disc:
Nit: social security numbers are not unique enough, it
turns out; various "agencies" want SSN plus date of
birth.
There are non-example.com domain names.
No "Security Consideration" section.
draft-ietf-ips-iscsi-boot:
No further objections.
The authors may want to look at Chuang and Roe, "A Case
Study of Secure ATM Switch Booting", NDSS 1996,
http://www.isoc.org/conferences/ndss96/chuang.ps
(I think that Roe has done other work on the subject,
but I can't find it at the moment.) Also see
N. Itoi, W. A. Arbaugh, S. Pollack, and D. M. Reeves,
``Personal Secure Booting,'' in Proceedings of the
Sixth Australian Conference on Information Security
and Privacy, pp. 130 - 144, July 2001.
http://www.cs.umd.edu/%7Ewaa/pubs/personal-secure-booting.pdf
Comments:
=========
Steve:
Defer -- there was no way I could get through 290 pages of iSCSI this
week... (Allison, is there more than the usual urgency here? I know
you've been trying hard to get the other IPS drafts through.)
Allison:
Steve,
There is just the usual urgency. This spec is very cleaned up
for its length and we hoped folks could read it and get it
done. There's been a long run up to this point and we need to
get this work out there in stable form for the industry. I'll
ask you to look at the fixes on ips-security at the same
time that you read this defer, Steve :).
Steve:
What a fun way to spend vacation time, which for me starts on
Saturday...
Sure, I'll try, and if there are no respin-grade DISCUSSes I'll even
try to deal with it by email early next week.
Patrik:
Note: Normative references to draft-ietf-ips-iscsi-string-prep-03.txt
which is needed for the naming mechanisms. Should these really be
released without the stringprep profile? I.e. should not the profile
be part of the package.
Allison:
Randy, you are only putting a Discuss on iscsi-boot and not on the
other documents in the set right?
I would like to let the others go forward, if there is not a Discuss
(we've yet to see this, of course) from SMB, the last reader...
BTW, I am very* glad to get these reviews - I had seen such issues
and knew they were needed, but this kind of review does not naturally
arise from TSV reviewers, and I had forgotten to ping about the topic...
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ips@ece.cmu.edu
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: iSCSI to Proposed Standard
-------------
The IESG has approved publishing both of the following Internet-Drafts
as Proposed Standards:
o iSCSI <draft-ietf-ips-iscsi-19.txt>
o Bootstrapping Clients using the iSCSI Protocol
<draft-ietf-ips-iscsi-boot-08.txt>
In the same action, the IESG approved publication of iSCSI Naming and
Discovery <draft-ietf-ips-iscsi-name-disc-08.txt> as an Informational
RFC.
These documents are the product of the IP Storage Working Group.
The IESG contact persons are Allison Mankin and Scott Bradner.
Technical Summary
The Small Computer Systems Interface (SCSI) is a family of
protocols for communicating with I/O devices, especially storage
devices. SCSI is a client-server architecture. The SCSI protocol
has been mapped over various transports, including Parallel SCSI,
IPI, IEEE-1394 (firewire) and Fibre Channel. These transports are
I/O specific and have limited distance capabilities. The iSCSI
protocol defined in draft-ietf-ips-iscsi describes a means of
transporting of the SCSI packets over TCP/IP, providing for an
interoperable solution which can take advantage of existing
Internet infrastructure, Internet management facilities and
address distance limitations. Mapping over TCP ensures that the
high volume storage transfers use congestion control.
The protocol defined in draft-ietf-ips-iscsi-boot enables iSCSI
boot clients to obtain the information to open an iSCSI session
with the iSCSI boot server. Its authentication support for this
is that of the iSCSI protocol login.
The Naming document provides examples of iSCSI name construction
and discussion of discovery of iSCSI resources (targets) by iSCSI
initiators (clients). This document complements the iSCSI
protocol document.
Working Group Summary
Special care was taken by the working group in a number of
areas: string comparison (based on Internet stringprep); strong
risk analysis and security; and the SCSI standards. Balance was
needed on each of these and the chairs and working group took
time to get the right details.
Protocol Quality
The protocol was reviewed for the IESG by Allison Mankin, David
Black, Elizabeth Rodriguez and Bernard Aboba. There are numerous
implementations reported to the Area Directors, including the
security features.
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-ips-iscsi-boot - Bootstrapping Clients
using the iSCSI Protocol to Proposed Standard
--------
Last Call to expire on: 2002-12-16
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Scott Bradner [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Patrik Faltstrom [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ips@ece.cmu.edu
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Bootstrapping Clients using the iSCSI Protocol
to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Bootstrapping Clients using
the iSCSI Protocol' <draft-ietf-ips-iscsi-boot-08.txt> as a Proposed
Standard. This document is the product of the IP Storage Working
Group. The IESG contact persons are Allison Mankin and Scott Bradner.
Technical Summary
(What does this protocol do and why does the community need it?)
Working Group Summary
(Was there any significant dissent? Was the choice obvious?)
Protocol Quality
(Who has reviewed the spec for the IESG? Are there implementations?)
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-ips-iscsi-name-disc - iSCSI Naming and
Discovery to Informational
--------
Last Call to expire on: 2002-12-16
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Scott Bradner [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Patrik Faltstrom [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, ips@ece.cmu.edu
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: iSCSI Naming and Discovery to Informational
-------------
The IESG has approved the Internet-Draft 'iSCSI Naming and Discovery'
<draft-ietf-ips-iscsi-name-disc-08.txt> as an Informational RFC. This
document is the product of the IP Storage Working Group. The IESG
contact persons are Allison Mankin and Scott Bradner.
Technical Summary
(What does this protocol do and why does the community need it?)
Working Group Summary
(Was there any significant dissent? Was the choice obvious?)
Protocol Quality
(Who has reviewed the spec for the IESG? Are there implementations?)
To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-avt-smpte292-video - RTP Payload Format
for SMPTE 292M Video to Proposed Standard
--------
Last Call to expire on: 2002-12-31
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Scott Bradner [ X ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Patrik Faltstrom [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jeff Schiller [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, avt@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: RTP Payload Format for SMPTE 292M Video to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'RTP Payload Format for SMPTE
292M Video' <draft-ietf-avt-smpte292-video-08.txt> as a Proposed
Standard. This document is the product of the Audio/Video Transport
Working Group. The IESG contact persons are Scott Bradner and Allison
Mankin.
Technical Summary
This document specifies a RTP payload format for encapsulating
uncompressed High Definition Television (HDTV) as defined by the
Society of Motion Picture and Television Engineers (SMPTE) standard,
SMPTE 292M. SMPTE is the main standardizing body in the motion imaging
industry and the SMPTE 292M standard defines a bit-serial digital
interface for local area HDTV transport and defines a universal medium
of interchange for uncompressed High Definition Television (HDTV)
between various types of video equipment (cameras, encoders, VTRs,
etc.). SMPTE 292M stipulates that the source data be in 10 bit words
and the total data rate be either 1.485 Gbps or 1.485/1.001 Gbps.
The use of a dedicated serial interconnect is appropriate in a studio
environment, but it is desirable to leverage the widespread
availability of high bandwidth IP connectivity to allow efficient wide
area delivery of area delivery of SMPTE 292M format content. This memo
defines a way to do so.
Working Group Summary
The AVT working group supported publication of this document on the
standards track.
Protocol Quality
This document was reviewed for the IESG by Scott Bradner.
License to Enhance Messaging Oriented Network Access for Diverse
Endpoints (lemonade)
-------------------------------------------------------------
Charter
Last Modified: 2002-12-09
Current Status: Active Proposed Working Group
Chair(s):
Glenn Parsons <gparsons@nortelnetworks.com>
Eric Burger <eburger@snowshore.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Ned Freed <ned.freed@mrochek.com>
Mailing Lists:
General Discussion:um@snowshore.com
To Subscribe: majordomo@snowshore.com
In Body: subscribe um
Archive: http://flyingfox.snowshore.com/um_archive/maillist.html
Description of Working Group:
Lemonade brings together a body of work related to Internet messaging,
in particular work done by the VPIM, FAX, IMAPEXT< and other IETF
working groups. The goal is to provide a set of enhancements and
profiles of Internet email submission, transport, and retrieval
protocols to facilitate operation in environments which use
Internet-based technologies but which have link characteristics, device
characteristics, or service environments that are significantly
different from those common on the Internet. A primary goal of this
work is to ensure that those profiles and enhancements continue to
interoperate with the existing Internet email protocols in use on the
Internet, so that these environments and more traditional Internet
users have access to a seamless service.
Given the potentially broad scope of "unified messaging", this working
group will focus specifically on the following work items:
1. An informational RFC will be produced on LEMONADE requiremens.
2. Enhance the existing IMAP4 message retrieval protocol to satisfy
the requirements for streaming playback of multimedia content.
3. Enhance the exsiting IMAP4 message retrieval protocol to facilitate
its use with devices that have limited capabilities such as mobile
endpoints. The existing standards-track CONNEG framework will be
used if content negotiation capabilities are needed.
3. Create a message notification protocol for the specific purpose of
servers reporting message status information to other servers.
4. Create a specification describing the use of Internet message
services in environments where message delivery may take place
using either Internet protocols or external protocols such as SMS.
Any protocols defined by this working group will include appopriate
security mechanisms, including authentication, privacy, and access
control. Mandatory-to-implement security mechanisms will be specified as
needed in order to guarantee secure protocol interoperability.
The transport area will be consulted to deal with any transport-related
issues that arise, especially in regards to items 1, 2, and 3 above.
The BOF is aware of several related activities in other groups:
- 3GPP TSG T WG2 SWG3 Messaging <http://www.3gpp.org/TB/T/T2/T2.htm>
- W3C Mulitmodal interaction Activity <http://www.w3.org/2002/mmi/>
- Open Mobile Alliance <http://www.openmobilealliance.org/>
- 3GPP2 TSG-P <http://3gpp2.org/Public_html/P/index.cfm>
- 3GPP2 TSG-N <http://3gpp2.org/Public_html/N/index.cfm>
The goal is to coordinate efforts with at least these groups as required.
While there is obvious synergy, given the end-of-life of the VPIM and
FAX work groups and the similar membership, the BOF does not expect to
coordinate with those groups.
Drafts to be used as input for working group deliverables (grouped per
milestone)
=========================================================
o draft-vaudreuil-um-issues-00.txt
o draft-burger-um-reqts-00.txt
o draft-wong-umcli-00.txt
o draft-shapira-snap-04.txt
o draft-burger-imap-chanuse-00.txt
o draft-nerenberg-imap-channel-01.txt
o draft-neystadt-imap-status-counters-00.txt
o draft-shveidel-mediasize-00.txt
o draft-vaudreuil-futuredelivery-00.txt
Goals and Milestones:
DEC 02 LEMONADE Requirements
MAR 03 Notification protocol
MAY 03 IMAP extensions for VM playback
JUL 03 IMAP extensions for mobile devices
NOV 03 Translation to other messaging systems