Subject: [Mip6] RE: WGLC: draft-ietf-mip6-bootstrapping-split-01 - Comments

From: Gerardo Giaretta <[email-masked]>
Date: Thu, 01 Dec 2005 11:37:27 +0100

> Editorial:
> 
> 1. In figures 3 & 4, the last message (from HA to MN) should 
> be BAck (not BU). 
>

Fixed.

Thanks,
--Gerardo
 
> 
> Thanks,
> Vidya
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Gerardo Giaretta
> > Sent: Thursday, November 24, 2005 8:52 AM
> > To: [email-masked]
> > Subject: Reminder -- [Mip6] WGLC: 
> > draft-ietf-mip6-bootstrapping-split-01(Deadline is Nov 30, 05)
> > 
> > Hi all,
> > 
> > no comments have been sent so far on 
> > draft-ietf-mip6-bootstrapping-split-01. 
> > Please review the draft and provide your feedback. The 
> > deadline is November 30th 2005.
> > 
> > Thanks,
> > --Gerardo 
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] 
> > On Behalf 
> > > Of Basavaraj Patil
> > > Sent: venerdì 4 novembre 2005 21.15
> > > To: [email-masked]
> > > Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-split-01
> > > (Deadline is Nov 30, 05)
> > > 
> > > 
> > > 
> > > Hello,
> > > 
> > > This is a Working Group last call for the following I-D:
> > > I-D :draft-ietf-mip6-bootstrapping-split-01
> > > Title: Mobile IPv6 bootstrapping in split scenario
> > > 
> > > The status associated with this I-D is : Standards track
> > > 
> > > Please review and post your comments by November 30th, 2005.
> > > 
> > > -Chairs
> > > 
> > > URL to I-D:
> > > http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-
> > > split-01.txt
> > > 
> > > 
> > > _______________________________________________
> > > Mip6 mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/mip6
> > > 
> > 
> > 
> > Gruppo Telecom Italia - Direzione e coordinamento di Telecom 
> > Italia S.p.A.
> > 
> > ====================================================================
> > CONFIDENTIALITY NOTICE
> > This message and its attachments are addressed solely to the 
> > persons above and may contain confidential information. If 
> > you have received the message in error, be informed that any 
> > use of the content hereof is prohibited. Please return it 
> > immediately to the sender and delete the message. Should you 
> > have any questions, please send an e_mail to 
> > [email-masked]. Thank you 
> > ====================================================================
> > 
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mip6
> > 
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Francis Dupont <[email-masked]>
Date: Thu, 01 Dec 2005 13:46:08 +0100

In your previous mail you wrote:

   > => IMHO an IKEv2 implementation should perform a proxy DAD when it
   > allocates an address before returning it as it should provide
   > a proxy NDP service (i.e., reply to NS by not-overriding NA).
   > Both should be configurable with by default being on.
   
   okay, but I dont think we should mandate the IKEv2 implementation
   to do proxy DAD.
   
=> we (as the MIP6 WG) should not but we (as the IETF) should.

   >    the authorization check is required. cant be skipped.
   > 
   > => show us where this authorization for the address is required
   > or even mentioned in RFC 2136, PLEASE!
   
   in the security considerations section we have the following.
   
=> this is fully irrelevant as this is *not* from the RFC 2136.

       This
       choice was motivated by a concern for preventing redirection-based
       flooding attacks (see draft-ietf-mip6-ro-sec [19] for more
       information about redirection-based flooding attacks and the role
       preventing them played in the design of Mobile IPv6 route
       optimization security). Exactly as for route optimization, it is
       possible for a node that is the legitimate owner of a DNS FQDN -
       in the sense that it has a security association with the DNS
       server allowing it to perform dynamic DNS update of its FQDN - to
       bind its FQDN to the address of a victim, then redirect large
       volumes of traffic at the victim. The attack may be propagated
       without the owner's knowledge, for example, if the node is
       compromised by malware, or it may be intentional if the node
       itself is the attacker.
   
   if RFC 2136 ignored this, I cant help it.
   
=> the RFC 2136 ignored this and it is in its scope, not in the scope
of the MIP6 WG.

Regards

[email-masked]