Hi Bernie, Thanks. I’ll still with 3315bis for now then.
BTW - I’ve added another paragraph to the Sec. Considerations section reading: A client may attempt to overload the server by sending multiple source address update messages (see Section 7.2.1) in a short time frame. This risk can be reduced by implementing a server policy enforcing a minimum time interval between client address changes as described in Section 8.1. DOS prevention was the reason for including the minimum time in the first place, so I think it makes sense to list it here. Cheers, Ian > On 8. May 2018, at 16:39, Bernie Volz (volz) <[email protected]> wrote: > > Hi Ian: > > Thanks … suggested text changes look good. I would think it best to reference > 3315bis … hopefully it won’t hold up publication of this draft since it may > take RFC Editor a bit longer to process the 3315bis document, but they also > will have a head start. (If it does hold it up and we need to expedite > release of this draft as an RFC, we can always ask for reference to change to > 3315.) > > Bernie > > From: Ian Farrer <[email protected]> > Date: Tuesday, May 8, 2018 at 10:10 AM > To: Bernie Volz <[email protected]> > Cc: "[email protected]" <[email protected]>, > "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - > EXTENDED - Respond by April 17, 2018 > > Hi Bernie, > > Many thanks for the review. I’ve had a look through your comments and they > all look straightforward enough. They will be in the next version with > Tomek’s comments. > > Here’s my suggestions in response to a couple of your comments: > > SECTION 9: > > - More of a question – do the new options or procedures add any new > or different considerations? If not, great. > > There is one case that I think is missed. I’ve update the Security > Considerations section to add the following text: > > A rogue client could attempt to use the mechanism described > in "Changing the Bound IPv6 Softwire Source Address” to redirect IPv4 > traffic > intended for another client to itself. This would be performed by > sending a DHCPREQUEST message for another client's active IPv4 > lease containing the attacker's softwire IPv6 address in > OPTION_DHCP4O6_S46_SADDR. > > For such an attack to be effective, the attacker would > need to know both the client identifier and active IPv4 > address lease currently in use by another client. The risk > of this can be reduced by using a client identifier format > which is not easily guessable, e.g. by including a time > component for when the client identifier was generated > (see [I-D.ietf-dhc-rfc3315bis] Section 11.2). > > >> - And, it is rather odd that DHCPv4 (RFC2131) and DHCPv6 >> (draft-ietf-dhc-rfc3315bis) aren’t referenced in the document. They are >> implicit because RFC7341 is referenced, but not always clear that this is >> the best way to go. But I didn’t find any easy way to incorporate these >> references directly. > > I’ve added the following to Section 4. Solution Overview: > > In order to provision a softwire, both IPv6 and IPv4 configuration > needs to be passed to the client. To map this to the DHCP 4o6 > configuration process, the IPv6 configuration is carried in > DHCPv6 options [I-D.ietf-dhc-rfc3315bis], carried > inside the DHCPv6 message DHCPV4-RESPONSE (21) > sent by the server. > > And: > > IPv4 configuration is carried in DHCPv4 messages <xref target="RFC2131"/>, > (inside the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism > described in <xref target="RFC7341"/>. > > The normative refs. are updated with these as well. > > BTW, should I be referencing RFC3315 or the -bis version as normative at this > stage? > > Thanks, > Ian >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
