[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IESG Telechat Agenda and Package for Febuary 6, 2003
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the February 6, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
- January 23, 2003
o Review of Action Items
OUTSTANDING TASKS
Last updated: February 5, 2002
IP o <draft-dfncis-netnews-admin-sys-04.txt> in Expert Review; Ned to
evaluate.
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 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
IP o Patrik to re-evaluate state of draft-irtf-idrm-handle-system (Informational)
IP o Erik to re-evaluate state of draft-jl-pcdp (Informational)
IP o Allison to re-evaluate state of draft-malis-sonet-ces-mpls (Request).
Allison to send message to Andy.
IP o Ned to re-evaluate state of draft-tegen-smqp (Informational)
DONE o Ned to re-evaluate state of draft-tiwari-appl-wxxx-forms (Informational)
IP o Thomas to get IESG's sign off for draft-stoica-diffserv-dps.
Secretariat to announce.
IP o Secretariat to publish all liaison statements immediately.
IP o Secretariat to have aliases for statements to ietf.org that goes
to ticket system.
IP o Secretariat to include all IETF Secretariat action items on the
list.
IP o Harald to compose note for draft-ietf-isis-traffic-04.txt.
IP o Scott and Allison to confer on draft-foster-mgcp-basic-packages
and return next week with discussion points.
DONE o Secretariat to place 'lemonade' on new-work.
DONE o Secretariat to note in minutes of January 9, 2003 that the IDR
Working Group was discussed and approved.
IP o Ned to email Secretariat about draft-new-apex-server; Secretariat to
forward to RFC Editor.
DONE o Secretariat to send all liaison statements to ticketing system for
tracking.
IP o Harald to draft note regarding Zorn Formal Appeal Against IESG
decision. Secretariat to announce.
IP o Secretariat to list all known meetings that overlap/conflict with
IETF on existing calendar.
2. Protocol Actions
o A Conservative SACK-based Loss Recovery Algorithm for TCP
(Proposed Standard)
<draft-allman-tcp-sack-13.txt>
Token: Bradner, Scott
3. Returning to Agenda
o Internet Printing Protocol/1.1: IPP URL Scheme (Proposed Standard)
<draft-ietf-ipp-url-scheme-05.txt>
Token: Freed, Ned
Note: Waiting for Patrik to clear discuss
o Link Selection sub-option for the Relay Agent Information Option for
DHCPv4 (Proposed Standard)
<draft-ietf-dhc-agent-subnet-selection-04.txt>
Token: Narten, Thomas
Note: On Hold until DHC WG gets updated charter and credible plan for
addressing DHC security shortcomings.
o Guidelines for Writing RFC Text on Security Considerations (BCP)
<draft-iab-sec-cons-02.txt>
Token: Nordmark, Erik
Note: Waiting for Ned's review of the changed text in 02.
4. Working Group Submissions
o Alternative OSPF ABR Implementations (Informational)
<draft-ietf-ospf-abr-alt-05.txt>
Token: Fenner, Bill
o IP over Optical Networks: A Framework (Informational)
<draft-ietf-ipo-framework-03.txt>
Token: Bradner, Scott
o Robust ECN Signaling with Nonces (Experimental)
<draft-ietf-tsvwg-tcp-nonce-04.txt>
Token: Mankin, Allison
o Benchmarking Methodology for Firewall Performance (Informational)
<draft-ietf-bmwg-firewall-08.txt>
Token: Bush, Randy
5. Individual Submissions
o Mesh-enhanced Service Location Protocol (Experimental)
<draft-zhao-slp-da-interaction-16.txt>
Token: Narten, Thomas
Note: Original request was to publish on standards track, but authors
have agreed to go experimental based on IESG feedback. This version
also incorporates feedback from IESG reviewers.
o The Ogg encapsulation format version 0 (Informational)
<draft-pfeiffer-ogg-fileformat-01.txt>
Token: Mankin, Allison
Note: Outcome of IESG discussion 2003-Jan-23: WG and authors should
review Harald's question - maybe a rev is needed - question is in
comment section and sent to WG.
o Private Session Initiation Protocol(SIP) Proxy-to-Proxy Extensions
for Supporting DCS (Informational)
<draft-dcsgroup-sipping-proxy-proxy-02.txt>
Token: Mankin, Allison
Note: For 2003-Feb-06 agenda - ballot not needed, it is an
Informational document that has had Expert Review by the SIPPING
working group.
6. Proposed Working Groups
o IPSEC KEYing information resource record (ipseckey)
Token:Steve Belllovin
o Enhancements to Internet email to support diverse service
environments (lemonade)
Token: Ned
Note: New title: Enhancements to Internet email to support
diverse service environments (lemonade) and updated charter
o PROBLEM (problem)
Token: Harald
7. Working Group News We Can Use
8. IAB News we can use
9. Management Issues
o IESG Statement about International Domain Names
o IANA adding Names of STD organizations when assigning code points
o Revision to media types registration procedure
o OPES note and ICAP IESG notes
o crldp no-last-call complaint
o IETF/IEEE issues
DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT *
INTERNET ENGINEERING STEERING GROUP (IESG)
January 23, 2002
Reported by: Jacqueline Hargest, IETF Assistant Director
ATTENDEES
---------
Alvestrand, Harald / Cisco
Bellovin, Steve / AT&T Labs
Bradner, Scott / Harvard
Cotton, Michelle / ICANN
Daigle, Leslie / Verisign (IAB)
Faltstrom, Patrik / Cisco
Fenner, Bill / AT&T
Floyd, Sally / IAB Liaison
Freed, Ned / Innosoft
Hargest, Jacqueline / IETF
Mankin, Allison / Bell Labs, Lucent
Narten, Thomas / IBM
Nordmark, Erik / Sun
Reynolds, Joyce K. / ISI (RFC Editor)
Schiller, Jeff / MIT
Wijnen, Bert / Lucent
Zinin, Alex / Alcatel
REGRETS
-------
Austein, Rob / IAB Liaison
Bush, Randy / IIJ
Coya, Steve / IETF
Minutes
-------
1. The minutes of the January 9, 2003 teleconference were approved,
pending the Secretariat including a note that the IDR Working Group
was discussed and approved. Secretariat to then place in public
archives.
2. Prior to the January 23, 2003 teleconference, the following
documents were APPROVED:
o 'DHCP Option for CableLabs Client Configuration' (Proposed)
<draft-ietf-dhc-packetcable-06.txt>
o 'More MODP Diffie-Hellman groups for IKE' (Proposed)
<draft-ietf-ipsec-ike-modp-groups-05.txt>
o 'FC Frame Encapsulation' (Proposed)
<draft-ietf-ips-fcencapsulation-08.txt>
o 'Fibre Channel Over TCP/IP (FCIP)' (Proposed)
<draft-ietf-ips-fcovertcpip-12.txt>
o 'iFCP - A Protocol for Internet Fibre Channel Storage
Networking' (Proposed)
<draft-ietf-ips-ifcp-14.txt>
o 'RTP Payload Format for SMPTE 292M Video' (Proposed)
<draft-ietf-avt-smpte292-video-08.txt>
o 'Securing Block Storage Protocols over IP' (Proposed)
<draft-ietf-ips-security-16.txt>
o 'MDN profile for IMAP' (Proposed)
<draft-melnikov-imap-mdn-05.txt>
3. The following action items were reported as DONE:
o Allison and Thomas to draft note for draft-stoica-diffserv-dps
o Scott to summarize discussion on the Osama document.
o Patrik to re-evaluate state of draft-jaffer-metric-interchange-format
(None)
4. Protocol Action APPROVED:
The IESG approved publication of 'Diameter Base Protocol'
<draft-ietf-aaa-diameter-17.txt> as a Proposed Standard. Secretariat
to announce.
5. Protocol Actions TENTATIVELY APPROVED:
The IESG has tentatively approved publication of 'The AES-XCBC-MAC-96
Algorithm and Its Use With IPsec'
<draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt> as a Proposed Standard,
pending note from Jeff Schiller. Once received, Secretariat to
announce.
The IESG has tentatively approved publication of 'The application/ogg
Media Type' <draft-walleij-ogg-mediatype-05.txt> as a Proposed Standard,
pending RFC Editor Note from Allison. Once received, Secretariat to
announce.
6. Document Actions APPROVED:
The IESG has approved the Internet-Draft 'Diameter Command Codes for
3GPP Release 5' <draft-loughney-aaa-cc-3gpp-01.txt> as an
Informational RFC. Secretariat to send announcement.
The IESG has approved the Internet-Draft 'CR-LDP Extensions for ASON'
<draft-aboulmagd-ccamp-crldp-ason-ext-02.txt> as an Informational RFC.
Secretariat to send announcement.
The IESG has approved the Internet-Draft 'LDP and RSVP Extensions for
Optical UNI Signaling' <draft-bala-uni-ldp-rsvp-extensions-04.txt> as
an Informational RFC. Secretariat to send announcement.
7. The following documents are still under DISCUSSION:
o 'Intrusion Detection Message Exchange Format Data Model and
Extensible Markup Language (XML) Document Type Definition' (Proposed)
<draft-ietf-idwg-idmef-xml-09.txt>
o 'IP over Optical Networks A Framework' (Informational)
<draft-ietf-ipo-framework-03.txt>
o 'Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework' (Informational)
<draft-ietf-pkix-ipki-new-rfc2527-01.txt>
o 'Policy Requirements for Time-Stamping Authorities' (Informational)
<draft-ietf-pkix-pr-tsa-02.txt>
o 'Generic Requirements for Provider Provisioned VPN' (Informational)
<draft-ietf-ppvpn-generic-reqts-02.txt>
o 'The Ogg encapsulation format version 0' (Informational)
<draft-pfeiffer-ogg-fileformat-01.tx>
o 'IP Version 6 over MAPOS' (Informational)
<draft-ogura-ipv6-mapos-01.txt>
8. Working Group Action:
o 'License to Enhance Messaging Oriented Network Access for Diverse
Endpoints' (lemonade)
Note: Secretariat to send Working Group Review Message to
ietf-announce and new-work mailing list.
9. DNP:
o 'Per Hop Behaviors Based on Dynamic Packet State' (Experimental)
<draft-stoica-diffserv-dps-02.txt>
Note: Thomas to send RFC Editor Note to Secretariat. Secretariat
to send DNP announcement.
10. NEW Action Items:
o Secretariat to note in minutes of January 9, 2003 that the IDR
Working Group was discussed and approved.
o Ned to email Secretariat about draft-new-apex-server; Secretariat to
forward to RFC Editor.
o Secretariat to send all liaison statements to ticketing system for
tracking.
o Harald to draft note regarding Zorn Formal Appeal Against IESG
Decision. Secretariat to send announcement.
o Secretariat to list all known meetings that overlap/conflict with
IETF on existing calendar.
11. Outstanding Action Items:
IP o <draft-dfncis-netnews-admin-sys-04.txt> in Expert Review; Ned to
evaluate.
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 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
IP o Patrik to re-evaluate state of draft-irtf-idrm-handle-system (Informational)
IP o Erik to re-evaluate state of draft-jl-pcdp (Informational)
IP o Allison to re-evaluate state of draft-malis-sonet-ces-mpls (Request)
Allison to send message to Andy.
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)
IP o Thomas to get IESG's sign off for draft-stoica-diffserv-dps.
Secretariat to announce.
IP o Secretariat to publish all liaison statements immediately.
o Secretariat to have aliases for statements to ietf.org that goes
to ticket system.
IP o Secretariat to include all IETF Secretariat action items on the
list.
IP o Harald to compose note for draft-ietf-isis-traffic-04.txt.
IP o Scott and Allison to confer on draft-foster-mgcp-basic-packages
and return next week with discussion points.
IP o Secretariat to place 'lemonade' on new-work.
12. The following action items have been removed:
IP o Jeff to compare and contrast identity vs. identifier
o Patrik to re-evaluate state of draft-new-apex-server
(Informational)
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-allman-tcp-sack - A Conservative SACK-based
Loss Recovery Algorithm for TCP to Proposed Standard
--------
Last Call to expire on: 2003-2-13
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>, tsvwg@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: A Conservative SACK-based Loss Recovery
Algorithm for TCP to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'A Conservative SACK-based
Loss Recovery Algorithm for TCP' <draft-allman-tcp-sack-13.txt> as a
Proposed Standard. This document is the product of the Transport Area
Working Group. The IESG contact persons are Scott Bradner and Allison
Mankin.
Technical Summary
This document presents a conservative loss recovery algorithm for TCP
that is based on the use of the selective acknowledgment TCP option.
The algorithm presented in this document conforms to the spirit of the
current congestion control specification RFC2581, but allows TCP
senders to recover more effectively when multiple segments are lost
from a single flight of data.
Working Group Summary
The working group supported publishing of this document.
Protocol Quality
This document was reviewed for the IESG by Allison Mankin and Scott
Bradner.
Evaluation: draft-ietf-ipp-url-scheme - Internet Printing
Protocol (IPP): IPP URL Scheme to Proposed Standard
--------
Last Call to expire on: December 3, 2001
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Scott Bradner [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Patrik Faltstrom [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ X ] [ ] [ ] [ ]
Marcus Leech [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
April Marine [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jeff Schiller [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
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>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: ipp@pwg.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Internet Printing Protocol (IPP): IPP URL
Scheme to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Internet Printing Protocol
(IPP): IPP URL Scheme' <draft-ietf-ipp-url-scheme-03.txt> as a Proposed
Standard. This document is the product of the Internet Printing
Protocol Working Group. The IESG contact persons are Ned Freed and
Patrik Faltstrom.
Technical Summary
This document registers the "ipp" URL scheme with IANA in a fashion
that fully conforms to the requirements in [RFC-2717]. This "ipp"
URL scheme is a means of specifying the location of an IPP Printer,
IPP Job, or other IPP object which implements the IPP/1.1 Model
[RFC-2911] and the IPP/1.1 Protocol encoding over HTTP.
Working Group Summary
This document is a product of the IPP working group.
Protocol Quality
Ned Freed reviewed this specification for the IESG.
Evaluation: draft-ietf-dhc-agent-subnet-selection
Subnet Selection sub-option for the Relay Agent Information
Option to Proposed Standard
--------
Last Call to expire on: January 28, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ XX] [ X ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Scott Bradner [ ] [ XX] [ X ] [ ]
Randy Bush [ ] [ X ] [ ] [ ]
Patrik Faltstrom [ ] [ X ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ X ] [ ] [ X ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jeff Schiller [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ XX] [ X ] [ ]
2/3 (10) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS
=======
Thomas:
> 4. Security
> DHCP currently provides no authentication or security mechanisms.
What about DHCP authentication?
I've sent a note to the authors, but would like it balloted anyway.
Scott: this option is IPv4 specifc - the title should say so
(like RFC 3011, which it extends, does)
as long as there is a RFC editor note to chnage the title to make it
IPv4 spectific I'm OK with this ID (no-ob)
Harald: since rfc 3118 now exists, the security section that says no
security xists for DHCP is now untrue. hould the draft be updated
to match?
Alex:
While the contents of the document are clearly useful,
I couldn't make myself ignore some things. Most of
them are discuss-discuss. I'm willing to change my
Discuss to Yes as soon as these are clarified.
> 1. Introduction
...
> 1. IP y might not be unique for this subnet, but might instead be
> shared as a gateway address by multiple subnets.
Not clear what the authors mean by this. I can try to guess,
but the words do not help much.
> 2. Terminology
...
> o "link"
>
> A link is a collection of subnets that all coexist on the same
> physical medium. Sometimes called a lan segment or network seg-
> ment in other contexts.
I can't agree with definition of a link as a "collection of subnets".
First there was a link, not a subnet.
> 3. Link selection sub-option definition
>
...
I didn't find explicit specification of which DHCP messages
the sub-option can be put in. The descriptive paragraph in
introduction does not seem to be very precise.
> (i.e.: the network and subnet bits are left alone and the
> remaining (address) bits are set to zero).
I realize this text was taken from 3011 (dated 1997), but it's
strange to see terms "network" and "subnet" when the world is running
on CIDR.
> will also be considered in the same way as
> currently specified for the processing of the giaddr in [RFC 2131].
Can we have a more specific pointer, probably with section numbers?
The most related text I found was in 4.3.1 "DHCPDISCOVER message":
Note that, in some network architectures (e.g., internets with
more than one IP subnet assigned to a physical network segment),
it may be the case that the DHCP client should be assigned an
address from a different subnet than the address recorded in
'giaddr'. Thus, DHCP does not require that the client be assigned
as address from the subnet in 'giaddr'. A server is free to
choose some other subnet, and it is beyond the scope of the
DHCP specification to describe ways in which the assigned IP
address might be chosen.
Is this the one?
Alex's Update:
I discussed this with Bill yesterday and I think he had a valid
point that the draft assumes that the agent-server interaction
is already specified, so lack of description of implied details
is not a problem that this draft introduces. Hence, I'm willing
to withdraw the following comments from my DISCUSS, assuming
that the right thing would be to clarify this in the basic
specs, not in this draft.
> The sub-option contains a single IP address that is an address con-
> tained in a subnet. The value for the subnet address is determined
> by taking any IP address on the subnet and ANDing that address with
> the subnet mask
How does the DHCP server know the mask for the prefix that the
address sent by the client belongs to? Does it perform a lookup
operation? Where is this specified?
> This determines a single
> subnet, and when allocating an IP address, all of the other related
> subnets on the same link
How does the server group the subnets belonging to the same link,
especially for remote links? I couldn't find this in 2131.
If this is an implementation detail, do we still need some words?
Status as of May 16:
Thomas: For the remaining items, I think a respin will be done. I'll circulate
a revised version when its done. (The respin will also deal with
Scott's issue on mentioning v4 in the title.)
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,dhcwg@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Subnet Selection sub-option for the Relay
Agent Information Option to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Subnet Selection sub-option
for the Relay Agent Information Option'
<draft-ietf-dhc-agent-subnet-selection-04.txt> as a Proposed Standard.
This document is the product of the Dynamic Host Configuration Working
Group. The IESG contact persons are Erik Nordmark and Thomas Narten.
Technical Summary
In "Dynamic Host Configuration Protocol" (RFC2131), the giaddr
field specifies a single address that indicates both the subnet on
which a DHCP client resides as well as the IP address through which
the DHCP response is to be relayed back to the client. The Subnet
Selection Option (RFC 3011) allows a client (when acting as a DHCP
proxy) to override the default function of the giaddr so that a
different address can be provided to indicate the subnet from which
to allocate an IP address on (the giaddr field still indicates the
IP (relay) address through which the DHCP server responds to the
client).
Analgous situations exist where the relay agent needs to specify a
subnet on which a DHCP client resides that is different from the
address in the giaddr field. The DHCP Relay Agent Subnet-Selection
sub-option specified in this document provides a mechanism to do
this.
Working Group Summary
There was support for this document in the WG, and no issues were
raised during Last Call.
Protocol Quality
This document has been reviewed for the IESG by Thomas Narten.
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-iab-sec-cons - Guidelines for Writing
RFC Text on Security Considerations to BCP
--------
Last Call to expire on: July 15, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ X ] [ ] [ ] [ ]
Scott Bradner [XX ] [ ] [ X ] [ ]
Randy Bush [XX ] [ ] [ X ] [ ]
Patrik Faltstrom [XX ] [ ] [ X ] [ ]
Bill Fenner [ ] [ ] [ X ] [ ]
Ned Freed [ ] [ ] [ X ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ XX] [ ] [ 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
=======
Patrik:
I think the document do a bit more than talking about security
considerations, and that is help for actual designers of the document
which is to have the security considerations. I think that is a good
idea.
But, when looking at the architectual discussions, I would like to have
some wording on two things which are discussed a lot in applications
area. I have no idea what to write, but would like to have it written
down, and it has to do with TLS:
- The document talks about TLS in basically two places, regarding
authentication and securing of a connection. I would like to have
some more words about what happens if these are combined. I.e.
my personal view is that TLD for securing connection is a good
idea, but at the same time for mutual authentication is hard,
as "The Global PKI" doesn't exist. Because of that, I have
suggested wg's in apps area to use TLS for securing connection,
but then things like SASL for authentication.
Is that a good or bad suggestion? I.e. I would like text
about when one do authentication and securing of channel.
- The current implementations of TLS I have seen do secure
the channel before one in the protocol have passed the
information about what one want to connect to. This implies
that if one do virtual hosting of HTTP or SMTP (for example),
the server doesn't know really what cert to present to the
client. This leads to "one port per virtual host" which is
not so fun, as we really want the cert used in TLS be the
name of the _virtual_domain_ and not the host. This because
the name of the host is normally fetched from DNS (SRV/MX)
or whatever else "unsecure" mechanism, while the virtual
domain is in the URI.
I would like to have some wording about this aswell.
But, let me emphasize that these are additional things. I think the
document is good, and will help work in my area.
Scott:
notes:
good document but ....
the ID needs an abstract
the actual filename is draft-iab-sec-cons-00.txt
MUST used but not defined
references not split
since one of our biggest proboems is people claiming
that they do not have to security because thir appliction
will only be run in a closed environment (much of
the "discussion" in IP Storage) I think its very
important to have a section in this document that
addresses that claim head-on (once someting runs on IP
there is no way for the host to be SURE that its in
a confined net etc)
in general I think the doc could use a bit more
discussion of architecture in that it seems to be
mechanism-centric
also - Jeff said some things about IPSec the other day
that might be good to fold into this document
Bill:
I looked closely at section 6.2, since the VRRP WG is interested in
advancing the VRRP spec to Draft, and the security considerations are
one of the issues. I'm sorry that this is kind of a stream of
consciousness, but it's been rattling around in my head for months and
I haven't managed to get it out properly yet.
Minor initial comment:
Section 6.2.1.3 contains a transcription error, changing RFC 2338's
reference to RFC 2403 into a reference to RFC 2104. This leads to the
note that there should be a recommended algorithm, but 2338 does
recommend HMAC-MD5-96.
However, based on some discussion on the VRRP WG list and my own
analysis, I think there's a large amount of analysis missing from
2338 -- notably, what happens with authentication failures.
Basically, VRRP authentication failures are likely to cause multiple
VRRP master routers (one in each authentication "domain", which I
define as a set of systems that have the same authentication info).
Having multiple VRRP masters is not a situation that was ever
considered in the spec, and could prove more disruptive than an attack
on the VRRP protocol itself.
The threat: an attacker on the same LAN can send VRRP messages claiming
to have high priority. Since the IP Address Owner never gives up being
the forwarder, the attacker can only disrupt the network when the
IP Address Owner is down; it can then cause itself to be elected
Virtual Router Master and e.g. blackhole or MITM all the traffic.
Relative threat analysis: This is much easier in two ways: ARP and
switch-fooling. ARP's vulnerabilities are well known, and were in
fact accidentally demonstrated at the Yokohama IETF. Fooling an auto-
learning switch into forwarding you traffic destined for mac address M
by sourcing packets with mac address M is trivial, and in fact this
procedure is described in RFC 2338.
Now, just because there are easier ways to accomplish this doesn't
mean that we shouldn't try to secure VRRP, but since
a) authentication failures cause multiple masters to be elected
b) multiple masters are potentially very disruptive
this tradeoff should be analyzed.
Multiple masters can cause disruptions from black holes to duplicated
traffic, depending on the environment. In a switched environment,
they can cause the switches' idea of where the virtual router MAC
address is attached to change twice per second, possibly causing
forwarding irregularities during the switch (and possibly directing
traffic for some of the time to a misconfigured router).
My final analysis: the Simple Text Password turns minor
misconfigurations into major disruptions (it's better to just let the
misconfigured router participate in an unauthenticated VRRP election
than to have it elect itself as master because all the proper election
packets fail authentication), so should be eliminated. The IPSEC AH
section doesn't talk about keying, even though it sends to multicast
groups; I think it should talk about using static keys and disabling
replay prevention, and optionally using a group keying protocol when
one is defined. The document also needs to talk about these tradeoffs
of multiple masters due to authentication failures.
The body of the document also could use some tightening up wrt
security, e.g.
7.1 Receiving VRRP Packets
Performed the following functions when a VRRP packet is received:
...
- MUST perform authentication specified by Auth Type
but the check that I'm willing to accept this auth type is not
explicitly present, so a packet with no authentication would pass these
rules even if the router was configured to send plain-text
authentication. This is probably not a draft-iab-sec-cons issue, though.
Ned:
Section 4.2, fourth paragraph. It says in part "For instance, SASL can
be used merely as an authentication framework--in which case the SASL
exchange occurs but the rest of the connection is unprotected, but can
also negotiate TLS as a mechanism.". This is incorrect; there is no
defined way to negotiate TLS as a mechanism in SASL, and as a practical
matter protocol that provide the means to use both SASL and TLS do so
with separate commands or negotiations. What SASL provides is a means
to negotiate either an integrity or confidentiality layer coincident
with authorization, distinct from similar layers provided by TLS.
Some mention of the SASL EXTERNAL mechanism and its ability to import
authentication credential from outside sources like TLS might also be
useful here. It certainly adds yet another nuance to the overlapping
nature of our security building blocks.
Section 6.1. A comparison of this hypothetical security considerations
section for SMTP with the recently constructed one that appears in the
updated SMTP specification RFC 2821 shows a number of interesting
differences. Generally speaking what appears in section 6.1 focuses on
how additional external services can be used to advantage to make SMTP
more secure, whereas what appears in RFC 2821 focuses on security
issues within SMTP itself.
I think section 6.1 puts the focus in the wrong place. While it is
undeniably true that increased use of security building blocks is a
Good Thing, I think it is far more important for security considerations
sections to focus on security issues inherent in the specification
itself. Endless reiteration that IPsec, TLS, S/MIME, PGP are good tools
to use looks more and more like security pixie dust to me.
I would therefore suggest that this section be redone to at least
mention the many security issues inherent in SMTP that are raised in
RFC 2821.
Section 6.1.1. I find it curious that SASL isn't listed as a tool to
use in the SMTP context. In practice SASL is _the_ way that
authentication is done in SMTP; such usage has become quite
commonplace as a means for remote users to get their SMTP server to
accept messages for relay. I think it needs to be on this list and there
needs to be a section describing its use.
Finally, I see no mention in this document of the risks of executable
content. We have a lot of RFCs that define media types; when defining
a media type the single most important issue that needs to be addressed
in a security considerations section is whether or not the type admits
executable content and if it does what steps are taken to prevent it
from becoming a problem. I think this at least needs to be mentioned here.
Thomas:
Overall, this document is great and needed addition. Thanks for doing
it!
One thing I think would benefit from some explicit discussion,
however, concerns distinguishing between threats caused by on-link
attackers, on-path attackers, and off-path attackers. Two issues here:
1) it may make sense in the security considerations section to talk
about these classes because the protocol itself may be deployed in
more limited scope environments, and the threat models are then
different.
2) In some cases, it makes sense for the protocol itself to add
mechanisms to reduce threats that aim at thwarting (say) just
off-link or off-path attackers. Again, this may be useful for
certain deployments. E.g., VRRP uses the TTL=255 trick to reduce
threats from off-link attackers. MIPv6 (still an ID) pays a lot
more attention to threats from off-path attackers than on-path,
since on-path attackers have such a large arsenal of tricks.
I'm not immediately sure the best place to put in text related to the
above. Section 3 or 3.1 perhaps?
Section 3 says:
By contrast, we assume that the attacker has nearly complete
control of the communications channel over which the end-systems
communicate. This means that the attacker can read any PDU
(Protocol Data Unit) on the network and undetectably remove,
change, or inject forged packets onto the wire. This includes
being able to generate packets that appear to be from a trusted
machine. Thus, even if the end-system with which you wish to
communicate is itself secure, the Internet environment provides
no assurance that packets which claim to be from that system in
fact are.
I think "assume attacker has nearly complete control" is basically
right by default, but that folks should also think about whether it
makes sense to distinguish between on-path, off-path, etc.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Guidelines for Writing RFC Text on Security
Considerations to BCP
-------------
The IESG has approved the Internet-Draft 'Guidelines for Writing RFC
Text on Security Considerations' <draft-iab-sec-cons-00.txt> as a BCP.
This document is the product of the Internet Architecture Board.
The IESG contact persons are Erik Nordmark and Thomas Narten.
Technical Summary
All RFCs are required by [RFC 2223] to contain a Security Considera-
tions section. The purpose of this is both to encourage document
authors to consider security in their designs and to inform the
reader of relevant security issues. This memo is intended to provide
guidance to RFC authors in service of both ends.
Working Group Summary
This document is not a product of a working group.
Protocol Quality
This document has been reviewed for the IESG by Erik Nordmark.
IPSEC KEYing information resource record (ipseckey)
---------------------------------------------------
Charter
Last Modified: 2003-02-02
Current Status: Active Proposed Working Group
Chair(s):
Olafur Gudmundsson <ogud@ogud.com>
Michael Richardson <mcr@sandelman.ottawa.on.ca>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Steven Bellovin <smb@research.att.com>
Mailing Lists:
General Discussion:ipseckey@sandelman.ca
To Subscribe: ipseckey-request@sandelman.ca
Archive: http://www.sandelman.ca/lists/html/ipseckey/
Description of Working Group:
This effort has a goal of designing a IPSEC specific resource record for
the domain name system (DNS) to replace the functionality of the IPSEC
sub-type of the KEY resource record.
Original DNSSEC specification explicitly specified flags on KEY resource
records for use by IPSEC. Experience has show this to cause operational
problems. DNSEXT working group is restricting the use of the KEY record
to DNS uses only. IPSEC keying via DNS thus needs a new resource record.
The scope of work is to identify what information is needed in a
IPSEC specific keying resource record. The contents of the resource
record are not limited to only the information that is in the DNS KEY
record but also to contain useful IPSEC information information, such as
that which is required for Opportunistic Encryption. The record is not
limited to such use.
The general problems of key management, and semantic content of the data
stored in the resource record is beyond the scope of this effort. This
effort is limited to syntactic issues only. Semantics of the contained
information is left to future deployment documents to define.
This effort is specific to providing IPSEC information in DNS. All other
distributed channels are out of scope.
Goals and Milestones:
MAR 03 Solicit various proposals on what information is needed in
IPSEC specific KEYing record
APR 03 First draft of consensus RR proposal
MAY 03 Advance Document to IESG
Enhancements to Internet email to support diverse service environments (lemonade)
---------------------------------------------------------------------------------
Charter
Last Modified: 2003-01-31
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 is tasked 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.
Lemonade's work is at the crossroads of a body of work related to
Internet messaging, in particular work done by the VPIM, FAX, IMAPEXT
and other IETF working groups. Given the potentially broad scope of
activities this group could engage in, the group will focus
specifically on the following work items:
0. An informational RFC will be produced on LEMONADE requirements.
1. Enhance the existing IMAP4 message retrieval protocol to satisfy
the requirements for streaming playback of multimedia content.
2. 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 through an MMS server using
WAP to communicate with the receiving user agent.
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-4 above.
The working group 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 working group does not
expect to coordinate with these other groups.
Drafts to be used as input for working group deliverables (grouped per
milestone):
LEMONADE requirements
- draft-vaudreuil-um-issues-00.txt
- draft-burger-um-reqts-00.txt
- draft-wong-umcli-00.txt
Server to server notification protocol
- draft-shapira-snap-04.txt
IMAP4 extensions for VM playback
- draft-burger-imap-chanuse-00.txt
- draft-nerenberg-imap-channel-01.txt
IMAP4 extensions for mobile devices
- draft-neystadt-imap-status-counters-00.txt
- draft-shveidel-mediasize-00.txt
Translation to and from other messaging systems
- draft-vaudreuil-futuredelivery-00.txt
Goals and Milestones:
FEB 03 LEMONADE Requirements
MAY 03 Server to server notification protocol
JUL 03 IMAP extensions for VM playback
SEP 03 IMAP extensions for mobile devices
JAN 04 Translation to and from other messaging systems
Problem Statement (problem)
---------------------------
Charter
Last Modified: 2003-01-31
Current Status: Active Proposed Working Group
Chair(s):
Avri Doria <avri@acm.org>
Melinda Shore <mshore@cisco.com>
General Area Director(s):
Harald Alvestrand <harald@alvestrand.no>
General Area Advisor:
Harald Alvestrand <harald@alvestrand.no>
Mailing Lists:
General Discussion:problem-statement@alvestrand.no
To Subscribe: problem-statement-request@alvestrand.no
Archive: http://www.alvestrand.no/pipermail/problem-statement/
Description of Working Group:
Discussions during 2002 have revealed a significant number of thoughts
about problems that exist with the way the IETF operates. In advance of
trying to change the IETF procedures and rules to deal with these
problems, the IETF should have a clear, agreed description of what
problems we are trying to solve.
This group is charged with producing the document describing these
problems. The analysis of the problem should seek out the root causes
of the problems as well as the perceived derivative problems.
The intent is that the group will discuss issues on its mailing list,
and that there will be an editing team to produce a clear concise
problem statement on which the group has come to consensus and present
to the IETF as a basis for an IETF consensus.
As a second work item, the group will also produce a proposal for a
process to develop solutions to the problems identified by this working
group.
It is not a part of this group's charter to propose solutions to the
problems.
The work items will be reviewed in IESG plenary at the IETF.
Goals and Milestones:
JAN 03 Group formed
FEB 03 First I-D of problem statement issued
MAR 03 Problem statement reviewed at the IESG Plenary
MAR 03 First I-D of process proposal issued
MAY 03 Problem statement submitted for IESG review
JUL 03 Process proposal reviewed at the IESG Plenary
AUG 03 Process proposal submitted for IESG review
OCT 03 Re-charter or close working group
IANA adding Names of STD organizations when assigning code points
- do we agree if IANA requires to add the names of STDs
organizations or fora/consortia when assigning code points
- or do we not care and do we leave it up to IANA
I have posted a few emails from Bob Braden (in fact I am not
sure in what position he was speaking, probably as RSVP expert
or on individual title), but in any event, IANA is now wondering.
The specific example leading to this topic is that I believe
Bob is asking for example for the assignment, which now reads
(from <http://www.iana.org/assignments/rsvp-parameters)>
228 CALL_OPS (ASON) [RFC-lin-ccamp-gmpls-ason-rsvpte-04.txt]
Class Types or C-Types:
1 Type 1 CALL_OPS [RFC-lin-ccamp-gmpls-ason-rsvpte-04.txt]
Into something like (if I understood Bob correctly):
228 ITU_CALL_OPS (ASON) [RFC-lin-ccamp-gmpls-ason-rsvpte-04.txt]
Class Types or C-Types:
1 Type 1 ITU_CALL_OPS [RFC-lin-ccamp-gmpls-ason-rsvpte-04.txt]
One could say that for ATM that was kind of done, but here the FORUM
is named the same as the technology, so it has:
227 ATM_SERVICECLASS [RFC-malis-diff-te-serviceclass-04.txt]
Class Types or C-Types:
1 ATM Service class [RFC-malis-diff-te-serviceclass-04.txt]
I must also say, that if people request for an ifType from IANA, and
if they tell me/us that it is a proprietary interface, then I tend
to ask then to prefix the descriptor also with a company name).
For example we have in <http://www.iana.org/assignments/ianaiftype-mib>
pdnEtherLoop1 (217), -- Paradyne EtherLoop 1
pdnEtherLoop2 (218), -- Paradyne EtherLoop 2
I have asked Bob Braden for a summary of what he exactly wants and
what his reasoning is. And I have asked IANA to not yet prefix
anything.
Revision to media types registration procedure
(see: ftp://mauve.mrochek.com/mime4.txt)
OPES/ICAP Notes
Recall that we agreed that a note needed to be sent to the OPES group prior to
announcing approval of the two OPES informational documents. Attached below is
a draft of that note.
Also recall that we agreed that publication of ICAP protocol specification is
appropriate provided an IESG note explaining that work is underway in OPES to
develop a standards track replacement is attached. Attached below is a draft of
that note.
Secretariat, please add both of these as discussion items to this week's
agenda. Thanks.
Ned
P.S. I wrote these some time back and I was sure I'd sent them out a couple of
weeks ago. But after seeing no comments I checked and could not find any
indication they ever went out. Oops.
The IESG has approved the drafts
ietf-opes-protocol-reqs-03.txt
draft-ietf-opes-architecture-04.txt
for publication as informational RFCs. An announcement to this effect will be
sent shortly. As explained previously, the IESG beleieves that
draft-ietf-opes-scenarios-01.txt is too dependent on
draft-ietf-opes-threats-00.txt to publish at this time.
The IESG is concerned, however, that what appears in these drafts is a fairly
high level overview of OPES requirements and architecture. Missing is any
mention of specific mechanisms to provide security and congestions.
This is not necessarily a problem given these are informational requirement and
architecture documents. However, the IESG notes that the lack of specificity
at this point may lead to problems deciding on actual protocol
details later in process. Requirement and architecture documents have often
proved to be useful tools in reaching consensus on subsequent protocol
specifications.
Should difficulties arise in reaching consensus later it may be necessary and
useful to expand on these documents with information about specific mechanisms
to be used.
--Boundary_(ID_h2a7Xsnd9lkSLkUGZ34lPA)
The Open Pluggable Edge Services (OPES) working group has been chartered to
produce a standards track protocol specification for a protocol intended to
perform the same sorts of functions as ICAP. However, since ICAP is already in
widespread use the IESG believes it is appropriate to document existing usage
by publishing the iCAP specification as an informational document. The IESG
also notes that ICAP was developed before the publication of RFC 3238 and
therefore does not address the architectural and policy issues described in
that document.