Subject: [dhcwg] WGLC comments for draft-ietf-dhc-dhcp4o6-saddr-opt

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 3 May 2018 10:28:44 +0100

Apologies for sending this review so late. Life and day job frequently
gets in the way... Anyway, here it goes.

Section 1, the reference seems a bit dubious. The text mentions DHCPv6
configuration, but references 7597. RFC7597 defines the MAP-E
mechanism, the DHCPv6 configuration is defined in RFC7598. Did you
want to reference the latter? Or both?

pg 6: also, optionally => also optionally

pg 7: Please unify the diagrams and how option-code is presented. The
preferred way is to simply state just the option contant
(e.g. OPTION_S46_BIND_IPV6_PREFIX without TBD) and then have
option-code: OPTION_S46_BIND_IPV6_PREFIX (tbd1) in the text
below. That's what RFC3315, 3315bis and many other DHC docs did.

bind-ipv6-prefix: the text already says the padding must be filled
with zeros by sender, which is good. It should also says the padding
is to be ignored by receiver. Adding forward reference to Section 7.4
would be useful.

pg. 10: repsonse => response

pg. 10, section 7.4. That doesn't sound right:

"The received bindprefix6-len value is not larger than the number of
bytes sent in the bind-ipv6-prefix field". You either need to change
to "of bits sent" or say bindprefix8-len divided by 8.

"For either of these cases the receiver MAY either discard the option
and proceed to attempt configuration as if the option had not been
received, or attempt to use the received values for the longest prefix
match anyway." I don't like this text. It's impossible to write
reasonable conformance tests for this. If yo can, please choose one
error handling and stick with it. In my opinion discarding invalid option
is cleaner.

Section 7.5: "wait for a randomized time interval". What is the upper bound
this random delay could take? If it follows any regular DHCPREQUEST
retransmission, please add "as defined by standard DHCPREQUEST request
defined in RFC2131, section X.Y" (sorry, on an airplane right now and
don't have the RFC around).

Regarding the itemized list, I don't like the alternative error
handling much. Why do you need both? It would be simpler (and far
easier to write conformance tests) if there was only one. If you
really need two, can you make one of them SHOULD and the other MAY?

Ok, that's it. Overall, I think the draft is almost ready and support
moving it forward.

Tomek

---

From: [email-masked]
Date: Tue, 8 May 2018 16:10:29 +0200

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 8 May 2018 14:39:45 +0000

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-masked]>
Date: Tuesday, May 8, 2018 at 10:10 AM
To: Bernie Volz <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - Respond by April 17, 2018

Hi Bernie,

SECTION 9:

And:

Thanks,
Ian

---

From: [email-masked]
Date: Wed, 9 May 2018 09:53:09 +0200

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-masked]> wrote:
> 
> Hi Ian:
>  
> Bernie

---

From: [email-masked]
Date: Wed, 9 May 2018 09:55:24 +0200

Hi Tomek,

Thanks for your review. Please see inline below.

Cheers,
Ian

> On 3. May 2018, at 11:28, Tomek Mrugalski <[email-masked]> wrote:
> 

[if - RFC7598 is correct. Thanks for catching it.]

> pg 6: also, optionally => also optionally

[if - done]

> below. That's what RFC3315, 3315bis and many other DHC docs did.

[if - For the DHCPv4 option ‘OPTION_DHCP4O6_S46_SADDR’ it’s not
possible to fit the name into the option-code field. Is there any precedence
on how to handle this?

Looking to the 3315bis-13 document, I see some option format’s using the name
of the option in the option-code field (e.g. OPTION_INFORMATION_
REFRESH_TIME, sec. 21.23) and some saying ‘option-code’
(e.g. SOL_MAX_RT, sec 21.24) in this field.]

> is to be ignored by receiver. Adding forward reference to Section 7.4

[if - done]

> pg. 10: repsonse => response

[if -done]
> to "of bits sent" or say bindprefix8-len divided by 8.

[if - The intention here is to check that the number (of bytes) in
the bindprefix6-len field matches what is received in the bind-ipv6-prefix-field.
I think the problem is using the word sent when I meant received!
Does this wording work better?:

"The received bindprefix6-len value is not larger than the number
  of bytes received in the bind-ipv6-prefix field. (e.g. the
  bindprefix6-len is 128 but the bind-ipv6-prefix field is only 8 bytes
 long)."

> error handling and stick with it. In my opinion discarding invalid option

[if - Text updated to:

For either of these cases, the receiver discards the invalid 
         option and proceeds to attempt configuration as if the option had
         not been received.]
> really need two, can you make one of them SHOULD and the other MAY?

[if - What about:

   If the client receives a DHCPACK message with an
   OPTION_DHCP4O6_S46_SADDR containing an IPv6 address which differs
   from its active softwire source address, the client SHOULD wait for a
   randomised time interval and then resend the DHCPREQUEST message with
   the correct softwire source address.  [RFC2131] Section 4.1 descibes
   the retransmission backoff interval process.

   If, after a number of re-tries, the retransmission process does not
   return a DHCPACK message with the correct bound IPv6 address, a
   client MAY send a DHCPRELEASE message and re-start the process
   described in Section 7.  The number of re-tries should be
   configurable and aligned with any server policy defining the minimum
   time interval for client address updates as described in Section 8.1.

]

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 9 May 2018 11:12:26 +0000

This inconsistency in 3315bis should be addressed in auth-48!

- Bernie (from iPad)

> On May 9, 2018, at 3:55 AM, "[email-masked]" <[email-masked]> wrote:
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 30 May 2018 17:54:11 +0200

Thanks for addressing my comments. See my responses (tm>) below.

> possible to fit the name into the option-code field. Is there any precedence
Ah, forgot about the option code length in v4. Ok, so it looks like a
lost cause.
We can't hope to fit the names into such short space.
I'd say leave it as it is now.
>   bindprefix6-len is 128 but the bind-ipv6-prefix field is only 8 bytes
tm> No. The problem I have with this text is that bindprefix6-len is
expressed in bits, but the text wants to check it against the number of
bytes received. You need to either add "divided by 8" or change the text
to "number of bits received".
>          option and proceeds to attempt configuration as if the option had
tm> Looks great!
>    time interval for client address updates as described in Section 8.1.
tm> Looks good. Thanks for doing this.

Tomek