Narayanan, Vidya | 7 Jul 23:55 2006

Symmetric-key Based Addresses (SBA)

All,
We are trying to have a discussion in Montreal on the problem of IP
address authorization and how this relates to proxy neighbor discovery
and IP mobility protocols, in the context of AAA-based systems. SEND
solves the problem on the local link that a node resides in. However, IP
mobility protocols like Mobile IP and NETLMM require an entity (e.g.,
Home Agent) to defend the IP address of a node in proxy mode. There is
also the issue in NETLMM that when an AR needs to perform mobility for a
given node, it must have a means of authorizing the IP address of the
node before it does that. Protocols like FMIPv6 require address
authorization prior to binding a key for a given MN with its CoA. CGAs
don't really solve the problem in such cases. In AAA-based systems, we
can achieve this type of IP address authorization using addresses
generated with symmetric keys. 

Towards such an approach, we have an initial draft on Symmetric-key
Based Addresses
(http://www.ietf.org/internet-drafts/draft-narayanan-pba-01.txt). The
draft does not provide the complete solution or architecture, but is
seen as a starting point for discussion. 

We are hoping to have a discussion in the INT area meeting on this
topic. However, it may turn out due to lack of time at that meeting that
we end up having this presentation and discussion at the MIPSHOP
meeting. A pointer to an early version of the slides can be found at
http://www.geocities.com/hellovidya/SBA_IETF-66.pdf.

We invite reviews and thoughts on the problem space - our goal is to get
a discussion on the problems and guage interest in solving this. 

(Continue reading)

Pekka Savola | 9 Jul 14:21 2006
Picon

RFC 3484 updates [Re: int-area agenda, take 1]

On Fri, 30 Jun 2006, Jari Arkko wrote:
> 3. Source address selection problem for multihomed environments, Marcelo
>   Bagnulo (10 min)
>   http://www.ietf.org/internet-drafts/draft-bagnulo-rfc3484-update-00.txt
>   Goal: Does RFC 3484 need updating? Provide input on Marcelo's multihoming
>   issues.

Yes, I believe RFC3484 needs updating.  I think it requires a bigger 
update than just source-address retrying that Marcelo argues for in 
this draft.  Hence I think a better draft to start thinking about the 
revision is draft-arifumi-v6ops-addr-select-ps-00.txt which also 
includes the source address selection problem.

Two specific comments about draft-bagnulo:
  - Section 2.2 talks about ISP-Internet link failing.  These kind of 
events are very rare, and the issue is same for ISP-customer link 
failure.  Hence, this problem should rather be described from that 
perspective.
  - Section 3.1.2 first change seems to assume that all the source 
addresses (when bind() is used for example) are equivalent.  That's 
not necessarily the case.  My perception is that app writers use 
bind() for client-like applications when they actually want to 
specify the address or interface (using SO_BINDTODEVICE or the 
like) in case of connected sockets or when they want to select the 
source address (so that they always use the same one) for unconnected 
sockets (e.g., NTP daemon).  In either case, the proposed approach 
might not produce desired results.  Hence, it would be useful to get a 
bit more knowledge of how folks use bind() like APIs for client apps.
  - Section 3.1.2, proposed rule 0 should probably include some 
discussion on what "is known to be not working" means and how it's 
(Continue reading)

Pekka Savola | 9 Jul 15:00 2006
Picon

Mobility comparison comments

On Fri, 30 Jun 2006, Jari Arkko wrote:
> 6. Comparison of mobility protocols (Dave Thaler, 30 min)
>   http://www.ietf.org/internet-drafts/draft-thaler-mobility-comparison-01.txt
>   Goal: Increase awareness of where the different schemes are. Discuss.

I liked the draft, though in places it could have possibly gone a bit 
deeper.   Maybe it's even more useful for the folks who are not aware 
of these already.  Some comments below.

substantial
-----------

    +-------------------+--------------+-------------+-----------------+
    |                   | MIP6         | SHIM6       | HIP             |
    +-------------------+--------------+-------------+-----------------+
    | Stable addresses  | Yes          | Assumed     | Non-routable    |
    +-------------------+--------------+-------------+-----------------+

==> I believe MIP6 part is mischaracterization.  The whole concept of 
MIPv6 HoA stability depends on ... well, the stability of Home 
Address.  So I'd change "Yes" to "HoA Assumed" or just "Assumed". 
For example, you cannot renumber your home address when you have 
connections going (a bit similar to SHIM6) and you also have 
multihoming redundancy issues (like SHIM6) unless you have PI space.

5. Deployment Considerations

    +-------------------+--------------+-------------+-----------------+
    |                   | MIP6         | SHIM6       | HIP             |
    +-------------------+--------------+-------------+-----------------+
(Continue reading)

Pekka Savola | 9 Jul 15:05 2006
Picon

RFC 3484 address selection problem statement comments

Hi,

(Crossposting as RFC 3484 update is being discussed on int-area..)

A few comments on:

      Problem Statement of Default Address Selection in Multi-prefix
         Environment: Operational Issues of RFC3484 Default Rules
                draft-arifumi-v6ops-addr-select-ps-00.txt

.. which I believe is a good start at gathering bits and pieces for 
RFC 3484 update.

Comments below, mostly relating to making it clearer what the actual 
problem is (but this is to be expected in a -00 problem statement 
draft :-):

substantial
-----------

Section 2.1.3. Half-Closed Network Problem
....
    This network environment is commonly used in practice because the
    access-line to the ISP2 might actually be a VPN tunnel over ISP1 and
    the Internet.

==> it's not clear what you're using as a justification in saying that the
network environment is commonly used in practice.  Typical enterprise VPN
deployments (so far as I've seen) often route all the traffic through them
(i.e., are connected to the Internet).  Are you referring to ones which only
(Continue reading)

Stig Venaas | 9 Jul 15:59 2006
Picon
Picon

Re: RFC 3484 updates [Re: int-area agenda, take 1]

Pekka Savola wrote:
[...]
>  - Section 3.1.2 first change seems to assume that all the source 
> addresses (when bind() is used for example) are equivalent.  That's not 
> necessarily the case.  My perception is that app writers use bind() for 
> client-like applications when they actually want to specify the address 
> or interface (using SO_BINDTODEVICE or the like) in case of connected 
> sockets or when they want to select the source address (so that they 
> always use the same one) for unconnected sockets (e.g., NTP daemon).  In 
> either case, the proposed approach might not produce desired results.  
> Hence, it would be useful to get a bit more knowledge of how folks use 
> bind() like APIs for client apps.

I would say it's pretty common to use bind() to use one fixed source 
address. The application might let the stack choose the address, but by 
using bind() it can make sure that the address is fixed, and the 
application might also care which address it got for the socket.

 From what I've seen on the operating systems I've tested, for tcp and 
also udp if socket is bound, the source address is fixed. I've even 
tried to remove an address from the interface and the removed address is 
still being used as source.

For udp if the socket is not bound, I would hope that address selection 
is used, but it might be bad for some applications to change source 
address during a udp "session".

Stig

>  - Section 3.1.2, proposed rule 0 should probably include some 
(Continue reading)

Julien Laganier | 11 Jul 01:45 2006
Picon

Re: Mobility comparison comments

Hi Pekka,

I have some precisions on HIP inlined below,

[...]

> 5. Deployment Considerations

>     SHIM6 and HIP both require support in both ends before their
>     benefits can be realized.
>
> ==> I think you should go a bit deeper on this.  Important question
> to ask should be, "What impact does enabling this mechanism at one
> end have, when it isn't supported on the other?"  For example, in
> HIP there are extra DNS requests for new RR with HIP, with fallback
> to A/AAAA (i.e., extra delay of at least 1 DNS roundtrip, possibly
> more when trying to connect to any non-HIP destination).

I don't think that is necessarily the case. The HIP DNS draft has no 
normative text describing that lookups should be serialized and 
ordered. It is entirely possible that you issue simultaneously A/AAAA 
and HIP RR QUERIES (and I was told my DNSext people that it's not a 
problem.) If you receive a HIP RR the other end does support HIP and 
you establish an association, and if no HIP RR comes back you connect 
with plain IP.

[...]

>     HIP depends on the IPsec [IPSEC] protocol for basic operation. 
> It also depends on the existence of a HIP Rendezvous Server for its
(Continue reading)

Pekka Savola | 11 Jul 01:54 2006
Picon

Re: Mobility comparison comments

On Tue, 11 Jul 2006, Julien Laganier wrote:
>> ==> I think you should go a bit deeper on this.  Important question
>> to ask should be, "What impact does enabling this mechanism at one
>> end have, when it isn't supported on the other?"  For example, in
>> HIP there are extra DNS requests for new RR with HIP, with fallback
>> to A/AAAA (i.e., extra delay of at least 1 DNS roundtrip, possibly
>> more when trying to connect to any non-HIP destination).
>
> I don't think that is necessarily the case. The HIP DNS draft has no
> normative text describing that lookups should be serialized and
> ordered. It is entirely possible that you issue simultaneously A/AAAA
> and HIP RR QUERIES (and I was told my DNSext people that it's not a
> problem.) If you receive a HIP RR the other end does support HIP and
> you establish an association, and if no HIP RR comes back you connect
> with plain IP.

I've certainly advocated this approach myself for AAAA/A lookup 
problems (RFC 4472, section 5.1).  I'm not sure whether or how widely 
parallel lookups have been implemented.  I've heard some comments of 
application complexity of handling asynchronous events and/or 
threading with various possible results, but it's unclear whether this 
would be a real impediment.  Certainly, I'd be interested in any 
implementation experience in this area.

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
marcelo bagnulo braun | 20 Jul 15:07 2006
Picon

about draft-bagnulo-multiple-hash-cga-00

Hi,

During the presentation of the draft in the Int area meeting there was 
quite a lot of feedback. First of all i would like to thank for so many 
constructive comments (this was an unusual experience for me at ietf 
:-)
As i understood most folks thought that it was a good idea to enable 
multiple hash support in the CGAs and that the proposed approach for 
supporting it was acceptable.

As i recall there was only one comment left for further discussion 
(please if there was another issue for discussion let me know and i 
will address it in the ml). The open issue was Gabriel question about 
supporting multiple public key algorithms and in case that we want to 
do this, whether this needs to be done in this draft/registry.

As you know, draft-bagnulo-multiple-hash-cga-00 is proposing the 
creation of a registry for the Sec values, so that the hash function 
can be encoded in the address itself, in order to prevent the so-called 
downgrading attacks. The registry will also contain the associated Sec 
parameter value for the assigned value.

The question raised by Gab is, in case we want to support multiple 
public key algorithms, do we need to encode them in the address itself?

After discussing this with Gab, my understanding is that the public key 
algorithm does not need to be encoded in the address itself, since this 
is not required to prevent downgrading attacks that may sprig from 
using weaker public key algorithms (please Gab correct me if my 
understanding is inaccurate).
(Continue reading)

Arifumi Matsumoto | 28 Jul 13:00 2006
Picon

Re: RFC 3484 address selection problem statement comments

Pekka,
thank you for your comments.
I'm really sorry for very late reply.

Comments below.

Pekka Savola wrote:
> Hi,
> 
> (Crossposting as RFC 3484 update is being discussed on int-area..)
> 
> A few comments on:
> 
>      Problem Statement of Default Address Selection in Multi-prefix
>         Environment: Operational Issues of RFC3484 Default Rules
>                draft-arifumi-v6ops-addr-select-ps-00.txt
> 
> .. which I believe is a good start at gathering bits and pieces for RFC 
> 3484 update.
> 
> Comments below, mostly relating to making it clearer what the actual 
> problem is (but this is to be expected in a -00 problem statement draft 
> :-):
> 
> substantial
> -----------
> 
> Section 2.1.3. Half-Closed Network Problem
> ....
>    This network environment is commonly used in practice because the
(Continue reading)

Jari Arkko | 31 Jul 20:58 2006
Picon

Looking for a new co-chair in MIPSHOP


Gabriel Montenegro is stepping down as a co-chair of MIPSHOP,
after having served years in this role and having taken the
first incarnation of the WG to its successful conclusion
(thank you Gabriel!).

The Area Directors are now looking for a new co-chair to
work with Stefano Faccin, who remains as the other co-chair.

We have decided to make this announcement in order to ensure
that all the potential candidates are aware of the open position.

Please find below a brief profile for the co-chair. We would
like you to consider this profile and either nominate yourself
or other people that you think that would fit well in this
role.  Send the nominations by e-mail to me.

Note that this profile is written for a somewhat ideal
candidate. We fully realize that such people are probably
non-existent, so don't hesitate to nominate somebody who in
your opinion would fit this role quite well but doesn't fit
this profile 100%. And the intent is to select a person so
that the co-chairs can complement each other and work
together.

As for the profile:

- Good management and process skills, including but not
  limited to choosing and supervising editors, commitment and
  follow-through on the charter, active management of the
(Continue reading)


Gmane