[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Agenda and Package for June 12, 2003 Telechat (Final)
INTERNET ENGINEERING STEERING GROUP (IESG)
Agenda for the June 12, 2003 IESG Teleconference
1. Administrivia
o Roll Call
Harald Alvestrand---Will call in*
Rob Austein---Will call in
Steve Bellovin---Regrets
Randy Bush---+81-3 3287 2921 Room 1415*
Michelle Cotton---Will call in*
Leslie Daigle---Will call in*
Dinara Suleymanova---Will call in*
Bill Fenner---Regrets
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---Regrets
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*
o Bash the Agenda
o Approval of the Minutes
- May 29, 2003
o Review of Action Items
OUTSTANDING TASKS
Last updated: June 10, 2003
DONE o Alex to send RFC Editor Note for draft-ietf-ppvpn-framework-08.txt
addressing Bert's and Ted's concerns.
DONE o Alex will notify Secretariat once ok to announce
draft-ietf-ipo-framework-04.txt
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 Ted to write straw working group procedures for handling consensus-blocked
decisions
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 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.
IP o Collective Attributes in LDAP (Proposed Standard)
<draft-zeilenga-ldap-collective-08.txt>.
Under discussion by Steve Bellovin and Russ Housley.
o Harald Alvestrand to talk to RFC Editor about independent submissions.
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 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.
o IESG to review IANA matrix data.
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.txt>
Token: Housley, Russ
- Transporting S/MIME Objects in X.400 (Proposed Standard)
<draft-ietf-smime-x400transport-07.txt>
o Mobility Support in IPv6 (Proposed Standard)
<draft-ietf-mobileip-ipv6-22.txt>
Token: Narten, Thomas
Note: On agenda to flush out discuss comments.
o Definitions of Managed Objects for the Ethernet-like Interface
Types (Proposed Standard)
<draft-ietf-hubmib-etherif-mib-v3-03.txt>
Token: Wijnen, Bert
Note: Requested to go on IESG agenda on June 12th.
Responsible: bwijnen/iesg
- Definitions of Managed Objects for IEEE 802.3 Medium
Attachment Units (MAUs) (Proposed Standard)
<draft-ietf-hubmib-mau-mib-v3-04.txt>
- Definition of Managed Objects for the Ethernet WAN Interface
Sublayer (Proposed Standard)
<draft-ietf-hubmib-wis-mib-07.txt>
- Applicability Statement for Reclassification of RFC 1643 to
Historic Status (Informational)
<draft-ietf-hubmib-1643-to-historic-01.txt>
o Multi Protocol Label Switching Label Distribution Protocol
Query Message Description (Proposed Standard)
<draft-ietf-mpls-lsp-query-06.txt>
Token: Zinin, Alex
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.
o An Extension to the Session Initiation Protocol (SIP) for
Symmetric Response Routing (Proposed Standard)
<draft-ietf-sip-symmetric-response-00.txt>
Token: Mankin, Allison
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>
Token: Bush, Randy
o PacketCable Security Ticket Control Sub-option for the
CableLabs Client Configuration Option (Proposed Standard)
<draft-ietf-dhc-pktc-kerb-tckt-02.txt>
Token: Narten, Thomas
Note: 2003-04-22: sent small set of comments to list, but
started IETF LC.
o Remote Network Monitoring MIB Protocol Identifier Reference
(Draft Standard)
<rfc2895.txt>
Token: Wijnen, Bert
Note: On IESG agenda for June 12th. Responsible: bert/iesg
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>
Token: Narten, Thomas
Note: On agenda to flush out discuss comments.
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
2.2.2 Returning Item
o Registration procedures for message header fields (BCP)
<draft-klyne-msghdr-registry-06.txt>
Token: Freed, Ned
Note: Writeup submitted; asked to have on IESG agenda
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>
Token: Fenner, Bill
o Introduction to the Remote Monitoring (RMON) Family of MIB
Modules (Informational)
<draft-ietf-rmonmib-framework-05.txt>
Token: Wijnen, Bert
Note: Now on IESG agenda for June 12th. Responsible: Bert/IESG
o Goals for IPv6 Site-Multihoming Architectures (Informational)
<draft-ietf-multi6-multihoming-requirements-06.txt>
Token: Bush, Randy
o Transition Scenarios for 3GPP Networks (Informational)
<draft-ietf-v6ops-3gpp-cases-03.txt>
Token: Bush, Randy
o Guidelines for Extending the Extensible Provisioning Protocol
(Informational)
<draft-ietf-provreg-epp-ext-03.txt>
Token: Hardie, Ted
o Border Gateway Multicast Protocol (BGMP): Protocol
Specification (Informational)
<draft-ietf-bgmp-spec-05.txt>
Token: Zinin, Alex
3.1.2 Returning Item
o SDPng Transition (Informational)
<draft-ietf-mmusic-sdpng-trans-04.txt>
Token: Peterson, Jon
Note: Roadmap document explaining relation of various
extensions of SDP such as offer-answer and fid to the SDPng
work.
3.2 Indiviual Submissions Via AD
3.2.1 New Item
o The QCP File Format and Associated Media Types (Informational)
<draft-gellens-qcp-01.txt>
Token: Mankin, Allison
Note: This documents a storage format for QCELP audio - it is
time-sensitive to 3GPP2, which needs it for the streaming
applications of the EVRC and SMV vocoders. It was discussed by
the AVT Working Group, which published its own storage format
for data from those vocoders, but agreed this one, with a
distinct name, was equally publishable.
3.2.2 Returning Item
NONE
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>
Token: Zinin, Alex
o Guidelines for MPLS Load Balancing (Informational)
<draft-allan-mpls-loadbal-04.txt>
Token: Zinin, Alex
3.3.2 Returning Item
o Basic MGCP Packages (Informational)
<draft-foster-mgcp-basic-packages-10.txt>
Token: Mankin, Allison
Note: This was on the agenda before and I held it because of
concerns over its use of IETF protocols - I want to clear it
and have it approved with an IESG note, having completed
review.
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Layer 2 Virtual Private Networks
Token: Thomas
o Path Maximum Transmission Unit Discovery
Token: Allison
o Layer 3 Virtual Private Networks
Token: Thomas
4.1.2 Proposed for Approval
NONE
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
o review the mechanism for call-in.
Proposal: adjust system so that call
participants notify secretary of changes needed (different
number, not able to attend), but otherwise assume
steady state.
-Ted
INTERNET ENGINEERING STEERING GROUP (IESG)
May 29, 2003
Reported by: Dinara Suleymanova, IETF Secretariat
ATTENDEES
---------
Harald Alvestrand / Cisco
Rob Austein / IAB Liaison
Marcia Beaulieu / IETF Secretariat
Steve Bellovin / AT&T Labs
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.
Russ Housley / Vigil Security, LLC
Allison Mankin / Bell Labs, Lucent
Jon Peterson / NeuStar, Inc.
Dinara Suleymanova / IETF Secretariat
Bert Wijnen / Lucent
Alex Zinin / Alcatel
REGRETS
---------
Jacqueline Hargest / IETF Secretariat
Thomas Narten / IBM
Erik Nordmark / Sun
Joyce K. Reynolds / ISI (RFC Editor)
Minutes
--------
1. The minutes of the May 15, 2003 teleconference were approved.
The Secretariat to place in public archives.
2. Review Action Items
DONE TASKS:
o Secretariat to send ldup WG Action/Re-charter announcement to IAB, IESG, WG Chairs.
If nothing happens, in one week Ted will ask Secretariat to announce.
o After netconf WG Chairs are approved, Bert will ask Secretariat to send WG Action
to ietf-announce, cc: WG Chairs.
o Secretariat to send mmusic charter (WG Re-charter) to ietf-announce and new-work.
o Secretariat to send IESG a list of groups with whom we need to avoid meeting conflicts
when scheduling IETF conferences.
o Alex to send RFC Editor Note for draft-ietf-ppvpn-framework-08.txt addressing
Bert's and Ted's concerns.
o Secretariat to include IESG note in announcement for draft-ogura-ipv6-mapos-02.txt
o Secretariat to include new RFC Editor Note in announcement for
draft-murchison-sieve-subaddress-06.txt
o Secretariat to send internal Working Group Review message for simple WG
o Alex to send DNP message for draft-srisuresh-ospf-te-05.txt to Secretariat to send
on behalf of IESG.
o Alex will notify Secretariat once ok to announce draft-ietf-ipo-framework-04.txt
(removed)
OUTSTANDING TASKS:
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 Ted to write straw working group procedures for handling consensus-blocked decisions
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.
NEW TASKS:
o Harald Alvestrand to talk to RFC Editor about independent submissions.
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 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.
o IESG to review IANA matrix data.
2. Protocol Actions
2.1. WG Submissions
2.1.1. New Item
o RTCP attribute in SDP (Proposed Standard)
<draft-ietf-mmusic-sdp4nat-04.txt>
Token: Peterson, Jon
Approved pending RFC Editor's Note to be prepared by
Jon Peterson with authors' permission.
Secretariat to send Protocol Action Announcement including RFC Editor's Note.
o Registration Revocation in Mobile IPv4 (Proposed Standard)
<draft-ietf-mobileip-reg-revok-07.txt>
Token: Narten, Thomas
Approved pending RFC Editor's Note to be prepared by Steve Bellovin.
Secretariat to send Protocol Action Announcement including RFC Editor's Note.
o Textual Conventions for IPv6 Flow Label (Proposed Standard)
<draft-ietf-ops-ipv6-flowlabel-01.txt>
Token: Bush, Randy
Approved.
Secretariat to send Protocol Action Announcement.
2.1.2. Returning Item
NONE
2.2. Individual Submissions
2.2.1. New Item
o Printer MIB v2 (Proposed Standard)
<draft-ietf-printmib-mib-info-15.txt>
Token: Freed, Ned
Approved.
Secretariat to send Protocol Action Announcement.
o Registration procedures for message header fields (BCP)
<draft-klyne-msghdr-registry-06.txt>
Token: Freed, Ned
Deferred by Harald Alvestrand, Allison Mankin, Jon Peterson.
Secretariat to put on the agenda for the next telechat on June 12, 2003.
o Delegation of E.F.F.3.IP6.ARPA (BCP)
<draft-ymbk-6bone-arpa-delegation-01.txt>
Token: Narten, Thomas
Approved.
Secretariat to send Protocol Action Announcement.
2.2.2. Returning Item
o Collective Attributes in LDAP (Proposed Standard)
<draft-zeilenga-ldap-collective-08.txt>
Token: Hardie, Ted
Under discussion by Steve Bellovin and Russ Housley.
3. Document Actions
3.1. WG Submissions
3.1.1. New Item
o IS-IS Cryptographic Authentication (Informational)
<draft-ietf-isis-hmac-04.txt>
Token: Zinin, Alex
Note: Responsible: Author
Approved.
Secretariat to send Document Action Announcement.
o Multicast Source Discovery Protocol (MSDP) (Experimental)
<draft-ietf-msdp-spec-20.txt>
Token: Zinin, Alex
Approved pending RFC Editor's Note to be prepared by Alex Zinin.
Secretariat to send Document Action Announcement including RFC Editor's Note.
3.1.2. Returning Item
NONE
3.2. Indiviual Submissions Via AD
3.2.1. New Item
o Printer Finishing MIB (Informational)
<draft-ietf-printmib-finishing-16.txt>
Token: Freed, Ned
Note: Four week last call requested
Approved pending RFC Editor's Note to be prepared by Ned Freed.
Secretariat to send Document Action Announcement including RFC Editor's Note.
o IANA Charset MIB (Informational)
<draft-mcdonald-iana-charset-mib-02.txt>
Token: Freed, Ned
Note: Four week last call requested
Under discussion by Ted Hardie (for Michelle Cotton).
Secretariat to put on the agenda for the next telechat on June 12, 2003,
if not approved prior to that date.
3.2.2. Returning Item
o RADIUS Support For Extensible Authentication Protocol (EAP) (Informational)
<draft-aboba-radius-rfc2869bis-22.txt>
Token: Bush, Randy
Approved.
Secretariat to send Document Action Announcement.
Randy Bush to prepare a note for the minutes regarding why this document
is not in the Standards Track.
NOTE: RFCs 1321 and 2104 define a cryptographic algorithms. We have agreed that
it is okay to reference such documents. So, only the 1st and 3rd bullets
seem relevant.
The document draft-aboba-radius-rfc2869bis-22.txt is informational
as opposed to standards track because
o a standards track document may not make normative reference
to a document at a 'lesser' status
o draft-aboba-radius-rfc2869bis-22.txt has normative references
to rfcs 1321 and 2104, both of which are informational
o it also makes inescapable normative reference to
draft-chiba-radius-dynamic-authorization-20.txt, which will
be informational.
3.3. Indiviual Submissions Via RFC Editor
3.3.1. New Item
o Developing High Quality SNMP Agents (Informational)
<draft-aromanov-snmp-hiqa-04.txt>
Token: Wijnen, Bert
Note: On IESG agenda for 29 May
The document is not in conflict with IETF work. Bert Wijnen to prepare
a replacement message for Secretariat to send to RFC Editor.
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
NONE
4.2. WG Rechartering
4.2.1. Under evaluation for IETF Review
o Next Steps in Signaling
Token: Mankin, Allison
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 SIP for Instant Messaging and Presence Leveraging Extensions
Token: Hardie, Ted
SIP for Instant Messaging and Presence Leveraging Extensions (simple)
Approved.
Secretariat to send a WG Action: RECHARTER Announcement.
4.2.2. Proposed for Approval
o IP Telephony
Token: Peterson, Jon
Note: under discussion
IP Telephony (iptel)
Approved.
Secretariat to send a WG Action: RECHARTER Announcement.
5. Working Group News We Can Use
5.1. WG Closing
o Content Distribution Internetworking (cdi)
Token: Hardie, Ted
Approved.
Ted Hardie to send a note for the minutes documenting why the IESG
chose to close the WG while some documents are in RFC Editor's Queue. Ted to prepare
the WG Action: WG to Conclude Announcement for the Secretariat to send.
NOTE: Ted Hardie, Area Advisor for the CDI working group, asked that
the IESG agree to close this group. Historically, working groups
have not closed while they have documents active in the RFC editor's
queue. This group does have two informational documents still
in the that queue. Ted asked for a variance from that
precedent in this case, as the working group has ceased to serve
as a viable forum for discussion of these issues; any issues raised
by the RFC editor will need to be handled by the editors. Further,
the documents at issue are not protocol standards, as they
provide a set of scenarios and an abstract model. The IESG agreed
to the closure of the group, pending a note drafting the reasoning for
this being included in the working group closure notice. Ted agreed
to draft that note and send it to the Secretariat for the closure notice.
Separately, the IESG agreed that a more definite set of procedures
for working group closure is needed. Allison and Ted
volunteered to send draft text to Harald for inclusion in his
procedures draft.
6. IAB News We Can Use
7. Management Issues
o DNP - Harald Alvestrand
(skipped)
o Review criteria for independent submissions - Harald Alvestrand
(discussed)
o Does ballot text need a change - Bert Wijnen
(discussed)
o PPVPN Issue - added by Alex Zinin
(discussed)
o IANA Matrix Data - added by Michelle Cotton
(discussed)
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-smime-x400wrap - Securing X.400 Content
with S/MIME to Proposed Standard
--------
Last Call to expire on: November 20, 2001
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
=======
Steve:
The Security Considerations section of both documents is inadequate.
(The phrase "the entire document is about security" is almost as bad as
"security is not discussed".) Are there new security issues raised by
this? If so, outline them. If not, say that, explicitly. The
pointers to the other documents are fine. If the new text is simple
enough, it can be inserted via an RFC Editor's note.
Why isn't AES listed, at least as a SHOULD?
COMMENTS:
========
Ted:
2.6.1--->"because those type do not" has subject/verb agreeement problem.
2.6.2-----> "A RecipeintInfo" should be "RecipientInfo".
3.2----->"whatever gateway system that is bridging" seems grammatically wrong.
3.2.1---->"since it is out" should be "since it is outside"?
3.3----->"If other binary transport" should "If another binary"?
3.3.1------> "it is out" again, outside?
3.4.1---> "7-bit transport, is optional" spurious comma.
3.4.1--->"certs-only, which is only for signed)" seems to be missing a noun.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>,
ietf-smime@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Securing X.400 Content with S/MIME to
Proposed Standard
-------------
The IESG has approved publication of the following Internet-Drafts as
Proposed Standards:
o Securing X.400 Content with S/MIME
<draft-ietf-smime-x400wrap-06.txt>
o Transporting S/MIME Objects in X.400
<draft-ietf-smime-x400transport-07.txt>
These documents are the product of the S/MIME Working Group. The IESG
contact persons are Russell Housley and Steven Bellovin.
Technical Summary
These documents describe the use of the S/MIME security mechanisms in
an X.400 messaging environment.
"Securing X.400 Content with S/MIME" describes the use of the
Cryptographic Message Syntax (CMS) to digital signature and encryption
services to X.400 content.
"Transporting S/MIME Objects in X.400" describes protocol options for
conveying CMS-protected objects associated with S/MIME version 3 over
an X.400 message transfer system.
Working Group Summary
The S/MIME Working Group came to consensus on this document.
Protocol Quality
This document was reviewed by Jeff Schiller and Russell Housley for the IESG.
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-mobileip-ipv6 - Mobility Support in
IPv6 to Proposed Standard
--------
Last Call to expire on: 2003-2-6
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
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
=======
Steve:
For a spec of this length, complexity, and security sensitivity, I'm
remarkably happy with it. I have some issues, but I suspect that most
can be resolved pretty easily. It was a delight to be able to delete
some of my notes as I progressed through the document. Furthermore,
given the length and complexity of the spec, I could easily be wrong
about many of these points. I'd be delighted if that were the case.
5.1 In my opinion, IKE support should be a SHOULD, not a MAY. I
have problems with the replay protection (see below).
5.2.5 The figure shows the Home Test Init message going from the
mobile->home agent->correspondent. The text says that
it goes from the mobile->correspondent. Which is it?
There are a number of HMAC'd fields floating around. Some, at
least, seem to have a distinguishing type value, such as 0 in
the home keygen token. The Binding Update takes a parameter
with a BU in the last byte. Is that intended to serve the same
purpose? I don't see a value for BU defined anywhere -- is that
the '5' in Section 14? If so, the 0 and 1 shouldn't overlap
that type space, and there should be an explicit statement about
the reserved values in Section 14, so that no future IANA
assignments conflict with them. I'd also like the authors to
verify that all HMAC'd fields have such such type code that is
never used elsewhere.
6.1.7 The text here (and in 6.1.8 and 6.1.9) should note that the
authorization option is mandatory. It says so later, but not
that clearly.
6.2.6 Should Mobility Data include the home address? The option
doesn't seem to protect other data, including things like
lifetime, sequence #, etc.
7.5 Those advertisement frequencies scare me -- they're quite high.
Worse yet, the most likely place they're needed -- microcells --
have limited bandwidth.
7.6 Which link is this link-local local to? The home network?
9.5.1 If there's no IPsec-level replay protection, this sequence number
just won't do the trick. A wireless mobile node could very
easily generate enough binding updates per day that an enemy
could replay old ones that appeared to be in the window.
10.3.1 Has the IPsec wg verified that K=1 really works? I'm not
convinced of it, since some cookies are address-dependent.
Beyond that, the SPD and the SADB will need to change as the
source and destination IP addresses change.
10.4.5 In the absence of ESP -- and why would it be omitted? --
how can the home agent reliably verify that the source address
in the tunnel IP header is legitimate? I'd say that reverse-
tunneled packets MUST be discard unless ESP-protected. (I'm
astonished that it isn't even a SHOULD.)
11.3.5 Should some sort of timeout be associated with the fact that
a certain destination address can't accept Mobility Headers?
11.7.2 Same comment about sequence number processing
Erik:
I'd like to finish reading it thus I have both a discuss and a
defer :-)
Comments on draft-ietf-mobileip-ipv6-21.txt
I've so far only read about half the spec, but overall, especially
given its size, it looks very well written. (I was expecting to see
lots of inconsistencies but find very few.)
Substantial:
Section 2:
o The movement detection mechanism in Mobile IPv6 provides
bidirectional confirmation of a mobile node's ability to
communicate with its default router in its current location.
But this is not sufficient when there are more than one router
on the visited link. In many cases each of those routers will
be used to forward inbound packets towards the MNs COA.
Thus the fact that the MN knows that it has bidirectional
connectivity with one router on the link is no guarantee for it to be
able to communicate when there are more than one router on the link.
So unless the purpose of this detection in section 11.5.1
is to provide an indication to the MN to do a handover to a different
link I don't see the benefit of this.
The mechanism adds complexity to the notion of reachability beyond
what is done in RFC 2461.
I haven't seen any discussion of the duplicate address detection
changes in section 7.6 in the IPv6 WG.
While these changes seem harmless I'm concerned about them being
included in such a huge specification which makes them less likely
to receive careful review. Can't this be handled separately by a
small specification?
Minor:
The abstract and introduction have text of the flavour:
This document specifies the operation of the IPv6 Internet with
mobile computers.
I think the scope of the specification is quite narrower for instance
it doesn't specify any operational procedures for the Internet.
I think it is more accurate to say e.g.
This document specifies a protocol which allows IPv6 nodes
to move around in the Internet while remaining reachable at
a fixed IPv6 address.
It makes sense to make it more clear that the specification doesn't
prevent a MN from having multiple home addresses.
I suggest clarifying this in the definitions section by:
home address
A unicast routable address assigned to a mobile node, used as
the permanent address of the mobile node. This address is within
the mobile node's home link. Standard IP routing mechanisms will
deliver packets destined for a mobile node's home address to its
home link.
ADD When there are multiple home prefixes on the home link the mobile
node will have multiple home addresses.
care-of address
A unicast routable address associated with a mobile node while
visiting a foreign link; the subnet prefix of this IP address is
a foreign subnet prefix. Among the multiple care-of addresses
that a mobile node may have at any given time (e.g., with
different subnet prefixes), the one registered with the mobile
node's home agent is called its "primary" care-of address.
Change "home agent" to "home agent for a given home address".
Section 5.2.5 says:
For
improved security, the data passed between the home agent and the
mobile node can be made immune to inspection and passive attacks.
Such protection can be gained by encrypting the home keygen token
as it is tunneled from the home agent to the mobile node as
specified in Section 10.4.6.
which reads like an optional thing
but in 10.4.6 the support for this is mandatory.
Suggest rewording the above by s/can be/is/ in two places in the text.
Section 7.2 and 7.5 are inconsistent.
The former says that routers MAY and the latter says they SHOULD
include at least one R-bit prefix.
Nits:
The document uses the term "byte" about 5 times, and otherwise uses
"octet". Why not use "octet" throughout?
The definition of "registration" vs. "binding procedure" seem
confusing. Are they intended to mean exactly the same thing or
something slightly different? Perhaps the term "registration" isn't
needed or the relationship between the terms can be clarified somehow.
Section 4.1 says:
Mobile IPv6 also provides support for multiple home agents, and
the reconfiguration of the home network.
Given that the security aspects of renumbering the home link are not
worked out it makes sense to tone down the language somehow.
Section 4.2 says:
These four messages are used to initiate the return
routability procedure from the mobile node to a correspondent
node.
I thought "perform" would be more accurate than "initiate"
since the 4 messages is the entirety of the RR procedure, right?
Section 4.2:
Binding Refresh Request
A Binding Refresh Request is used to request a mobile node to
re-establish its binding with the correspondent node.
Hard for a new reader to understand that only CN send BRs (and not
e.g. a HA). Change "used" to "used by a correspondent node".
Section 4.6:
Mobile nodes may not be aware of which site they are currently on, it
s/on/in/
Section 6.7 doesn't state whether or not ICMP Mobile Prefix
Solicitation Messages can carry options. I think RFC 2461 router
solicitations can which is why I think it makes sense to be explicit
on this point.
It would be useful to state in section 6.7 and 6.8 respectively
that these are just slightly modified router solicitation and
router advertisement messages to make it more obvious
that they use the RFC 2461 option format etc.
Erik:
> 6.1.7 The text here (and in 6.1.8 and 6.1.9) should note that the
> authorization option is mandatory. It says so later, but not
> that clearly.
I think it is only mandatory for BUs to a correspondent - BUs to
a home agent are protected with IPsec.
Erik
Erik:
Here are the comments to add to my previous set of discuss comments.
Erik
Major issue:
------------
Section 11.3.1 says that one of the mobile node's care of addresses
is good enough as a source when sending packets with a HAO.
This isn't correct since the CN will verify that the source address
is exactly the CoA that the CN has in its BCE. Thus the requirement
for the sending is to use the CoA contained in the binding update
list and no other CoA.
The same issue appears in 11.3.2 where it says:
destination option into the packet, replacing the Source
Address in the packet's IP header with a care-of address
suitable for the link on which the packet is being sent,
as described in Section 11.3.1.
"with the care-of address used with this correspondent" is better once
11.3.1 has been fixed.
Minor issues:
-------------
Section 8.2 has a MUST for an administrative knob. We try to avoid
mandating knobs to make it easier to implement small devices.
Could this be a SHOULD instead?
Section 9.1. says:
Destination Cache [12]. That is, any Binding Cache entry for
this destination SHOULD take precedence over any Destination
Cache entry for the same destination.
I don't think "precedence" is the best way to describe this.
The binding cache provides information that a routing header be added,
but the destination cache is still consulted e.g. for path MTU
information. (In fact, when the CoA changes it would presumably be
useful to carry the path MTU from the destination cache entry for the
old CoA to the destination cache entry for the new CoA since it is
likely to be a more robust starting point than using the interface
MTU on the correspondent.)
Section 9.3.4 says that the BCE SHOULD be deleted due to ICMP errors.
But packets with HAO can continue to arrive which will cause a Binding
Error. It makes sense to point out this downside in this section and
leave the SHOULD in place.
Section 9.4.3 talks about avoiding route optimization for HOT messages,
but there is no corresponding text about avoiding using HOA for HOTI
messages in section 11.
Is there something generic which can be said about applying HOA and RH
type 2 to MH messages? I think the only case where RH type 2 makes
sense and should be allowed is for a bind ack when the BU was
succesful. If there isn't a generic rule that can be applied perhaps
text should be added in section 6 for the different MH types e.g.
A HOT message is never sent using RH type 2 even if
there is an existing binding, and HOA is never applied
to a HOT message since HOT messages bypass the binding
update list; in essence route optimization MUST NOT be
applied to HOT messages.
and similarly for COT, HOTI, COTI, BU, and perhaps others.
That way the specific text in 9.4.3 can be removed and there isn't
need to add text elsewhere in section 9 or 11.
Does it make sense to explicitly state that RH type 2 and HAO must
never be applied to Neighbor Discovery packets? Or packets local to a
link in general?
Section 9.5.1 says:
o If the Alternate Care-of Address option is present, the care-of
address is the address in that option.
[...]
o Otherwise, the home address is the Source Address field in the
packet's IPv6 header. This implies that the mobile node is at
home and is about to perform de-registration.
The last sentence implicitly states that sending a BU with alt-coa and
no HAO is not allowed. If the intent is to forbid that combination
please make it explicit. Otherwise drop the last sentence.
Section 9.5.2 talks about the CN reducing the lifetime
of a binding. Given that the MN might continue sending packets with HAO
until the MN thinks the binding times out it seems unwise for the CN
to limit the lifetime unless it explicitly informs the MN by sending a BAck.
Section 9.5.4 states that Binding Acks don't use the Binding Cache.
Do they or do they not use the Binding Update List to determine whether
or not to add a HAO?
Section 10.3.1:
o Else, if the home address for the binding (the Home Address field
in the packet's Home Address option) is not an on-link IPv6
address with respect to the home agent's current Prefix List or if
the corresponding prefix was not advertised with the Home Agent
(H) bit set, then the home agent MUST reject the Binding Update
and SHOULD return a Binding Acknowledgement to the mobile node, in
which the Status field is set to 132 (not home subnet).
The H-bit is set in the RA and not for each prefix as this text assumes.
Is the intent just to say that "if the HA is not operating as a HA on that
interface"?
Section 10.6.1:
I question the wisdom of having HAs learn information to advertise
from other HAs on the link; normal routers do not do this so why do
HA have to be different in this respect?
To minimize the risk of bad effects if a MN moves from one HA to
another on the home link, why not have the HAs verify that the
other HAs on the link advertise the same list of prefixes and the same
M/O settings and log an event should they differ?
That would simplify section 10.6.1 quite significantly.
Section 10.6.2 says:
o The valid or preferred lifetime or the state of the flags changes
for the prefix of the mobile node's registered home address.
But when the lifetimes decrement in real time the above would become
true every second (the lifetime granularity).
I don't think that is the intent.
What is the intent?
Section 10.6.2 has:
MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime),
Is this the right thing to do even when a prefix is deprecated?
(i.e. it has a zero preferred lifetime).
Section 10.1 is not very clear that (and when) the Binding Update List
is used to add HAO to outgoing packets.
Compare with section 9.1 which is clear that the Binding Cache is
used to add a RH type 2.
(Presumably such a statement for HAO would have an exception clause as well
since there are packets to which HAO should not be added even there is
a BUL entry.)
I think the text should capture that when there is a BUL entry for the HoA
that is "current" (i.e. the CN has been informed of the latest CoA
and optionally the binding ack has been received) that precense of that
BUL entry means that packets can be sent directly to the CN with HAO added.
Some more discription on this front also help nail down the meaning
of "binding exists" and "aware that the CN already has a BCE" in section
11.3.1. In both those cases the "current" property is silently assumed.
Section 11.3.1 says:
reverse tunneling. Detailed operation for both of these cases is
described later in this section and also discussed in [29].
but I have no idea what detailed operation the default address selection
document offers for reverse tunneling vs. route optimization.
Did the last sentence get placed in the wrong part of the text?
Section 11.4.3 has:
o If a solicitation has been sent recently, the ICMP Identifier
value MUST be the same as in the solicitation.
which seems odd given that solicitations and advertisements might
cross in flight and "recently" is not well-defined.
Isn't the intent that if an advertisement matches the most recently
sent identifier value (and no advertisement has previously matched it)
the advertisement is considered to be solicited and is used to update the
state about the prefixes.
Otherwise the advertisement is considered to be unsolicited and
can only be used to trigger a (rate limited) solicitation?
If that is the case it doesn't make sense to have a MUST discard when
the ICMP identifier doesn't match.
Section 11.7.1 last sentence has a MAY while referring to some possible
future work in appendix B.5. This makes no sense since it isn't possible
to implement this until the work outlined in B.5 has resulted in a
specification. Thus this needs to be reworded to refer to this
as "Perhaps this can be solved in the future using the scheme outlined
in appendix B.5" or something along those lines.
Section 11.7.2:
In addition, when a mobile node receives a packet for which the
mobile node can deduce that the original sender of the packet has a
stale Binding Cache entry for the mobile node, the mobile node SHOULD
initiate a correspondent binding procedure.
How does a mobile node tell that the sender has stale info?
By the fact that the packet was not send to the MN?
Section 11.7.2:
o The packet does not contain a Care-of Test Init message.
Why is CoTI special? Aren't there other RR procedure messages that should
be subject to the same exclusion?
Section 11.7.2:
A mobile node MAY also choose to keep its location private from
certain correspondent nodes, and thus need not initiate the
correspondent binding procedure.
While the document uses "location" all over to refer to "topological location"
I think in a sentence about location privacy it would be good to spell
this out to avoid confusing this with geographical location privacy.
Section 11.7.2:
A Binding Update is created as follows:
o The Source Address of the IPv6 header MUST contain the current
care-of address of the mobile node.
Is use of alt-coa explicitly forbidden?
Section 11.7.3:
o If the Status field indicates that the Binding Update was rejected
(the Status field is greater than or equal to 128), then the
mobile node SHOULD record in its Binding Update List that future
Binding Updates SHOULD NOT be sent to this destination.
Optionally, the mobile node MAY then take steps to correct the
cause of the error and retransmit the Binding Update (with a new
Sequence Number value), subject to the rate limiting restriction
specified in Section 11.8.
I thought e.g. responding to 135-138 errors was more than optional.
Requiring that the MN give up (SHOULD NOT) is odd in any case.
Only if the MN either doesn't have a recourse or chooses not to
take optional recourse, is it the case that it SHOULD NOT send further BUs.
Section 11.8:
I assume that this retransmission behavior should apply to home agent discovery
as well. The document seems silent on such retransmissions.
Nits:
-----
Some IPv6 nodes might implement HAO and/or RH type 2 even if they do not
implement route optimization. Thus it would be useful to restate the
constraints for those found in section 8.2 under section 8.1 with a
"if an IPv6 node implements X it MUST ...".
Section 9.1 says:
o The home address of the mobile node for which this is the Binding
Cache entry. This field is used as the key for searching the
Binding Cache for the destination address of a packet being sent.
If the destination address of the packet matches the home address
in the Binding Cache entry, this entry SHOULD be used in routing
that packet.
It would be more clear if this had "except as noted in xxx"
because there are some cases in the return routability procedure
when the binding cache entry needs to be explicitly ignored.
The descriptions for the ICMP parameter problem errors do not specify
how to set the offset field in section 9.2:
o The Payload Proto field MUST be IPPROTO_NONE (59 decimal).
Otherwise, the node MUST discard the message and SHOULD send ICMP
Parameter Problem [14], Code 0, to the Source Address of the
packet.
with the offset pointing at the payload proto field.
o The Header Len field in the Mobility Header MUST NOT be less than
the length specified for this particular type of message in
Section 6.1. Otherwise, the node MUST discard the message and
SHOULD send ICMP Parameter Problem [14], Code 0, to the Source
Address of the packet.
with the offset pointing at the header len field.
In 9.2:
Mobile nodes are expected to include a Home Address destination
option in a packet they believe the correspondent node has a Binding
Cache entry for the home address of a mobile node. Packets
s/expected/can/ since they might choose to reverse tunnel
s/packet they/packet when they/
In 9.5.1:
o The Sequence Number field in the Binding Update is greater than
the Sequence Number received in the valid previous Binding Update
for this home address, if any.
s/valid previous/previous valid/
In 9.5.1
If the mobile node sends a sequence number which is not greater than
the sequence number from the last successful Binding Update, then the
I assume "succesful" should be "valid" since there is no definition of
what is a succesful BU.
In 9.5.1:
If the Binding Update is valid according to the tests above, then the
Binding Update is processed further as follows:
It would be good to explicitly state that the recorded sequence number
is updated from the binding update packet here.
Section 9.5.1 checks the H-bit earlier and then unnecessarily talks about
checking the H-bit in these paragraphs:
o If the Lifetime specified in the Binding Update is nonzero and the
specified care-of address is not equal to the home address for the
binding, then this is a request to cache a binding for the mobile
node. If the Home Registration (H) bit is set in the Binding
Update, the Binding Update is processed according to the procedure
specified in Section 10.3.1; otherwise, it is processed according
to the procedure specified in Section 9.5.2.
o If the Lifetime specified in the Binding Update is zero or the
specified care-of address matches the home address for the
binding, then this is a request to delete the mobile node's cached
binding. In this case, the Binding Update MUST include a valid
home nonce index, and the care-of nonce index MUST be ignored by
the correspondent node. The generation of the binding management
key depends then exclusively on the home keygen token (Section
5.2.5). If the Home Registration (H) bit is set in the Binding
Update, the Binding Update is processed according to the procedure
specified in Section 10.3.2; otherwise, it is processed according
to the procedure specified in Section 9.5.3.
Section 9.5.{1,2,3} talks about a a binding cache entry for a
mobile node when in
fact a binding cache entry is for a home address; a mobile node can have
multiple HoA each having a binding cache entry:
This might cause confusion. Suggest using "home address" instead.
Section 9.6 second paragraph (except first few words) and third paragraph
are about Home Agent behavior and is already covered in section 10; no need
to talk about that in the correspondent node section.
Section 9.6 fourth paragraph should point out that discarding a BCE before
it times out will cause packets with HAO to be dropped. Also add point
about keeping information around until the nonces used to create the BCE
have expired to prevent replays.
Section 10.3.1
home agent assures to the mobile node that its address(es) will
continue to be kept unique by the home agent at least as long as the
lifetime granted for the bindings is not over.
s/bindings is not over/binding/ (no "s")
In 10.4.4:
This section describes how home agents support the use of stateful
address autoconfiguration mechanisms such as DHCPv6 [28] from the
mobile nodes. If this support is not provided, then the M and O bits
must remain cleared on the Mobile Prefix Advertisement Messages. Any
mobile node which issues autoconfiguration queries for servers
without this support will not receive a response.
The "autoconfiguration queries" is odd. Is it supposed to mean "tries
to use DHCPv6"? Then I suggest saying so explicitly.
In 11.3.3:
While away from home, a mobile node will receive packets addressed to
its home address, by one of three methods:
I only count to two methods.
In 11.3.4:
1. Send directly on the foreign link being visited.
The application is aware of the care-of address and uses it for
multicast traffic just like any other stationary address. The
mobile node MUST NOT use Home Address destination option in such
traffic.
It would be helpful to add that the care-of address is used as the source
address in this case.
In 11.3.4 last paragraph it talks about reverse tunneling and
then covers performance issues about multicast packets tunneled
in the forward direction.
Saying "bidirectional" instead of "reverse" would be less confusing.
Section 11.5.4:
home address. In addition, when returning home prior to the
expiration of a current binding for its home address, and configuring
its home address on its network interface on its home link, the
mobile node MUST NOT perform Duplicate Address Detection on its own
home address, in order to avoid confusion or conflict with its home
agent's use of the same address. If the mobile node returns home
after the bindings for all of its care-of addresses have expired,
then it SHOULD perform DAD.
It makes sense to add that the MUST NOT also applies to performing
DAD on the link-local address when the L-bit was set in the BU.
In 11.6.1:
MAY record the same information in multiple Binding List entries.
Elsewhere this is called a binding update list.
Section 11.6.2:
mobile node SHOULD continue waiting for additional messages.
More clear to say "a CoT message" instead of "additional messages".
mobile node SHOULD continue waiting for additional messages.
More clear to say "a HoT message" instead of "additional messages".
Section 11.7.1:
value is received, because information learned through prefix
discovery on an earlier registration may have changed.
s/on/after/
Section 11.7.1:
If the mobile node has additional home addresses using a different
interface identifier, then the mobile node SHOULD send an additional
packet containing a Binding Update to its home agent to register the
care-of address for each such other home address (or set of home
addresses sharing an interface identifier).
The above seems like a carry-over from when multiple addresses
using the same interface ID could be updated in a single BU.
Suggest replace with:
If the mobile node has additional home addresses,
then the mobile node SHOULD send an additional
packet containing a Binding Update to its home agent to register the
care-of address for each such other home address.
Section 11.7.2:
Binding Update List. This is necessary in order to ensure that
correspondent nodes do not have invalid information about the current
location of the mobile node. The initiated procedures can be used to
s/invalid/stale/
Section 11.7.2 has:
If set to one of the mobile node's current care-of addresses, the
Binding Update requests the correspondent node to create or update an
entry for the mobile node in the correspondent node's Binding Cache
in order to record this care-of address for use in sending future
packets to the mobile node. In this case, the value specified in the
"set" makes no sense. But even replacing it with "sent" doesn't
make sense since BUs aren't sent to MNs.
Is the intent "sent to correpondent to create or update a binding cache entry"?
Section 11.7.2:
If the mobile node wants to ensure that its new care-of address has
been entered into a correspondent node's Binding Cache, the mobile
node MAY request an acknowledgement by setting the Acknowledge (A)
bit in the Binding Update. In this case, however, the mobile node
The "If ... MAY " construction doesn't make sense.
s/MAY/needs to/
In 15.4.1:
ability of attackers to see these nonces. For instance, this
prevents attacks launched from the mobile node's current foreign
link where no link-layer confidentiality is available.
s/where/even when/
In 15.4.3:
In contrast, an attacker who uses only plain IPv6 generally has to be
stay on the link in order to continue the attack. Note that in order
s/has to be stay/has to stay/
In 15.4.3:
vulnerability. This limited vulnerability can also be compared to
similar vulnerabilities in IPv6 Neighbor Discovery, with Neighbor
Cache entries having a limited lifetime.
Neighbor cache entries have no limited lifetime. They can be garbage
collected, and NUD will remove ones with stale information should
they be used. So I suggest you strike the last sentence.
Section 9.3.1:
No additional authentication of the Home Address option is required,
except that if the IPv6 header of a packet is covered by
authentication, then that authentication MUST also cover the Home
Address option; this coverage is achieved automatically by the
s/authentication/IPsec Authentication Header/ at least for the first occurance.
to the packet's final destination, and thus the option is included in
the authentication computation. By requiring that any authentication
s/authentication/AH/
When attempting to verify authentication data in a packet that
contains a Home Address option, the receiving node MUST calculate the
authentication data as if the following were true: The Home Address
s/authentication/AH authentication/
Section 9.3.2:
of its care-of address. When calculating authentication data in a
packet that contains a type 2 routing header, the correspondent node
MUST calculate the authentication data as if the following were true:
s/authentication/AH authentication/
Section 15.8:
No special authentication of the Home Address option is required
beyond the above, except that if the IPv6 header of a packet is
covered by authentication, then that authentication MUST also cover
s/covered by authentication/covered by IPsec Authentication Header/
COMMENTS:
=========
Russ:
This already has a ballot, and it was started before I became a member
of the IESG. However, I have a few comments.
Comments:
Please spell out the first use of FQDN.
In section 3.1, the definition of "unicast routable address"
uses the term "site-local scope." I thought we deprecated this concept.
Also, can we simply delete section 4.6?
In section 3.1, the definition of "security association" is
consistent with RFC 2401, but I find the use of "connection" (in quotes)
misleading in this context. I prefer:
An IPsec security association is a cooperative relationship
formed by the sharing of cryptographic keying material and
associated context. Security associations are simplex.
That is, two security associations are needed to protect
bidirectional traffic between two nodes, one for each
direction.
In section 5.1 and section 5.4 say that the Encapsulating Security
Payload (ESP) protocol SHOLD be used. To ensure that interoperable
configurations emerge, I would prefer to see ESP as a mandatory to
implement. This seems consistent with the requirements for ESP in section 8.
In section 5.2.5, the procedure for generating Kbm is described as:
Kbm = SHA1 (home keygen token | care-of keygen token)
or:
Kbm = SHA1(home keygen token)
The text is clear about when each formula applies. Each of the tokens is
64 bits, and the Kbm value is 20 octets. The input values are not
secrets. There is some discussion about the amount of traffic that would
be need to spoof these messages in the Security Considerations, but it
assumes that the token values are unknown.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, mobile-ip@sunroof.eng.sun.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Mobility Support in IPv6 to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Mobility Support in IPv6'
<draft-ietf-mobileip-ipv6-21.txt> as a Proposed Standard. This
document is the product of the IP Routing for Wireless/Mobile Hosts
Working Group. The IESG contact persons are Thomas Narten and Erik
Nordmark.
Technical Summary
This document specifies the Mobile IP protocol for IPv6. Mobile IP
allows a node to move around the internet, yet keep the same
address while continue to communicate transparently with other
nodes as it moves. Each mobile node is identified by its home
address, regardless of its current point of attachment to the
Internet. While situated away from its home, a mobile node is also
associated with a care-of address, which provides information about
the mobile node's current location. IPv6 packets addressed to a
mobile node's home address are transparently routed to its care-of
address. The protocol enables IPv6 nodes to cache the binding of a
mobile node's home address with its care-of address, and to then
send any packets destined for the mobile node directly to it at
this care-of address.
Mobile IP for IPv6 includes a route optimization mechanism that
allows communicating nodes to forward packets directly to each
other without having to relay all traffic via a Home Agent at the
mobile node's home address. Route optimization can be invoked
between arbitrary nodes without the need for some pre-existing
shared security relationship. Route optimization uses a
return-routablity procedure to verify the safety of performing
route optimization.
Working Group Summary
This document has been under very long development within the WG. It
was brought to the IESG over a year ago, but was sent back to the WG
in order to make changes to the security properties of route
optimization. That led to the development of the return-routability
mechanism.
There is strong support for moving this document forward, and there
continues to be frustration at the length of time this document has
been under development.
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-ietf-hubmib-etherif-mib-v3 -
Definitions of Managed Objects for the Ethernet-like Interface
Types to Proposed Standard
--------
Last Call to expire on: 2003-6-5
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
COMMENTS:
========
Ted:
I found it odd that the security considerations sections of
draft-ietf-hubmib-etherif-mib-v3 and draft-ietf-hubmib-mau-mib-v3
were after the references. No big deal, but since the
draft-ietf-hubmib-wis-mib didn't, I gather it is not
a working group convention.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, hubmib@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Definitions of Managed Objects for the Ethernet-like
Interface Types to Proposed Standard
-------------
The IESG has approved the following documents. These documents
are the product of the Ethernet Interfaces and Hub MIB Working
Group. The IESG contact persons are Randy Bush and Bert Wijnen
o Definitions of Managed Objects for the Ethernet-like Interface Types
<draft-ietf-hubmib-etherif-mib-v3-03.txt>
Proposed Standard
o Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)
<draft-ietf-hubmib-mau-mib-v3-04.txt>
Proposed Standard
o Definition of Managed Objects for the Ethernet WAN Interface Sublayer
<draft-ietf-hubmib-wis-mib-07.txt>
Proposed Standard
o Applicability Statement for Reclassification of RFC 1643 to Historic Status
<draft-ietf-hubmib-1643-to-historic-01.txt>
Informational
At the same time, the IESG approved the re-classification of RFC1643
to Historic Status.
Technical Summary
o Definitions of Managed Objects for the Ethernet-like Interface Types.
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing Ethernet-like
interfaces.
This memo obsoletes RFC 2665. It updates that specification by
including management information useful for the management of 10
Gigabit per second (Gb/s) Ethernet interfaces.
o Definitions of Managed Objects for IEEE 802.3 Medium Attachment
Units (MAUs)
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing IEEE 802.3 Medium
Attachment Units (MAUs).
This memo obsoletes RFC 2668. This memo extends that specification
by including management information useful for the management of 10
gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515.
o Definition of Managed Objects for the Ethernet WAN Interface Sublayer
This document defines a portion of the Management Information Base
(MIB) for use with network management protocols in TCP/IP based
internets. In particular, it defines objects for managing the
Ethernet Wide Area Network (WAN) Interface Sublayer (WIS).
The MIB module defined in this memo is an extension of the SONET/SDH
Interface MIB and is implemented in conjunction with it and with the
Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB,
the Interfaces Group MIB, and the Inverted Stack Table MIB.
o Applicability Statement for Reclassification of RFC 1643 to Historic
Status
This memo recommends that RFC 1643 be reclassified as an Historic
document and provides the supporting motivation for that
recommendation.
Working Group Summary
There is Working Group Consensus on the above documents for Proposed
Standard and for reclassification of RFC1643 to Historic Status.
Protocol Quality
These documents have been reviewed for the IESG by Bert Wijnen.
RFC-Editor note:
In document draft-ietf-hubmib-mau-mib-v3-04.txt, pls remove an
extraneous "IANA. " on page 25.
CURRENT TEXT:
DESCRIPTION "This object identifies the MAU type. Values for
standard IEEE 802.3 MAU types are defined above.
IANA. If the MAU type is unknown, the object identifier
SHOULD BE:
DESCRIPTION "This object identifies the MAU type. Values for
standard IEEE 802.3 MAU types are defined above.
If the MAU type is unknown, the object identifier
Bert
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-mpls-lsp-query - Multi Protocol Label
Switching Label Distribution Protocol Query Message
Description to Proposed Standard
--------
Last Call to expire on: 2003-3-25
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 [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Russ:
I do not like the Abstract. I propose:
This document describes the encoding and procedures for three
new Label Distribution Protocol (LDP) messages: Query Message,
Query-Reply Message and Partial Query-Reply Message. A Label
Edge Router (LER) sends a Query message when it needs information
about an established Label Switched Path (LSP). The Query message
can be used to request information about LDP LSPs as well as
Constraint-Based Label Switched Paths (CR-LSPs). The response to
the query is encoded into the Query-Reply and Partial Query-Reply
messages.
The Introduction should be rewritten so that is does not depend on the
Abstract to define terms.
In the security considerations, the document says:
The Query mechanism inherits the same security mechanism
described in Section 4.0 of [4].
Section 4.0 of RFC 3036 is the IANA Considerations! I assume that Section
5 should have been referenced. Further, section 5.1 of RFC 3036 discussed
the TCP MD5 Signature Option. This appear to be the only integrity
mechanism available. Since this protocol runs on top of TCP, why not
discuss IPsec ESP and/or TLS?
Section 5 of RFC 3036 also said that the peers need to be trusted to label
properly. What are the impacts on these new protocol messages if this
trust is misplaced? This topic should be discussed in the security
considerations section.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, mpls@uu.net
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Multi Protocol Label Switching Label
Distribution Protocol Query Message Description to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'Multi Protocol Label
Switching Label Distribution Protocol Query Message Description'
<draft-ietf-mpls-lsp-query-06.txt> as a Proposed Standard. This
document is the product of the Multiprotocol Label Switching Working
Group. The IESG contact persons are Alex Zinin and Bert Wijnen.
Technical Summary
This document describes the encoding and procedures for three new
Label Distribution Protocol (LDP) messages: Query Message, Query-
Reply Message and Partial Query-Reply Message (the last one is almost
identical to the Query-Reply message; therefore all references to the
Query-Reply messages imply the Partial Query-Reply messages as well,
unless otherwise specified). A Lable Edge Router (LER) sends a Query
message when it needs to find out information about a Label Switched
Path (LSP). The Query message is sent for an established LSP. The
Query message can be used for LDP LSPs as well as for Constraint-
Based Label Switched Paths (CR-LSPs). The queried data is encoded
into the Query-Reply messages.
Working Group Summary
The document has been reviewed by the WG participants. The WG
supported advancement of the document.
Protocol Quality
The specification has been reviewed for the IESG by Scott Bradner
and Alex Zinin.
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 [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
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>, 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.
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-sip-symmetric-response - An Extension
to the Session Initiation Protocol (SIP) for Symmetric Response
Routing to Proposed Standard
--------
Last Call to expire on: 2002-12-9
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 [ ] [ ] [ X ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
Allison Mankin [ X ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
=======
Ted:
First, let me say that a large number of the issues I had
with the document turned out to be very well documented
in the IAB considerations section of the draft. A few
other issues:
In Section 3:
When the client sends the request, if the request is sent using UDP,
the client MUST be prepared to receive the response on the same
socket the request was sent on. Specifically, it MUST be prepared to
receive the response on the same IP address and port present in the
source IP address and source port of the request. For backwards
compatibility, the client MUST still be prepared to receive a
response on the port indicated in the sent-by field of the topmost
Via header field value, as specified in Section 18.1.1 of SIP [1].
It seems pretty clear from the "on the same socket" that the following
sentence means the IP address and port present in the source IP
and port of the request _when it is sent_. I think it would be clearer,
though, to use phrasing like "it MUST be prepared to receive the
response on the same IP address and port it used to populate
the source IP address and source port of the request.".
Also in Section 3:
To keep the binding fresh, the client SHOULD retransmit its INVITE every 20
seconds or so. These retransmissions will need to take place even
after receiving a provisional response.
based on the idea the one minute seems to be a common UDP binding lifetime.
Section 9.3 notes, however, that there is no way to determine the UDP binding
lifetime. Is there anyway to introduce a growing/shrinking algorithm
to this for cases where the binding lifetime is much longer (to avoid the
aggressiveness of 20 seconds for an arbitrary period of time) or to handle
the cases where the binding lifetime is shorter than 20+transmission time to
the NAT (since this has to handle the NAT being at some arbitrary place in
the topology).
In the initial section of 9:
The client can then perform an additional registration,
using this address in a Contact header. This would allow a client to
receive incoming requests, such as INVITE, on the socket through
which the registration was sent.
As is noted below that point, there are cases in which the port binding
is only valid for the server to which the original registration was sent.
Will the Contact header "leak" that so that a direction connection between a
different sip agent (user or proxy) might attempt to use it? If so, a forward
pointer to the limitation might be useful here.
I would personally consider the UNSAF document a normative reference,
but this is not a big deal.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: An Extension to the Session Initiation
Protocol (SIP) for Symmetric Response Routing to Proposed
Standard
-------------
The IESG has approved the Internet-Draft 'An Extension to the Session
Initiation Protocol (SIP) for Symmetric Response Routing'
<draft-ietf-sip-symmetric-response-00.txt> as a Proposed Standard.
This document is the product of the Session Initiation Protocol
Working Group. The IESG contact persons are Allison Mankin and Jon
Peterson.
Technical Summary
The Session Initiation Protocol (SIP) operates over UDP and TCP. When
used with UDP, responses to requests are returned to the source
address the request came from, and to the port written into the
topmost Via header field value of the request. This behavior is not
desirable in many cases, most notably, when the client is behind a
Network Address Translator (NAT). This extension defines a new
parameter for the Via header field, called "rport", that allows a
client to request that the server send the response back to the
source IP address and port where the request came from.
Working Group Summary
The Working Group supported the advancement of this document.
There were reviews by working group members.
Protocol Quality
The document includes an analysis of the work in the perspective
of the IAB's UNSAF Considerations. The review for the IESG was
carried out by 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-snmpv3-coex-v2 - Coexistence between
Version 1, Version 2, and Version 3 of the Internet-standard
Network Management Framework to BCP
--------
Last Call to expire on: 2003-6-5
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ X ] [ ] [ ] [ ]
Bill Fenner [ X ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ XX] [ X ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ R ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Russ:
Since this document will obsolete RFC 2576, it would be very helpful if
the document contained a summary of the changes which are implemented by
this document. I assume that Appendix B is not intended to be included in
the final RFC. I think that the change summary should be at a much higher
level than Appendix B.
In section 8, the document says: "... USM, with authentication and
privacy." Please change "privacy" to "confidentiality."
COMMENT:
========
Russ:
The discussion of the RFC Editor note:
> > > > In section 8, the document says: "... USM, with authentication and
> > > > privacy." Please change "privacy" to "confidentiality."
> > > >
> > >Well, we have Authentication and Privcacy protocols in USM. That is how
> > >they have been known since oh mid 90s or so.
> > >
> > >So we have a authNoPriv and a authPriv way of communicating.
> > >So I think that sticking to privacy is better given the history and
> > >the name of the fields and bits that we use.
> >
> > How about ".. USM, with authentication and privacy (also known as
> > confidentiality)."
> >
>That seem quite acceptable to me.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, snmpv3@lists.tislabs.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Coexistence between Version 1, Version 2,
and Version 3 of the Internet-standard Network Management
Framework to BCP
-------------
The IESG has approved the Internet-Draft 'Coexistence between
Version 1, Version 2, and Version 3 of the Internet-standard
Network Management Framework' <draft-ietf-snmpv3-coex-v2-04.txt> as
a BCP. This document is the product of the SNMP Version 3 Working
Group. The IESG contact people are Randy Bush and Bert Wijnen
Technical Summary
This document describes coexistence between version 3 of the
Internet-standard Network Management Framework, SNMPv3, version 2
of the Internet-standard Network Management Framework SNMPv2, and
the original Internet-standard Network Management Framework
SNMPv1. It also describes how to convert MIB modules from SMIv1
format to SMIv2 format. This document obsoletes RFC 2576.
Working Group Summary
There was WG consensus to publish this document as BCP.
Protocol Quality
The document has been reviewed for te IESG by Bert Wijnen and
Randy Bush
RFC-Editor note:
On page 39, pls make the following change:
OLD:
Changed the name of 'snmpCommunityGroup' to a name
conflict with the SNMPv2-MIB.
NEW:
Changed the name of 'snmpCommunityGroup' to
snmpCommunityTableGroup to avoid a name conflict
with the SNMPv2-MIB.
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-dhc-pktc-kerb-tckt - Security Ticket
Control Sub-option for the CableLabs Client Configuration
Option to Proposed Standard
--------
Last Call to expire on: 2003-5-6
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ X ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ X ] [ ] [ ]
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'.
COMMENTS:
========
Steve:
What does "locally persisted" mean? I think that the proper phrase is
"locally cached".
Section 4 should state that bit values not known to the client MUST be
ignored, or it will be very difficult to add new options.
^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: Security Ticket Control Sub-option for the
CableLabs Client Configuration Option to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Security Ticket Control
Sub-option for the CableLabs Client Configuration Option'
<draft-ietf-dhc-pktc-kerb-tckt-01.txt> as a Proposed Standard. This
document is the product of the Dynamic Host Configuration Working
Group. The IESG contact persons are Thomas Narten and Erik Nordmark.
Technical Summary
This document defines a new sub-option for the CableLabs Client
Configuration (CCC) Option. This new sub-option will be used to
direct CableLabs Client Devices (CCDs) to invalidate locally
persisted security tickets.
Working Group Summary
There was WG consensus to advance the document.
Protocol Quality
The specification 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: Ballot: Remote Network Monitoring MIB Protocol Identifier
Reference to Draft Standard
--------
Last Call to expire on: 2003-6-4
Please return the full line with the vote.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ X ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]
2/3 (10) Yes or No-Objection votes needed to pass.
* Indicate reason if 'Discuss'.
^L
To: IETF-Announce
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@iab.org>
Cc: rmonmib@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Remote Network Monitoring MIB Protocol Identifier
Reference to Draft Standard
-------------
The IESG has approved RFC2895, 'Remote Network Monitoring MIB
Protocol Identifier Reference' to advance to Draft Standard. This
document is the product of the Remote Network Monitoring
Working Group. The IESG contact persons are Bert Wijnen
and Randy Bush
Technical Summary
This memo defines a notation describing protocol layers in a protocol
encapsulation, specifically for use in encoding INDEX values for the
protocolDirTable, found in the RMON-2 MIB (Remote Network Monitoring
Management Information Base) (RFC2021). The definitions for the
standard protocol directory base layer identifiers are also included.
The first version of the RMON Protocol Identifiers Document (RFC2074)
has been split into a standards-track Reference portion (this
document), and an Informational document. The RMON Protocol
Identifier Macros document (RFC2896) now contains the non-normative
portion of that specification.
This document obsoletes RFC 2074.
Working Group Summary
The WG has consensus to advance this document to Draft Standard.
Protocol Quality
This document has been reviewed for the IESG by Bert Wijnen
The implemenation report is at
http://www.ietf.org/IESG/Implementations/RFC2895-Implementation.txt
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-mobileip-mipv6-ha-ipsec - Using IPsec
to Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents to Proposed Standard
--------
Last Call to expire on: 2003-3-7
Please return the full line with your position.
Yes No-Objection Discuss * Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ XX] [ D ]
Randy Bush [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ XX] [ D ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ X ] [ ] [ ] [ ]
Erik Nordmark [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ XX] [ ] [ D ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
DISCUSS:
========
Randy:
ops-dir comment causes me to register a DISCUSS
randy
---
http://www.piuha.net/~jarkko/publications/mipv6/issues/issue284.txt
and further
From: Greg O'Shea
I have been raising issues on the MobileIP list as I encounter them,
resulting in a number of mods to the spec of which my favourite was
removal of the S bit in binding updates. Of what remains I do not know
of anything that I think warrants delay.
IMHO what is needed most at this point is a stake in the ground (an
initial stable spec.) pending which everyone is sitting painfully
still and holding their breath. Once the base spec is approved I
expect the innovation and serious experimentation will begin afresh
around it.
I do think that the specification could have been simpler, although
this is not a show stopper and once the initial base spec is
approved there may be efforts in this direction. I believe that home
nets and therefore home addresses should be virtual nets e.g. on a
virtual IF on a HA. This means that random hosts cannot directly
attach to the net and interfere with address assignment. In turn this
means that HA need not run DAD before protecting a HoA, the HA need
not protect link-local addresses derived from HoA, NS code is simpler
and in some cases handoff latency is reduced by a second or two. This
idea was well received on the list but has been set aside as future
work.
I am somewhat dubious about the HA discovery and prefix discovery
stuff. At best I think it belongs in a separate doc. It doesn't
achieve much at all with manual keying. But again that is not a show
stopper.
Steve:
Per Steve Kent's comments (see his annotated version of the draft
at http://psg.com/~smb/draft-ietf-mobileip-mipv6-ha-ip.htm ),
there seems to be a serious mismatch between the semantics of IPsec
and what is needed by this spec. In particular, the spec demands
special matching and processing rules for input and output packets
that are seriously inconsistent with IPsec. In principle, IPsec might
be changeable in this regard, since the specs are currently undergoing
revision; in practice, I suspect that the changes needed are too great.
In any event, the changes will require the approval of the IPsec
working group.
Beyond that, this spec requires changes to the SPD as the mobile node
roams. That implies a deep coupling between the MobileIP layer and the
IPsec layer. Implementation might be problematic if outboard (i.e.,
NIC-resident) IPsec implementations are used. I would note that these
have been on the market for a couple of years at the least; they're
not hypothetical devices. I suspect that some of these issues might
be resolvable by using IKE and negotiating new Phase 2 associations.
This would rely on the existing API to IPsec, though admittedly it
might require a new interface to IKE.
Kent's much more detailed comments must be addressed, too.
Russ:
Comments:
In section 1, ESP does not provide in order delivery. The introduction
indicates that this service is needed. If this is correct, then
additional protocol mechanisms are needed.
In section 3, in each instance tell whether ESP is used in transport
mode or tunnel mode.
In section 4.1, the document requires support for manual security
association configuration. I think this should be clear that ESP SAs
are being configured, not IKE pre-shared keys. Also, the phrase
"IPsec protection" really means ESP enacpsulation in many different
places.
Steve Kent's comments on section 4.2, 4.3, 5.1, 5.2, and 5.3 need to be
addressed (see http://psg.com/~smb/draft-ietf-mobileip-mipv6-ha-ip.htm
). Since RFC 2401 is being updated, there is an opportunity for
compromise, but the MobileIP and IPsec working groups need to work
together in this area.
In section 4.3, I suggest that all discussion of AH be removed.
In section 4.4, there seems to be confusion about ESP replay
detection. Why not just say that IKE must be used if replay protection
is needed?
COMMENTS:
=========
Ted:
A couple of editorial nits, and three notes, cc'ed only
to Thomas, so as not to clutter the IESG list with
efforts-to-educate-the-newcomer.
Nits:
The Introduction says it illustrates the use of IPsec
in securing control traffic; Section 3.4 describes the
use of IPsec in protecting payload packets tunneled to
the home agent. Since these can be "any protocol",
they are probably not limiting this to control traffic.
"It is important for the home agent to verify that the care-of address
has not been tampered." seems to be missing a with"
"Where <condition> is an boolean expression" should be
"a boolean expression".
Notes:
I was surprised that the manual configuration for security
associations were MUST and IKE only MAY. I assume that
there is lots of history here, and I don't want to draw anyone into
it, but I was surprised.
In section 4.3, I was surprised that the instructions on using
integrity protection with the manually configured SA did not
have a "as of this writing FOO would be the best choice", since
it was willing to toss DES. I'm guessing that this means
different folks have different flavor preferences here.
Section 7's implementation considerations on fragmentation
in the presence of certificates surprised me by recommending
replacing firewalls or routers, given that we're talking about
mobility. Replacing gear in someone else's network is a good
trick.
^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
Internet Architecture Board <iab@iab.org>, mobile-ip@sunroof.eng.sun.com
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Using IPsec to Protect Mobile IPv6 Signaling
between Mobile Nodes and Home Agents to Proposed Standard
-------------
The IESG has approved the Internet-Draft 'Using IPsec to Protect
Mobile IPv6 Signaling between Mobile Nodes and Home Agents'
<draft-ietf-mobileip-mipv6-ha-ipsec-04.txt> as a Proposed Standard.
This document is the product of the IP Routing for Wireless/Mobile
Hosts Working Group.
The IESG contact persons are Thomas Narten and Erik Nordmark.
Technical Summary
Mobile IPv6 uses IPsec to protect signaling between the home agent
and the mobile node. The mobile IPv6 base document defines the
main requirements these nodes must follow. This document discusses
these requirements in more depth, illustrates the used packet
formats, describes suitable configuration procedures, and shows how
implementations can process the packets in the right order.
Working Group Summary
There was support for this document in the WG.
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-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 [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Russ Housley [ X ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Erik Nordmark [ ] [ ] [ ] [ ]
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>,
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.
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-klyne-msghdr-registry - Registration procedures
for message header fields to BCP
--------
Last Call to expire on: 2002-12-4
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 [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
* Indicate reason if 'Discuss'.
"Defered" by Harald Alvestrand, Allison Mankin, Jon Peterson
COMMENTS:
========
Ted Hardie:
Two notes:
In section 3.2.1 "An header" should be "A header".
In section 3.4, the draft says:
Publication in an IESG-approved RFC or other form of Open Standard
document (per RFC 2026 [1], section 7) is sufficient grounds for
publication in the permanent registry.
Note that the text IESG-approved suggests a different test from
the one set out above--which would allow Experimental and
Informational RFCs which the IESG may choose to advise the RFC editor
on, but does not exactly "approve". To avoid the swamp, I'd suggest
the text here
be shifted to "published RFC" to be in accord with the text above.
^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: Registration procedures for message header
fields to BCP
-------------
The IESG has approved the Internet-Draft 'Registration procedures for
message header fields' <draft-klyne-msghdr-registry-06.txt> as a BCP.
This has been reviewed in the IETF but is not the product of an IETF
Working Group. The IESG contact persons are Ned Freed and Ted Hardie.
Technical Summary
This specification defines registration procedures for the message
header field names used by Internet mail, HTTP, newsgroup feeds and
other Internet applications.
Benefits of a central registry for message header field names
include:
o providing a single point of reference for standardized and widely-
used header field names;
o providing a central point of discovery for established header
fields, and easy location of their defining documents;
o discouraging multiple definitions of a header field name for
different purposes;
o helping those proposing new header fields discern established
trends and conventions, and avoid names that might be confused
with existing ones;
o encouraging convergence of header field name usage across multiple
applications and protocols.
Working Group Summary
This has been reviewed in the IETF but is not the product of an IETF
Working Group.
Protocol Quality
Ned Freed reviewed the document for the iESG.
RFC Editor note
The IPR boilerplate is missing from this document and needs to be added.
To: RFC Editor <rfc-editor@isi.edu>
Cc: iesg@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: Developing High Quality SNMP Agents
to Informational
The IESG has no problem with the publication of 'Developing High Quality
SNMP Agents' <draft-aromanov-snmp-hiqa-04> as an Informational RFC.
RFC-Editor Note:
The IESG would like to see an IESG note added on the front-page of
the document.
IESG Note
This document represents the opinions of the author. It has not
been widely reviewed in the IETF.
Publication of this document does not mean endorsement by the IESG
or the IETF (or SNMP) community.
And also FIX some problems:
- The suggestion on page 6, bullet (b) is questionable:
(b) an agent must return `inconsistentValue' if the complexity of
the SetRequest-PDU exceeds the agent's ability to perform consistency
checking: e.g. if the PDU contains any other variable. If an agent
Many people will think that a 'genErr' is more appropriate. The author
may have a defendable position. If so, it would be good to add that.
- Section 3.2 is believed to be conflicting with the RFC 3416 specification,
sect 4.2.5, specifically the text on page 22 towards the end of that
section 4.2.5.
Sect 3.2 of the internet-draft says:
Since the `commitFailed' error code does not convey any meaningful
information to NMS, an SNMP agent may substitute some meaningful
error code (e.g. `resourceNotAvailable') for such cases. An SNMP
agent should not ever find itself in the situation where it will
return `undoFailed'.
And so that recommendation should be taken out.
If the intention is to indicate that an SNMP agent should try its
utmost to first do as much checking as possible (rfc3416 says so too)
and if it concludes that committing the SET operation would fail,
that it then sends a 'resourceNotAvailable', then that is fine.
But that is not what it says.
And RFC3416 clearly states that IF a commit fails, then you MUST
return a commitFailed. And if an undo fails, then you MUST return
an undoFailed.
And that we have suggestions for changes as follows:
- Change the title from
Developing High Quality SNMP Agents
into something aka:
Considerations for SNMP agent developers
Justification:
- the doc itself is (in my view) not high quality itself.
- the doc discussus only a small part of the whole problem
space and the many tricky things in SNMP agent development
- one needs to be an SNMP expert to understand what is
being described.
- Change the "recommendations", i.e.
- The author often speaks like "It is recommended", where
it seems to make more sense to say "I recommend"
- References need to be made to the new SNMP STD documents (that
is in the 341x range instead of 257x range). We understand that
those were not yet RFCs when the I-D was submitted to RFC-Editor.
- Instead of talking about an "index string", we strongly recommend
to talk about an "index sequence". Otherwise people too easily
think about an ascii representation of OID components in the
dotted notation, and the author means an array (or sequence) of
unsigned integers that represent OID components (or sub-IDs).
- Same for "string of Object Identifiers"
- In many places, when the author talks about "OID" he really means
an OID component (i.e. one unsigned integer instead of a
sequence of unsigned integers).
- Bullet 3 on page 4 and 5. Strongly recommend to move the 1st
sentence of the last para (i.e.
This OID range checking must start at the end of index string and
progress towards its beginning.
to the beginning of bullet 3. Otherwise it is impossible to
understand what the steps mean.
- We suggest that the author explains what he means by non-implied
and explains that it is about INDEX objects that have the keyword
IMPLIED associated with it. SO it would then also be better to
us non-IMPLIED instead of "non-implied".
Layer 2 Virtual Private Networks (l2vpn)
-----------------------------------------
Charter
Last Modified: 2003-06-09
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: 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:
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--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--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.
The group will review proposed protocol extensions for L2VPNs before
they are recommended to appropriate protocol-specific WGs.
As a specific example, this WG will not define new encapsulation
mechanism, but will use those defined in the PWE3 WG.
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 service parameters
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 and VPWS.
6. Interworking of IP devices connected to an IP-only L2 VPN using
dissimilar attachment circuits. This topic will be explored only
after the basic L2VPN services (VPWS, VPLS, and IP L2VPN) are
defined.
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
FEB 2004 Submit MIB for VPWS to IESG
MAR 2004 Submit OAM for VPLS to IESG
MAR 2004 Submit OAM for VPWS to IESG
Path Maximum Transmission Unit Discovery (pmutd)
------------------------------------------------
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.
Layer 3 Virtual Private Networks (l3vpn)
-----------------------------------------
Charter
Last Modified: 2003-06-09
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:
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. The group 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 CE Route Authentication to IESG for publication as PS
(draft-ietf-ppvpn-l3vpn-auth-03)
March 2004 Submit specification of OSPF as the PE/CE Protocol in BGP/MPLS VPNs for publication.
(draft-rosen-vpns-ospf-bgp-mpls-06.txt)