Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03

From: Vincent Roca <[email-masked]>
Date: Sat, 03 Jul 2010 15:04:01 +0200

Dear authors,

Thanks for your prompt reply. A few additional comments
(it's my role ;-))

** new "Security Considerations" section says:
>    This attack
>    is similar to Neighbor Discovery attacks that use Redirect or
>    Neighbor Advertisement messages to redirect traffic to individual
>    addresses to malicious parties.  In general, the attacks related to
>    RDNSS and DNSSL are similar to both Neighbor Discovery attacks and
>    attacks against unauthenticated DHCP, as both can be used for both
>    "wholesale" traffic redirection and more specific attacks.
>   
You're right, other attacks are possible that lead to
the same result. ND and unauthenticated DHCP are
such possibilities. However, IMHO this is not a sufficient
reason not to RECOMMEND a security solution for RA.
Indeed, if ND / DHCP are made robust but nothing is done
for RA, then the threat remains.

So the updated text does not fully satisfies me, even if
the new paragraph is more clear than the old one.

>> ** Section 7:
>> Another point... the authors explain than network devices like
>> switches can be configured in such a way to disable ND/DHCP from
>> some ports.  That's great and I agree it helps preventing attacks.
>> However this is limited to wired networks. Nothing is said concerning
>> ND configurations in wireless networks. The situation is rather
>> different since any host can issue ND/DHCP traffic as if it were a
>> legitimate server if I understand correctly. The document MUST
>> include this kind of discussion.
>>   
>>     
> But this is generic issue with spoofing RAs and I am not sure it is the 
> task of this document to specify the solutions. One solution exists in 
> SEND (RFC 3791).
>   
Once again I agree. You don't have to specify technical
solutions. However you need to provide a good security
analysis, perhaps inherited from that of the base RA
document for the generic RA threats, with some text
describing the additional threats added by the proposed
extensions. And since security solutions exist elsewhere
(SEND), you should recommend their use. That's your
responsibility.

>> ** Section 7:
>> Yet another remark: SEND is listed as one potential solution to
>> add signatures in ND packets issued from servers.
>> I don't know SEND at all, so may be my remarks are flawed (but in
>> that case the text should be at least clarified).
>> - Shouldn't the use of SEND be RECOMMENDED as a solution to
>> mitigate attacks? Current document is not clear.
>> - Does SEND enable an authentication of the sender (the document
>> only mentions integrity protection)? If there's no sender
>> authentication, then I agree that the added value of SEND would be
>> limited. I'd like the authors to clarify this as well.
>>   
>>     
> The details are in RFC 3791 and its companion documents. SEND does 
> enable a host to verify that the sender of an RA is actually a router 
> authorized to act as a router.
>   

The text in your proposed I-D update does not
reflect this. Can you add it? Being able to authenticate
the sender is as important as being able to check the
packet integrity.

** I'm coming back to a comment I made earlier
and that has not been answered.

In the updated I-D, section 5.3.1, I read:

  "In the case where the DNS options of RDNSS and DNSSL can be obtained
   from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep
   some DNS options from all sources. "

I don't see (but I read very quickly so I may have missed
something) that secured RA/RDNSS/DNSSL messages
be prefered in the choice. If some RA use SEND, they must
be preferred over others.

I hope my comments are useful.
Cheers,

    Vincent

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir

---

From: Jaehoon Jeong <[email-masked]>
Date: Sat, 3 Jul 2010 11:32:40 -0600

Hi Vincent,
I would like to address your comments as below.

The updated I-D is located in the following link:
http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-06.txt

