[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Alternate Agenda and Package for June 26, 2003 Telechat
INTERNET ENGINEERING STEERING GROUP (IESG)
Summarized Agenda for the June 26, 2003 IESG Teleconference
1. Administrivia
o Roll Call
o Bash the Agenda
o Approval of the Minutes
o Review of Action Items
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o SDP: Session Description Protocol (Proposed Standard) - 1 of 1
<draft-ietf-mmusic-sdp-new-13.txt>
2.1.2 Returning Item
o The Secure Real-time Transport Protocol (Proposed Standard) - 1 of 2
<draft-ietf-avt-srtp-08.txt>
o Mapping of of Integrated Services Digital Network (ISUP) Overlap Signalling
to the Session Initiation Protocol (Proposed Standard) - 2 of 2
<draft-ietf-sipping-overlap-04.txt>
2.2 Individual Submissions
2.2.1 New Item
NONE
2.2.2 Returning Item
o Generating One-Time Passwords with SHA-256, SHA-384, and SHA-512 (Proposed
Standard) - 1 of 1
<draft-nesser-otp-sha-256-384-512-02.txt>
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o Requirements for Distributed Control of ASR, SI/SV and TTS Resources
(Informational) - 1 of 5
<draft-ietf-speechsc-reqts-04.txt>
o Applicability Statement for Restart Mechanisms for the Label Distribution
Protocol (Informational) - 2 of 5
<draft-ietf-mpls-ldp-restart-applic-01.txt>
o Compact Forward Error Correction (FEC) Schemes (Experimental) - 3 of 5
<draft-ietf-rmt-bb-fec-supp-compact-01.txt>
o Cross Registry Internet Service Protocol (CRISP) Requirements
(Informational) - 4 of 5
<draft-ietf-crisp-requirements-05.txt>
o Unmanaged Networks IPv6 Transition Scenarios (Informational) - 5 of 5
<draft-ietf-v6ops-unman-scenarios-02.txt>
3.1.2 Returning Item
o Goals for IPv6 Site-Multihoming Architectures (Informational) - 1 of 2
<draft-ietf-multi6-multihoming-requirements-07.txt>
o Requirements of a QoS Solution for Mobile IP (Informational) - 2 of 2
<draft-ietf-nsis-qos-requirements-01.txt>
3.2 Indiviual Submissions Via AD
3.2.1 New Item
o URI Scheme for the TFTP Protocol (Informational) - 1 of 1
<draft-lear-tftp-uri-06.txt>
3.2.2 Returning Item
NONE
3.3 Indiviual Submissions Via RFC Editor
3.3.1 New Item
o The Media Gateway Control Protocol (MGCP) Bulk Audit Package
(Informational) - 1 of 2
<draft-foster-mgcp-bulkaudits-09.txt>
o .sex Considered Dangerous (Informational) - 2 of 2
<draft-eastlake-xxx-06.txt>
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
o Layer 3 Virtual Private Networks - 1 of 3
Token: Thomas
o Path Maximum Transmission Unit Discovery - 2 of 3
o Layer 2 Virtual Private Networks - 3 of 3
Token: Thomas
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4.2.2 Proposed for Approval
NONE
5. Working Group News We Can Use
6. IAB News We Can Use
7. Management Issues
------------------------------------------------------------------------------
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the June 26, 2003 IESG Teleconference
1. Administrivia
o Roll Call
Harald Alvestrand---Will call in
Rob Austein---Will call in
Steve Bellovin---Will call in
Randy Bush---Will call in
Michelle Cotton---Will call in
Leslie Daigle---Will call in
Dinara Suleymanova---Will call in
Bill Fenner---Will call in
Ned Freed---Will call in
Barbara Fuller---Will call in*
Ted Hardie---Will call in
Jacqueline Hargest---Will call in*
Russ Housley---Will call in
Allison Mankin---Will call in
Thomas Narten---Will call in
Erik Nordmark---Call at +33-4-76-99-84-29
Jon Peterson---Will call in
Joyce K. Reynolds---Will call in
Bert Wijnen---Will call in
Alex Zinin---Will call in
Participants inside the U.S. should dial
888-315-1685.
If you have requested operator assistance,
an operator will call you and connect
you to the call.
All participant should enter the passcode
235467 when prompted to do so.
Participants outside the U.S. should use
either one of the toll-free numbers listed
below, or the direct-dial number 703-788-0617.
Participants using the direct-dial number
will pay their own long distance charges
through their own carriers. Participants
dialing the toll-free number will not pay
any charges for the conference as all
charges, including long distance, will be
included on the invoice sent to the company
hosting the call. In some cases, participants
from certain international countries may only
use a direct-dial number.
The first person on the call will not hear
anything until joined by other participants.
A tone will sound as others join the conference.
****************************************
TOLL-FREE NUMBERS
ARGENTINA---0800-666-0375
AUSTRALIA---1800-001-906
BRAZIL---000-817-200-5360
CHINA---10800-1300398
FINLAND---08001-10966
FRANCE---0800-91-1452
GERMANY---0800-181-7632
HONG KONG---800-96-3907
HUNGARY---06-800-15083
ISRAEL---18009300182
JAPAN---00531-13-0415
MEXICO---001-866-857-1855
NORWAY---800-10-074
SWEDEN---020-791386
UNITED KINGDOM---0800-904-7969
SOUTH KOREA---00308-131103
NETHERLANDS---0800-023-2726
PARTICIPANTS FROM ALL OTHER COUNTRIES MUST USE
THE DIRECT DIAL NUMBER AND THUS INCUR CHARGES
FROM THEIR OWN CARRIER.
o Bash the Agenda
o Approval of the Minutes
DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT
INTERNET ENGINEERING STEERING GROUP (IESG) MINUTES
June 12, 2003 IESG Teleconference
Reported by: Jacqueline Hargest, IETF Secretariat
ATTENDEES
-----------------
Harald Alvestrand / Cisco
Rob Austein / IAB Liaison
Randy Bush / IIJ
Michelle Cotton / ICANN
Leslie Daigle / Verisign (IAB)
Bill Fenner / AT&T
Ned Freed / Sun Microsystems
Barbara Fuller / IETF Secretariat
Ted Hardie / Qualcomm, Inc.
Jacqueline Hargest / IETF Secretariat
Russ Housley / Vigil Security, LLC
Allison Mankin / Bell Labs, Lucent
Erik Nordmark / Sun
Jon Peterson / NeuStar, Inc.
Joyce K. Reynolds / ISI (RFC Editor)
Dinara Suleymanova / IETF Secretariat
Bert Wijnen / Lucent
Alex Zinin / Alcatel
REGRETS
------------
Steve Bellovin / AT&T Labs
Thomas Narten / IBM
Minutes
--------
1. The minutes of the May 29, 2003 teleconference were approved.
The Secretariat to place in public archives.
2. Review Action Items
DONE TASKS:
o Ted to write straw working group procedures for handling consensus-
blocked decisions
o Printer Finishing MIB (Informational) <draft-ietf-printmib-
finishing-16.txt> RFC Editor's Note to be prepared by Ned Freed.
Secretariat to send Document Action Announcement including RFC Editor's Note.
o Secretariat to include the following statement (line) before the
draft approval announcement that is part of a ballot.
---- following is a DRAFT of message to be sent AFTER approval ---
To: IETF-Announce:;
Dcc: *******
o IESG to review IANA matrix data.
OUTSTANDING TASKS:
o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
o Erik to document process of how the IESG goes about asking
architectural questions of the IAB
o Thomas to write (or cause to be written) a draft on "how to get to Draft".
o Thomas to contact Cablelabs to discuss formal relationship with IAB
o Allison and Thomas will email Secretariat note to send to RFC Editor
about 3GPP RFC Editor documents.
o Ned to write an IESG note for draft-tegen-smqp (Informational)
o Steve to write RFC re: TCP MD5 option
o Randy and Ned to finish ID on Clarifying when Standards Track Documents
may Refer Normatively to Documents at a Lower Level
o Alex to send proposal and justification for interim document review.
o Steve to generate a summary of IESG views of the "problem"
o Steve to propose a different document classification than the current
info/proposed/etc.
o Next Steps in Signaling (nsis)
Allison Mankin to submit a Revised Charter to the Secretariat. Secretariat
to send a WG Review Announcement with copy to new-work@ietf.org.
o Harald Alvestrand to talk to RFC Editor about independent submissions.
o Alex Zinin to phrase a question to RTG and OPS Area Directoriats and IAB
on PPVPN issue. Alex to summarize the results as a proposed IESG consensus
regarding the PPVPN issue to be given to the PPVPN working group.
NEW TASKS:
o Secretariat to include teleconference bridge/call-in details in telechat
packages going forward.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item
o Securing X.400 Content with S/MIME (Proposed Standard)
<draft-ietf-smime-x400wrap-06.tx>
Under Discussion by Steve Bellovin - IESG Review - AD Follow Up
o Mobility Support in IPv6 (Proposed Standard)
<draft-ietf-mobileip-ipv6-22.txt>
Under Discussion by Steve, Erik
o Definitions of Managed Objects for the Ethernet-like
Interface Types (Proposed Standard)
<draft-ietf-hubmib-etherif-mib-v3-03.tx>
Approved - Secretariat to announce, and include note
that as a result of this approval, RFC1643 has been
re-classified to Historic Status.
o Multi Protocol Label Switching Label Distribution Protocol
Query Message Description (Proposed Standard)
<draft-ietf-mpls-lsp-query-07.txt>
Under discussion by Harald, Steve and Russ
o The Secure Real-time Transport Protocol (Proposed Standard)
<draft-ietf-avt-srtp-08.tx>
Deferred to next telechat by Russ Housley, Jon Peterson
Discuss comments by Steve Bellovin
o An Extension to the Session Initiation Protocol (SIP) for
Symmetric Response Routing (Proposed Standard)
<draft-ietf-sip-symmetric-response-00.txt>
Under discussion by Ted, Erik
o Coexistence between Version 1, Version 2, and Version 3 of
the Internet-standard Network Management Framework (BCP)
<draft-ietf-snmpv3-coex-v2-04.txt>
Approved - Point Raised
Secretariat to announce pending RFC Editor Note from Bert.
o PacketCable Security Ticket Control Sub-option for the
CableLabs Client Configuration Option (Proposed Standard)
<draft-ietf-dhc-pktc-kerb-tckt-02.txt>
Under Discussion - Point Raised by Harald
o Remote Network Monitoring MIB Protocol Identifier Reference
(Draft Standard)
<rfc2895.txt>
Under Discussion by Steve
2.1.2 Returning Item
o Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes
and Home Agents (Proposed Standard)
<draft-ietf-mobileip-mipv6-ha-ipsec-05.txt>
Under Discussion by Steve, Randy and Russ
2.2 Individual Submissions
2.2.1 New Item
o Generating One-Time Passwords with SHA-256, SHA-384, and
SHA-512 (Proposed Standard)
<draft-nesser-otp-sha-256-384-512-02.txt>
Under Discussion by Harald, Steve, Randy and Russ
o Registration procedures for message header fields (BCP)
<draft-klyne-msghdr-registry-06.txt>
Under Discussion by Allison, Jon
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
o OSPF Refresh and Flooding Reduction in Stable Topologies
(Informational)
<draft-pillay-esnault-ospf-flooding-06.txt>
Removed per Bill Fenner
o Introduction to the Remote Monitoring (RMON) Family of MIB
Modules (Informational)
<draft-ietf-rmonmib-framework-05.txt>
Approved - Secretariat to announce
o Transition Scenarios for 3GPP Networks (Informational)
<draft-ietf-v6ops-3gpp-cases-03.txt>
Approved - Secretariat to announce
o Guidelines for Extending the Extensible Provisioning Protocol Informational)
<draft-ietf-provreg-epp-ext-03.txt>
Approved pending RFC Editor Note - Secretariat to announce
o Border Gateway Multicast Protocol (BGMP): Protocol
Specification (Informational)
<draft-ietf-bgmp-spec-05.txt>
Under discussion by Randy
3.1.2 Returning Item
o SDPng Transition (Informational)
<draft-ietf-mmusic-sdpng-trans-04.txt>
Approved - Point raised - Pending RFC Editor Note, Secretariat to announce
3.2 Indivdiual Submissions Via AD
3.2.1 New Item
o The QCP File Format and Associated Media Types (Informational)
<draft-gellens-qcp-01.txt>
Approved - Secretariat to announce
Note: IESG may request expedited publication.
3.3 Indiviual Submissions Via RFC Editor
3.3.1 New Item
o Backtrace Messages for Label Switched Paths (Informational)
<draft-kishan-lsp-btrace-04.txt>
Secretariat to send DNP message to RFC Editor per AlexËs note.
o Guidelines for MPLS Load Balancing (Informational)
<draft-allan-mpls-loadbal-04.txt>
Secretariat to send DNP message to RFC Editor per AlexËs note.
3.3.2 Returning Item
o Basic MGCP Packages (Informational)
<draft-foster-mgcp-basic-packages-10.txt>
Approved - Point Raised. Secretariat to announce, incorporating
IESG note from Allison Mankin.
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Layer 2 Virtual Private Networks
Token: Thomas
After Alex and Allison agree on Item 6, Alex will notify
Secretariat. Secretariat to send Working Group Review
Message to IETF and new-work simultaneously with L3VPN message.
o Path Maximum Transmission Unit Discovery
Token: Allison
Secretariat to send Working Group Review message to IETF
and new-work.
o Layer 3 Virtual Private Networks
Token: Thomas
After Alex and Allison agree on wording of Layer 2 Virtual
Private Networks, Alex will notify Secretariat. Secretariat
to send Working Group Review Message to IETF and new-work
simultaneously with L2VPN message.
Management Issues
o Review the mechanism for call-in Ted Hardie
(discussed)
NOTE: Going forward, it was agreed that IESG members need only
notify Secretariat if he/she is either unavailable for the
upcoming telechat, or there is a change in how he/she will
connect to the call. Otherwise it will be assumed that he or
she plans to join.
1. Administrivia
o Review of Action Items
OUTSTANDING TASKS
Last updated: June 20, 2003
IP o Allison to review draft-agrawal-sip-h323-interworking-reqs
and send decision to IESG.
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 Thomas to contact Cablelabs to discuss formal relationship with IAB
IP o Allison and Thomas will email Secretariat note to send to RFC Editor
about 3GPP RFC Editor documents.
IP o Ned to write an IESG note for draft-tegen-smqp (Informational)
IP o Steve to write RFC re: TCP MD5 option
IP o Randy and Ned to finish ID on Clarifying when Standards Track Documents may
Refer Normatively to Documents at a Lower Level
IP o Alex to send proposal and justification for interim document review.
IP o Steve to generate a summary of IESG views of the "problem"
IP o Steve to propose a different document classification than the current
info/proposed/etc.
IP o Next Steps in Signaling (nsis)
Allison Mankin to submit a Revised Charter to the Secretariat. Secretariat
to send a WG Review Announcement with copy to new-work@ietf.org.
IP o Harald Alvestrand to talk to RFC Editor about independent submissions.
IP o Alex Zinin to phrase a question to RTG and OPS Area Directoriats and IAB
on PPVPN issue. Alex to summarize the results as a proposed IESG consensus
regarding the PPVPN issue to be given to the PPVPN working group.
IP o Secretariat to include teleconference bridge/call-in details in telechat
packages going forward.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Item - 1 of 1
o SDP: Session Description Protocol (Proposed Standard)
<draft-ietf-mmusic-sdp-new-13.txt>
Token: Peterson, Jon
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-mmusic-sdp-new - SDP: Session
Description Protocol to Proposed Standard
--------
Last Call to expire on: July 12, 2002
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ X ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
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>, mmusic@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: SDP: Session Description Protocol to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'SDP: Session Description
Protocol' <draft-ietf-mmusic-sdp-new-10.txt> as a Proposed Standard.
This document is the product of the Multiparty Multimedia Session
Control Working Group. The IESG contact persons are Jon Peterson and
Allison Mankin.
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?)
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 1 of 2
o The Secure Real-time Transport Protocol (Proposed Standard)
<draft-ietf-avt-srtp-08.txt>
Token: Mankin, Allison
Note: Ready for IESG review - last call comments found a few concerns with
the treatment of padding and index and these were corrected in a new rev.
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-srtp - The Secure Real-time
Transport Protocol to Proposed Standard
--------
Last Call to expire on: 2003-5-22
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ XX] [ X ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ D ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ D ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
Discuss:
=======
Steve:
SSRC should be expanded in the text the first time it's used.
The IV definition in 4.1.1 has me a bit nervous. Right now, it's
(k_s << 16) ^ (ssrc << 64) ^ (i << 16), where k_s is the session key,
ssrc is the 32-bit synchronization source, and i is the 48-bit packet
index. The low-order 16 bits are for the block number within the
packet, which is fine.
The problem I have is that given the mandated 0-padding, the high-order
32 bits of the IV are from k_s, unmodified by anything else. Furthermore
ssrc and i are known to the attacker, and the block count is obvious.
This means that the IV is a trivial function of most of the session key.
I don't *think* that that's a problem, but any extra use of keys makes me
nervous.
^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: The Secure Real-time Transport Protocol to
Proposed Standard
-------------
The IESG has approved the Internet-Draft 'The Secure Real-time
Transport Protocol' <draft-ietf-avt-srtp-08.txt> as a Proposed
Standard. This document is the product of the Audio/Video Transport
Working Group. The IESG contact persons are Allison Mankin and Jon
Peterson.
Technical Summary
This specification defines a profile for the Real-time Transport Protocol
(RTP) and Real-time Transport Control Protocol (RTCP) called the Secure
Real-time Transport Protocol (SRTP).
The security goals for SRTP are to ensure:
* the confidentiality of the RTP and RTCP payloads, and
* the integrity of the entire RTP and RTCP packets, together with
protection against replayed packets.
These security services are optional and independent from each
other, except that SRTCP integrity protection is mandatory
(malicious or erroneous alteration of RTCP messages could disrupt
the processing of the RTP stream).
Other, functional, goals for the protocol are:
* a framework that permits upgrading with new cryptographic
transforms,
* low bandwidth cost, i.e., a framework preserving RTP header
compression efficiency,
The provision of integrity is strongly recommended for most applications
of SRTP. The mandatory to implement transform for this profile is AES
counter mode, and there are risks associated with not using cryptographic
integrity with it (see Section 9.5).
Working Group Summary
The initial drafts had a default in which integrity services were not
the norm and in which SRTCP did not have mandatory integrity protection.
There was a lengthy security review to ensure that the authentication tag
is recommended to most RTP recommendations.
Protocol Quality
The specification was reviewed for the IESG by Eric Rescorla and Allison
Mankin. Implementations that tested the specification were discussed by
the working group.
2. Protocol Actions
2.1 WG Submissions
2.1.2 Returning Item - 2 of 2
o Mapping of of Integrated Services Digital Network (ISUP) Overlap Signalling
to the Session Initiation Protocol (Proposed Standard)
<draft-ietf-sipping-overlap-04.txt>
Token: Mankin, Allison
Note: New version needs review by the Discussants.á One past revision was
unclear, but this revision looks good..
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-sipping-overlap - Mapping of ISUP Overlap
Signaling to the Session Initiation Protocol to Proposed Standard
--------
Removed from draft-ietf-sipping-isup 26aug.
Last Call to expire on: August 5, 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 [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
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
=======
Steve: It says "encrypt and authenticate", but it doesn't say how. What is
mandatory to implement? More seriously, the first scenario (section 3)
describes communication from an arbitrary SIP phone to a gateway.
Since bad guys can purchase phone service as easily as good guys can
(more easily -- they can use fraudulent payment instruments...), what's
really needed is not just authentication, but authorization at the
level of individual protocol elements. Some analysis needs to be
performed about just what messages and parameters are dangerous, and I
suspect that this is the document to do it if there's no ISUP security
analysis document in ITU space. I'd be willing to accept a separate
security analysis document, but that would, I think, be a normative
reference from this document.
Section 4.4: Is [16] mandatory to implement? If not, what is?
4.5: Same sort of thing -- it says "MGCs should support ... [1]". Is
that a SHOULD? (2119 isn't invoked.) A MUST? If not, how is this
done?
draft-ietf-sipping-overlap-01.txt:
There are non-ASCII characters.
Is there any potential for denial of service from receipt of partial
numbers by either the GSTN or SIP gateways? Please clarify.
Randy: i should probably just piggyback on smb's
5. Security Considerations
No extra security risk outside these specified by [3] are
foreseen.
but [3], which refers to -02 not -04, says
In most respects, the information that is translated from ISUP
to SIP has no special security requirements. In order for
translated parameters to be used to route requests, they should
be legible to intermediaries; end-to-end confidentiality of this
data would be unnecessary and most likely detrimental. There are
also numerous circumstances under which intermediaries can
legimitately overwrite the values that have been provided by
translation, and hence integrity over these headers is similarly
not desirable.
so i am confused about the mitm situation when things are made even
more vulnerable by being chopped up in draft-ietf-sipping-overlap-01.txt
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, sipping@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: ISUP to SIP Mapping to Proposed Standard
-------------
The IESG has approved publication of the following Internet-Drafts as
Proposed Standards:
o Mapping of ISUP Overlap Signaling to the Session Initiation
Protocol <draft-ietf-sipping-overlap-01.txt>
This document is the product of the Session Initiation Proposal
Investigation Working Group. The IESG contact persons are Allison
Mankin and Scott Bradner.
Technical Summary
The "ISUP to SIP Mapping" document takes into consideration ISUP
en-bloc signalling, which means sending the complete telephone
number of the callee in the first signalling message. Although modern
switches always use en-bloc signalling, some parts of the PSTN still
use overlap signalling, and this is the subject of the second document,
"Mapping of ISUP Overlap Signaling to the Session Initial Protocol."
Overlap signalling consists of sending just some digits
of the callee's number in the first signalling message.
Further digits are sent in subsequent signalling messages.
Working Group Summary
The current version of the document reflects the issues raised during
the IETF Last Call.
Protocol Quality
This document was reviewed for the IESG by Allison Mankin.
2.2.1 New Item
NONE
2. Protocol Actions
2.2 Individual Submissions
2.2.2 Returning Item - 1 of 1
o Generating One-Time Passwords with SHA-256, SHA-384, and SHA-512 (Proposed
Standard)
<draft-nesser-otp-sha-256-384-512-02.txt>
Token: Housley, Russ
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-nesser-otp-sha-256-384-512 - AES Companion
Hash Definitions (SHA256, SHA384, SHA512) for OTP to Proposed
Standard
--------
Last Call to expire on: 2003-1-30
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ X ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ X ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Allison:
Perhaps a bad idea to have the set of home-grown definitions of MAY, SHOULD,
MUST, rather than citing RFC 2119. The definitions aren't bad, but it's not
a great precedent?
Steve:
I do not believe it's correct to refer to the new hash functions as
"AES hashes".
I have doubts about whether or nor this should be a Proposed standard.
I don't really see the need, and the document itself expresses
concerns. A longer hash is useful if more of the output is being used,
but that's not the case here.
Randy:
ops-dir comment
> 2.2 Individual Submissions
> 2.2.1 New Item
> ** o Generating One-Time Passwords with SHA-256, SHA-384, and
> SHA-512 (Proposed Standard)
> <draft-nesser-otp-sha-256-384-512-02.txt>
> Token: Housley, Russ
==> doesn't have the IPR considerations section
1.0 ABSTRACT
==> abstract is numbered.
Although the SHA-256, SHA-384 and SHA-512 alogrithms are still in their
==> s/alog/algo/
8.0 Neccessity of Implementation
==> s/cc/c/
9.0 SECURITY CONSIDERATIONS
==> some sections appear to be all-uppercase, while some are not
3.0 REQUIREMENTS TERMINOLOGY
==> any particular reason not to use RFC2119 terminology?
12.0 REFERENCES
[FIPS 180-2] Secure Hash Standard: A Revision of FIPS 180-1, August 2002
==> not split to normative/informative
==> should have a normative reference to RFC2289, at the very least!
^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: AES Companion Hash Definitions (SHA256,
SHA384, SHA512) for OTP to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Generating One-Time
Passwords with SHA-256, SHA-384, and SHA-512' <draft-nesser-otp-
sha-256-384-512-02.txt> as a Proposed Standard. The IESG contact
persons are Russell Housley and Steven Bellovin.
Technical Summary
This document describes the use of the new SHA-256, SHA-384 and
SHA-512 hash alogrithms, for use with the One Time Password (OTP)
system, as defined by RFC 2289.
Working Group Summary
This was not a the product of any IETF working group. No issues were
raised during the IETF Last Call.
Protocol Quality
This document was reviewed by Russell Housley for the IESG.
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 1 of 5
o Requirements for Distributed Control of ASR, SI/SV and TTS Resources
(Informational)
<draft-ietf-speechsc-reqts-04.txt>
Token: Peterson, Jon
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 2 of 5
o Applicability Statement for Restart Mechanisms for the Label Distribution
Protocol (Informational)
<draft-ietf-mpls-ldp-restart-applic-01.txt>
Token: Zinin, Alex
Note: Responsible: WG chairs
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 3 of 5
o Compact Forward Error Correction (FEC) Schemes (Experimental)
<draft-ietf-rmt-bb-fec-supp-compact-01.txt>
Token: Mankin, Allison
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 4 of 5
o Cross Registry Internet Service Protocol (CRISP) Requirements
(Informational)
<draft-ietf-crisp-requirements-05.txt>
Token: Freed, Ned
Note: Asked to be added to IESG agenda
3. Document Actions
3.1 WG Submissions
3.1.1 New Item - 5 of 5
o Unmanaged Networks IPv6 Transition Scenarios (Informational)
<draft-ietf-v6ops-unman-scenarios-02.txt>
Token: Bush, Randy
3. Document Actions
3.1 WG Submissions
3.1.2 Returning Item - 1 of 2
o Goals for IPv6 Site-Multihoming Architectures (Informational)
<draft-ietf-multi6-multihoming-requirements-07.txt>
Token: Bush, Randy
3. Document Actions
3.1 WG Submissions
3.1.2 Returning Item - 2 of 2
o Requirements of a QoS Solution for Mobile IP (Informational)
<draft-ietf-nsis-qos-requirements-01.txt>
Token: Mankin, Allison
Note: This document is a renaming of
draft-ietf-mobileip-qos-requirements-03.txt (expired). That document was
reviewed by IESG already and was given a go, except for lacking a Security
Consideration section, which it now has (2003-06-19).
3. Document Actions
3.2 Indiviual Submissions Via AD
3.2.1 New Item - 1 of 1
o URI Scheme for the TFTP Protocol (Informational)
<draft-lear-tftp-uri-06.txt>
Token: Hardie, Ted
3.2.2 Returning Item
NONE
3. Document Actions
3.3 Indiviual Submissions Via RFC Editor
3.3.1 New Item - 1 of 2
o The Media Gateway Control Protocol (MGCP) Bulk Audit Package
(Informational)
<draft-foster-mgcp-bulkaudits-09.txt>
Token: Peterson, Jon
3. Document Actions
3.3 Indiviual Submissions Via RFC Editor
3.3.1 New Item - 2 of 2
o .sex Considered Dangerous (Informational)
<draft-eastlake-xxx-06.txt>
Token: Alvestrand, Harald
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4. Working Group Actions
4.1 WG Creation
4.1.2 Proposed for Approval
o Layer 3 Virtual Private Networks - 1 of 3
Token: Thomas
Layer 3 Virtual Private Networks (l3vpn)
-----------------------------------------
Charter
Last Modified: 2003-06-12
Current Status: Proposed Working Group
Chair(s):
<under discussion>
Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <nordmark@sun.com>
Area Advisor:
Thomas Narten <narten@us.ibm.com>
Technical Advisor:
Alex Zinin <zinin@psg.com>
Mailing Lists:
General Discussion: l3vpn@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/l3vpn
Archive: https://www1.ietf.org/mail-archive/working-groups/l3vpn/current/maillist.html
Description of Working Group:
Alex is the routing advisor.
This working group is responsible for defining and specifying a
limited number of solutions for supporting provider-provisioned
Layer-3 (routed) Virtual Private Networks (L3VPNs).
The WG is responsible for standardization of the following solutions:
1. BGP/MPLS IP VPNs (based on RFC 2547)
2. IP VPNs using Virtual Routers
3. CE-based VPNs using IPSEC
The following VPN deployment scenarios will be considered by the WG:
1. Internet-wide: VPN sites attached to arbitratry points in
the Internet
2. Single SP/single AS: VPN sites attached to the network of a
single provider within the scope of a single AS
3. Single SP/multiple AS'es: VPN sites attached to the network
of a single provider consisting of multiple AS'es
4. Cooperating SPs: VPN sites attached to networks of different
providers that cooperate with each other to provide VPN service
As part of this effort the WG will work on the following tasks
(additional work items will require rechartering):
1. Requirements and framework for Layer 3 VPNs
2. Solution documents for each approach listed above (including
applicability statements)
3. MIB definitions for each approach
4. Security mechanisms for each approach
As a general rule, the WG will not create new protocols, but will provide
functional requirements for extensions of the existing protocols that will
be discussed in the protocol-specific WGs. L3VPN WG will review proposed
protocol extensions for L3VPNs before they are recommended to appropriate
protocol-specific WGs.
Multicast and QoS support are excluded from the charter at this time.
They may be considered for inclusion in an updated charter
at a later time. Future work items may also include OAM support.
WG Milestones (optimistic):
Dec 2002 Submit L3 VPN Requirements Document to IESG for publication as Info
(completed)
Dec 2002 Submit Generic Requirements Document to IESG for publication as Info
(completed)
Dec 2002 Submit L3 VPN Framework Document to IESG for publication as Info
(completed)
Dec 2003 Submit VPN Security Analysis to IESG for publication as Info
(draft-fang-ppvpn-security-framework-00)
Dec 2003 Submit BGP/MPLS VPNs specification and AS to IESG for
publication as PS
(draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01)
Dec 2003 Submit CE-based specification and AS to IESG for publication as PS
(draft-ietf-ppvpn-ce-based-03)
(draft-declercq-ppvpn-ce-based-sol-00)
(draft-declercq-ppvpn-ce-based-as-01)
Dec 2003 Submit Virtual Router specification and AS to IESG for publication as PS
(draft-ietf-ppvpn-vpn-vr-03, draft-ietf-ppvpn-as-vr-01)
Jan 2004 Submit VPN MIB Textual Conventions to IESG for publication as PS
(draft-ietf-ppvpn-tc-mib-02)
Jan 2004 Submit MPLS/BGP VPN MIB to IESG for publication as PS
(draft-ietf-ppvpn-mpls-vpn-mib-05)
Jan 2004 Submit VR MIB to IESG for publication as PS
(draft-ietf-ppvpn-vr-mib-04)
Jan 2004 Submit BGP as an Auto-Discovery Mechanism for publication as PS.
(draft-ietf-ppvpn-bgpvpn-auto-05.txt)
March 2004 Submit specification of using IPSEC for PE-PE encapsulation in BGP/MPLS VPNs to IESG
for publication as PS
(draft-ietf-ppvpn-ipsec-2547-03)
March 2004 Submit specification of using GRE for PE-PE encapsulation in BGP/MPLS VPNs to IESG
for publication as PS
(draft-ietf-ppvpn-gre-ip-2547-02)
March 2004 Submit specification of BGP-MPLS VPN extension for IPv6 VPN to IESG for publication as PS
(draft-ietf-ppvpn-bgp-ipv6-vpn-03)
o Path Maximum Transmission Unit Discovery - 2 of 3
Path Maximum Transmission Unit Discovery (pmtud)
------------------------------------------------
Charter
Last Modified: 2003-06-06
Current Status: Proposed Working Group
Chair(s):
Matt Mathis <mathis@psc.edu>
TBD
Transport Area Directors(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing List (temporary):
General Discussion: mtu@psc.edu
Subscribe: majordomo@psc.edu with "subscribe mtu" in the body
Archive: http://www.psc.edu/~mathis/MTU/mbox.txt
(This is to be moved to the IETF as soon as chartered).
Description of Working Group:
The goal of the PMTUD working group is to specify a robust method for
determining the IP Maximum Transmission Unit supported over an
end-to-end path. This new method is expected to update most uses of
RFC1191 and RFC1981, the current standards track protocols for this
purpose. Various weakness in the current methods are documented in
RFC2923, and have proven to be a chronic impediment to the deployment
of new technologies that alter the path MTU, such as tunnels and new
types of link layers.
The proposed new method does not rely on ICMP or other messages from
the network. It finds the proper MTU by starting a connection using
relatively small packets (e.g. TCP segments) and searching upwards by
probing with progressively larger test packets (containing application
data). If a probe packet is successfully delivered, then the path MTU
is raised. The isolated loss of a probe packet (with or without an
ICMP can't fragment message) is treated as an indication of a MTU
limit, and not a congestion indicator.
The working group will specify the method for use in TCP, SCTP, and
will outline what is necessary to support the method in transports
such as DCCP. It will particularly describe the precise conditions
under which lost packets are not treated as congestion indications.
The work will pay particular attention to details that affect
robustness and security.
Path MTU discovery has the potential to interact with many other parts
of the Internet, including all link, transport, encapsulation and
tunnel protocols. Thereforethis working group will particularly
encourage input from a wide cross section of the IETF to help to
maximize the robustness of path MTU discovery in the presence of
pathological behaviors from other components.
Input draft:
Packetization Layer Path MTU Discovery
draft-mathis-plpmtud-00.txt
Goals and Milestones:
Jul 03 Reorganized Internet-Draft. Solicit implementation and field experience.
Dec 03 Update Internet-Draft incorporating implementers experience,
actively solicit input from stakeholders - all communities that might
be affected by changing PMTUD.
Feb 04 Submit completed Internet-draft and a PMTUD MIB draft for
Proposed Standard.
o Layer 2 Virtual Private Networks - 3 of 3
Token: Thomas
Layer 2 Virtual Private Networks (l2vpn)
-----------------------------------------
Charter
Last Modified: 2003-06-17
Current Status: Proposed Working Group
Chairs: <under discussion>
Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <nordmark@sun.com>
Area Advisor:
Thomas Narten <narten@us.ibm.com>
Technical Advisor:
Alex Zinin <zinin@psg.com>
Russ Housley <housley@vigilsec.com>
Mailing Lists:
General Discussion: l2vpn@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/l2vpn
Archive: https://www1.ietf.org/mail-archive/working-groups/l2vpn/current/maillist.html
Description of Working Group:
Alex is the routing advisor.
Russ is the security advisor.
This working group is responsible for defining and specifying a
limited number of solutions for supporting provider-provisioned
layer-2 virtual private networks (L2VPNs).
The WG is responsible for standardization of the following solutions:
1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN
across an IP and an MPLS-enabled IP network, allowing standard
Ethernet devices communicate with each other as if they were
connected to a common LAN segment.
2. Virtual Private Wire Service (VPWS)--L2 service that provides L2
point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI,
point-to-point Ethernet) across an IP and an MPLS-enabled IP network.
3. IP-only L2 VPNs--L2 service across an IP and an MPLS-enabled
IP network, allowing standard IP devices to communicate with each
other as if they were connected to a common LAN segment or a point-
to-point circuit.
The WG will address intra-AS scenarios only at this point (other
scenarios will be considered for inclusion in the updated charter when
the current one is completed.)
As a general rule, the WG will not create new protocols, but will
provide functional requirements for extensions of the existing
protocols that will be discussed in the protocol-specific WGs.
As a specific example, this WG will not define new encapsulation
mechanism, but will use those defined in the PWE3 WG.
L2VPN WG will review proposed protocol extensions for L2VPNs before
they are recommended to appropriate protocol-specific WGs.
The WG will work on the following items. Adding new work items
will require rechartering.
1. Discovery of PEs participating in L2 service, and
topology of required connectivity
2. Signaling of l2vpn related information for the purpose of
setup and maintenance of l2vpn circuits. As much as possible
PWE3 signaling procedures should be used
3. Solution documents (providing the framework for a specific
solution, should include info on how discovery, signaling,
and encaps work together, include security, AS as a separate
document)
4. MIBs
5. L2VPN-specific OAM extensions--extensions to existing OAM
solutions for VPLS, VPWS, and IP-only L2VPNs.
Where necessary, the WG will coordinate its activities with IEEE 802.1
Milestones (optimistic):
JUL 2003 Submit L2 requirements to IESG for publication as Informational RFC
JUL 2003 Submit L2 framework to IESG for publication as Informational RFC
JUL 2003 Identify VPLS and VPWS solutions for the WG
AUG 2003 Submit an I-D describing MIB for VPLS
AUG 2003 Submit an I-D describing MIB for VPWS
AUG 2003 Submit an I-D on OAM for VPLS
AUG 2003 Submit an I-D on OAM for VPWS
DEC 2003 Submit VPLS solution documents to IESG
DEC 2003 Submit VPWS solution documents to IESG
JAN 2004 Submit IP-only L2VPN solution documents to IESG
FEB 2004 Submit MIB for VPLS to IESG
MAR 2004 Submit OAM for VPWS to IESG
APR 2004 Submit OAM for IP L2VPN to IESG
4. Working Group Actions
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
NONE
4. Working Group Actions
4.2 WG Rechartering
4.2.2 Proposed for Approval
NONE
5. Working Group News We Can Use
Harald Alvestrand
Steve Bellovin
Randy Bush
Bill Fenner
Ned Freed
Ted Hardie
Russ Housley
Allison Mankin
Thomas Narten
Erik Nordmark
Jon Peterson
Bert Wijnen
Alex Zinin
6. IAB News We Can Use
7. Management Issues