Subject: [Hipsec-rg] RoHC
From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Tue, 18 Nov 2008 14:10:27 -0500

>>>>> "Robert" == Robert Moskowitz <rgm at htt-consult.com> writes:
    Robert> Sitting in the IPSECME meeting and the RoHC presentation.

    Robert> If they need 'help' from IKE, it would stand to reason that
    Robert> this would have some impact on HIP as well.  RoHC is not
    Robert> new, so has anyone looked at this?

  Get the BEET mode draft published already.
  For host/host IPsec, BEET meet is even better than RoHC...

-- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue, 18 Nov 2008 10:38:45 -0600
Subject: [Hipsec-rg] RoHC
Message-ID: <[email-masked]>

Sitting in the IPSECME meeting and the RoHC presentation.

If they need 'help' from IKE, it would stand to reason that this would 
have some impact on HIP as well.  RoHC is not new, so has anyone looked 
at this?

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Thu, 13 Nov 2008 14:29:34 +0200
Subject: [Hipsec-rg] HIP Animation
Message-ID: <[email-masked]>

http://people.arcada.fi/~bergstr/HIP/
Check out an applet showing HIP protocol in action.
Might be useful for introducing new people to HIP...

Andrei

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Wed, 12 Nov 2008 22:37:45 -0800
Subject: [Hipsec-rg] current agenda for HIPRG meeting, Fri. Nov. 21
Message-ID: <[email-masked]>

Please follow this URL to watch for late changes to the HIPRG meeting
agenda:
http://www.ietf.org/proceedings/08nov/agenda/HIPRG.txt

Below is the current agenda:

HIPRG IETF-73 meeting

Meeting Friday 0900-1100 November 21, 2008, in the Duluth Room.

Current agenda (last updated November 12)
-----------------------------------------

- HIP Extensions for Object-to-Object Communications
-- draft-lee-hip-object-01.txt
 (Gyu Myoung Lee)

- Delivering Geographic Location in HIP 
-- draft-cao-hip-geolocation-01.txt
 (Hui Deng)

- Update on the HIP-based Secure Mobile Architecture project at Boeing
 (Tom Henderson)

- Update on HIIT and InfraHIP's recent activities and future plans
 (Joakim Koskela)

Feel free to contact one of the chairs for any additional suggested 
agenda items.

From: miika.komu at hiit.fi (Miika Komu)
Date: Fri, 07 Nov 2008 16:46:54 +0200
Subject: [Hipsec-rg] Some comments on the draft-melen-hip-nat-mm-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Varjonen Samu wrote:

Hi,

> Miika Komu wrote:
>> Varjonen Samu wrote:
>>
> Included only the ones that had more discussion...
> 
>>
>>> - Section 4. start about the locator reachability status. RFC 5206 
>>> defines two state for the address, ACTIVE and UNVERIFIED. Would these 
>>> reachability related ones be actually new address states and be 
>>> somewhere between ACTIVE and UNVERIFIED?
>>
>> No, they are the same states as in RFC5206.
>>
> So the locator reachability status is just some implementation specific 
> local value stored with the locator pair, something like local priority 
> (priority as in type 2 locator).

Yes.

>>> - Section 4. at the end where it is discussed about using multiple 
>>> locator pairs at the same time when sending traffic. Should 
>>> asymmetric routing be mentioned and discussed in some detail. It is 
>>> not mentioned in RFC 5206 other than as a experimental curiosity. 
>>> Hmm, how about separating control messages to their own link and data 
>>> to another (mindfart)?
>>
>> The abstract says:
>>
>> The focus of the extensions in this document is on fault-tolerance 
>> with *symmetric* locator pairs, and load-balancing is also discussed.
>>
>> To be honest, the asymmetric routes would be just too much to handle 
>> for now. The draft is still sketchy here and there.
>>
> 
> Then there should be a note in the section 4 that ties this into 
> symmetric routes. Just as a reminder.

Ok.

>>> - Section 4. last paragraph "SPI value value", double value two times 
>>> in the paragraph.
>>>
>>> - The paragraph needs clarification on the SPI usage.
>>
>> Where, more explicitly, or everywhere?
>>
> In overall that paragraph needs some editing in my opinion. Like the 
> "Each end-host conveys the available locator
>    set information to the peer in a separate UPDATE message." should 
> state that this is also per interface.
> 
> Waiting for the next preversion. I'll send more comments if something 
> comes up.

Ok, thanks.

From: samu.varjonen at helsinki.fi (Varjonen Samu)
Date: Fri, 07 Nov 2008 13:58:50 +0200
Subject: [Hipsec-rg] Some comments on the draft-melen-hip-nat-mm-00
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Miika Komu wrote:
> Varjonen Samu wrote:
> 
Included only the ones that had more discussion...

> 
>> - Section 4. start about the locator reachability status. RFC 5206 
>> defines two state for the address, ACTIVE and UNVERIFIED. Would these 
>> reachability related ones be actually new address states and be 
>> somewhere between ACTIVE and UNVERIFIED?
> 
> No, they are the same states as in RFC5206.
> 
So the locator reachability status is just some implementation specific 
local value stored with the locator pair, something like local priority 
(priority as in type 2 locator).

>> - Section 4. at the end where it is discussed about using multiple 
>> locator pairs at the same time when sending traffic. Should asymmetric 
>> routing be mentioned and discussed in some detail. It is not mentioned 
>> in RFC 5206 other than as a experimental curiosity. Hmm, how about 
>> separating control messages to their own link and data to another 
>> (mindfart)?
> 
> The abstract says:
> 
> The focus of the extensions in this document is on fault-tolerance with 
> *symmetric* locator pairs, and load-balancing is also discussed.
> 
> To be honest, the asymmetric routes would be just too much to handle for 
> now. The draft is still sketchy here and there.
> 

