Candidate Access Router Discovery (CARD)
draft-ietf-seamoby-card-protocol-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Thomas Narten |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Steven Bellovin |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Alex Zinin |
2004-11-11
|
(System) | Posted related IPR disclosure: Nortel Networks Statement about IPR claimed in draft-ietf-seamoby-card-protocol | |
2004-10-04
|
08 | Allison Mankin | State Change Notice email list have been change to , from , |
2004-09-23
|
08 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2004-09-21
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent |
2004-09-21
|
08 | Amy Vezza | IESG has approved the document |
2004-09-21
|
08 | Amy Vezza | Closed "Approve" ballot |
2004-09-21
|
08 | Allison Mankin | Note field has been cleared by Allison Mankin |
2004-09-21
|
08 | Allison Mankin | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Allison Mankin |
2004-09-21
|
08 | Allison Mankin | [Note]: 'Picked up a new Discuss - fixable - from GEN-Art. Russ had to miss telechat. Emailed him to ask for re-review.' added by Allison … [Note]: 'Picked up a new Discuss - fixable - from GEN-Art. Russ had to miss telechat. Emailed him to ask for re-review.' added by Allison Mankin |
2004-09-14
|
08 | (System) | New version available: draft-ietf-seamoby-card-protocol-08.txt |
2004-09-03
|
08 | Alex Zinin | [Ballot Position Update] Position for Alex Zinin has been changed to No Objection from Discuss by Alex Zinin |
2004-07-12
|
08 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2004-07-12
|
08 | Allison Mankin | [Note]: 'Picked up a new Discuss - fixable - from GEN-Art. Russ had to miss telechat. Emailed him to ask for re-review. ' added by … [Note]: 'Picked up a new Discuss - fixable - from GEN-Art. Russ had to miss telechat. Emailed him to ask for re-review. ' added by Allison Mankin |
2004-07-12
|
08 | Allison Mankin | [Note]: 'Picked up a new Discuss - fixable - from GEN-Art. ' added by Allison Mankin |
2004-07-09
|
08 | (System) | Removed from agenda for telechat - 2004-07-08 |
2004-07-08
|
08 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2004-07-08
|
08 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-07-08
|
08 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
2004-07-08
|
08 | Bert Wijnen | [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen |
2004-07-06
|
08 | Steven Bellovin | [Ballot Position Update] Position for Steve Bellovin has been changed to No Objection from Discuss by Steve Bellovin |
2004-07-05
|
08 | Alex Zinin | [Ballot discuss] Gen-art reviewer Joel M. Halpern : > This draft is on the right track but has open issues, described in the review. > … [Ballot discuss] Gen-art reviewer Joel M. Halpern : > This draft is on the right track but has open issues, described in the review. > It should not be hard to fix the problems, but it appears to me that the > current sub-option structure ought to be a show stopper. Sorry. > Significant concern: > The specification indicates that the TLV encoding for the sub-options uses > a length whose units depend upon the type of the sub-option. This means > that we can never (okay, maybe "only with great care, good luck, and > difficulty") introduce new optional sub options, since if they arrive at an > un-upgraded system the system will not be able to determine the length, and > so will not be able to parse the packet. > I presume this was done because some options will not fit in 255 bytes. > Will they all fit in 1020 bytes? If so, all sub-option lengths could be in > multiples of 4 (sub-options are required to be multiples of 32 bits by > other wording in the spec.) > Sub-options could be required to be a multiple of 8 bytes, and lengths in > units of 8 bytes. > Alternatively, a bit or two could be taken out of the sub-option type to > explicitly indicate the resolution of the sub-option length. > Or sub-option lengths could be 12 bits, with sub-option types only 4 bits > (or 11 and 5). > I am sure that there are other alternatives. > Section 5.1.4 defines the Capability AVP. The diagram explicitly shows a 1 > octet AVP length, and one Reserved octet. The text indicates that the AVP > Length is two octets. Which is it? |
2004-07-05
|
08 | Alex Zinin | [Ballot Position Update] New position, Discuss, has been recorded for Alex Zinin by Alex Zinin |
2004-06-30
|
08 | Allison Mankin | Placed on agenda for telechat - 2004-07-08 by Allison Mankin |
2004-06-30
|
08 | Allison Mankin | State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Allison Mankin |
2004-06-30
|
08 | Allison Mankin | [Note]: 'Re-review only - revision was done for the Security ADs and the IANA issues. Thomas and IANA have already cleared the IANA. Would be … [Note]: 'Re-review only - revision was done for the Security ADs and the IANA issues. Thomas and IANA have already cleared the IANA. Would be BLUE Team if it was new.' added by Allison Mankin |
2004-06-24
|
08 | Thomas Narten | [Ballot Position Update] Position for Thomas Narten has been changed to No Objection from Discuss by Thomas Narten |
2004-06-09
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2004-06-09
|
07 | (System) | New version available: draft-ietf-seamoby-card-protocol-07.txt |
2004-03-30
|
08 | Allison Mankin | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Allison Mankin |
2004-03-30
|
08 | Allison Mankin | [Note]: '"Experimental" Experimental - revision is being worked for Security and icmp type issues that were raised.' added by Allison Mankin |
2004-03-30
|
08 | Allison Mankin | [Ballot comment] Jim Kempf is addressing Thomas/Ted comments by putting the ICMP in one exper type for all mobile expers - separate i-d. I have … [Ballot comment] Jim Kempf is addressing Thomas/Ted comments by putting the ICMP in one exper type for all mobile expers - separate i-d. I have cleared a worry I had about transport congestion because the protocol is only inter-router. Here is some information about addressing the Sec ADs' concerns: Date: Mon, 22 Mar 2004 16:21:08 -0500 From: Russ Housley To: "James Kempf" , "Steve Bellovin" cc: ,"Kempf" Resolves my concerns ..... Russ At 12:58 PM 3/12/2004 -0800, James Kempf wrote: >Hi Steve and Russ, > >With reference to your discuss comment on >draft-ietf-seamoby-card-protocol-06.txt >(https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=965 >8&rfc_flag=0, 2004-2-18), I rewrote the Security Considerations section to >address the comments. I've attached the revised section and a copy of the >old section for your reference, and would like to get comments about whether >you think it adequately addresses your concerns. In particular, I took >Steve's suggestion to use the SEND SA for the router to host authentication, >and Russ's points about lack of attention to key distribution on the router >to router SA. I also fixed a bunch of other issues that I think needed >attention. > >Please let me know if this is acceptable, or if further work is necessary. >Thanx. > > jak |
2004-02-19
|
08 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2004-02-19
|
08 | Thomas Narten | [Ballot discuss] Agree with Ted's concern, and this isssue is already being discussed in the context of two mipshop documents. Need to think a bit … [Ballot discuss] Agree with Ted's concern, and this isssue is already being discussed in the context of two mipshop documents. Need to think a bit on the best way to handle this. |
2004-02-19
|
08 | Thomas Narten | [Ballot Position Update] New position, Discuss, has been recorded for Thomas Narten by Thomas Narten |
2004-02-18
|
08 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2004-02-18
|
08 | Ted Hardie | [Ballot comment] This seems to be a very large consumption of IANA resources for an experimental protocol: The protocol described in this document requires … [Ballot comment] This seems to be a very large consumption of IANA resources for an experimental protocol: The protocol described in this document requires a new ICMP type to be assigned by the IANA for the CARD protocol main header (Section 5.1.1). Furthermore, two new ICMP option types (Section 5.1.2) are to be assigned for the protocol operation between a Mobile Node and its current Access Router for the Mobile IP Fast Handover Protocol [Kood03] and for the standalone use of CARD between the MN and AR. The protocol also requires a UDP port number to be assigned for the inter-Access Router CARD protocol operation (Section 5.2.1). To uniquely identify specific access technologies in the L2-Type field of a CARD L2 ID sub-option, the IANA should also set up a registry to assign fixed numbers for well-known access technologies (Section 5.1.3.1). Initially, values for IEEE802.11a, IEEE802.11b and IEEE802.11g should be assigned. To allow MNs receiving unsolicited CARD Reply messages only in case they are of interest to them, a well-known multicast IP address for IPv4 and IPv6 (link-local) needs to be assigned by IANA for that purpose (section 7). Are there ways to offload this during the experimental phase so that some of the effort is spared and some of the values not permanently burned during the testing? I have to say that the overall design seems quite heavyweight for the purpose, especially in the expectation that each AR will maintain the tables of both L2 to IP mappings and capabilities. I'd be curious to hear more about the environments where this is expected to see deployment (especially where the unsolicited multicast "reply" messages are expected to be useful, since they seem to get to be large table dumps in some of the deployments I could imagine). |
2004-02-18
|
08 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie |
2004-02-18
|
08 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to Undefined from Discuss by Ted Hardie |
2004-02-18
|
08 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to Discuss from Undefined by Ted Hardie |
2004-02-18
|
08 | Ted Hardie | [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie |
2004-02-18
|
08 | Steven Bellovin | [Ballot discuss] I agree with Russ' comments on establishing IPsec SAs. Beyond that, how does a mobile node know who is authorized to be an … [Ballot discuss] I agree with Russ' comments on establishing IPsec SAs. Beyond that, how does a mobile node know who is authorized to be an AR? This is especially problematic when roaming between domains. Protecting ICMP messages with IPsec can be difficult. The authors need to do a full-fledged design to make sure that it can be done. The experience of the SEND group may be relevant. What in the CARD messages may need to be confidential, and hence require encryption? The analysis needs to be done here, so that users of this spec know when to turn it on. |
2004-02-18
|
08 | Steven Bellovin | [Ballot Position Update] New position, Discuss, has been recorded for Steve Bellovin by Steve Bellovin |
2004-02-18
|
08 | Russ Housley | [Ballot discuss] Section 4.6 and section 5.2.1 say: > > IPSec ESP MUST be used with a non-null integrity protection and > … [Ballot discuss] Section 4.6 and section 5.2.1 say: > > IPSec ESP MUST be used with a non-null integrity protection and > origin authentication algorithm and SHOULD be used with a non-null > encryption algorithm for protecting the confidentiality of the CARD > information. > This is not sufficient. Where do the cryptographic keys come from? Is IKE required? I expected section 6.3 to discuss the establishment of security associations for IPsec ESP, but it does not. |
2004-02-18
|
08 | Russ Housley | [Ballot comment] Expand 'AP' and 'PCF' the first time they are used. In section 3.2: s/optimized handover/optimal handover/ |
2004-02-18
|
08 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley |
2004-02-12
|
08 | Allison Mankin | Placed on agenda for telechat - 2004-02-19 by Allison Mankin |
2004-02-12
|
08 | Allison Mankin | State Changes to IESG Evaluation from Publication Requested by Allison Mankin |
2004-02-12
|
08 | Allison Mankin | [Note]: '"Experimental" Experimental' added by Allison Mankin |
2004-02-12
|
08 | Ned Freed | [Ballot comment] Nit: (date) in copyright boilerplate Question: Is the IPR section on this document the right thing to have under the new rules? |
2004-02-12
|
08 | Ned Freed | [Ballot Position Update] New position, No Objection, has been recorded for Ned Freed by Ned Freed |
2004-02-12
|
08 | Allison Mankin | [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin |
2004-02-12
|
08 | Allison Mankin | Ballot has been issued by Allison Mankin |
2004-02-12
|
08 | Allison Mankin | Created "Approve" ballot |
2004-02-12
|
08 | (System) | Last call text was added |
2004-02-12
|
08 | (System) | Ballot approval text was added |
2004-01-16
|
08 | Dinara Suleymanova | State Changes to Publication Requested from AD is watching by Dinara Suleymanova |
2004-01-16
|
08 | Dinara Suleymanova | Intended Status has been changed to Experimental from Proposed Standard |
2004-01-14
|
06 | (System) | New version available: draft-ietf-seamoby-card-protocol-06.txt |
2003-11-20
|
05 | (System) | New version available: draft-ietf-seamoby-card-protocol-05.txt |
2003-09-24
|
04 | (System) | New version available: draft-ietf-seamoby-card-protocol-04.txt |
2003-08-20
|
03 | (System) | New version available: draft-ietf-seamoby-card-protocol-03.txt |
2003-08-11
|
(System) | Posted related IPR disclosure: Nokia's Statement about IPR claimed in draft-ietf-seamoby-card-protocol | |
2003-07-01
|
02 | (System) | New version available: draft-ietf-seamoby-card-protocol-02.txt |
2003-04-28
|
(System) | Posted related IPR disclosure: Nokia's Patent Statement Pertaining to draft-ietf-seamoby-card-protocol-01.txt | |
2003-03-18
|
(System) | Posted related IPR disclosure: DoCoMo USA Labs' Patent Statement pertaining to draft-ietf-seamoby-card-protocol-01.txt entitled 'Candidate Access Router Discovery' | |
2003-03-07
|
01 | (System) | New version available: draft-ietf-seamoby-card-protocol-01.txt |
2003-02-27
|
08 | Allison Mankin | State Changes to AD is watching from Publication Requested by Mankin, Allison |
2003-02-27
|
08 | Allison Mankin | Draft Added by Mankin, Allison |
2002-11-01
|
00 | (System) | New version available: draft-ietf-seamoby-card-protocol-00.txt |