headers
BOUVARD Bruno | 4 May 2004 13:44
Picon

MIPv6 implemntation

Hello,

I try to find documents, "howto" on how to implement and configure 
Mobile IPv6 with Free BSD version 4.9.
But I'm unsuccessfull !!

May you help me.

Regards

Bruno BOUVARD
Permalink | Reply | 0 comments |
headers
Francis Dupont | 5 May 2004 10:03
Picon
Picon

Re: Template for raising issues w.r.t WG documents

Description of issue : Presentation of ingress filtering in RO security
Submitter name: Francis Dupont
Submitter email address: Francis.Dupont <at> enst-bretagne.fr
Date first submitted: 2004/05/05
Reference: <attachement>
Document: draft-ietf-mip6-ro-sec-00.txt
Comment type: T
Priority: 1
Section: 1.1.1
Rationale/Explanation of issue:
 The description of ingress filtering in 1.1.1 is both incomplete and
 misleading.
Length description of problem :
 First ingress filtering may be applied not only by the access ISP,
 secondly unicast RPF check works in the core network, even with
 asymmetrical routing.
 [http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement.pdf]
Requested change: 
 Complete the description (first paragraph) according to RFC 2827/BCP 38
 (and please cite it). Reconsider the opinions (second paragraph).
Proposal:
Permalink | Reply | 4 comments |
headers
Francis Dupont | 5 May 2004 10:20
Picon
Picon

Re: Template for raising issues w.r.t WG documents

Description of issue : Passive attack against privacy
Submitter name: Francis Dupont
Submitter email address: Francis.Dupont <at> enst-bretagne.fr
Date first submitted: 2004/05/05
Reference:
Document: draft-ietf-mip6-ro-sec-00.txt
Comment type: E
Priority: 1
Section: 3
Rationale/Explanation of issue:
 Authors consider only active attackers when passive attackers can be
 a threat against privacy.
Length description of problem :
 The privacy issue is very important because of regulation bodies and
 is not limited to active attacks.

Requested change: 
 Explicitely state that the privacy issue is not in the scope of the document.
Proposal:
Permalink | Reply | 3 comments |
headers
Pekka Savola | 5 May 2004 10:30
Picon

Re: Template for raising issues w.r.t WG documents

On Wed, 5 May 2004, Francis Dupont wrote:
> Length description of problem :
>  First ingress filtering may be applied not only by the access ISP,
>  secondly unicast RPF check works in the core network, even with
>  asymmetrical routing.
>  [http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement.pdf]
> Requested change: 
>  Complete the description (first paragraph) according to RFC 2827/BCP 38
>  (and please cite it). Reconsider the opinions (second paragraph).
> Proposal: 

RFC3704 (BCP 84) may be worth a read here, it tries to give a better
picture of ingress filtering than BCP 38..

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Permalink | Reply | 3 comments |
headers
Francis Dupont | 5 May 2004 10:47
Picon
Picon

Re: Template for raising issues w.r.t WG documents

Description of issue : Improvement to 3.3.1 (spurious BUs) for CNs
Submitter name: Francis Dupont
Submitter email address: Francis.Dupont <at> enst-bretagne.fr
Date first submitted: 2004/05/05
Reference: 
Document: draft-ietf-mip6-ro-sec-00.txt
Comment type: T
Priority: 2
Section: 3.3.1
Rationale/Explanation of issue:
 Use the destination cache (RFC 2461 5.1) to recognize addresses with
 which CNs have had meaningful comminication recently.
Length description of problem :
 RFC 2461 section 5.1 (Host) Conceptual Data Structures defines
 the Destination Cache as a set of entries about destinations to which
 traffic has been sent recently. The RO security document specifies
 that the node may also recognize addresses with which they have had
 meaningful communication in the past and sent binding updates to or
 accept them from those addresses.
Requested change: 
 Suggest to use the destination cache.
Proposal:
Permalink | Reply | 3 comments |
headers
Francis Dupont | 5 May 2004 11:07
Picon
Picon

Re: Template for raising issues w.r.t WG documents

Description of issue : Strong disagreement vs 3.5 introduction
Submitter name: Francis Dupont
Submitter email address: Francis.Dupont <at> enst-bretagne.fr
Date first submitted: 2004/05/05
Reference: 
Document: draft-ietf-mip6-ro-sec-00.txt
Comment type: T
Priority: S
Section: 3.5
Rationale/Explanation of issue: 
 I strongly disagree with the first paragraph of 3.5.
Length description of problem :
 The current text is:
   Early in the MIPv6 design process it was assumed that plain IPsec
   could be used for securing Binding Updates. However, this turned out
   to be impossible for two reasons. The first reason can be inferred
   from the attack descriptions above: IPsec is not designed to protect
   against the kinds of DoS attacks that would be possible with MIPv6.
   Protecting against the flooding attacks would be very difficult or
   even impossible with plain vanilla IPsec. The second reason is
   scalability.

 I have three points:
  - I agree with the last statement (scalability) only.
  - the word "could" in the first statement should be improved because
    it may be interpreted as IPsec can't be used to protect BUs when
    in fact the idea is that IPsec can't be the default/required mechanism.
  - the first reason is completely wrong IMHO. One can argue that IPsec
    has its own DoS issues but this is not what I can read here. Do authors
    really believe that the strong mutual authentication required/used by
(Continue reading)

