I tried to read this before the interm meeting, but found out that it would require me to read it trough several times before I could really understand it.
The basic architecture is simple, we have some trusted third party, ADS which stores all information and ADC devices talk to it and gets some information from there. What that information is and how it is used is not that clear, as it would require to understand what is in each of the payloads and how they are used, i.e. it would require some more time to try to decode what is done in each operation. One question is how is the trust between ADS and ADC creted, how it is protected, and how is it authenticated. As far as I can see from the draft, it says it is outside the scope, i.e. I assume it would need to be configured in ADCs manually. This also creates single point of failure, i.e. if the ADS goes down nothing really works. Old connections stay up, but creating new ones ends up problems. Also using the private-IP address as identity for the ADC might not be that good idea. In section 4 before going to the actual protocol exchanges it would be nice to have some description about the payloads involved. It is hard to understand what "Client Information Registration" does when you do not have any idea what is in the CIDHdr or CI. Adding bit more description in there explaining that for example CIDHdr contains the Client Private Address, which is used to identify the ADC in the messages. Also in the fixed header there is type field, but I have no idea what kind of message is containe for example in the Delete Request. I.e. is there CIHdr or SEssHdr there next? What is the meaning of it etc. As currently written the draft is quite hard to understand, and would most likely require several rereads to be able to really understand how it works. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
