[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Working Group Last Call (WGLC): draft-ietf-ipdvb-ar-04.txt
Hi Gorry,
your proposed change to the security considerations text (see below) would
do just fine....
hth,
George
On Fri, 7 Jul 2006, Gorry Fairhurst wrote:
> On 6/7/06 13:09, "George Gross" <gmgross@nac.net> wrote:
>
> > Hi Gorry,
> >
> > first off, a question about this draft: I'm assuming it is planned for
> > "informational RFC" status, correct?
> >
> Yes.
>
> > just checking, since there are no MUST/SHOULD ;o)
> >
> Good question, let's discuss this in the ipdvb WG meeting: I can see there
> are places were more formal language could be used, even in an Informational
> document.
> >
> > in section 8, the "Security Considerations" should mention that when the
> > optional IPDVB SNDU security mechanisms are present, ARP and ND security
> > becomes nearly at rough parity with a private wireless LAN. The ARP or ND
> > multicast transmissions will be accepted only from those peer DVB
> > terminals that share a common group encryption and common group
> > authentication key provided by SNDU key management.
> >
> > Whereas, without that optional ULE security extension, security is
> > dependent on the Adversary not cracking into the DVB satellite receiver
> > terminal to eavesdrop on the ARP or ND packets addressed to any other DVB
> > terminal in the satellite network. If a DVB terminal is cracked open, then
> > the Adversary could then issue bogus ARP or ND packets, masquerading as a
> > legitimate peer in the ARP or ND protocols.
> >
> OK, that seems a reasonable addition. The current text says:
>
> There are known security issues relating to the use of unsecured
> address resolution [RFC3756]. Readers are also referred to the
> known security issues when mapping IP addresses to MAC/NPA addresses
> using ARP [RFC826] and ND [RFC2461]. It is recommended that AR
> protocols support authentication of the source of AR messages and
> the integrity of the AR information, this avoids known security
> vulnerabilities resulting from insertion of unauthorised AR messages
> within a L2 infrastructure. For IPv6, the SEND protocol [RFC3971]
> may be used in place of ND. This defines security mechanisms that
> can protect AR.
>
> Does the following additional paragraph capture this?:
>
> AR protocols can also be protected by the use of L2 security methods
> (e.g. Encryption of the ULE SNDU [ID-IPDVB-SEC]). When these methods
> are used, the security of ARP and ND can be comparable to that of
> a private LAN: A Receiver will only accept ARP or ND transmissions from
> the set of peer senders that share a common group encryption and
> common group authentication key provided by the L2 key management.
>
> Add Informative Reference:
>
> [ID-IPDVB-SEC] H.Cruickshank, S. Iyengar, L. Duquerroy, P. Pillai, "Security
> requirements for the Unidirectional Lightweight Encapsulation (ULE)
> protocol", Work in Progress, draft-cruickshank-ipdvb-sec-req-xx.txt.
>
> > there would also need to be an informational reference added to point at
> > the IPDVB ULE security extension draft (which I'm assuming will become a
> > proposed standard RFC someday).
> >
> Would the requirements (INFO) be sufficient (this one is a milestone listed
> on the Charter page)?
>
> > hth,
> > George
> >
> > On Wed, 28 Jun 2006, Gorry Fairhurst wrote:
> >
> >> This note starts the ipdvb WG Last Call for comments for the WG document
> >> named below:
> >>
> >> draft-ietf-ipdvb-ar-04.txt
> >> http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/
> >>
> >> This last call will end on 18th July 2006.
> >>
> >> The period of this last call has been extended because it also includes
> >> the week of the IETF meeting.
> >>
> >> You are asked to read the draft and send any issues, comments, or
> >> corrections to this mailing list. The WGLC procedure is the last chance
> >> for this working group to modify/correct this.
> >>
> >> Please do forward any comments to the ipdvb list.
> >>
> >> Best wishes,
> >>
> >> Gorry Fairhurst
> >> (ipdvb WG Chair)
> >>
> >
>
>