On Sat, Jul 3, 2010 at 11:31 AM, Jaehoon Jeong <[email-masked]> wrote:
>
>
> -----Original Message-----
> From: Vincent Roca [mailto:[email-masked]]
> Sent: Saturday, July 03, 2010 8:04 AM
> To: Jaehoon Jeong
> Cc: Jari Arkko; [email-masked]; [email-masked]; IESG; 6man Chairs; [email-masked]
> Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03
>
> Dear authors,
>
> Thanks for your prompt reply. A few additional comments (it's my role ;-))
>
> You're right, other attacks are possible that lead to the same result. ND and unauthenticated DHCP are such possibilities. However, IMHO this is not a sufficient reason not to RECOMMEND a security solution for RA.
> Indeed, if ND / DHCP are made robust but nothing is done for RA, then the threat remains.
>
> So the updated text does not fully satisfies me, even if the new paragraph is more clear than the old one.

I reorganize the text such that the description for SEND (as a security solution for RA) follows the above paragraph:
   ...
   In general, the attacks related to RDNSS and DNSSL are similar to both 
   Neighbor Discovery attacks and attacks against unauthenticated DHCP, 
   as both can be used for both "wholesale" traffic redirection and more 
   specific attacks.

   If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as
   a security mechanism for ND, all the ND options including the RDNSS
   and DNSSL options are automatically included in the signatures, so
   the transport for the RA options is integrity-protected; that is,
   SEND can prevent the spoofing of these DNS options with signatures.
   Also, SEND enables an IPv6 host to verify that the sender of an RA is
   actually a router authorized to act as a router.  However, since any
   valid SEND router can still insert RDNSS and DNSSL options, SEND
   cannot verify which one is or is not authorized to send the options.

>>> switches can be configured in such a way to disable ND/DHCP from some
>>> ports.  That's great and I agree it helps preventing attacks.
>> But this is generic issue with spoofing RAs and I am not sure it is
>> the task of this document to specify the solutions. One solution
>> exists in SEND (RFC 3791).
>>
> Once again I agree. You don't have to specify technical solutions. However you need to provide a good security analysis, perhaps inherited from that of the base RA document for the generic RA threats, with some text describing the additional threats added by the proposed extensions. And since security solutions exist elsewhere (SEND), you should recommend their use. That's your responsibility.

In the following paragraph, we address that SEND can prevent such RA DNS option spoofing:

   If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as
   a security mechanism for ND, all the ND options including the RDNSS
   and DNSSL options are automatically included in the signatures, so
   the transport for the RA options is integrity-protected; that is,
   SEND can prevent the spoofing of these DNS options with signatures.
   Also, SEND enables an IPv6 host to verify that the sender of an RA is
   actually a router authorized to act as a router.  However, since any
   valid SEND router can still insert RDNSS and DNSSL options, SEND
   cannot verify which one is or is not authorized to send the options.

>
>>> ** Section 7:
>>> Yet another remark: SEND is listed as one potential solution to add
>>> signatures in ND packets issued from servers.
>>> - Shouldn't the use of SEND be RECOMMENDED as a solution to mitigate
>>> attacks? Current document is not clear.
>>> - Does SEND enable an authentication of the sender (the document only
>>> mentions integrity protection)? If there's no sender authentication,
>>> then I agree that the added value of SEND would be limited. I'd like
>>> the authors to clarify this as well.
>>>
>>>
> The text in your proposed I-D update does not reflect this. Can you add it? Being able to authenticate the sender is as important as being able to check the packet integrity.

According to the comments, the checking for valid router is mentioned in the middle:

   If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as
   a security mechanism for ND, all the ND options including the RDNSS
   and DNSSL options are automatically included in the signatures, so
   the transport for the RA options is integrity-protected; that is,
   SEND can prevent the spoofing of these DNS options with signatures.
   Also, SEND enables an IPv6 host to verify that the sender of an RA is
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   actually a router authorized to act as a router.  However, since any
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   valid SEND router can still insert RDNSS and DNSSL options, SEND
   cannot verify which one is or is not authorized to send the options.

>
> ** I'm coming back to a comment I made earlier and that has not been answered.
>
> something) that secured RA/RDNSS/DNSSL messages be preferred in the choice. If some RA use SEND, they must be preferred over others.
>

In Section 5.3.1, the considerations on SEND is mentioned as follows:

   In the case where the DNS options of RDNSS and DNSSL can be obtained
   from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep
   some DNS options from all sources.  Unless explicitly specified for
   the discovery mechanism, the exact number of addresses and domain
   names to keep is a matter of local policy and implementation choice.
   However, it is RECOMMENDED that at least three RDNSS addresses (or
   DNSSL domain names) can be stored from at least two different
   sources.  The DNS options from Router Advertisements and DHCP SHOULD
   be stored into DNS Repository and Resolver Repository so that
   information from DHCP appears there first and therefore takes
   precedence.  Thus, the DNS information from DHCP takes precedence
   over that from RA for DNS queries.  On the other hand, for DNS
                                                                           ^^^^^^^^^^^^^^^^^^^^^^^^^
   options announced by RA, if some RAs use the Secure Neighbor
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Discovery (SEND) protocol [RFC3971] for RA security, they MUST be
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   preferred over those which do not use SEND.  Refer to Section 7 for
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the detailed discussion on SEND for RA DNS options.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> I hope my comments are useful.

