Subject: Re: [Mip6] Template for raising issues w.r.t WG documents

From: Francis Dupont <[email-masked]>
Date: Wed, 05 May 2004 10:03:00 +0200

Description of issue : Presentation of ingress filtering in RO security
Submitter name: Francis Dupont
Submitter email address: [email-masked]
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: 

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 May 2004 10:20:38 +0200

Description of issue : Passive attack against privacy
Submitter name: Francis Dupont
Submitter email address: [email-masked]
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:

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 May 2004 11:30:44 +0300 (EEST)

>  (and please cite it). Reconsider the opinions (second paragraph).

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 May 2004 10:47:33 +0200

Description of issue : Improvement to 3.3.1 (spurious BUs) for CNs
Submitter name: Francis Dupont
Submitter email address: [email-masked]
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:

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 May 2004 11:07:13 +0200

Description of issue : Strong disagreement vs 3.5 introduction
Submitter name: Francis Dupont
Submitter email address: [email-masked]
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
    IPsec is weaker than return routability check?

Requested change: 
 Reword the first statement and remove the "first reason" (the second
 should be enough, and was).

Proposal: 

Extra note: (editorial) change the 3ff0::/16 into 3ffe::/16

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 May 2004 11:26:26 +0200

Description of issue : DNSSEC bashing
Submitter name: Francis Dupont
Submitter email address: [email-masked]
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:

---

From: Jari Arkko <[email-masked]>
Date: Wed, 05 May 2004 12:36:59 +0300

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.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 05 May 2004 12:47:38 +0300

>   - I agree with the last statement (scalability) only.

Ok.

>     in fact the idea is that IPsec can't be the default/required mechanism.

I'd be willing to look at proposed text. Some rewording might
be OK.

>     IPsec is weaker than return routability check?

I don't like the current text either. It talks about DoS attacks
in a way that can be interpreted in the wrong way. OTOH, I don't
agree with you above either, when you say that strong mutual
authentication is better than RR. The problem with strong mutual
authentication is that it does not address the authorization
issue (except perhaps in limited cases, and certainly not in
a scalable way). But perhaps its easy for us to find agreement
by expanding a bit the scalability reason. For instance, we
can state the requirements, such as being able to show some
form of "address ownership", and mention the problems in getting
something IPsec and certificates to provide that in a large
scale, even if your laptop and home server could be set up
this way.

> Extra note: (editorial) change the 3ff0::/16 into 3ffe::/16

Thanks for noticing this.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 05 May 2004 12:39:30 +0300

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 05 May 2004 12:32:30 +0300

Changing the subject line to match the disussion
better. Otherwise I agree with the issue and its
proposed resolution. Thanks for raising this issue.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 May 2004 14:56:49 +0200

In your previous mail you wrote:

=> thanks for the pointer. Perhaps if the ingress filtering vs.
multi-homing last remark is kept this RFC/BCP should be cited too,
shouldn't it?

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 May 2004 15:20:30 +0200

=>

=> this text is far better but still a bit vague about problems with
site multi-homing: one can argue that the site multi-homing has a problem
with ingress filtering, not the reverse. IMHO in order to be fair and
accurate the best solution is to point to the RFC 3704/BCP 84 (giving
the full name of the document).

Thanks

PS: in the issue tracking system the RFC/BCP should replace the pointer
to the Cisco enhanced uRPF document.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 May 2004 15:26:33 +0200

=> as the document goal (1) is to provide hints to MIPv6 implementors
I believe this hint is short and useful enough to be added (i.e.,
priority is "should" (2)). I am adding the same kind of statement
in the new OMIPv6+ I-D.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 May 2004 15:39:53 +0200

=> my English is not as good as it should be but something like
"plain IPsec could be the default way to secure Binding Updates."
is already better.

   a scalable way).

=> even authentication is not authorization it is better to base
the authorization on strong authentication than on RR check...

   But perhaps its easy for us to find agreement
   by expanding a bit the scalability reason.

=> what I asked is to remove the first reason too.

   For instance, we
   
=> IMHO the right argument is a global PKI is hard to deploy and
none is available in a reasonnable timeframe. As unfortunately
nobody can prove this statement is wrong by exhibing a global PKI,
IMHO we don't need more.

Thanks

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 05 May 2004 08:50:41 -0700

Hello folks,

I have another major disagreement with the text below.

>   even impossible with plain vanilla IPsec. The second reason is
The first reason that IPsec was denigrated was because of the structure of
the Binding Update.  The IPsec experts claimed that one could not use the
destination option number as a selector for a security association.

The second reason was that the area directors insisted on a scalable
solution for binding updates with arbitrary correspondent nodes, but
historically that was secondary.  And, as we have seen, it would have
been better anyway to pursue that later; even now it is burdensome to
have the return routability in the same document as the base specification.
So, scalability was at once mandated and yet not possible at that time
with any known mechanisms.

The other points were raised afterwards, historically speaking.
And, try as I might, I can't get bent out of shape about the address
ownership problem anyway, so I would very much object to
making that anywhere near the "major" reason.  I've never heard
of any threats outside the realm of thought experiments involving
applications with weird properties.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 May 2004 18:27:28 +0200

Description of issue : IPsec & home test
Submitter name: Francis Dupont
Submitter email address: [email-masked]
Date first submitted: 2004/05/05
Reference: 
Document: draft-ietf-mip6-ro-sec-00.txt
Comment type: T
Priority: S
Section: 5.2
Rationale/Explanation of issue: 
 The purpose of the home address check is messed with the authentication
 is not authorization issue.
Length description of problem :
 The current text is:
   If one wants
   to replace the home address check with some cryptographic
   credentials, the credentials must carry proper authorization for the
   specific home address. For example, if the mobile nodes hands out a
   certificate to the correspondent node and they consequently create a
   pair of IPsec security associations, it is not necessarily clear that
   those security associations could be used to replace the home address
   check. Instead, if and only if the certificate explicitly states what
   the mobile node's home address is and that the mobile node is
   authorized to create bindings for its home address, home address
   checks may be dropped. Furthermore, care must be taken to make sure
   that the issuer of the certificate is entitled to express such
   authorization.

The issue is the home address check is only a return routability check,
i.e., it gives some assurance the mobile node is really reachable at
the home address. Of course IPsec/IKE includes the same check (one can
argue the round trips are too many :-) and usually gives far more.
The real issue is an authorization one, i.e., to be allowed to establish
some IPsec security associations is to be allowed to do anything.
This is a standard policy issue which has nothing to do with the home
address check, and usually the issue is not spurious authorization to
create bindings, it is to (mis)use the authorization to create bindings
to try to get higher priviledges.

Requested change: 
 Complete rewording of the paragraph. One can use text from the MN-CN
IPsec I-D.
Proposal: