headers
Jari Arkko | 1 Jun 2004 06:07
Picon
Picon

Re: Re: One more modification to the base

Vijay Devarapalli wrote:
> hi Jari,
> 
> I am not sure I understand. even if the IESG approves, lets say,
> a new mobility message type, it would still need IANA action.
> IANA action is required in all cases.
> 
> "... can be allocated using Standards Action or IESG Approval"
> doesnt make sense to me.
> 
> I guess you are trying to say Standards Action is a MUST, but
> for some cases (like Experimental purpose) IESG approval is

That's about right. The idea is that standards action is
the usual case, but in some exceptional cases one can go
through the iesg approval too.

The IANA action issue is separate. An IANA action is
always needed, as you say, but what we talk about here
is the allocation policy that determines when and if
they will perform this action. For instance, an allocation
policy can be FCFS, which means that IANA will happily
do their action upon request. Or it can be Standards
Action, in which case they only do it while a Standards
Track RFC is being processed by the RFC Editor.

> required. IMO, these things should not be in the spec, but
> should be communicated to the IANA. IANA should be told that
> when they allocate new MH types, it might make sense to consult
> the IESG. and if the IESG says no, dont allocate it. or
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vijay Devarapalli | 1 Jun 2004 07:50
Picon

Re: Re: One more modification to the base

okay. thanks for the clarification.

Vijay

Jari Arkko wrote:

> Vijay Devarapalli wrote:
> 
>> hi Jari,
>>
>> I am not sure I understand. even if the IESG approves, lets say,
>> a new mobility message type, it would still need IANA action.
>> IANA action is required in all cases.
>>
>> "... can be allocated using Standards Action or IESG Approval"
>> doesnt make sense to me.
>>
>> I guess you are trying to say Standards Action is a MUST, but
>> for some cases (like Experimental purpose) IESG approval is
> 
> 
> That's about right. The idea is that standards action is
> the usual case, but in some exceptional cases one can go
> through the iesg approval too.
> 
> The IANA action issue is separate. An IANA action is
> always needed, as you say, but what we talk about here
> is the allocation policy that determines when and if
> they will perform this action. For instance, an allocation
> policy can be FCFS, which means that IANA will happily
(Continue reading)

Permalink | Reply | 0 comments |
headers
Basavaraj.Patil | 3 Jun 2004 15:16
Picon

Mailing list problems


Hello,

Ryuji Wakikawa who is responsible for managing the MIP6 ML has noted
that the mailing list is experiencing a few problems. These problems
are not unique to the MIP6 ML. Other MLs in the IETF are also experiencing
similar problems and the IETF secretariat is looking at it.

Ryuji's comments:

>There are non SPAM emails in the blocked mail page,
>It might be better to announce this to MIP6 ML.
>For example, Samita, Jari's mail is blocked right now.

>I am one of MIP6 ML admin and doing human SPAM filter every days.
>Since mailman was updated, I couldn't process SPAM mails.

>I tried to discard some of SPAM mails and took action for such mails (press
>"Submit All Data" button). Nothing was occurred. The page was reloaded,
>but SPAM was still there.

>ryuji

Please be aware of the problems in case you are wondering if your mail did not
go through.

And again, thanks to Ryuji for taking on the MIP6 ML responsibilities.

-Basavaraj
(Continue reading)

Permalink | Reply | 0 comments |
headers
gabriel montenegro | 3 Jun 2004 17:46
Picon

issue 3: Presentation of ingress filtering in RO security