Then there should be a note in the section 4 that ties this into 
symmetric routes. Just as a reminder.

>> - Section 4. last paragraph "SPI value value", double value two times 
>> in the paragraph.
>>
>> - The paragraph needs clarification on the SPI usage.
> 
> Where, more explicitly, or everywhere?
> 
In overall that paragraph needs some editing in my opinion. Like the 
"Each end-host conveys the available locator
    set information to the peer in a separate UPDATE message." should 
state that this is also per interface.

Waiting for the next preversion. I'll send more comments if something 
comes up.

BR,
Samu

From: miika.komu at hiit.fi (Miika Komu)
Date: Wed, 05 Nov 2008 16:43:52 +0200
Subject: [Hipsec-rg] Some comments on the draft-melen-hip-nat-mm-00
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Varjonen Samu wrote:

Hi,

> Hi,
> 
> Some comments for the draft-melen-hip-nat-mm-00. I have had some offline 
> discussions about some of these issues with Miika Komu. First some 
> smaller nitpicks, typos and stuff then to bigger issues.

your comments will be addressed in the next preversion. I didn't include 
the comments here that I agree with, just the ones that deserve more 
discussion.

> - In section 3.1.1. it says
>    "First, the phone is already transmitting data over one active 
> interface. Then, the phone starts to use the other interface, but only 
> after the handover procedure has been completed over the other link." 
> This is a bit confusing. There is first the other interface and then 
> other link and the other interface is used after handover is completed 
> *over* the other link. Too many others. Does this mean that the initial 
> UPDATE traverses also through the other link. For me it would make more 
> sense in sending the initial UPDATE, with preferred bit saying that move 
> to the other link, through the active link. And then pause in traffic 
> and address verification and traffic flowing again when the SAs are 
> updated. Or is it so that the initial UPDATES are done per interface and 
> LOCATORs contain only addresses from that interface. But the main point 
> was that it was not totally clear what is happening.

Agree that the text is unclear, but isn't it irrevant which interface to 
use for the UPDATE as long as the path works? Remember that this is just 
a scenario, not section describing exact protocol flow diagrams.

And pausing is unnecessary in this particular scenario because it talks 
about simultaneous multihoming.

> - Section 3.2.1. last paragraph "The hot backup *may* cost more 
> because...". I would say it will always cost because you have to send 
> keepalives etc. Also in cases where you have to *pay* for the 
> connectivity this is not so nice feature, like 3/4G radio links as 
> backup links may be not what is wanted because its more expensive in 
> monetary means and in power consumption. So should this be corrected to 
> *will* and a mention on the 4G stuff as they were already used as example.

Some operators provide flat free and the keepalives etc don't really 
cost anything. Hence, I would keep the "may" there.

> . Section 3.3. second paragraph in the end it is mentioned HIP return 
> routability. NAT traversal draft does not mention this and RFC 5206 
> mentions this ones in section where "address verification" is discussed. 
> I know this is the same thing but return routability is taken from MIPv6 
> (?). So should this be clarified in section Terminology also?

The term address verification should be used.

> - Section 4. start about the locator reachability status. RFC 5206 
> defines two state for the address, ACTIVE and UNVERIFIED. Would these 
> reachability related ones be actually new address states and be 
> somewhere between ACTIVE and UNVERIFIED?

No, they are the same states as in RFC5206.

> - Section 4. monitoring connection and failure detection. I have 
> implemented and tested with heartbeats (ICMPv6) sent through the tunnel. 
> I think these heartbeats could be used as keepalives for the channel and 
> so on. I am not sure does the heartbeat issues inside or outside HAs 
> belong to this draft but had to mention this anyway.

Section 5.2 says:

Keepalive are send in periods of 20 seconds, but MUST be omitted if some 
other traffic (e.g.  ESP) occupies the corresponding transport-layer 
connection.

Nothing prevents the HIP daemon from periodically sending ICMPv6 
messages to the tunnel to avoid the STUN based keepalives to get 
triggered. After all, the HIP daemon is just an application running on 
the end-host.

The design team discussed this issue a while ago and the opinion was to 
avoid mentioning this explicitly. You can see this "hidden" information 
in both drafts.

> - Section 4. at the end where it is discussed about using multiple 
> locator pairs at the same time when sending traffic. Should asymmetric 
> routing be mentioned and discussed in some detail. It is not mentioned 
> in RFC 5206 other than as a experimental curiosity. Hmm, how about 
> separating control messages to their own link and data to another 
> (mindfart)?

The abstract says:

The focus of the extensions in this document is on fault-tolerance with 
*symmetric* locator pairs, and load-balancing is also discussed.

To be honest, the asymmetric routes would be just too much to handle for 
now. The draft is still sketchy here and there.

> - Section 4. last paragraph "SPI value value", double value two times in 
> the paragraph.
> 
> - The paragraph needs clarification on the SPI usage.

Where, more explicitly, or everywhere?

>Is it the ESP_INFO 
> old and new? If it is then how can it be set so that it does not mean 
> all locators in the following LOCATOR? If it has something to do with 
> type 2 locator it should be clarified.
>.. 
> OK, this was all I had to say about the draft on the first read. 
> Hopefully the comments are useful :)

Thanks for comments, I found them very useful!