Subject: RE: [rfc2461bis] Security issues

From: "Soliman Hesham" <[email-masked]>
Date: Mon, 14 Jun 2004 21:09:41 -0400

James,

Thank you for the review. 

 > 1) Much of what is in the Section 11.1 seems a summary of 
 > RFC 3756. On the
 > one hand, I suppose it is helpful to refresh the reader's 
 > memory, on the
 > other, it could shorten the spec and make for less reading. 
 > It's just a
 > stylistic issue.

=> ok.

 > 2) Regarding in Section 11.1 last paragraph:
 > 
 >    many of the threats discussed in this section are less
 >    effective, or non-existent, on point-to-point links, or cellular
 >    links where hosts share links with one neighbor, i.e. the default
 >    router.
 > 
 > I thought 2461 explicitly did not apply to point to point links or
 > point-to-point like links such as cellphones, and other 
 > links that were NBMA
 > (speaking of which, I suppose the actual NBMA technology has 
 > been worked out
 > by now, so the statement in Section 1 paragraph 2 about NBMA 
 > being FFS might
 > be obsolete and, if so, could be replaced by a reference to 
 > the RFC where
 > that is described).

=> I'm not aware of restrictions for ND on cellular links.
For instance, RFCs 3314 and 3316 talk about address config
and ND on 3GPP links, which are a good example of those 
point to point-like links. Sure there is no multicast 
capability but ND works fine. 

Hesham

 > 
 > The discussion of IPsec in Section 11.2 looks fine.
 > 
 >             jak
 > 
 > 
 > 
 > 
 > 
 > ----- Original Message ----- 
 > From: "Soliman Hesham" <[email-masked]>
 > To: <[email-masked]>
 > Sent: Monday, June 14, 2004 2:48 AM
 > Subject: [rfc2461bis] Security issues
 > 
 > 
 > Folks,
 > 
 > I'm formally addressing the issues left for 2461bis.
 > All the issues were either resolved or agreed on in
 > the meeting. The next series of emails are to inform
 > the list about the resolutions that we already agreed
 > on and see if there are any comments before I close the
 > issues.
 > 
 > The security issues were regarding:
 > - Use of IPsec
 > - Relation to SEND
 > 
 > The current draft includes the following:
 > 
 > - Removed suggestions for using IPsec to secure ND
 > - A discussion on IPsec and when it might be useful
 > - Expanded the security considerations section to include
 >   more threats and pros and cons of using IPsec
 > - Referenced threats and solutions drafts in SEND.
 > 
 > Please read the current draft, in particular sections
 > 3.3 and 11 to see all the changes. If there are no
 > objections I'll close this issue.
 > 
 > Hesham
 > 
 > ===========================================================
 > This email may contain confidential and privileged material 
 > for the sole use
 >  of the intended recipient.  Any review or distribution by others is
 > strictly
 >  prohibited.  If you are not the intended recipient please 
 > contact the
 > sender
 >  and delete all copies.
 > ===========================================================
 > 
 > 
 > --------------------------------------------------------------------
 > IETF IPv6 working group mailing list
 > [email-masked]
 > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
 > --------------------------------------------------------------------
 > 
 > 
 > 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 16 Jun 2004 03:25:28 -0400

Thanks, I'll update the text and reference accordingly.

Hesham

 > -----Original Message-----
 > From: Erik Nordmark [mailto:[email-masked]]
 > Sent: Wednesday, June 16, 2004 3:17 AM
 > To: Soliman Hesham
 > Cc: James Kempf; [email-masked]
 > Subject: RE: [rfc2461bis] Security issues
 > 
 > 
 > >    The
 > >    details of how one uses ND on NBMA links is an area for further
 > >    study.
 > > 
 > > => Perhaps this statement can be made clearer. I assume that
 > > it is referring to applying some form of multicast to 
 > > NBMA links? Perhaps Erik or Thomas can shed some light
 > > on the intention here. 
 > 
 > When the document was written the IPv6 over NBMA didn't 
 > exist yet (RFC 2491).
 > 
 > It might make sense to add an informative reference to that work.
 > 
 > FWIW RFC 2491 basically says that a NBMA supports IPv6 by 
 > using RFC 2022 (MARS)
 > which emulates multicast; thus from IP's perspective it 
 > isn't a non-broadcast
 > network any more even though the L2 itself is non-broadcast.
 > 
 >   Erik
 > 
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================