DECADE WG Minutes Meeting: IETF-81, Tuesday, 15:20 -- 17:00, Quebec City, 2011-07-26 Location: Room 206B, Hilton Quebec Chairs: Haibin Song and Richard Woundy Responsible AD: David Harrington Note takers: Carl Williams [carlw@mcsr-labs.org], edited by Rich Woundy and Haibin Song [These minutes represent a condensed summary of the meeting. Fully detailed discussions can be heard on the audio recording of the meeting, currently found at http://www.ietf.org/audio/ietf81/ietf81-206b-20110726-1256-pm.mp3, starting at offset 02:28:51 and finishing at offset 04:07:29.] Chairs open the meeting at 17:40. Presentation - DECADE Chair Slides Speaker: Richard Woundy Materials: http://www.ietf.org/proceedings/81/slides/decade-0.pdf [Audio Offset 02:31:15] Agenda: 1. Agenda bashing 5 mins – 1520-1525 2. DECADE Architecture - 20 minutes 1525-1545 Richard Alimi – draft-ietf-decade-arch-02 3. Requirements – 20 minutes 1545-1605 Richard Alimi draft-ietf-decade-reqs-03 4. URIs for Named Information – 10 minutes 1605-1615 Stephen Farrell draft-farrell-ni-00 5. Rechartering Discussion – 40 minutes 1615-1655 Chairs 6. Conclusion and next steps – 5 minutes 1655-1700 Status of DECADE Drafts: The authors of draft-ietf-decade-problem-statement-03 are working on a revised version to respond to AD review. Hannes Tschofenig agreed to help with the security review of the problem statement. The authors of draft-ietf-decade-survey-04 are awaiting feedback from IESG review (telechat on August 11). Akbar Rahman: We received 2 comments on the DECADE survey; one comment was from Phillip Hallam-Baker from the security directorate. Phillip was thinking that DECADE would be used for an emergency backup scenario. He noted that this is a survey so he does not have any security concerns, but on other hand he is concerned about how access authorization was covered in the survey. Richard Woundy: These were "meta" security concerns about the protocols discussed in the survey. Is this a big concern? David Harrington: Phillip makes two points. Security analysis as presented in the draft is not useful. It was insufficient analysis in that it was discussing security of 'at rest' storage. I agree it was insufficient analysis but this is an informational document so it may not require this level of security. I am not convinced the document requires it. I will discuss with the directorate and will let the authors know if they require any additional response. The authors are preparing draft-ietf-decade-reqs-03 and draft-ietf-decade-arch-02 for working group last call after expert reviews. (See minutes below for additional discussion.) The document draft-ietf-decade-integration-example-01 has been accepted as a working group draft and in need of expert review. [Audio offset: 02:43:00] Presentation - Architecture Speaker: Richard Alimi Draft: draft-ietf-decade-arch-02 Materials: http://www.ietf.org/proceedings/81/slides/decade-1.pdf Richard Alimi said that draft went under expert reviews by working group members Martin Stiemerling, David McDysan and Borje Ohlman. See slides for major changes to the I-D. Richard Alimi said that the DRP and SDT are logically separated, but not necessarily physically separate. He moved some use cases from the problem statement to this doc. Richard Alimi noted that he added new section on Discovery, which is not intended to provide discovery of DECADE Servers used by other DECADE clients. Richard Woundy: This version was based on 3 reviewer's comments and others who read the draft. Ten people indicated that they had read the architecture draft. ** HUM TEST: Is the architecture draft ready for working group last call? ** HUM RESULT: The room agrees with starting working group last call. This will be conducted on the mailing list. [Audio offset: 02:51:55] Presentation - Requirements Speaker: Richard Alimi Draft: draft-ietf-decade-reqs-03 Materials: http://www.ietf.org/proceedings/81/slides/decade-2.pdf A couple of new requirements to fill in some gaps were incorporated into the -02 revision on May 17. A -03 revision was submitted right before meeting on July 11 based on review comments received from Dave McDysan and Akbar Rahman. Richard Woundy: It would be good to have one more expert review, since we prefer to have three. Borje Ohlman agreed to provide a third review. New requirements were added to the draft to fill in gaps. One new requirement provides a mode for data to pass over a secure transport. Another new requirement specifies unique names. DECADE clients need to discover suitable DECADE servers, and discovery should work even if clients are behind NATS and firewalls. Richard Alimi noted that in Akbar's expert review, Akbar had asked whether metadata should be immutable or not. Are we going to provide metadata at all for objects? Metadata are envisioned to be name-value pairs attached to objects. If metadata is immutable: - Not too bad to handle, aside from object naming issue. - Are we giving up too much flexibility? If metadata is not immutable: - Locking and caching issues -- both for intermediaries and within applications Richard Yang: Please do not associate metadata with data chunks. This might be contradicting our goal – decoupling of control and data. We do need some metadata information, such as hash and naming. A small limited set of metadata might be acceptable. Do not store name-value pairs as objects themselves. Richard Alimi: We envisioned to leave them separate anyways. The DECADE server would need to know the name anyways. We are talking about arbitrary data that a DECADE client or application can attach to the object. Richard Yang: can you give use case that this metadata will be very useful? Richard Alimi: Suppose you have a live streaming client and you have a bunch of chunks that you download from a DECADE server. Then you want to resume that stream on a different device. The new device could go to the DECADE server, find what chunks are there already, and start downloading them. If you do not have this shared state on the DECADE server, than the application has to figure out a way to get that directory of what is actually at the DECADE server over to your new device. If this is a specific and limited use case then we can ignore it. Richard Yang: The DECADE server will need to build an inverted index database. That means that metadata at the DECADE server is not transparent and not opaque. DECADE servers need to understand semantics of all the metadata or at least some of the metadata. Richard Alimi: If you wish to return a filter list, then I agree. Yunfei Zhang: I have same opinion as Richard Yang. I think that metadata should be kept inside of the application, to deal with the correspondence between the metadata and real data. This is not the job of the DECADE server. Ed Simon: (stated he is passing through the working group as a "tourist") Authorization seems to be an important part of DECADE. Fine grained access to objects is based on metadata associated with the resource. It would seem good to support metadata associated with fine grain authorization in DECADE. Metadata with a strong binding to the data object itself is useful. Not necessarily for the application itself. Richard Woundy: Do you think such metadata is immutable or mutable? Ed Simon: Some metadata may be mutable. Access control lists may change over time. Richard Alimi: Some of that can be done at the application layer. One way to deal with authorization is if you give a token to somebody for access to the object, you do not give them the token if they should not have access. You may give them the token associated with a window of time of access. The application decides if that client should be given the token, and if so what are the parameters for it. The DECADE server determines whether the token is valid, and if so then give them the object. A decision has to be made – the application may decide this before giving out a token, as opposed to the DECADE server deciding it. Ed Simon: I was thinking the policy decision point is a different party, that might not be in the application. There are valid scenarios either way. Richard Alimi: It might be useful for you to point us to use cases where you do not put this in the application. For example, where it must be at the server. Ed Simon: I am thinking of gateways between networks or something like that. Something acting as a guard. The guard is saying whether you have access to data or not. David Black: The more specification of metadata you include, the more functionality you pull into the server. If you have to index individual key-value pairs, you have a lot of work to do. I recommend you go back and look at the use cases and find out what minimal amount of metadata you can get away with to satisfy those use cases, and draw the line there. Richard Alimi: 3 out of 4 people seem to be against the inclusion of metadata. Haibin Song: Do the authors think we can resolve this question before we take this to working group last call? Richard Alimi: Yes, this will impact the protocol. Richard Woundy: Do the authors have enough direction from the working group to answer the question? Richard Alimi: I believe so. David Harrington: This discussion should go to the mailing list. Richard Yang: I assume we are not moving in the direction of highly classified data. We assume this is consumer level information. Richard Woundy: Individually speaking, I agree with direction this discussion is going in - define as little metadata as possible. In CDNi, they have to worry about all this other metadata (content lifetime, etc) for distributing content to consumer grade equipment. I would not want to toss metadata completely away. But we should not drag it in if we do not have to. Richard Alimi: This is a matter of tightening up draft to say that it will be metadata needed by the DECADE server to do its job, otherwise it is the application's job. Eight people indicated that they had read the architecture draft. ** HUM TEST: Is the requirements draft ready for working group last call? ** HUM RESULT: While the majority of the room agrees with starting working group last call, there was one objection. The objector (David Black) wants resolution of the metadata issue before last call. The authors and the room agreed that the issue will be resolved on the mailing list first, a new revision would be posted, and the expert reviewers would review the draft before starting working group last call. David Harrington: In today's security directorate meeting, there were potential issues raised about privacy in the DECADE work. Are our security considerations making sure we are taking care of privacy issues? Richard Alimi: We do not explicitly mention it now, but we could. We could take care of this while we close the metadata issue. Stephen Farrell (Security Directorate): Our concerns were not very specific. If these caches were deployed, they may include user tracking and advertisements. This is not a detailed protocol point. There may be a need for tightening later. Good to think about it; it may be an easy item to address. Richard Woundy: Are the privacy issues about 'data at rest' or about network privacy 'data in motion'? Steve Farrell: Concern today was not very specific. We do not need a huge essay about everything. Note that these concerns may need tightening later. David Harrington: My impression of the discussion is that there are no guidelines at this point for what should be in the privacy points. When the security directorate review is done, we cannot predict what will be raised in terms of the privacy concerns, but be prepared that people may raise questions on privacy. David Black: There is something related that you might want to think about. This may be more on next draft (naming) than this one. You are using content hashes for addresses, and if data is in more than one place than it is going to have the same content hash. That makes it useful to do some interesting correlations. In particular, I can figure out the people who access the same data because it turned up in caches with the same hash – I can see the same hash go by on the wire even though I cannot get the hash out of the data. You can see the direction this is going; the object name provides for some interesting tracking possibilities. Looking outward from network of who is accessing objects, as opposed to looking in of who is accessing. There are interesting opportunities to disclose commonality of things that maybe should not have been exposed. I just want to put this on your radar screens since the word 'privacy' came up. [Audio offset: 03:25:40] Presentation - URIs for Named Information Speaker: Stephen Farrell Draft: draft-farrell-ni-00 Materials: http://www.ietf.org/proceedings/81/slides/decade-3.pdf (note: slide 2 was corrected after the meeting to say "location-independent" instead of "location-specific") Stephen asserted that there is an emerging need for naming resources uniquely without being specific about location. The draft was pushed out after the IETF meeting in Prague. The DECADE architecture calls for something similar to this. DECADE needs way to deal with these hashes. This draft gives you an option. Richard Woundy: Are you on the Apps Area agenda? Stephen Farrell: Not at this IETF meeting. David Black: Let me make a comment that IPSEC has been truncating hashes for quite a while now, and there has been some good experience over there; those are typical keyed hashes that are used for content integrity, but not used for the identification purposes that you have in mind here. Stephen Farrell: There are a bunch of applications here that can live with very short truncated hashes. Yunfei Zhang: I remember another proposal (Borje) presented in the DECADE working group. This is a common problem for many information centric working groups (PPSP, DECADE). Why not form a naming working group? Stephen Farrell: The danger with naming working group is that it would boil the ocean (too much process). Richard Yang: Suppose I have content and assign names. Then suppose I operate server A, and I don't trust server B. The content is on both servers, and server A wants to verify that server B has the content. Using the named hash scheme can we do a simple verification? Is there some way to challenge it? Stephen Farrell: You can do that, but I do not think that you want to embed that information in the name. There are ways to do that, such as challenge-response. I think there is some related IPR that comes to mind. You could start embedding lots of stuff in the name. Richard Woundy (to Richard Yang): Are you talking about challenge response or integrity checking? Richard Yang: I am talking about challenge response. If the naming scheme can verify this very easily, than it would be helpful in terms of the scenario I described. Akbar Rahman: What is confusing to me is that this approach expands beyond DECADE. Can you explain the key parts that are applicable to DECADE? Would the new URI scheme be mandatory for DECADE? Stephen Farrell: I do not know. Richard Woundy: That might be a working group decision. Stephen Farrell: It could be that you inherit the hash scheme or also use these URIs. Richard Woundy: Our DECADE work does need a unique naming scheme, so it might be interesting -- especially if it were to be adopted by the Apps Area, so we leverage a naming scheme that goes beyond the scope of DECADE. Conversely, if it does not make sense to have a cross-app scheme for named information, I think than it might make sense to take this and simplify it. What would we absolutely need for DECADE, and take some variation of that and use it in DECADE. Akbar Rahman: If in DECADE we use HTTP as one of protocols, how would this scheme work with the existing URI schemes for example. Wesley Eddy: I am thinking that this is just a URI scheme – pretty simple. If we think that we need it, then we should do it here and not send it to Apps Area to see if they want to do it or not. Stephen Farrell: It makes sense to check with Apps Area list to see if it is useful. Stephen Farrell: There is no IPR in this draft. David Harrington: My leaning is that (not making any decision at this point) a good naming scheme could be useful in a number of working groups in the IETF. I like to see it socialized wider to find out who else has interest. One way to do that is with a non-working group forming BOF. That may be more work than justified with such a short draft. Then this may not be the only proposal. Socializing to the Apps Area may be enough but I have to be convinced of that. The problem that I have is that I do not know who else may be interested in this. As the responsible AD for STORM and NFS, they may have naming requirements and may have solutions already. Once it is socialized wider and see who is interested in this, then we can make decision if this can be chartered in DECADE. Stephen Farrell: I want to clarify that applications should not be required to verify a name; therefore an application does not have to see all of the object data in order to validate the hash. [Audio offset: 03:47:15] Presentation - DECADE Re-chartering Discussion Speaker: Richard Woundy Materials: http://www.ietf.org/proceedings/81/slides/decade-4.pdf The rechartering discussion started in Prague. The working group's responses to questions about re-chartering were provided -- see slides. David Black: Question on iSCSI, what is the typical size of objects being stored? Richard Alimi: Anywhere from 64 kilobytes and up. But probably not more than 1 Megabyte or so. David Black: The size is reasonable for iSCSI; but need a filesystem in the stack somewhere. Richard Woundy: OAUTH is directionally helpful even if it does not solve all our authorization problems. Richard Woundy: Should DECADE rely on a single name format? We have not resolved that yet. That is part of the reason we had the discussion on named information by Stephen. Richard Woundy went over some thoughts on data transport. DECADE does not appear to need most of the NFS mechanisms. DECADE is not a general file store, does not need file locking, and only needs a flat namespace. WebDAV is interesting but DECADE does not need WEBDAV collections or file locking from what we can tell. (Richard Woundy: The assertions are meant to provoke discussion.) David Harrington: A general comment or warning –- security protocol designers have said that they do not need all these features and by time they are done they have all the features in and perhaps worse. Same thing for transport and network management. Just be careful that you may need these mechanisms. Richard Woundy: This is no where near working group consensus. Some people out there believe this, and we need to resolve this before we can re-charter. David Harrington: In many cases the heavy weight protocols that exist allow you to turn off a lot of things and use a subset of functionality. David Black: There are three protocols you are talking about, and one of them is not a storage protocol. That would be HTTP. Knock HTTP out of scope and start with WebDAV and see if you can subset it. If you start with HTTP, then you are inventing a new storage protocol, and think about how close to WebDAV that that slippery slope is going to get you. Akbar Rahman: I am not a proponent of HTTP but would like to point out that Google storage and other protocols/ systems use HTTP as part of their storage systems. It is accurate to say that HTTP by itself does not provide you with a pure storage system. Google uses OAuth to fulfill the authorization needs. They do some extensions on HTTP and that is missed here. Richard Alimi: I agree with David's comment that it warrants making sure that we see what we can do with WebDAV. Richard Woundy: Start with WebDAV and subtract rather go to HTTP and add. Mike Eisler: Note that the cloud data management protocol (Cloud Data Management Interface) is becoming an ISO standard. That might be something else you can consider. You can Google for CDMI. Richard Woundy: We did not cover CDMI in the DECADE survey. Akbar Rahman agrees to add CDMI to the survey. David Harrington: The survey is scheduled for the next IESG telechat for approval. This seems like an important omission. Richard Alimi: If it helps make the draft more complete, than it is good idea. Akbar Rahman: If we do quick update in next few days, can we continue with the telechat approval? David Harrington: I will warn IESG that we will send an updated draft only with the new change for CDMI. Richard Woundy: Authors, only add the CDMI section and no other changes. Mike Eisler: What about Amazon S3? Akbar Rahman: We do have Amazon S3 in the survey. Richard Woundy: What we are talking about is a strawman of potential re-chartering. We need to take to the mailing list the 'WebDAV minus' proposal, and also look at CDMI and decide if a 'CDMI minus' makes sense. Richard Woundy: OAUTH 2.0 seems like the preferred authorization protocol we are looking at. We will now have to see how it fits in with CDMI. DECADE may need an OAUTH extension. This is part of investigation. We have to make sure that OAUTH fully meets the requirements and needs of the overall solution. Richard Alimi: If we went with NFS in the future and chose OAUTH 2.0, that might present a large problem. How much do we care about this? Richard Woundy: If we use NFS today, would we use a different authorization mechanism –- say, one that is built into NFS? Then we might use OAUTH for HTTP-based mechanisms. David Harrington: We are here to develop interoperable standards. So if you have too many optional pieces that plug together, you may lose interoperability. For example, adding NFS later may not be beneficial. Richard Woundy: We do need a naming scheme. It must be location agnostic. We had this discussion at the end of Stephen's talk. Richard Woundy: Does DECADE require a discovery mechanism? If so, what is the approach? Should we use ALTO discovery as a model? Richard Woundy: Do we handle anything other than P2P applications? We should look at the requirements draft to see what it says about the application domain. Richard Woundy: Let's take the rest of the re-chartering discussion to the mailing list. That is it.