headers
Shinta Sugimoto | 1 Sep 2005 04:25
Picon

Re: comments/questions on draft-ieft-mip6-ikev2-ipsec-02.txt

Hello Francis,

On Wed, 31 Aug 2005 16:49:43 +0200
Francis Dupont <Francis.Dupont <at> enst-bretagne.fr> wrote:

>  In your previous mail you wrote:
> 
>      o  The home agent and mobile node MUST have equivalent settings of
>         security policy in terms of granularity of upper layer protocol
>         specified in the traffic selector.
>    
> => there was a long discussion about SPD mismatch between IKE peers
> in the IPsec mailing list. It seems the TS exchange helps to detect
> this kind of problems but IMHO even it should be common sense we can
> repeat the policies at each side must match.
> (PS: TSs are not enough, for instance they don't always show if a
> SA pair can be shared... IMHO their indications are mainly negative,
> and of course they never repair misconfigs).

OK. TS negotiation seems to be (to some extent) helpful to detect the
mismatch of security policy between the peers.

>    - Section 6.1.2, I found that some of the selector information does
>      not contain src addr, dst addr (or both).  Is there any specific
>      reason for this ? In addition, I found description of inner src/dst
>      addr information as a part of SPD entry but is it needed ?
> 
> => the inner addresses are part of the selectors (if the abstract
> syntax for SPD entries was used, this kind of questions would be
> avoided).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shinta Sugimoto | 1 Sep 2005 05:15
Picon

Re: comments/questions on draft-ieft-mip6-ikev2-ipsec-02.txt

Hello Vijay,

On Wed, 31 Aug 2005 15:45:09 -0700
Vijay Devarapalli <vijayd <at> iprg.nokia.com> wrote:

> Shinta Sugimoto wrote:
> > Hello,
> > 
> > I read draft-ieft-mip6-ikev2-ipsec-02.txt and had following
> > comments/questions.  I support this draft and think it's useful.
> > 
> > Technical Comments:
> > 
> > - Basically I agree that removal of dependency on per-interface SPD
> >   entry is a good thing which can be achieved by having MH type in
> >   the traffic selector.  But I see concern about interoperability
> >   issue which may come up when the security policy settings of the
> >   mobile node and home agent are slightly different.  For instance,
> >   suppose if the home agent does not support RFC2401bis and sets
> >   only MH(135) in the protocol field while the mobile node supports
> >   RFC2401bis and specifies MH type in its selector of the SP entry.
> >   Obviously such operation will fail.  The mobile node will fail to
> >   receive IPsec tunneled mobility signals (e.g. BA or CoTI) from its
> >   peer who is also a mobile node.  This problem was seen in the past
> >   interop event.  So, I would suggest to add some texts in Section
> >   4.3 to avoid having interoperability problem.
> 
> I dont have anything to add to what Francis said. we can't do
> anything about this.
>
(Continue reading)

Permalink | Reply | 9 comments |
headers
Richard Han | 1 Sep 2005 01:40
Picon
Favicon

[Securecomm-cfp] CFP IEEE/CreateNet SecureComm, Sept 5-9, Athens, Greece

Dear Colleague,

  Please find attached the call for participation for the First
  IEEE/CreateNet International Conference on Security and Privacy for
  Emerging Areas in Communication Networks (SecureComm 2005) to be held
  in Athens, Greece from Sep. 5-9, 2005.

  The conference program consists of 32 full papers and 20 short
  papers, keynote and invited talks, and a panel. In addition, there
  are four workshops on related topics. The complete information is
  available on the website: www.securecomm.org

  Note that Early Conference Registration Ends August 25, 2005!
  Discounted Hotel Reservation Rates end September 1, 2005.

  We apologize if you receive multiple copies of this message. Please
  feel free to distribute this to colleagues who might be interested.

regards,