Thanks for your efforts on the improvement for this document.

Best Regards,
Paul

---

From: Jaehoon Jeong <[email-masked]>
Date: Tue, 6 Jul 2010 08:37:06 -0600

Hi Jari,
Is this update fine to  you along with Section 5.3.2 (Warnings for DNS Options Configuration)?

The difference between 05-version and 06-version is located at:
http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/wdiff%20draft-ietf-6man-dns-options-bis-05_txt%20draft-ietf-6man-dns-options-bis-06_txt.htm

If so, I will submit the version 06-ID today.

Thanks.

Best Regards,
Paul

-----Original Message-----
From: Jaehoon Jeong [mailto:[email-masked]] 
Sent: Saturday, July 03, 2010 12:33 PM
To: Vincent Roca
Cc: Jari Arkko; [email-masked]; [email-masked]; IESG; 6man Chairs
Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03

Hi Vincent,

On Sat, Jul 3, 2010 at 11:31 AM, Jaehoon Jeong <[email-masked]> wrote:
> Cc: Jari Arkko; [email-masked]; 
> [email-masked]; IESG; 6man Chairs; [email-masked]

>>> However this is limited to wired networks. Nothing is said 
>>> concerning ND configurations in wireless networks. The situation is 
>>> rather different since any host can issue ND/DHCP traffic as if it 
>>> were a legitimate server if I understand correctly. The document 
>>> MUST include this kind of discussion.
>>>
>>>

Best Regards,
Paul

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 6 Jul 2010 13:08:14 -0400 (Eastern Daylight Time)

There is presently a discussion between the secdir and the authors of a 
new csi document that describes ways to use a new authorization value to 
provide more fine grained protection than "is a router".  I notice that 
SEND protection of RA is mentioned below, with the caveat that RFC3971 
SEND does not distinguish the specific authority of authorized routers. 
Perhaps this work in csi would be of value.

--Sandy

P.S.  I added the appropriate recipient expansions for the csi drafts to 
the recipient list.  That makes for a bunch of recipients, not all of whom 
would be interested in a longer exchange on the topic.  Please consider 
trimming the list if you reply .

On Sat, 3 Jul 2010, Jaehoon Jeong wrote:

> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
>

---

From: Jaehoon Jeong <[email-masked]>
Date: Tue, 6 Jul 2010 11:11:05 -0600

Sandra,
Thanks for this useful information.

Best Regards,
Paul

-----Original Message-----
From: Sandra Murphy [mailto:[email-masked]] 
Sent: Tuesday, July 06, 2010 12:08 PM
To: Jaehoon Jeong
Cc: Vincent Roca; 6man Chairs; [email-masked]; [email-masked]; Jari Arkko; IESG; [email-masked]; [email-masked]
Subject: Re: [secdir] SecDir review of draft-ietf-6man-dns-options-bis-03

There is presently a discussion between the secdir and the authors of a new csi document that describes ways to use a new authorization value to provide more fine grained protection than "is a router".  I notice that SEND protection of RA is mentioned below, with the caveat that RFC3971 SEND does not distinguish the specific authority of authorized routers. 
Perhaps this work in csi would be of value.

--Sandy

P.S.  I added the appropriate recipient expansions for the csi drafts to the recipient list.  That makes for a bunch of recipients, not all of whom would be interested in a longer exchange on the topic.  Please consider trimming the list if you reply .

On Sat, 3 Jul 2010, Jaehoon Jeong wrote:

>>> enable a host to verify that the sender of an RA is actually a 
>>> router authorized to act as a router.
>>>
>>

---

From: Vincent Roca <[email-masked]>
Date: Tue, 20 Jul 2010 12:24:28 +0200 (CEST)

Dear authors,

First of all, sorry for this late answer.

Otherwise I read -06 version and I'm now happy with modifications
made in Section 5.3.

Concerning Section 7 "Security Considerations", I still find the
current text confusing (sorry):

- there is no clear discussion of what are the additional
  threats specific to the proposed RDNSS/DNSSL. 
  Instead I see a discussion explaining that the situation is
  not worse than before because an attacker can launch other
  types of attacks on ND. You're right and you can mention this
  quickly, but do not limit yourself to such a discussion.

- the new text on SEND is much better. However there is no
  explicit recommendation (no RECOMMENDED/SHOULD keyword).
  How should I understand this? Is it deliberate? Why?

So I suggest that you add two subsections (with a suggested
structure):
    7.1. Security threats
         <specific attacks on RDNSS/DNSSL>
         <how to launch them (rogue router or forged packets)>
         <in fact the situation is not worse than ND or DHCP
          attacks>
    7.2. Recommendations
         <port filtering in case of wired networks is RECOMMENDED>
         <mitigation at the DNS resolver is RECOMMENDED>
         <SEND is RECOMMENDED>

NB: In paragraph discussing filtering on switches:
"is recommended" -> "is RECOMMENDED"

NB2: I wouldn't like to give you the feeling that I set myself
against you, this is not my goal.

Cheers,

   Vincent

----- Original Message -----
> From: "Jaehoon Jeong" <[email-masked]>
> To: "Jari Arkko" <[email-masked]>
> Cc: "Vincent Roca" <[email-masked]>, "draft-ietf-6man-dns-options-bis all"
> <[email-masked]>, [email-masked], "IESG" <[email-masked]>, "6man Chairs"
> <[email-masked]>
> Sent: Tuesday, July 6, 2010 4:37:06 PM
> [email-masked]; IESG; 6man Chairs
> > Thanks for your prompt reply. A few additional comments (it's my
> > role
> > ;-))
> >
> > You're right, other attacks are possible that lead to the same
> > result. ND and unauthenticated DHCP are such possibilities. However,
> > IMHO this is not a sufficient reason not to RECOMMEND a security
> > solution for RA.
> > So the updated text does not fully satisfies me, even if the new
> > paragraph is more clear than the old one.
> 
> I reorganize the text such that the description for SEND (as a
> security solution for RA) follows the above paragraph:
> ...
> > Once again I agree. You don't have to specify technical solutions.
> > However you need to provide a good security analysis, perhaps
> > inherited from that of the base RA document for the generic RA
> > threats, with some text describing the additional threats added by
> > the proposed extensions. And since security solutions exist
> > elsewhere (SEND), you should recommend their use. That's your
> > responsibility.
> 
> >>> add
> > The text in your proposed I-D update does not reflect this. Can you
> > add it? Being able to authenticate the sender is as important as
> > being able to check the packet integrity.
> 
> > something) that secured RA/RDNSS/DNSSL messages be preferred in the
> > choice. If some RA use SEND, they must be preferred over others.
> >
>

---

From: Jaehoon Jeong <[email-masked]>
Date: Tue, 20 Jul 2010 08:00:18 -0600

Hi Vincent,
I will work on Security considerations according to your guidelines.
Thanks.

Best Regards,
Paul

-----Original Message-----
From: Vincent Roca [mailto:[email-masked]] 
Sent: Tuesday, July 20, 2010 5:24 AM
To: Jaehoon Jeong
Cc: draft-ietf-6man-dns-options-bis all; [email-masked]; IESG; 6man Chairs; Jari Arkko
Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03

Dear authors,

Otherwise I read -06 version and I'm now happy with modifications made in Section 5.3.

Concerning Section 7 "Security Considerations", I still find the current text confusing (sorry):

NB2: I wouldn't like to give you the feeling that I set myself against you, this is not my goal.

Cheers,

   Vincent

----- Original Message -----
> http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/w
> diff%20draft-ietf-6man-dns-options-bis-05_txt%20draft-ietf-6man-dns-op
> tions-bis-06_txt.htm
> 
> and DNSSL options are automatically included in the signatures, so the 
> transport for the RA options is integrity-protected; that is, SEND can 
> prevent the spoofing of these DNS options with signatures.
> >>> concerning ND configurations in wireless networks. The situation 
> >>> is rather different since any host can issue ND/DHCP traffic as if 
> >>> it were a legitimate server if I understand correctly. The 
> >>> document MUST include this kind of discussion.
> >>>
> >>>
> and DNSSL options are automatically included in the signatures, so the 
> transport for the RA options is integrity-protected; that is, SEND can 
> prevent the spoofing of these DNS options with signatures.

---

From: Vincent Roca <[email-masked]>
Date: Thu, 22 Jul 2010 14:36:08 +0200 (CEST)

Hello Paul,

I'm okay with the new text :-)
I've just found a  typo (section 7, 2nd line): s/secuity/security/

Regards,

   Vincent

----- Original Message -----
> To: "Vincent Roca" <[email-masked]>
> Cc: "draft-ietf-6man-dns-options-bis all" <[email-masked]>, [email-masked], "IESG"
> <[email-masked]>, "6man Chairs" <[email-masked]>, "Jari Arkko" <[email-masked]>, "Tony Cheneau"
> <[email-masked]>
> Sent: Thursday, July 22, 2010 12:53:38 AM
> I updated the document according to your guidelines as follows:
> - The new ID:
> http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-07.txt
> 
> - Difference between 06-version and 07-version:
> http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/wdiff%20draft-ietf-6man-dns-options-bis-06_txt%20draft-ietf-6man-dns-options-bis-07_txt.htm
> 
> Tony Cheneau provided the text about DNS option authorization as
> below:
> -----------------------------------------------------------------------
> I agree that currently SEND does not provide any mechanism
> to indicate if a router can or cannot insert RDNSS and DNSSL options.
> However, I think the document draft-ietf-csi-send-cert-05 could help
> with that issue. The section 7 of the document describes
> Extended Key Usage for the certificate deployed in SEND.
> While it currently defines roles for Routers, Routers acting as Proxy
> and
> Address Owner, I think it could be extended to a new usage
> that indicates that the Router was indeed authorized
> to insert RDNSS and DNSSL options.
> -----------------------------------------------------------------------
> 
> I reflected his comments on this update.
> 
> Could you check whether this update is fine to you or not?
> 
> If it is fine to you, I will submit it to the IETF repository.
> 
> Thanks.
> 
> Best Regards,
> Paul
> 
> 
> > <[email-masked]>,
> > [email-masked], "IESG" <[email-masked]>, "6man Chairs"
> > Is this update fine to you along with Section 5.3.2 (Warnings for
> > DNS
> > Options Configuration)?
> >
> > > Cc: Jari Arkko;
> > > [email-masked];
> > >>    addresses to malicious parties. In general, the attacks
> > >>    related
> > >>    to
> > the
> > the
> > According to the comments, the checking for valid router is
> > mentioned
> > in the middle:
> >
> > > ** I'm coming back to a comment I made earlier and that has not
> > > been
> > > answered.
> > >

---

From: Jaehoon Jeong <[email-masked]>
Date: Wed, 21 Jul 2010 16:53:38 -0600

Hi Vincent,

Tony Cheneau provided the text about DNS option authorization as below:
While it currently defines roles for Routers, Routers acting as Proxy and 

Thanks.

Best Regards,
Paul

-----Original Message-----
From: Vincent Roca [mailto:[email-masked]] 
Sent: Tuesday, July 20, 2010 5:24 AM
To: Jaehoon Jeong
Cc: draft-ietf-6man-dns-options-bis all; [email-masked]; IESG; 6man Chairs; Jari Arkko
Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03

Dear authors,

Cheers,

   Vincent

---

From: Jaehoon Jeong <[email-masked]>
Date: Thu, 22 Jul 2010 07:36:51 -0600

Hi Vincent,
After fixing this typo, I will submit the new version.
Thanks very much for your contribution.

Best Regards,
Paul

-----Original Message-----
From: Vincent Roca [mailto:[email-masked]]
Sent: Thursday, July 22, 2010 7:36 AM
To: Jaehoon Jeong
Cc: draft-ietf-6man-dns-options-bis all; [email-masked]; IESG; 6man Chairs; Jari Arkko; Tony Cheneau
Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03

Hello Paul,

Regards,

   Vincent

