Subject: Comments on draft-ietf-6man-nd-opt-validation-00

From: Jen Linkova <[email-masked]>
Date: Wed, 25 Mar 2015 14:24:45 +0100

Hi guys,

After reading this draft I'm a bit confused. The big portion of it repeats what
RFC4861 and RFC2464. The new checks introduced are related to
SLLA/TLLA checks (some of them would break DAD actually).

Wouldn't it be better just to document just this particular use case
(so if/when a new ND option gets introduced we do not have to write
another draft which would copy all content of this draft + some new
checks...and then repeat it every time a new option is introduced)?

I should say that the most interesting part of the draft is the
Appendix and after reading it I got an impression that you are trying
to prevent two specific cases:
1) mapping a host's own L2 address to an Ipv6 address which does not
belong to the host
2) mapping unicast IPv6 address to broadcast or multicast.

In this case wouldn't it be simpler to just to declare that
'a host MUST not install a NC entry if it maps it's own L2 address to
v6 address which does not belong to it or if it maps a unicast v6
address to broadcast?
Basically, introduce additional checks for updating NC instead of
trying to cover every possible combination of ND message type and ND
option?

BTW, regarding mapping an IPv6 address to multicast:
the document says:

"The Link-Layer Address field specifies the link-layer address of the
   packet's originator.  It MUST NOT be any of the following:

   o  a broadcast address (see Appendix B for rationale)

   o  a multicast address (see Appendix B for rationale)"

however the appendix B explains broadcast case only.

-- 
SY, Jen Linkova aka Furry

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 25 Mar 2015 15:56:03 +0000

Jen,

When Fernando and I first submitted this draft, it described only two validations, against the SLLA and TLLA options. These validations were required to mitigate the vulnerability that is described in the appendix.

At IETF 90, the WG instructed us to expand the scope of the draft to describe validations against all ND options. We complied with that instruction. 

As you accurately observe, the resulting document:

- repeats what is already said in RFC 4861 and 2464
- when not repeating RFC 4861 and 2464, dwells upon the obvious

IMHO, expanding the scope of the document was not a good idea. If the WG would retract its instruction to expand scope, we would be happy to update the draft, restricting it to its initial scope. However, before doing that, we would look for guidance from the WG and chairs.

Also, I agree that we need to reword the TLLA/SLLA validation to make sure that we don't break DAD.

                                                                       Ron

> -----Original Message-----
> From: Jen Linkova [mailto:[email-masked]]
> Sent: Wednesday, March 25, 2015 8:25 AM
> To: Ronald Bonica; Fernando Gont
> Cc: 6man
> Subject: Comments on draft-ietf-6man-nd-opt-validation-00
> 
> Hi guys,
> 
> RFC4861 and RFC2464. The new checks introduced are related to SLLA/TLLA
> checks (some of them would break DAD actually).
> 
> Wouldn't it be better just to document just this particular use case (so
> if/when a new ND option gets introduced we do not have to write another
> draft which would copy all content of this draft + some new checks...and
> then repeat it every time a new option is introduced)?
> 
> I should say that the most interesting part of the draft is the Appendix and
> after reading it I got an impression that you are trying to prevent two specific
> cases:
> 1) mapping a host's own L2 address to an Ipv6 address which does not belong
> to the host
> In this case wouldn't it be simpler to just to declare that 'a host MUST not
> install a NC entry if it maps it's own L2 address to
> v6 address which does not belong to it or if it maps a unicast v6 address to
> broadcast?
> Basically, introduce additional checks for updating NC instead of trying to
> cover every possible combination of ND message type and ND option?
>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 30 Mar 2015 11:00:24 -0700

At Wed, 25 Mar 2015 15:56:03 +0000,

> IMHO, expanding the scope of the document was not a good idea. If the WG would retract its instruction to expand scope, we would be happy to update the draft, restricting it to its initial scope. H…

I don't have a strong opinion on whether to discuss other general
matters than the very original issue ("two validations, against the
SLLA and TLLA options"), but I'm inclined to prefer limiting the scope
to the original point.  I think the discussions we've had so far were
useful if only to realize that we only found something obvious, but if
so, it probably makes more sense to choose to keep the resulting
document concise.

--
JINMEI, Tatuya

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 30 Mar 2015 18:13:34 +0000

Jinmei,

Thanks much. I tend to agree with you.

If a few more WG members and the chairs weigh in on the topic, I will revise the draft accordingly.

                                                           Ron

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ????
> Sent: Monday, March 30, 2015 2:00 PM
> To: Ronald Bonica
> Cc: Jen Linkova; Fernando Gont; 6man
> Subject: Re: Comments on draft-ietf-6man-nd-opt-validation-00
> 
> > At IETF 90, the WG instructed us to expand the scope of the draft to
> describe validations against all ND options. We complied with that instruction.
> >
> > IMHO, expanding the scope of the document was not a good idea. If the
> WG would retract its instruction to expand scope, we would be happy to
> update the draft, restricting it to its initial scope. However, before doing that,
> we would look for guidance from the WG and chairs.
> 
> I don't have a strong opinion on whether to discuss other general matters
> than the very original issue ("two validations, against the SLLA and TLLA
> options"), but I'm inclined to prefer limiting the scope to the original point.  I
> think the discussions we've had so far were useful if only to realize that we
> only found something obvious, but if so, it probably makes more sense to
> choose to keep the resulting document concise.
> 
> --
> JINMEI, Tatuya