SecureComm 2005 Organizing  Committee

    ***************************************************************
			CALL FOR PARTICIPATION

       First IEEE/CreateNet International Conference on Security
        and Privacy for Emerging Areas in Communication Networks

        Athens, Greece / Hotel Amarilia / 5 - 9 September, 2005
			  www.securecomm.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
admin | 1 Sep 2005 22:23

[issue24] Mobile IPv6 and Firewalls: Problem statement


New submission from admin <roundup-admin <at> mip4.org>:

Review comments by Spencer Dawkins (Gen-ART)

Background for those on the CC list, who may be unaware of GenART:
GenART is the Area Review Team for the General Area of the IETF.  We
advise the General Area Director (i.e. the IETF/IESG chair) by
providing more in depth reviews than he could do himself of documents
that come up for final decision in IESG telechat.  I was selected
as the GenART member to review this document.  Below is my review,
which was written specifically with an eye to the GenART process, but
since I believe that it will be useful to have these comments more
widely distributed, others outside the GenART group are being copied.

Intended status: Informational

Summary - this document is very close to being ready for publication as 
Informational.

I don't believe that Gen-ART reviews for Informational documents need to 
say much more than this, but, since I'm typing...

- The document is clearly written and well-organized. Other reviewers 
might push back on the breezy English style, but I like it.

- The first time there's a clue that firewalls are problematic for 
NON-mobile users is in the Conclusion:

   Current firewalls may not only prevent route optimization but may
(Continue reading)

Permalink | Reply | 0 comments |
headers
Basavaraj Patil | 1 Sep 2005 23:02

[issue25] Discuss Comments by Bill Fenner


New submission from Basavaraj Patil <basavaraj.patil <at> nokia.com>:

Throughout the document, I find myself confused about whether a section is
talking about a system with Mobile-IP implemented in the kernel.  For example,
3.2.1 says

  The received ancillary data object for Home Address destination
  option SHOULD contain the Care-Of-Address of the mobile node.
...
  Note that whether or not these new APIs are used, the senders home
  address is contained in the source address

However, if the kernel doesn't implement Mobile-IP, then the HA option will have
the HA, and the IP source address will be the COA, right?

Another example is:
    For TCP data packets with Home Address destination option may be
    used with "sticky" option for all transmitted packets. However,
    at this point, it is unknown why an application  would want to
    set Home Address option or Route Header Type 2 extension header
    along with its data packets as Mobile IPv6 protocol takes care of
    them transparently at the protocol stack.
