Subject: [mobile-ip] Mipv6-ha-ipsec

From: "Greg O'Shea" <[email-masked]>
Date: Thu, 31 Oct 2002 17:57:04 -0000

On a first reading this looks like a helpful doc wrt examples and a
strawman for discussion, which is good. But I think it's premature to
talk about "last call" for this piece; I gather this is not longer the
intention so the attached queries may be premature in which case please
park them until the time is right. Anyway, from first reading I wonder
about the following:

1) Sect 5.1 shows ESP after HAO. This would appear to be incorrect if MN
and HA are using tunnel mode to protect their BU/BA - or that
configuration not allowed for some reason?

2) Sect 6 hyphen #17 (can't we number the paragraphs for ease of
reference?) seems to imply that *all* BU to HA should use alt-CoA "in
case ESP tunnel happens", in which case shouldn't the main draft should
say this too?  (Bad timing, I know.)

3) Are implementations expected to enforce Sect 6 hyphen #22? That would
require analysis of the SPD/SAD by the implementation - was that
intended?

4) Sect 7.2.1 presumably implementation could choose to config
protection on all traffic between MN and HA in which case the SPD
example is not definitive

5) Sect 7.2.1 and 7.2.3 the SAD could presumably say TUNNEL instead of
TRANSPORT

6) Sect 7 in general I think it needs to be made clear that these are
examples for illustrative purposes only. At least I assume that's the
case.

7) Sect 9 "we have chosen to require" sometimes the justification is
unclear e.g. wrt policy entries and virtual Ifs. Some of these seem like
implementation and admin considerations to me.

Greg

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 31 Oct 2002 10:43:35 -0800

hi Greg,

thanks for the comments.

> Greg O'Shea wrote:
> 
> 
> 1) Sect 5.1 shows ESP after HAO. This would appear to be incorrect if
> MN and HA are using tunnel mode to protect their BU/BA - or that

tunnel mode SA results in a 40 byte IPv6 hdr, which is 16 bytes
more than the 24 bytes for destination options header containing
HAO.

but you are right. somebody could still use tunnel mode ESP SA
to send MN - HA BUs. we shouldnt prohibit that.

> case ESP tunnel happens", in which case shouldn't the main draft
> should say this too?  (Bad timing, I know.)

its already there in draft 19. section 11.7.1 of
http://people.nokia.net/charliep/txt/mobilev6/mobilev6.txt

    -  The care-of address for the binding MUST be used as the Source
       Address in the packet's IPv6 header, unless an Alternate Care-of
       Address mobility option is included in the Binding Update.  This
       option MAY be included when the mobile node so desires, and
       MUST be included if the mobile node cannot be assured that the
       IPsec AH protocol is used to secure the Binding Update.  The ESP
       protocol will not be able to protect care-of addresses in the
       IPv6 header.  Mobile IPv6 implementations which are unaware of
       how IPsec secures their messaging will therefore need to use the
       Alternate Care-of Address option.

> 3) Are implementations expected to enforce Sect 6 hyphen #22? That
> would require analysis of the SPD/SAD by the implementation - was that
> intended?

didnt understand this. can you explain a bit more?

> example is not definitive

this falls under a generic VPN case where all traffic between 
MN and HA goes through an IPsec tunnel. Francis Dupont wanted 
to include that in this draft. but after some discussion we 
concluded that there is more to this than just giving another 
example. Gabriel decided that we should look at this seperately.

but you are right. you can configure an SPD entry where all traffic
goes through the IPsec tunnel. it is just not documented in this
draft.

> 5) Sect 7.2.1 and 7.2.3 the SAD could presumably say TUNNEL instead of

it could.

> examples for illustrative purposes only. At least I assume that's the

okay. 

the main idea behind this draft was to explain how IPsec could 
be used to secure MIPv6 messages. and also we had to keep it 
simple. we didnt want to document all possible ways of using
IPsec with MIPv6.

> unclear e.g. wrt policy entries and virtual Ifs. Some of these seem
> like implementation and admin considerations to me.

it was difficult writing this section. any ideas to improve it
will be appreciated. ofcourse, text would be nice :-)

regards
Vijay