[Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04
Greetings int-area and hiaps-mailing-list folks, I realize that this is midweek at the IETF, however this question is not far from several discussions I've had this week. I have been asked to consider AD sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 In the process of considering doing so I'd like to get some input with respect to: A. The appetite for pursuing some or any of this work in existing working groups, and in particular within the INT area. B. A consensus basis for moving beyond RFC 6269 into active work in this area. C. How we address concerns raised by the IETF community expressed through draft-farrell-perpass-attack when evaluating scenarios and beginning to address requirements and solution-space. Obviously these are complex questions and I do not expect that we will arrive at answers easily nor does work on this or other drafts depend on answering them, however it's part of the dialog. Thanks joel signature.asc Description: OpenPGP digital signature ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04
a) Since this is fixing some of the damage done by NAT, it's really unfinished business for BEHAVE, which if iirc was a Transport Area WG. Just saying... b) The word privacy doesn't appear in the draft. Discussing privacy aspects is clearly essential if there is any thought of advancing this work. Actually I doubt if such a host ID is ever going to be acceptable from a privacy point of view, unless the end system is at liberty to change it at random (like RFC 4941). c) A hard-nosed argument is that since we want to sunset IPv4, it's time to stop working on ways of making NAT solutions work better. Is there anything in the use cases that can't be fixed by native IPv6? (The use case in expired draft http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01 is not at all convincing to me, especially when adding the privacy argument. It actually seems to describe a bug in 3GPP. But in any case, the draft appears to suggest mitigations.) Regards Brian On 07/03/2014 05:28, joel jaeggli wrote: Greetings int-area and hiaps-mailing-list folks, I realize that this is midweek at the IETF, however this question is not far from several discussions I've had this week. I have been asked to consider AD sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 In the process of considering doing so I'd like to get some input with respect to: A. The appetite for pursuing some or any of this work in existing working groups, and in particular within the INT area. B. A consensus basis for moving beyond RFC 6269 into active work in this area. C. How we address concerns raised by the IETF community expressed through draft-farrell-perpass-attack when evaluating scenarios and beginning to address requirements and solution-space. Obviously these are complex questions and I do not expect that we will arrive at answers easily nor does work on this or other drafts depend on answering them, however it's part of the dialog. Thanks joel ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04
It also seems doubtful that this would be useful outside the carrier network, since service providers would have to implement it and middleboxes would have to support it, neither of which is something we can depend on. Inside of the carrier network, solutions like A+P at the very least are quite easy to track algorithmically, so this solution is overkill. And of course I agree with all the points you made, Brian. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04
On 3/6/2014 8:28 AM, joel jaeggli wrote: Greetings int-area and hiaps-mailing-list folks, I realize that this is midweek at the IETF, however this question is not far from several discussions I've had this week. I have been asked to consider AD sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 In the process of considering doing so I'd like to get some input with respect to: A. The appetite for pursuing some or any of this work in existing working groups, and in particular within the INT area. Given that draft-ietf-intarea-nat-reveal-analysis is in INT, and this document expands on that, I think this belongs in INT. B. A consensus basis for moving beyond RFC 6269 into active work in this area. See my response to (A). INT is already active in that area. C. How we address concerns raised by the IETF community expressed through draft-farrell-perpass-attack when evaluating scenarios and beginning to address requirements and solution-space. That should definitely be addressed in this doc. Joe ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04
Brian, Although I don't disagree with the points below, it's useful to consider that INT is already working in this area, so I don't see either (a) or (c) as being relevant unless you expect to shift current INT docs to other WGs too. (b) just warrants an update. I disagree that privacy concerns will negate the benefits, though - a HOST ID might also be used to defeat or deny other claimed identifiers. Joe On 3/6/2014 10:03 AM, Brian E Carpenter wrote: a) Since this is fixing some of the damage done by NAT, it's really unfinished business for BEHAVE, which if iirc was a Transport Area WG. Just saying... b) The word privacy doesn't appear in the draft. Discussing privacy aspects is clearly essential if there is any thought of advancing this work. Actually I doubt if such a host ID is ever going to be acceptable from a privacy point of view, unless the end system is at liberty to change it at random (like RFC 4941). c) A hard-nosed argument is that since we want to sunset IPv4, it's time to stop working on ways of making NAT solutions work better. Is there anything in the use cases that can't be fixed by native IPv6? (The use case in expired draft http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01 is not at all convincing to me, especially when adding the privacy argument. It actually seems to describe a bug in 3GPP. But in any case, the draft appears to suggest mitigations.) Regards Brian On 07/03/2014 05:28, joel jaeggli wrote: Greetings int-area and hiaps-mailing-list folks, I realize that this is midweek at the IETF, however this question is not far from several discussions I've had this week. I have been asked to consider AD sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 In the process of considering doing so I'd like to get some input with respect to: A. The appetite for pursuing some or any of this work in existing working groups, and in particular within the INT area. B. A consensus basis for moving beyond RFC 6269 into active work in this area. C. How we address concerns raised by the IETF community expressed through draft-farrell-perpass-attack when evaluating scenarios and beginning to address requirements and solution-space. Obviously these are complex questions and I do not expect that we will arrive at answers easily nor does work on this or other drafts depend on answering them, however it's part of the dialog. Thanks joel ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
