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

[Stephen Farrell <[e-mail]>]

Hi Sri,

Sorry for the slow response, I see you've posted -11 so this
response is based on the diff from -10 to -11. Apologies if
I've lost some context over the holidays, but I'm sure we can
re-establish that quickly enough.

On 14/12/15 17:18, Sri Gundavelli (sgundave) wrote:
> <Resending with the correct subject line>
> 
> 
> From: Sri Gundavelli <[e-mail]<mailto:[e-mail]>> 
> Date: Tuesday, December 8, 2015 at 3:06 PM To: Stephen Farrell
> <[e-mail]<mailto:[e-mail]>> Cc:
> "Bernie Volz (volz)" <[e-mail]<mailto:[e-mail]>>, IESG
> <[e-mail]<mailto:[e-mail]>>,
> "[e-mail]<mailto:[e-mail]>"
> <[e-mail]<mailto:[e-mail]>>,
> "[e-mail]<mailto:[e-mail]>"
> <[e-mail]<mailto:[e-mail]>>,
> "[e-mail]<mailto:[e-mail]>"
> <[e-mail]<mailto:[e-mail]>>,
> "[e-mail]<mailto:[e-mail]>"
> <[e-mail]<mailto:[e-mail]>>,
> Brian Haberman
> <[e-mail]<mailto:[e-mail]>>,
> "<[e-mail]<mailto:[e-mail]>>"
> <[e-mail]<mailto:[e-mail]>> Subject: Re: Ben Campbell's
> Discuss on draft-ietf-dhc-access-network-identifier-10: (with
> DISCUSS)
> 
> 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.

I note that Alissa hasn't yet cleared her discuss and her mail
from Dec 8th didn't seem to indicate that was about to happen.
(Though the direction in which the discussion seems to be heading
looks good.)

> 
> 
> 
> (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.

Sorry, it's not clear to me that it does. Can you explain how
the addition of "collocated" in section 2 resolves this? (Or
if I got the change wrong, can you say what change addresses
the issue?)

> 
> 
> (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."

Again, sorry for the loss of context, but I'm not getting how
that addition resolves the issue, can you explain?

> 
> (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 don't see a change in section 7 - are you saying that none
is needed?

Thanks and sorry again for the loss of context,
Cheers,
S.


> 
> 
> 
> *
> 
> 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
> 
>