[prev in list] [next in list] [prev in thread] [next in thread]
List: cifs-protocol
Subject: Re: [cifs-protocol] [REG:111061069959469] BranchCache and SMB2:
From: Edgar Olougouna <edgaro () microsoft ! com>
Date: 2011-06-17 15:48:52
Message-ID: E827A438BE2C9B4982EDA46E6B717188012DD41D () TK5EX14MBXC286 ! redmond ! corp ! microsoft ! com
[Download RAW message or body]
Chris,
Regarding the question on the server secret, I will be replying shortly and describe \
the algorithm in a new thread [REG:111061756137964] Encryption of the key for "netsh \
branchcache" importkey and exportkey. That way you can achieve the decryption of the \
exported server secret and verify your implementation.
Regarding your feedback on the glossary definition of "segment secret" in \
[MS-PCCRC]... I have passed on your observations to the product team.
Thanks,
Edgar
-----Original Message-----
From: Christopher R. Hertel [mailto:crh@ubiqx.com]
Sent: Friday, June 17, 2011 12:11 AM
To: Edgar Olougouna
Cc: cifs-protocol@samba.org
Subject: Re: [cifs-protocol] [REG:111061069959469] BranchCache and SMB2: Questions \
specific to BranchCache.
Edgar,
Thanks for the clarifications.
Regarding the dwOffsetInFirstSegment and dwReadBytesInLastSegment fields...
I have a working prototype, written as a CGI script and running under Apache. It \
seems to be giving correct results, when compared to a W2K8r2 server, but I cannot \
verify that I am correctly generating the Segment Secret correctly because I do not \
know the Server Secret generated by the Windows server.
I can extract the Windows Server Secret using a netsh command, but the command \
encrypts the Server Secret with a password, and I do not know what algorithm is used \
to perform the encryption. If I did, I could decrypt the Server Secret and use it in \
my test program to verify that I am generating the hash correctly.
Do you know where I could find documentation that would tell me what algorithm is \
being used to encrypt the extracted Server Secret?
Regarding the glossary definition of "segment secret" in [MS-PCCRC]...
I would suggest that the use of "authenticated" in the context of the description of \
"segment secret" is misleading. [MS-PCCRC] covers a variety of server types, and in \
many cases there is no authentication required. I'm testing using HTTP, for example, \
and my client is being given Content Information without performing any sort of \
authentication.
The fact that SMB2 requires authentication before providing access to a content or \
content information is an aspect of SMB2, not BranchCache. There is no authorization \
required by the Peer Content Caching and Retrieval: Content Identification protocol \
itself.
Thanks.
See you next week.
Chris -)-----
Edgar Olougouna wrote:
> Chris,
>
> For the question regarding "authorized client", BranchCache considers possession of \
> the Content Information data structure to be equivalent to possession of data for \
> access control purposes. If a client was able to obtain hashes from a file server, \
> we will allow that client to retrieve data from peers or the hosted cache server. \
> A file server is expected to protect the content information data structure the \
> same way it protects actual files. If a file server authenticates and authorizes \
> clients before allowing them to read files, it should do the same before providing \
> them with hashes.
> Yes, your interpretation regarding dwOffsetInFirstSegment and \
> dwReadBytesInLastSegment appears to be correct. Basically, \
> dwReadBytesInLastSegment is a count of bytes you can read in the last segment. If \
> the range is one segment long then the last segment is the only segment so \
> dwOffsetInFirstSegment and dwReadBytesInLastSegment both apply to it. If the range \
> is multiple segments long then dwOffsetInFirstSegment applies to the first segment \
> and dwReadBytesInLastSegment applies to the last segment.
> In my previous communication, it should be Windows Server 2008 R2 instead of \
> Windows 7. Only Windows Server 2008 R2 servers could be BranchCache servers, so \
> both OS versions cannot be used interchangeably in this case. Thanks for catching \
> this.
> Finally, I have passed on your feedback to the product team and suggested that an \
> example of range request being added to the document. Thanks again for the numerous \
> observations.
> Regards,
> Edgar
>
> -----Original Message-----
> From: Edgar Olougouna
> Sent: Friday, June 10, 2011 2:14 PM
> To: 'Christopher R. Hertel'
> Cc: cifs-protocol@samba.org
> Subject: RE: [cifs-protocol] [REG:111051857287367] BranchCache and SMB2: Questions \
> specific to BranchCache.
> Chris,
>
> Thanks for the numerous observations. I will review the questions and follow-up as \
> soon as I have an update.
> Regards,
> Edgar
>
> -----Original Message-----
> From: Christopher R. Hertel [mailto:crh@ubiqx.com]
> Sent: Friday, June 10, 2011 12:57 AM
> To: Edgar Olougouna
> Cc: cifs-protocol@samba.org
> Subject: Re: [cifs-protocol] [REG:111051857287367] BranchCache and SMB2: Questions \
> specific to BranchCache.
> Edgar,
>
> One more observation and another quick question:
>
> Question:
>
> The [MS-PCCRC] Glossary (section 1.1) gives the following definition:
>
> segment secret: The content-specific hash that is sent to authorized
> clients along with the rest of the content information. It is
> generated by hashing the concatenation of the segment hash of data
> and the server secret.
>
> What does the phrase "authorized clients" mean? How is a client
> authorized in this context?
>
> Observation:
> Now that I understand the purpose of the dwOffsetInFirstSegment and
> dwReadBytesInLastSegment fields it appears that the descriptions of
> these fields in [MS-PCCRC], though inscrutable, are plausible.
>
> In particular, the following now makes sense:
>
> dwReadBytesInLastSegment (4 bytes): Total number of bytes of the
> content range which lie within the final segment in the Content
> Information data structure.
>
> If the requested range includes multiple segments, then the offset
> of the dwReadBytesInLastSegment bytes to be read is 0, relative to
> the segment. What is interesting to note is that if the requested
> range is included in only ONE segment, then the
> dwReadBytesInLastSegment bytes to be read start at the offset
> indicated by dwOffsetInFirstSegment.
>
> Chris -)-----
>
>
> Christopher R. Hertel wrote:
> > Edgar,
> >
> > Thanks again for this reply. I have some comments which I hope you
> > will pass along to the documentation team and engineers.
> >
> > On Tue, May 31, 2011 at 08:43:22PM +0000, Edgar Olougouna wrote:
> > > Chris,
> > >
> > > Please find our answers as follows.
> > >
> > > BranchCache divides content into 32 megabyte segments and further
> > > subdivides these segments into 64 kilobyte blocks.
> > Yes. [MS-PCCRC] does a good job of explaining that part.
> >
> > > The content information encodes:
> > > (1) ullOffsetInContent - the offset within the content at which the
> > > first segment present in the content information begins and
> > Again yes, this makes sense to me.
> >
> > > (2) dwOffsetInFirstSegment - the offset from ullOffsetInContent at
> > > which the first block of the first segment present in the content
> > > information begins.
> > This is where things get confusing.
> >
> > > Let's walk through this with an example.
> > > Let's assume the client requests a content range starting at content
> > > offset 33554433 (a.k.a. 32 megabytes plus one byte) and extending
> > > for
> > > 10 bytes.
> > Problem #1 (for me): The examples given in the document specifically
> > state that they show requests for entire files. From section 3.1:
> >
> > "A client requests the entirety of the 125 kilobyte content from the
> > server. The server responds with Content Information of the following
> > form."
> >
> > > From section 3.2:
> >
> > "The same server S now receives a client request for a 125-megabyte
> > file."
> >
> > ...so, the examples in [MS-PCCRC] do not cover the use of ranges.
> > These are whole-file requests, so there is no example of how
> > dwOffsetInFirstSegment or dwReadBytesInLastSegment might be used
> > (though there are descriptions).
> >
> > > ullOffsetInContent will be 32 megabytes because that is where the
> > > first segment present in the content information begins.
> > Makes sense.
> >
> > > dwOffsetInFirstSegment will be 1 because the first segment in the
> > > content information is the second segment in the actual content
> > > because the requested content range starts at 32 megabytes plus one.
> > So... If I understand this correctly, the situation is that
> > BranchCache must operate in terms of Segments, and when it returns
> > the Segment Information for this segment, it is including an offset,
> > relative to the start of the Segment, at which the *requested* content begins.
> >
> > Is that correct?
> >
> > > dwReadBytesInLastSegment will be 10 because that is the length of
> > > the content range that lies within the final segment present in the
> > > content information.
> > If my new understanding of dwOffsetInFirstSegment is correct, then I
> > believe that my understanding of dwReadBytesInLastSegment is now also
> > correctly updated.
> >
> > Basically, if the client requests a range the server must send
> > Content Information covering the segments that completely include the
> > requested range. These two values indicate how to handle the cached
> > segments when the client retrieves them from the cache, as follows:
> >
> > dwOffsetInFirstSegment - Discard this many leading bytes of the first
> > segment retrieved from cache.
> >
> > Retain all bytes of all subsequent segments
> > retrieved from cache except the last one.
> >
> > dwReadBytesInLastSegment - Retain only this many leading bytes of the
> > last segment retrieved from cache.
> >
> > Is that correct?
> >
> > > Note that dwReadBytesInLastSegment may be zero if the client did not
> > > request a content range (i.e. the client asked for the entire content).
> > So a dwReadBytesInLastSegment value of zero is interpreted as "all bytes"
> > in the segment.
> >
> > > The scenarios in which dwReadBytesInLastSegment will be zero are
> > > Windows specific behavior. In Windows 7, this happens whenever the
> > > content information covers the entire content. In order to
> > > participate in the MS-PCCRC protocol, a client must be able to parse
> > > content information that contains a zero value for
> > > dwReadBytesInLastSegment. The client must react by treating the
> > > segment size for the final segment encoded in the content
> > > information as the amount of data in the final segment. If
> > > dwReadBytesInLastSegment is non-zero then the client must only
> > > attempt to read dwReadBytesInLastSegment from the final segment, regardless of \
> > > the segment size of the final segment.
> > Not quite... Assuming that I'm catching on here, and that such a bug
> > could happen, the goal would be something like the following:
> >
> > if 0 == dwReadBytesInLastSegment
> > readbytes = cbSegment
> > else
> > readbytes = min( dwReadBytesInLastSegment, cbSegment )
> >
> > If, due to some bug, the dwReadBytesInLastSegment were greater than
> > the number of actual bytes in the segment then you would still want
> > to read only the number of actual bytes in the segment. I can
> > envision something like this happing if the requested range extended
> > beyond the end of the Content and the server did not clean up the results \
> > properly.
> > Okay, so I am being picky here... but it serves to verify whether or
> > not I am understanding these fields.
> >
> > > On Windows 7, if the content fits in one segment and the client
> > > issued a request for the entire content then,
> > > dwReadBytesInLastSegment should be zero and dwOffsetInFirstSegment should be \
> > > zero.
> > It was my understanding, based on my reading of a number of several
> > MSDN web pages, that only Windows 2008R2 servers could be BranchCache servers.
> > Windows 7 systems could only be clients. Vista and Windows 2008
> > systems could also be clients if an additional package was installed.
> > (W2Kr2 servers can also be BranchCache clients, I believe.)
> >
> > The idea that Windows 7 cannot be a BranchCache Server is somewhat
> > supported by the following Windows Behavior note from [MS-PCCRC]:
> >
> > "<2> Section 2.3: In Windows 7, the [MS-PCCRR] implementation can only
> > accept segment IDs generated using SHA-256, whereas the Windows Server
> > 2008 R2 implementation of the hash generation part can generate segment
> > IDs using one of three hashing algorithms: SHA-256, SHA- 384, or
> > SHA-512."
> >
> > Note that the behavior note only talks about Windows 7 in client mode
> > and says nothing about its capabilities in server mode. I believe
> > that's because Windows 7 doesn't support server mode. Also, only a
> > Windows
> > 2008r2 server can act as a hosted cache. Windows 7 clients, I
> > believe, can operate as peer caches.
> >
> > So... Do you mean to say Windows 7 or Windows 2Kr2 in the statement above?
> > If Windows 7, then are you talking about W7 clients sending content
> > requests to the hosted cache server or as broadcasts on the local LAN?
> > If so, that part of BranchCache is outside of the scope of [MS-PCCRC] ...
> > which leaves me confused as to what you are trying to explain to me
> > when you describe Windows 7 behavior.
> >
> > > The product team will be reflecting the above clarification in the
> > > protocol document. Let me know whether this answers your questions.
> > It would be quite helpful if an additional example were presented in
> > order to show how these values are used. I found the descriptions of
> > these values to be difficult to interpret when reading the documentation.
> >
> > Unless you tell me that my understanding, given above, is incorrect I
> > believe that your description has clarified things nicely.
> >
> > Thanks.
> >
> > Chris -)-----
> >
> > > Regards,
> > > Edgar
> > >
> > > -----Original Message-----
> > > From: Edgar Olougouna
> > > Sent: Tuesday, May 31, 2011 11:07 AM
> > > To: 'Christopher R. Hertel'
> > > Cc: cifs-protocol@samba.org
> > > Subject: RE: [cifs-protocol] [REG:111051857287367] BranchCache and SMB2: \
> > > Questions specific to BranchCache.
> > > Chris,
> > >
> > > I am actively working on this with the product team to clarify a few more \
> > > points. I will update you as soon as possible.
> > > Regards,
> > > Edgar
> > >
> > > -----Original Message-----
> > > From: Christopher R. Hertel [mailto:crh@ubiqx.com]
> > > Sent: Sunday, May 29, 2011 5:57 PM
> > > To: Edgar Olougouna
> > > Cc: MSSolve Case Email; cifs-protocol@samba.org
> > > Subject: Re: [cifs-protocol] [REG:111051857287367] BranchCache and SMB2: \
> > > Questions specific to BranchCache.
> > > Edgar,
> > >
> > > I am just checking in on this ticket. I understand that the resolution to \
> > > these issues can take some time, but I want to test my implementation at the \
> > > FileSharing Plugfest in a few weeks time. Having the answers would help me \
> > > complete my testing implementation.
> > > Thanks.
> > >
> > > Chris -)-----
> > >
> > > Obaid Farooqi wrote:
> > > > Hi Chris:
> > > > Thank you for contacting Microsoft regarding your query on branch cache. A \
> > > > member of the protocol documentation team will be in touch soon.
> > > > Regards,
> > > > Obaid Farooqi
> > > > Escalation Engineer | Microsoft
> > > >
> > > > Exceeding your expectations is my highest priority. If you would
> > > > like to provide feedback on your case you may contact my manager at
> > > > allisong@microsoft.com
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Christopher R. Hertel [mailto:crh@ubiqx.com]
> > > > Sent: Tuesday, May 17, 2011 9:12 PM
> > > > To: Interoperability Documentation Help
> > > > Subject: BranchCache and SMB2: Questions specific to BranchCache.
> > > >
> > > > I have a couple of questions regarding BranchCache and [MS-PCCRC]. As you \
> > > > know, BranchCache--particularly the Content Information format specified in \
> > > > [MS-PCCRC]--can be used as an extension to SMB2.
> > > > 1) In the Content Information structure ([MS-PCCRC:2.3]), there is the
> > > > following field definition:
> > > >
> > > > dwOffsetInFirstSegment (4 bytes): Number of bytes into the first
> > > > segment within the Content Information data structure at which
> > > > the content range begins.
> > > >
> > > > I can't make heads nor tails of that description, and the captures I
> > > > have done on the wire typically show that field set to zero.
> > > > Similarly, the examples in section 3 of [MS-PCCRC] show the value of
> > > > this field to be zero.
> > > >
> > > > The field is 4 bytes in length, so it cannot be an offset into the
> > > > content itself, since content offsets are (should be) 8 bytes (64-bit).
> > > >
> > > > Please clarify: What does dwOffsetInFirstSegment actually represent?
> > > >
> > > > 2) I am not getting what I expect in the dwReadBytesInLastSegment field.
> > > > This field is defined in [MS-PCCRC:2.3], as follows:
> > > >
> > > > dwReadBytesInLastSegment (4 bytes): Total number of bytes of the
> > > > content range which lie within the final segment in the Content
> > > > Information data structure.
> > > >
> > > > It seems to me that this value represents the number of bytes
> > > > of actual content included in the calculation of the final
> > > > Segment block of the Content Information. That interpretation
> > > > is supported by the examples in section 3.
> > > >
> > > > In actual captures, however, Windows IIS server returns zero
> > > > (0x00000000) in the dwReadBytesInLastSegment field.
> > > >
> > > > Is this a documentation bug or is the IIS server returning the
> > > > wrong value?
> > > >
> > > > This is IIS running on W2K8r2 with fairly up-to-date patches
> > > > applied.
> > > >
> > > > Looking forward to the replies.
> > > >
> > > > Thanks.
> > > >
> > > > Chris -)-----
> > > >
> > > > --
> > > > "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
> > > > Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel
> > > > jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq.
> > > > ubiqx Team -- http://www.ubiqx.org/ -)----- crh@ubiqx.mn.org
> > > > OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@ubiqx.org
> > > >
> > > --
> > > Christopher R. Hertel -)----- Storage Architect & CIFS Geek
> > > http://www.ubiqx.com/ Data Storage and Systems Consulting
> > > "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
> > >
>
--
Christopher R. Hertel -)----- Storage Architect & CIFS Geek
http://www.ubiqx.com/ Data Storage and Systems Consulting
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
_______________________________________________
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic