Subject: RE: [Mip6] Re: Should we assume SeND in foreign/visited networks? (was:Substitute "high risk" for "mitigated risk" in SecurityConsiderations of draft-ietf-mip6-bootstrapping-split-02.txt)

From: "COMBES Jean-Michel RD-MAPS-ISS" <[email-masked]>
Date: Wed, 26 Apr 2006 15:39:32 +0200

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]] 
> Sent: Tuesday, April 25, 2006 5:58 PM
> To: Alexandru Petrescu
> Cc: [email-masked]
> Subject: [Mip6] Re: Should we assume SeND in foreign/visited 
> networks? (was:Substitute "high risk" for "mitigated risk" in 
> SecurityConsiderations of draft-ietf-mip6-bootstrapping-split-02.txt)
> 
> > James, I think I didn't make myself clear (if you got my message 
> > please skip this).  It's the DNS bootstrapping method that tells MN 
> > whether it's at home or not.  Clearly, a rogue AP/AR/DNS server can 
> > instruct a MN as apparently being at home.  This indication doesn't 
> > involve cert verification, because comes from RA and DNS.
> >
> > You're proposing this attack be foiled by running SeND on the home 
> > network.  But it should actually run on all foreign 
> networks where MN 
> > attaches.  To foil the attack, the MN shouldn't talk to any network 
> > that is not able to send SeND signatures on RAs.
> >
> 
> Right, if the 'H' bit is set on an RA in a foreign network, 
> how can the MN trust it?
> 
> This is something for the updated version of RFC 3775, I 
> think. Beyond the scope of the bootstrapping draft.
> 
> > So, do you propose to assume SeND is deployed on many 
> access networks?
> >
> 
> Well, I think SEND should be deployed on all last hop IPv6 
> networks. Having been the victim of an ARP spoofing attack 
> (on IPv4) myself , I can categorically state that the threat 
> is real, but most people don't seem to take it seriously. In 
> fact, I just got email the other day from a former IETF SEC 
> AD that he had suffered some kind of attack due to an 
> unsecured RA in IPv6. I don't know what the implementation 
> status of SEND is, but some people seem to be unhappy about 
> the fact that it contains IPR, even if the IPR is 
> royalty-free, which might be holding it up.

... and, AFAIK, IPR are only regarding CGA part of SeND.

Correct?

> 
> > If not, I think the risk you and I described above should 
> be evaluated 
> > as "high" and not "mitigated" in the section Security 
> Considerations 
> > of the draft.
> 
> Like I said, this is really beyond the bootstrapping draft. 
> RFC 3775 should recommend SEND to mitigate the risk of bogus 
> HA advertisement. But since RFC
> 3775 was written before SEND was completed, there is nothing in it. 
> Something for RFC 3775bis.
> 
>             jak
> 
>             jak 
> 
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

Best regards.

JMC.

France Telecom - R&D Division - MAPS/NSS   
Jean-Michel COMBES, Internet/Intranet Security
E-Mail: [email-masked]
Phone: +33 (0)1 45 29 45 94
Fax: +33 (0)1 45 29 65 19
Mobile: +33 (0)6 07 29 30 16 

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Apr 2006 15:57:44 +0200

COMBES Jean-Michel RD-MAPS-ISS wrote:
>> access networks? Well, I think SEND should be deployed on all last 
>> hop IPv6 networks. Having been the victim of an ARP spoofing attack
>>  (on IPv4) myself , I can categorically state that the threat is 
>> real, but most people don't seem to take it seriously. In fact, I 
>> just got email the other day from a former IETF SEC AD that he had 
>> suffered some kind of attack due to an unsecured RA in IPv6. I 
>> don't know what the implementation status of SEND is, but some 
>> people seem to be unhappy about the fact that it contains IPR, even
>>  if the IPR is royalty-free, which might be holding it up.
> 

Once again, I think the issue here is about properly evangelizing this
particular protocol.  I think we are good at launching good intelligent
things but forget about deploying it, and considering that somehow less
of an intellectual challenge.  In this view I regret the fact the
respective mailing list is closed.

I.e., if this RF/RAND aspect of this protocol were explained clearly and
at each time the question of using SeND comes up, as part of SeND
evangelizing, then we could advance and obtain quicker deployment,
or at least find out what else (than just IPR aspects) holds SeND
deployment back.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Wed, 26 Apr 2006 09:03:42 -0700

>... and, AFAIK, IPR are only regarding CGA part of SeND.

Yes.

BTW, after two years of trying, I have finally received approval to release 
DoCoMo's OpenSource SEND, for both Linux and BSD. I'll announce it on the 
IPv6 and SEND mailing lists when the Web site is set up.

            jak