Permalink | Reply | 5 comments |
headers
Francis Dupont | 5 May 2004 11:26
Picon
Picon

Re: Template for raising issues w.r.t WG documents

Description of issue : DNSSEC bashing
Submitter name: Francis Dupont
Submitter email address: Francis.Dupont <at> enst-bretagne.fr
Date first submitted: 2004/05/05
Reference: 
Document: draft-ietf-mip6-ro-sec-00.txt
Comment type: E
Priority: S
Section: 3.5
Rationale/Explanation of issue:
 3.5 contains a DNSSEC bashing which is both not wellcome and technically
 incorrect.
Length description of problem :
 DNSSEC works with any secure entry point, i.e., it does not require
 a signed root. For instance it is enough to make the IPv6 reverse tree
 signed by the 3 RIRs to deploy the scheme described in 3.5 in a global
 scale.
 The last paragraph is just a personal opinion of authors against DNSSEC
 and has nothing to do here. The last point ("nail on the coffin") is
 unfair because the section is about the home address authorization and
 the RR check does not assign and verify "ownership" of care-of addresses.

Requested change: 
 1- Do not require a signed root.
 2- Remove the last paragraph.
 3- Introduce the assign and ownership verification of care-of addresses
 item not as an argument against DNSSEC style PKIs, but as something
 which can be only provided by an AAA infrastructure.

Proposal:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jari Arkko | 5 May 2004 11:36
Picon
Picon

ro-sec-00.txt & ingress filtering (Was: Re: Template for raising issues w.r.t WG documents)

I agree with the issue and Pekka's note as well.
In the second paragraph, some of it still applies.
How about this:

    It should be noted that ingress filtering is relatively easy to apply
    at the edges of the network, but almost impossible in the core
    network. Basically, ingress filtering is easy only when the network
    topology and prefix assignment do follow the same hierarchical
    structure. Secondly, ingress filtering helps if and only if a large
    part of the Internet uses it. Thirdly, ingress filtering has its own
    technical problems, e.g. with respect to site multi-homing, and these
    problems are likely to limit its usefulness.

=>

    Ingress filtering helps if and only if a large part of the
    Internet uses it. Secondly, ingress filtering has some
    technical issues, e.g. with respect to site multi-homing, and these
    problems are likely to limit its usefulness.

Pekka Savola wrote:
> On Wed, 5 May 2004, Francis Dupont wrote:
> 
>>Length description of problem :
>> First ingress filtering may be applied not only by the access ISP,
>> secondly unicast RPF check works in the core network, even with
>> asymmetrical routing.
>> [http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement.pdf]
>>Requested change: 
>> Complete the description (first paragraph) according to RFC 2827/BCP 38
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jari Arkko | 5 May 2004 11:47
Picon
Picon

ro-sec-00.txt & ipsec in 3.5 (Was: Re: Template for raising issues w.r.t WG documents)


Francis Dupont wrote:
> Description of issue : Strong disagreement vs 3.5 introduction
> Submitter name: Francis Dupont
> Submitter email address: Francis.Dupont <at> enst-bretagne.fr
> Date first submitted: 2004/05/05
> Reference: 
> Document: draft-ietf-mip6-ro-sec-00.txt
> Comment type: T
> Priority: S
> Section: 3.5
> Rationale/Explanation of issue: 
>  I strongly disagree with the first paragraph of 3.5.
> Length description of problem :
>  The current text is:
>    Early in the MIPv6 design process it was assumed that plain IPsec
>    could be used for securing Binding Updates. However, this turned out
>    to be impossible for two reasons. The first reason can be inferred
>    from the attack descriptions above: IPsec is not designed to protect
>    against the kinds of DoS attacks that would be possible with MIPv6.
>    Protecting against the flooding attacks would be very difficult or
>    even impossible with plain vanilla IPsec. The second reason is
>    scalability.
> 
>  I have three points:
>   - I agree with the last statement (scalability) only.

Ok.

>   - the word "could" in the first statement should be improved because
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jari Arkko | 5 May 2004 11:39
Picon
Picon

Spurious BUs & Destination Cache (Was: Re: Template for raising issues w.r.t WG documents)

I think I agree about the issue as such. However, I
don't think ro-sec is the place to dictate _how_
things are to be done. Rather, it is an explanation
of the concepts. So I'd be fine even if the text
didn't talk about the destination cache. But I don't
mind changing it either.

--Jari

Francis Dupont wrote:
> Description of issue : Improvement to 3.3.1 (spurious BUs) for CNs
> Submitter name: Francis Dupont
> Submitter email address: Francis.Dupont <at> enst-bretagne.fr
> Date first submitted: 2004/05/05
> Reference: 
> Document: draft-ietf-mip6-ro-sec-00.txt
> Comment type: T
> Priority: 2
> Section: 3.3.1
> Rationale/Explanation of issue:
>  Use the destination cache (RFC 2461 5.1) to recognize addresses with
>  which CNs have had meaningful comminication recently.
> Length description of problem :
>  RFC 2461 section 5.1 (Host) Conceptual Data Structures defines
>  the Destination Cache as a set of entries about destinations to which
>  traffic has been sent recently. The RO security document specifies
>  that the node may also recognize addresses with which they have had
>  meaningful communication in the past and sent binding updates to or
>  accept them from those addresses.
> Requested change:
(Continue reading)

Permalink | Reply | 2 comments |

Gmane