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

[Vincent Roca <[e-mail]>]

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 -----
> From: "Jaehoon Jeong" <[e-mail]>
> To: "Vincent Roca" <[e-mail]>
> Cc: "draft-ietf-6man-dns-options-bis all" <[e-mail]>, [e-mail], "IESG"
> <[e-mail]>, "6man Chairs" <[e-mail]>, "Jari Arkko" <[e-mail]>, "Tony Cheneau"
> <[e-mail]>
> Sent: Thursday, July 22, 2010 12:53:38 AM
> Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03
> Hi Vincent,
> 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
> 
> 
> -----Original Message-----
> From: Vincent Roca [mailto:[e-mail]]
> Sent: Tuesday, July 20, 2010 5:24 AM
> To: Jaehoon Jeong
> Cc: draft-ietf-6man-dns-options-bis all; [e-mail]; IESG; 6man
> Chairs; Jari Arkko
> Subject: Re: SecDir review of draft-ietf-6man-dns-options-bis-03
> 
> 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" <[e-mail]>
> > To: "Jari Arkko" <[e-mail]>
> > Cc: "Vincent Roca" <[e-mail]>,
> > "draft-ietf-6man-dns-options-bis all"
> > <[e-mail]>,
> > [e-mail], "IESG" <[e-mail]>, "6man Chairs"
> > <[e-mail]>
> > Sent: Tuesday, July 6, 2010 4:37:06 PM
> > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03
> > 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/w
> > diff%20draft-ietf-6man-dns-options-bis-05_txt%20draft-ietf-6man-dns-op
> > tions-bis-06_txt.htm
> >
> > If so, I will submit the version 06-ID today.
> >
> > Thanks.
> >
> > Best Regards,
> > Paul
> >
> > -----Original Message-----
> > From: Jaehoon Jeong [mailto:[e-mail]]
> > Sent: Saturday, July 03, 2010 12:33 PM
> > To: Vincent Roca
> > Cc: Jari Arkko; [e-mail];
> > [e-mail]; IESG; 6man Chairs
> > Subject: RE: SecDir review of draft-ietf-6man-dns-options-bis-03
> >
> > 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/d
> > raft-ietf-6man-dns-options-bis-06.txt
> >
> > On Sat, Jul 3, 2010 at 11:31 AM, Jaehoon Jeong <[e-mail]>
> > wrote:
> > >
> > >
> > > -----Original Message-----
> > > From: Vincent Roca [mailto:[e-mail]]
> > > Sent: Saturday, July 03, 2010 8:04 AM
> > > To: Jaehoon Jeong
> > > Cc: Jari Arkko;
> > > [e-mail];
> > > [e-mail]; IESG; 6man Chairs; [e-mail]
> > > 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
> > > ;-))
> > >
> > > ** 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.
> >
> > 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.
> >
> > >
> > >>> ** 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.
> >
> > 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.
> > >>> 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.
> >
> > 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.
> > >
> > > 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 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.
> > > Cheers,
> > >
> > >    Vincent
> > >
> >
> > Thanks for your efforts on the improvement for this document.
> >
> > Best Regards,
> > Paul

_______________________________________________
secdir mailing list
[e-mail]
https://mailman.mit.edu/mailman/listinfo/secdir