Re: [Netconf] 回复： [Technical Errata Reported] RFC6242 (5305)

[Ignas Bagdonas <[e-mail]>]

Excellent. Will reject it then.



On 27/03/2018 15:41, fanhy wrote:
> After reading these emails, I understand the original text now. 
> Neither change nor erratum is needed.
>
> Thanks,
> Fanhy
>
> ------------------ 原始邮件 ------------------
> *发件人:* "Robert Wilton"<[e-mail]>;
> *发送时间:* 2018年3月27日(星期二) 晚上6:05
> *收件人:* "Kent Watsen"<[e-mail]>;"Ignas 
> Bagdonas"<[e-mail]>;"RFC Errata 
> System"<[e-mail]>;"[e-mail]"<[e-mail]>;"[e-mail]"<[e-mail]>;"[e-mail]"<[e-mail]>;
> *抄送:* "fanhy"<[e-mail]>; "[e-mail]"<[e-mail]>;
> *主题:* Re: [Netconf] [Technical Errata Reported] RFC6242 (5305)
>
> I think of the security considerations section of an RFC as outlining
> what the security issues might be present if care isn't taken when
> implementing the specification or deploying the technology associated
> with it.
>
> Not being able to access a device because it is blocked by a firewall
> seems like a functionality issue rather than a security issue. Normally
> you would expect this to be spotted during deployment, and hence I'm not
> convinced that additional text is required to cover this case.
>
> However, unwittingly opening up your device to a new attack vector does
> seem to be a security issue, and this is what the text is describing 
> today.
>
> So, I'm still not convinced, that any change or erratum is required.
>
> Thanks,
> Rob
>
>
> On 27/03/2018 00:09, Kent Watsen wrote:
> > I think both texts are correct, it completely depends on the firewall
> > policy in place.  In some cases, it may inadvertently grant access
> > and, in other it may inadvertently block access.   As I see it, the
> > current text is technically accurate, it just doesn't tell the whole
> > story.  So I'd reject the errata as presented, but might consider
> > one that more accurately reflects the whole story.
> >
> > K.
> >
> > ===== original message =====
> >
> > I also think that the existing RFC text looks right.
> >
> > My reading of the text is that it is suggesting that allowing netconf
> > access over other port numbers is a good idea, but care needs to be
> > taken to ensure that this doesn't result in unauthorized access to the
> > netconf/ssh subsystem.
> >
> > Thanks,
> > Rob
> >
> >
> > On 26/03/2018 17:07, Ignas Bagdonas wrote:
> >> Hi there,
> >>
> >> This paragraph taken out as stand-alone seems to have somewhat
> >> different meaning than if read together with the previous one in the
> >> document. If NETCONF is used over default port, it is explicitly
> >> required to be controlled by security policy, but there is no such
> >> requirement when used over non-default port, and the quoted paragraph
> >> mentions precisely this non-default port case. Therefore it seems that
> >> the text in the document is correct.
> >>
> >> The other aspect is the operational practice of security policies for
> >> network elements - generally it should be deny all allow what is
> >> needed, but that is not what the document is focusing on.
> >>
> >> Any opinions?
> >>
> >> Thank you,
> >>
> >> Ignas
> >>
> >>
> >>
> >> On 26/03/2018 07:19, RFC Errata System wrote:
> >>> The following errata report has been submitted for RFC6242,
> >>> "Using the NETCONF Protocol over Secure Shell (SSH)".
> >>>
> >>> --------------------------------------
> >>> You may review the report below and at:
> >>> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rfc-2Deditor.org_errata_eid5305&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=DiWeU-wyrNi7M183Zqrwk2er1MZS4MaIRqDJGXfI8CQ&s=EOfMENEtZKJI8OgKPlj-d_eAd8KPvVUehrS4w2JQBrs&e=
> >>>
> >>> --------------------------------------
> >>> Type: Technical
> >>> Reported by: HengyingFan <[e-mail]>
> >>>
> >>> Section: 6
> >>>
> >>> Original Text
> >>> -------------
> >>>      This document also recommends that SSH servers be configurable to
> >>>      allow access to the "netconf" SSH subsystem over other ports.
> >>> Use of
> >>>      that configuration option without corresponding changes to 
> firewall
> >>>      or network device configuration may unintentionally result in the
> >>>      ability for nodes outside of the firewall or other administrative
> >>>      boundaries to gain access to the "netconf" SSH subsystem.
> >>>
> >>>
> >>> Corrected Text
> >>> --------------
> >>>      This document also recommends that SSH servers be configurable to
> >>>      allow access to the "netconf" SSH subsystem over other ports.
> >>> Use of
> >>>      that configuration option without corresponding changes to 
> firewall
> >>>      or network device configuration may unintentionally result in the
> >>>      inability for nodes outside of the firewall or other 
> administrative
> >>>      boundaries to gain access to the "netconf" SSH subsystem.
> >>>
> >>>
> >>> Notes
> >>> -----
> >>> ability -> inability
> >>>
> >>> Instructions:
> >>> -------------
> >>> This erratum is currently posted as "Reported". If necessary, please
> >>> use "Reply All" to discuss whether it should be verified or
> >>> rejected. When a decision is reached, the verifying party
> >>> can log in to change the status and edit the report, if necessary.
> >>>
> >>> --------------------------------------
> >>> RFC6242 (draft-ietf-netconf-rfc4742bis-08)
> >>> --------------------------------------
> >>> Title               : Using the NETCONF Protocol over Secure Shell 
> (SSH)
> >>> Publication Date    : June 2011
> >>> Author(s)           : M. Wasserman
> >>> Category            : PROPOSED STANDARD
> >>> Source              : Network Configuration
> >>> Area                : Operations and Management
> >>> Stream              : IETF
> >>> Verifying Party     : IESG
> >> _______________________________________________
> >> Netconf mailing list
> >> [e-mail]
> >> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=DiWeU-wyrNi7M183Zqrwk2er1MZS4MaIRqDJGXfI8CQ&s=sMVpoddABtHDrtsSxGnxZF3r8ZbCAGl0CZpXLnYycRw&e=
> >> .
> >>
> >
> >