Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-access-network-identifier-10: (with DISCUSS)

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Stephen,

Thank you for your review. We probably addressed most of these issues as part of addressing Alissa's comments as there is overlap. Any case, please let us know if you are not happy with the changes.



(1) Did the DHC working group consider how this information,
when sent without adequate protection between relay and dhcp
server, could help in pervasive monitoring? If so, what was the
conclusion reached? We have seen http header field information
sent between infrastructure nodes being intercepted for that
purpose, so this has to be similarly at risk.  If the answer is
that this is only to be used within a single network operator's
setup (or a roaming arrangement) then that needs to be
justified (as practical) and, if it can be justified (I'm not
sure tbh), also made explicit.

[Sri] I believe this issue is now resolved after discussions with Alissa Cooper and the newly agreed text that introduces the "same operator" assumption.



(2) I had a DISCUSS on the draft that became rfc 6757 about
protection of this kind of data. In that context I think I was
assured that everything (in PMIPv6) was IPsec protected so it
was fine.  Why, in what we now know is a more threated
environment, is it ok to now have weaker protection when I was
assured then that IPsec was in fact quite usable in PMIPv6? I
think you maybe need to put in a MUST use IPsec requirement for
this to be as safe.


[Sri] No, its not. We are still identifying the information that is at risk in certain operating environments. We are also listing the tools that operator has their disposal as per the below text. The question is that determination on when the information is at risk, if its an operator call, or IETF call. I'm OK, but I will let Bernie and other DHCP experts comment on this MUST requirement.


   "In deployments where this information is considered secure
   and when such threat cannot be mitigated using IPsec [RFC4301] or
   other security protocols, then the administrators have to consider
   disabling the capability specified in this document on the DHCP
   entities."


(3) section 7: MAY store - this is possibly sensitive
information so you ought say that it SHOULD NOT be stored
unless needed, and if stored, SHOULD be deleted as soon as
possible. Storing sensitive information when not needed just
shouldn't be considered acceptable anymore I think - is that
reasonable?


[Sri] Ok.

Looking at RFC 7268, SSID (Network-Id-Name attribute) can be present in accounting records. So, this information is stored by network functions.



  *

I (strongly) support Alissa's DISCUSS and will be interested
in watching how that is resolved. Some of my DISCUSS points do
overlap though so from my POV feel free to mix'n'match the
discussions. Or to process first one then the other, whatever
you think is best.



[Sri] We resolved it; hope you are OK with the conclusion.


- RFC6757 defines exactly this for PMIPv6. That implies that
PMIPv6 should not be used to illustrate or motivate this, as
that problem is solved. Perhaps you would be better off if you
limited the scope of this to be used for networks that are some
kind of extension to PMIPv6 only? (You'd need to define what
kind I think.)

[Sri] I believe with all the text around "single operator", "IPsec" and other assumptions, I think we have resolved this issue.

Thanks for the reviews.

Regards
Sri