[written assuming that there's a mip6 stack]; vs. later in the document,
      However, some
  embedded software implementations may require to implement the IPv6
  packet processing/sending at the user level; those implementations
  may choose to provide API spport for sending home-address option
  at the application layer.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Basavaraj Patil | 1 Sep 2005 23:03

[issue26] Discuss comments by Bill Fenner (2)


New submission from Basavaraj Patil <basavaraj.patil <at> nokia.com>:

I wonder about the need for

    int inet6_rth_gettype(const void *bp);

The advanced API gives examples of, e.g., accessing rth->ip6r_segleft directly
in an ip6_rthdr; why not access rth->ip6r_type directly too?

Related to Sam's comments:
        uint8_t          ip6oha_addr[16];  /* Home Address */
It'd be really nice if this could be a struct in6_addr, but presumably it's this
way because struct padding gets badly in the way given the 8n+6 alignment of
this option.  It'd be nice if somehow the struct could contain the 6 so that you
could use the aligned struct in6_addr.  Is this the first struct defined for an
option with alignment requirements like this?

Moving the HA option automatically is a little weird; I'm uncomfortable about
asking the kernel to parse the IPV6_DSTOPTS and move an HA option if found
(especially with an 8n+6 padding, if there are other options packed in the
IPV6_DSTOPTS things could get weird) - if this is a one-off then I'm inclined to
let it go, but could there be another use for placing options between Routing
and Frag headers?  In which case, would it be better to define another
IPV6_???DSTOPTS option?

----------
category: Editorial
draft: draft-ietf-mip6-mipext-advapi
messages: 92
(Continue reading)

Permalink | Reply | 0 comments |
headers
Basavaraj Patil | 1 Sep 2005 23:05

[issue27] Discuss comment by Bert Wijnen


New submission from Basavaraj Patil <basavaraj.patil <at> nokia.com>:

citation/reference problems:
  !! Missing citation for Informative reference:
  P020 L028: [3]    Deering, S., Hinden, R., "Internet Protocol, Version 6

  !! Missing Reference for citation: [RFC-3493]
  P004 L038:    body, such as has been done with the Basic API [RFC-3493].

  !! Missing Reference for citation: [RFC3245]
  P004 L040:    [RFC3245], such standardization would make sense only if

----------
category: Editorial
draft: draft-ietf-mip6-mipext-advapi
messages: 93
nosy: bpatil
priority: Should fix
status: No discussion
title: Discuss comment by Bert Wijnen

_________________________________________________
Mip6 issue tracker <tracker-mip6 <at> mip4.org>
<http://www.mip4.org/issues/tracker/mip6/issue27>
_________________________________________________
Permalink | Reply | 0 comments |
headers
Basavaraj Patil | 1 Sep 2005 23:07

[issue29] Comment by Russ Housley


New submission from Basavaraj Patil <basavaraj.patil <at> nokia.com>:

In section 7: s/man in the middle/man-in-the-middle/

  Reference [1] contains two dates.  I believe the second one should
  be deleted.

  Section 11 should be deleted prior to publication.

----------
category: Editorial
draft: draft-ietf-mip6-mipext-advapi
messages: 95
nosy: bpatil
priority: Should fix
status: No discussion
title: Comment by Russ Housley

_________________________________________________
Mip6 issue tracker <tracker-mip6 <at> mip4.org>
<http://www.mip4.org/issues/tracker/mip6/issue29>
_________________________________________________
Permalink | Reply | 0 comments |
headers
Basavaraj Patil | 1 Sep 2005 23:07

[issue28] Gen-Art review comments


New submission from Basavaraj Patil <basavaraj.patil <at> nokia.com>:

>From Gen-ART review by Mark Allman:

  + Section 1: "mainly target user-level" --> "mainly targets
    user-level"

  + Section 1: While the document is fine without specifying error
    handling it might be nice to add a note that this is not good
    practice.

  + Section 1: "deployed among implementations, it" --> "deployed, it"

----------
category: Editorial
draft: draft-ietf-mip6-mipext-advapi
messages: 94
nosy: bpatil
priority: Should fix
status: No discussion
title: Gen-Art review comments

_________________________________________________
Mip6 issue tracker <tracker-mip6 <at> mip4.org>
<http://www.mip4.org/issues/tracker/mip6/issue28>
_________________________________________________
Permalink | Reply | 0 comments |
headers
Basavaraj Patil | 1 Sep 2005 23:09

[issue31] Comment by Sam Hartman


New submission from Basavaraj Patil <basavaraj.patil <at> nokia.com>:

ANSI C does not guarantee strict alignment of structs.  You can design
a struct that can hold all the fields of a packet, but you cannot
design a struct that if viewed as a buffer will represent a packet.  I
have included a review in the tracker that describes at least one case
where the structs in the draft do not actually align to wire formats.

The draft appears to believe that the structs do correspond to wire formats in
two places.  First, section 4 seems to imply that you can receive the mobility
header using a raw socket and use the structs in section 2.

Secondly, the description of section 2 claims that the structs do
correspond to wire formats.

At a minimum, the API needs to clarify the assumptions it makes.  In
addition, the document needs to clearly indicate which functions from
the advanced API return structs from section 2 and which functions
return bits from the wire.

----------
category: Editorial
draft: draft-ietf-mip6-mipext-advapi
messages: 97
nosy: bpatil
priority: Should fix
status: No discussion
title: Comment by Sam Hartman
(Continue reading)

Permalink | Reply | 0 comments |

Gmane