----- Original Message -----
> diff%20draft-ietf-6man-dns-options-bis-06_txt%20draft-ietf-6man-dns-op
> tions-bis-07_txt.htm
>
> ----------------------------------------------------------------------
> - I agree that currently SEND does not provide any mechanism to
> indicate if a router can or cannot insert RDNSS and DNSSL options.
> with that issue. The section 7 of the document describes Extended Key
> Usage for the certificate deployed in SEND.
> and Address Owner, I think it could be extended to a new usage that
> indicates that the Router was indeed authorized to insert RDNSS and
> DNSSL options.
> - there is no clear discussion of what are the additional threats
> specific to the proposed RDNSS/DNSSL.
> Instead I see a discussion explaining that the situation is not worse
> than before because an attacker can launch other types of attacks on
> ND. You're right and you can mention this quickly, but do not limit
> yourself to such a discussion.
>
> - the new text on SEND is much better. However there is no explicit
> recommendation (no RECOMMENDED/SHOULD keyword).
> <how to launch them (rogue router or forged packets)> <in fact the
> situation is not worse than ND or DHCP
> attacks>
> 7.2. Recommendations
> <port filtering in case of wired networks is RECOMMENDED> <mitigation
> at the DNS resolver is RECOMMENDED> <SEND is RECOMMENDED>
>
> > DNS Options Configuration)?
> >
> > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft
> > /d raft-ietf-6man-dns-options-bis-06.txt
> >
> > In general, the attacks related to RDNSS and DNSSL are similar to
> > both Neighbor Discovery attacks and attacks against unauthenticated
> > DHCP, as both can be used for both "wholesale" traffic redirection
> > and more specific attacks.
> >
> > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used
> > as a security mechanism for ND, all the ND options including the
> > RDNSS and DNSSL options are automatically included in the
> > signatures, so the transport for the RA options is
> > integrity-protected; that is, SEND can prevent the spoofing of these
> > DNS options with signatures.
> > Also, SEND enables an IPv6 host to verify that the sender of an RA
> > is actually a router authorized to act as a router. However, since
> > any valid SEND router can still insert RDNSS and DNSSL options, SEND
> > >>> is rather different since any host can issue ND/DHCP traffic as
> > >>> if it were a legitimate server if I understand correctly. The
> > >> But this is generic issue with spoofing RAs and I am not sure it
> > >> is the task of this document to specify the solutions. One
> > >> solution exists in SEND (RFC 3791).
> > >>
> > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used
> > as a security mechanism for ND, all the ND options including the
> > RDNSS and DNSSL options are automatically included in the
> > signatures, so the transport for the RA options is
> > integrity-protected; that is, SEND can prevent the spoofing of these
> > DNS options with signatures.
> > Also, SEND enables an IPv6 host to verify that the sender of an RA
> > is actually a router authorized to act as a router. However, since
> > any valid SEND router can still insert RDNSS and DNSSL options, SEND
> > >>> I don't know SEND at all, so may be my remarks are flawed (but
> > >>> in that case the text should be at least clarified).
> > >>> authentication, then I agree that the added value of SEND would
> > >>> be limited. I'd like the authors to clarify this as well.
> > >>>
> > >>>
> > >> The details are in RFC 3791 and its companion documents. SEND
> > >> does enable a host to verify that the sender of an RA is actually
> > >> a router authorized to act as a router.
> > >>
> > >
> > > The text in your proposed I-D update does not reflect this. Can
> > > you add it? Being able to authenticate the sender is as important
> > > as being able to check the packet integrity.
> >
> > mentioned in the middle:
> > If the Secure Neighbor Discovery (SEND) protocol [RFC3971] is used
> > as a security mechanism for ND, all the ND options including the
> > RDNSS and DNSSL options are automatically included in the
> > signatures, so the transport for the RA options is
> > integrity-protected; that is, SEND can prevent the spoofing of these
> > DNS options with signatures.
> > Also, SEND enables an IPv6 host to verify that the sender of an RA
> > is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > been answered.
> > > something) that secured RA/RDNSS/DNSSL messages be preferred in
> > > the choice. If some RA use SEND, they must be preferred over
> > > others.
> > >
> >
> > from multiple sources, such as RA and DHCP, the IPv6 host SHOULD
> > keep some DNS options from all sources. Unless explicitly specified
> > for the discovery mechanism, the exact number of addresses and
> > domain names to keep is a matter of local policy and implementation
> > choice.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^ options announced by RA, if some RAs use
> > the Secure Neighbor