[http://www.mip4.org/issues/tracker/mip6/issue3]

Thanks to Francis, Jari and Pekka Savola. I've tried to incorporate
some of what rfc3704 says, and also refer to it.

This is the proposed text, in section 1.1.1:

OLD:

   When ingress filtering is used, the source address of all packets are
   screened by the Internet service provider, and if the source address
   has a routing prefix that should not be used by the customer, the
   packets are dropped.

   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.

NEW:

   When ingress filtering is used, traffic with spoofed addresses is not
   forwarded.  This filtering can be applied at different network
   borders like those between an Internet service provider (ISP)  and
   its customers, between downstream and upstream ISPs, between peer
   ISPs, etc.  It enables traffic to be traceable to its real source
(Continue reading)

Permalink | Reply | 9 comments |
headers
gabriel montenegro | 3 Jun 2004 17:48
Picon

issue 4: Issues with IPsec related text in the Introduction

[http://www.mip4.org/issues/tracker/mip6/issue4]

Well, there were several reasons for IPsec
not being usable as the default mechanism to protect BU's, but I suspect
Francis is right in that the only real one is "scalability" (the lack of a
global PKI).

But even this is misleading, as this is a reason to not use IKE,
not necessarily a reason to dismiss IPsec (ESP and/or AH).
The real problem is IKE and its reliance on an infrastructure. Notice
that one can substitute IKE by an infrastructure-less mechanism,
in which case IPsec seems perfectly usable. This is what we've proposed
previously with our SUCV work (sucvP protocol did the key
exchange using CGAs after which one just used IPsec as usual).

Furthermore, it is not even a problem with IKE per se. In a previous
I-D we have also proposed modifications to IKE so that it can deal with
CGAs. In short, the problem is with vanilla IKE's reliance on
infrastructure-based security: a global PKI. The real reasons for
dismissing it were that (1) CGA applications to IPsec were not clearly understood and
(2) because of IPR complications. Whereas (1) is resolvable,
intellectual property concerns are still a major impediment.

But this seems to be a digression. The clue is "vanilla IPsec can't
be used as the default mechanism".

We had the additional constraint to not expect too many changes in IPsec
to accomodate MIPv6 security, hence things that departed from vanilla
IPsec (like the infrastructureless approaches mentioned above) didn't
stand much of a chance.
(Continue reading)

Permalink | Reply | 2 comments |
headers
gabriel montenegro | 3 Jun 2004 17:49
Picon

issue 5: DNSSEC bashing

[http://www.mip4.org/issues/tracker/mip6/issue5]

Francis Dupont wrote:

> 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.

I still don't think this presents a practical scheme, so I'm inclined to
keep the last paragraph, although I will try to soften it a bit (e.g.,
deleting the "last nail on the coffin" expression which seems out of place
in an RFC). A similar scheme is proposed in SeND to protect RA's, but
(Continue reading)

Permalink | Reply | 503 comments |
headers
gabriel montenegro | 3 Jun 2004 17:51
Picon

issue 6: IPsec & home test

[http://www.mip4.org/issues/tracker/mip6/issue6]

Francis,

I don't agree with your assessment that the home address check is
only a return routability check. Given that it passes through
a home agent on its way to the MN, it really gives you two things:

1. reachability or "liveness" test: is there a system out there
	responding currently at this (home) address?
2. this node is recognized by the HA as one of its rightful mobiles

Neither of the above is very strong evidence. This is
good and bad. Bad because we will always have this confusion as to
what the guarantees are exactly. The guarantees are not as close to 100%
as if they were *strong* (but nothing is 100% either). But
they are certainly better than 0%. And for most of us they are "good enough".
Specially, given the tradeoffs evident by what is good about these weak
guarantees: they are very cheap in CPU cost.

#2 above, compounded with the care-of test is what allows the CN to
have some greater than 0% assurance that this node is indeed entitled
to send BU's on behalf of this home address.

The text just says that the above guarantees (yes, probably with even
higher assurance) are also obtainable via explicit expressions in certificates,
but that these need to be very carefully done.

Perhaps I'm missing the sense of the comment, but I fail to see much
reason for it.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Heejin Jang | 4 Jun 2004 06:33

I-D ACTION : draft-jang-dhc-haopt-00.txt

Hello all,

I have posted an I-D that describes a DHCP-based mechanism 
to distribute dynamic discovery of  MIPv6 HA and home subnet. 
Any feedback will be highly welcome.

-------------------------------------------------------------------- 
A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : DHCP Option for Home Agent Discovery in MIPv6
Author(s) : Heejin Jang, Alper Yegin, Jinhyeok Choi
Filename : draft-jang-dhc-haopt-00.txt
Pages : 15
Date : 2004-6-2

   This draft defines a DHCP-based scheme to enable dynamic discovery of
   Mobile IPv6 home agent address and home subnet. A new DHCP option is
   defined to carry the information from a DHCP server to the DHCP
   client running on the mobile node.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jang-dhc-haopt-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-jang-dhc-haopt-00.txt".
Permalink | Reply | 0 comments |
headers
marcelo bagnulo braun | 4 Jun 2004 11:15
Picon

Re: issue 3: Presentation of ingress filtering in RO security

Hi Gabriel,

El 03/06/2004, a las 17:46, gabriel montenegro escribió:

> [http://www.mip4.org/issues/tracker/mip6/issue3]
>
> Thanks to Francis, Jari and Pekka Savola. I've tried to incorporate
> some of what rfc3704 says, and also refer to it.
>
> This is the proposed text, in section 1.1.1:
>
> OLD:
>
>    When ingress filtering is used, the source address of all packets 
> are
>    screened by the Internet service provider, and if the source address
>    has a routing prefix that should not be used by the customer, the
>    packets are dropped.
>
>    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.
>
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jari Arkko | 4 Jun 2004 14:01
Picon
Picon

Re: issue 6: IPsec & home test


I agree that this issue should be rejected. All that
the current text says is that the home address test
can not _necessarily_ be replaced by cryptographic
credentials. It does not say one couldn't design
a solution that satisfies the requirements. For
instance, even an opportunistic IPsec-IKE negotiation,
if run through the home agent and with its consent,
might work well. However, an IPsec-IKE negotiation
directly between a CN and MN without involving the
home agent even for routing would be troublesome.

--Jari

gabriel montenegro wrote:
> [http://www.mip4.org/issues/tracker/mip6/issue6]
> 
> Francis,
> 
> I don't agree with your assessment that the home address check is
> only a return routability check. Given that it passes through
> a home agent on its way to the MN, it really gives you two things:
> 
> 1. reachability or "liveness" test: is there a system out there
> 	responding currently at this (home) address?
> 2. this node is recognized by the HA as one of its rightful mobiles
> 
> Neither of the above is very strong evidence. This is
> good and bad. Bad because we will always have this confusion as to
> what the guarantees are exactly. The guarantees are not as close to 100%
(Continue reading)

Permalink | Reply | 4 comments |

Gmane